A WireMock simulation of U.S. Bank's REST API — covering payee token creation, retrieval, validation, deletion, and bulk upload and download.
A shared instance of this template runs on a public endpoint — call it right now from curl, an SDK, or an AI agent. Responses are fixed examples and behavior can't be changed; rate limits apply.
Jump to the endpoints ↓Run this template as a mock API in WireMock Cloud for a private instance you control — edit stubs, add stateful scenarios, use dynamic response templating, and inspect requests in the log.
Open in WireMock Cloud (free) →Live sandbox · no signup, no API key
A running WireMock Cloud instance of this template, callable right now from a terminal, a script, or an AI agent.
Endpoints
POST Bulk upload payee token file
curl -s -X POST 'https://vkdm7.wiremockapi.cloud/payees/bulk-upload' \
-H 'Content-Type: application/json' \
-d '{}'GET Bulk download payee token file
curl -s -X GET 'https://vkdm7.wiremockapi.cloud/payees/bulk-download'DELETE Delete payee
curl -s -X DELETE 'https://vkdm7.wiremockapi.cloud/payees/your-payeeAccountToken'Spec catalog — Payee Token+ API (1.3.0) · 6 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /payees | Create a Payee Token. |
| DELETE | /payees/{payeeAccountToken} | Delete a payee token by passing in the payee account token. |
| GET | /payees/{payeeAccountToken} | Retrieve payee details by passing in payee account token. |
| GET | /payees/{payeeAccountToken}/validate | Validate if the payee token is active by passing the payee account token. |
| GET | /payees/bulk-download | Download a file containing payee tokens or payee data by documentId. |
| POST | /payees/bulk-upload | Upload a file to create or retrieve payees in bulk. |
Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.
Payee Token+ solves a data-hygiene problem: store one opaque token instead of a payee's bank details, then pay over any rail by quoting it. The mock renders that promise concretely. Creating a payee returns a freshly minted token — a UUID under a "1-" version prefix — repeated across six rail blocks in the response: ACH and RTP, Zelle, check, domestic and international wire, and card. One token, every rail. Retrieval resolves the tokens this sandbox has issued and answers Payee not found for the rest, and what a resolved token returns is the full de-tokenized record: routing and account numbers for ACH, a Zelle alias, a postal address for checks, and international wire coordinates down to an IBAN and correspondent-bank identifiers — the sensitive payload the token exists to keep out of your database.
Only retrieval. GET on a token is gated on the mint registry — issued tokens expand into the payee record, anything else gets the 404 — while the validate and delete routes acknowledge whatever token the path carries, reporting ACTIVE and Deleted respectively for values that were never issued. The split is useful to know when you write assertions: existence tests belong on the GET, and the other two verbs verify request contracts, not registry state.
Every create mints a distinct token, but they all expand to the same canonical payee — the token is unique, the de-tokenized detail is shared fixture data. Assert on the mapping (the token you quote is the token whose record returns) rather than on per-payee field differences, and populate a private WireMock Cloud copy when tests need distinguishable payees per token.
A base64 field that decodes to a small binary blob opening with a PNG signature rather than rows of payee data — treat it as opaque bytes that exercise your decode-and-store path, not as a parseable export. Its upload counterpart acknowledges any submission with 202 and the same recorded documentId every time, so chain upload-then-download by wiring the id through rather than asserting on its value.
It's the same alias the Disbursements via Zelle template enrolls for its recipient persona, so the two sandboxes can play both halves of one flow: tokenize a payee here, disburse to the matching alias there. For payouts where the recipient chooses the rail themselves instead of the payer storing coordinates, the Payee Choice template models that inversion.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.