API template library

U.S. Bank Payee Choice mock API and live sandbox

A WireMock simulation of U.S. Bank's REST API — covering payee enrollment invitations and search, batch payment submission, and payment status retrieval.

Vendor
U.S. Bank
Functionality
Payee enrollment and payments
Spec version
2.2.0
Endpoints
6
Stubs
8
Protocol
REST
Validation
AI-validated Before publication, an AI agent exercised these endpoints against the real U.S. Bank API through WireMock's recording proxy, and the recorded traffic was used to verify each stub's request and response shapes.

Live sandbox · no signup, no API key

US Bank Payee Choice

A running WireMock Cloud instance of this template, callable right now from a terminal, a script, or an AI agent.

Base URL
https://kv670.wiremockapi.cloud

POST Send payee invitation

curl -s -X POST 'https://kv670.wiremockapi.cloud/payees/invitations' \
  -H 'Content-Type: application/json' \
  -d '{}'

POST Search payees

curl -s -X POST 'https://kv670.wiremockapi.cloud/payees/search' \
  -H 'Content-Type: application/json' \
  -d '{}'

POST Post payment

curl -s -X POST 'https://kv670.wiremockapi.cloud/payments' \
  -H 'Content-Type: application/json' \
  -d '{}'
Method Path Summary
GET /payees/{payeeID} Retrieve payee by payeeID.
POST /payees/invitations Initiate a payee enrollment invitation or enrollment reminder.
POST /payees/search Search for payee records and invitation enrollment status.
POST /payments Submit a payment instructions request.
GET /payments/{paymentID} Retrieve a payment by paymentID.
POST /payments/search Search list of payments.

Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.

What's inside the Payee Choice template

Payee Choice is disbursement with the method decision delegated to the recipient — the payer submits instructions, the payee follows an invitation link and picks how the money should arrive. The sandbox keeps both halves of that story in one persona: John Smith of Liberty Mutual, forever mid-enrollment, his records stamped ENROLLMENT_PENDING with the invitation URL attached. Submitting payments returns the template's most instructive body, a batch envelope reporting 500 instructions accepted, 100 rejected, and 600 in total, each listed instruction carrying its own status pair — PRE_PROCESSING atop an ENROLLMENT_REQUIRED substatus — plus an embedded warnings block, so per-item and batch-level outcomes arrive in a single response.

  • Payee onboarding — enrollment invitations and reminders with the hosted preference-page URL
  • Payee lookup — criteria search returning enrollment status and stored payment preferences
  • Payment submission — batch instructions whose acknowledgment mixes counts, statuses, and warnings
  • Payment tracking — by-id retrieval and search across submitted instructions

Frequently asked questions

That acceptance is not a scalar. A single submission response here contains a batch verdict, per-instruction statuses, a substatus explaining what blocks progress, and a warning with its own code and help link — four layers a robust client records separately. The counts themselves are fixture constants, so reconcile your submitted rows against the instruction list, not against the arithmetic.

Because in this product one drives the other: an instruction cannot leave PRE_PROCESSING while its payee still owes an enrollment decision, so every payment record embeds the payee's state and invitation URL alongside its own. Dashboards get both dimensions from one call — and the fixture's permanent pending-enrollment keeps the dependency visible in every test.

Through search. The payee-by-id route answers resource-not-found for every identifier, including the payee id the payment fixtures reference, so there is no reachable happy path on that route in the public sandbox — an honest gap worth knowing before you wire a detail screen to it. Payment-by-id, in contrast, resolves its canonical id with the full payee-and-payment record.

Choice of rails. Here the payee decides — ACH, card, whatever the preference page offers — and records carry a paymentType field reflecting it. The Disbursements via Zelle template commits to one network up front and organizes everything around alias enrollment instead. Payout platforms often integrate both, which is exactly when the two sandboxes earn their keep side by side.

Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.