A WireMock simulation of U.S. Bank's REST API — covering debit-card transfer initiation, status retrieval, and transaction search.
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 Initiate credit transfer
curl -s -X POST 'https://rqe0j.wiremockapi.cloud/transfers' \
-H 'Content-Type: application/json' \
-d '{}'POST Search credit transfers
curl -s -X POST 'https://rqe0j.wiremockapi.cloud/transfers/search' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Push to Card (1.2.0) · 3 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /transfers | Initiate a transfer to a domestic debit card. |
| GET | /transfers/{transactionID} | Retrieve status and details of a push to card transaction. |
| POST | /transfers/search | Find the card transactions matching the search criteria. |
Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.
Push to card is the rail for getting money onto a consumer's debit card in near real time — insurance claims, gig-economy earnings, marketplace payouts — and this compact template captures its three moves: initiate a transfer, look one up, and search the ledger. The intake is generous and immediate: any submission returns 200 with a freshly minted UUID transaction id, an empty warnings array, and a clientDetails field echoed as an empty string. The read side is strict to the point of austerity, and knowing that before writing tests is the difference between a productive hour and a confusing one: no transaction id resolves on the status route — minted ones included — and the search answers a well-formed empty page, total count zero, whatever criteria it receives. This sandbox verifies the submission contract and the empty-state and miss branches; the found branch is yours to stub.
Initiation mints ids without registering them anywhere the lookup can see, so every retrieval — minted id or invented — draws the gateway's URI-not-found envelope, code 404.2567.3452, with its developer-portal help link. Poll-based payout flows should therefore be tested here for their miss handling and timeout ceilings, and pointed at a private WireMock Cloud copy for the delivered / pending / failed status ladder.
The first render. Payout dashboards meet the zero-transaction state on day one of every new program, and this fixture serves it with intact paging metadata — page one, count zero — so empty-state UI, disabled pagination, and no-results messaging can be verified without contriving a filter that matches nothing. Populated search pages, like statuses, are stub material for your own copy.
No — bodies from empty JSON to fully specified transfers earn the same acknowledgment, and nothing inspects the PAN. Keep real card numbers out of the public sandbox on principle, and treat request-side validation (Luhn checks, network eligibility, amount ceilings) as production-gateway behavior to simulate with 4xx stubs privately.
By what the sender must know. Here the payer holds the recipient's debit card credentials and pushes directly to them; the Disbursements via Zelle template needs only an email or phone alias and inserts an enrollment handshake before money moves. Payout platforms usually offer both, choosing per recipient — which makes the two sandboxes a natural pair for testing rail-selection logic.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.