A WireMock simulation of U.S. Bank's REST API — covering payment instructions, virtual card management, authorizations, and remittance notices.
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 Create card
curl -s -X POST 'https://05q2y.wiremockapi.cloud/cards' \
-H 'Content-Type: application/json' \
-d '{}'PATCH Modify card by cardID
curl -s -X PATCH 'https://05q2y.wiremockapi.cloud/cards/your-cardID' \
-H 'Content-Type: application/json' \
-d '{}'POST Close card
curl -s -X POST 'https://05q2y.wiremockapi.cloud/cards/your-cardID/close' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Virtual Card Payments (2.6.0) · 16 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /cards | Create a virtual card. |
| GET | /cards/{cardID} | Retrieve virtual card information. |
| PATCH | /cards/{cardID} | Modify a virtual card. |
| GET | /cards/{cardID}/authorizations | Return authorizations for this card within a date range. |
| POST | /cards/{cardID}/cancel | Cancel a virtual card. |
| POST | /cards/{cardID}/close | Close a virtual card. |
| GET | /cards/{cardID}/realtime-credit-details | Retrieve available credit balance detail for the virtual card. |
| POST | /cards/{cardID}/remit | Send a remittance notice. |
| GET | /cards/{cardID}/transactions | List all transactions for this card. |
| POST | /cards/{cardID}/transactions/search | Return transactions for this card matching the search criteria. |
| POST | /payments | Create a new payment. |
| GET | /payments/{paymentID} | Retrieve payment information. |
| PATCH | /payments/{paymentID} | Modify a payment. |
| POST | /payments/{paymentID}/cancel | Cancel a payment. |
| POST | /payments/{paymentID}/close | Close a payment. |
| POST | /payments/{paymentID}/send-notification | Send an email or fax notification. |
Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.
The template runs two live registries side by side. Creating a payment mints a stored instruction — buyer, supplier ACME CO, PO number, amount, status OPEN — with a single-use virtual card embedded in the body, and that record is genuinely yours to mutate: PATCH a new amount and every later read reports it, cancel and the status flips to CANCELED for good. Creating a card mints the second kind of record, and its validity window is computed at request time — effectiveStart is today's date, expiry thirty days out — so date-sensitive card logic always sees a current window rather than a stale fixture. Ids you never created, in either registry, draw the numbered does-not-exist envelope.
Yes — modifications are written into the stored record, not just echoed. A reconciliation test can create a payment, PATCH the amount, cancel it, and verify all three effects through subsequent GETs. That makes this one of the few sandboxes in the library where an update-then-verify integration test passes for the right reason.
The embedded virtualCard is part of the payment fixture, not an entry in the card registry — only cards minted through the card-create route resolve there. Code that extracts the card id from a payment and dereferences it needs a private WireMock Cloud copy with that linkage stubbed, or should assert against the embedded object directly.
Assert relationships, not values. The mock stamps the window relative to the day of the request — start today, expiry a month out — so hard-coded date assertions rot overnight. Checks like "expiry falls after effectiveStart" or "the card is currently within its window" stay green indefinitely and match how the real API behaves.
It returns a bare 202 acknowledgment and stops there — no email, no fax, no callback. That is enough to test that your payables flow fires the notice at the right moment and handles the async accept; verifying notice content end-to-end requires the real gateway's delivery infrastructure.
When cards themselves are the product. Issuing cards to employees or customers, pushing them into digital wallets, and managing merchant category controls is the Card as a Service template's domain — this one models cards that exist to settle a specific payable and then disappear.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.