Skip to content

Generate admin session-transfer and SSO posts

Four RemotePostFiller methods build admin-facing redirects to US Bank's administrative site: initiating a call-center session, searching for a payor, searching for a payment, and initiating an unregistered ("make payment") admin payment. Each assembles a set of name/value pairs specific to its flow and then routes them through a single shared admin post-filler that chooses between plain form fields and an encrypted single sign-on (SSO) payload based on configuration.

Field Value
Operation ID OP-EPAY-06
Trigger Caller invokes one of RemotePostFiller.FillAdminInitiateCallRemotePost, FillAdminPayorSearchRemotePost, FillAdminPaymentSearchRemotePost, or FillAdminMakePaymentRemotePost
Inputs Admin user ID (all flows); IUSBankUser and IPolicyInfoProvider (payor search); confirmation number and IPolicyInfoProvider (payment search); amount, payment type, and IPolicyInfoProvider (make payment)
Outputs The inRemotePost parameter populated in place with URL set to the admin session-transfer URL and either plain fields or AdminOrg/AdminToken/InitVect/EncData/EncKey/Signature SSO fields
Primary components RemotePostFiller.FillAdminInitiateCallRemotePost, FillAdminPayorSearchRemotePost, FillAdminPaymentSearchRemotePost, FillAdminMakePaymentRemotePost, FillAdminRemotePost, FillAdminSingleSignOnRemotePost, FillAdminNonSingleSignOnRemotePost, AdjustAdminUserID
Entry point Business\SAIF.Business.EPay.USBank\RemotePostFiller.vb

Steps

  1. Adjust the admin user ID. Every flow calls AdjustAdminUserID(inAdminUserID) first: in non-production environments, if the voluntary biller ID is TSV and the admin session-transfer URL contains uat, the user ID is swapped for the fixed test user saifuser01*; otherwise the given ID is used, padded with trailing g characters until it reaches a minimum length of 6 (BR-015).
  2. Initiate call — build values. FillAdminInitiateCallRemotePost builds a list containing AdminOrg and the adjusted UserName.
  3. Payor search — build values. FillAdminPayorSearchRemotePost builds a list containing AdminOrg, adjusted UserName, NavAction = SearchPayor, BillerGroupId, the biller ID resolved from inPolicyInfo.IsVoluntaryPolicy, and UserId set to the US Bank user's sequence number.
  4. Payment search — build values. FillAdminPaymentSearchRemotePost builds a list containing AdminOrg, adjusted UserName, NavAction = SearchPayment, BillerGroupId, the biller ID resolved from inPolicyInfo.IsVoluntaryPolicy, and the given ConfirmationNumber.
  5. Make payment — build values. FillAdminMakePaymentRemotePost builds a list containing AdminOrg, adjusted UserName, NavAction = UnRegPayment, BillerGroupId, and always the voluntary biller ID via GetBillerId(True) regardless of the policy's actual market, plus the resolved product code, policy number, truncated policy name, and amount formatted to two decimals (BR-018).
  6. Route through the shared admin filler. FillAdminRemotePost sets inRemotePost.URL to the admin session-transfer URL and branches on USBankCodes.IsAdminSingleSignOnAvailable (config flag USE_ADMIN_SINGLE_SIGN_ON).
  7. Non-SSO path. FillAdminNonSingleSignOnRemotePost adds every built key/value pair directly as a plain RemotePost input.
  8. SSO path — serialize the values. ConvertToPipeSeparatedString appends a DateTimeStamp (UTC, MMddyyyyHHmmss) if one is not already present, then joins all key/value pairs into a single key=value pipe-delimited string.
  9. SSO path — encrypt the payload. GetSSOData(pipeSeparatedValues) returns an AdminSingleSignOnData object carrying the initialization vector, encrypted data, encrypted key, and signature.**
  10. SSO path — populate the post. FillAdminSingleSignOnRemotePost adds AdminOrg, AdminToken, InitVect, EncData, EncKey, and Signature as RemotePost inputs, replacing the plain-field approach entirely.

Process flow

The following diagram visualizes the shared admin routing pattern across the four flows.

flowchart TD
    Start{Which admin flow?}
    Start -->|Initiate call| VInit[Build AdminOrg, UserName]
    Start -->|Payor search| VPayor[Build AdminOrg, UserName,<br>NavAction=SearchPayor, biller info]
    Start -->|Payment search| VPay[Build AdminOrg, UserName,<br>NavAction=SearchPayment, ConfirmationNumber]
    Start -->|Make payment| VMake[Build AdminOrg, UserName,<br>NavAction=UnRegPayment,<br>always voluntary biller ID]
    VInit --> Adjust[Adjust admin user ID]
    VPayor --> Adjust
    VPay --> Adjust
    VMake --> Adjust
    Adjust --> Route{SSO available?}
    Route -->|No| Plain[Add all values as<br>plain RemotePost inputs]
    Route -->|Yes| Serialize[Pipe-separate values;<br>add DateTimeStamp]
    Serialize --> Encrypt[Encrypt via GetSSOData]
    Encrypt --> SSO[Add AdminOrg, AdminToken,<br>InitVect, EncData, EncKey, Signature]
    Plain --> Done([RemotePost ready for<br>admin browser redirect])
    SSO --> Done

Failure and edge-case behavior

  • Admin user IDs shorter than 6 characters are padded with trailing g characters rather than rejected, so two different short IDs (e.g., one 5 characters, one 4) could collide if both happen to pad to the same 6-character result.*
  • The test-user substitution in AdjustAdminUserID only applies outside production when the voluntary biller ID is TSV and the admin URL contains uat; any other combination uses the caller-supplied ID unchanged (after padding).
  • FillAdminMakePaymentRemotePost always resolves the voluntary biller ID even for assigned-risk policies, because the assigned-risk biller ID is not configured for credit card payments (BR-018); this could misroute admin make-payment redirects if US Bank ever expects the assigned-risk biller ID for a given policy's admin context.*
  • The SSO encryption helper (GetSSOData/AdminSingleSignOnData) is not implemented in this library's source; its behavior and failure modes could not be confirmed from the traced code.**
  • Switching USE_ADMIN_SINGLE_SIGN_ON changes the entire payload shape (plain fields vs. encrypted SSO fields) for all four admin flows simultaneously; there is no per-flow override.

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • Business\SAIF.Business.EPay.USBank\RemotePostFiller.vb
  • Business\SAIF.Business.EPay.USBank\USBankCodes.vb