A WireMock simulation of U.S. Bank's REST API — covering RTP transfers with same-day ACH and wire fallback, plus transfer status reads.
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 Submit transfer
curl -s -X POST 'https://227ml.wiremockapi.cloud/transfers' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — PaySmart (2.0.0) · 2 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /transfers | Initiate an RTP transaction with fallback as Same day ACH or wire transfer. |
| GET | /transfers/{transactionID} | Retrieve status and details of a Paysmart transfer. |
Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.
PaySmart's pitch is that you request an instant payment and the bank finds a way to deliver it — RTP first, same-day ACH or wire when it can't — and the sandbox drops you straight into the fallback story. Every submission mints an RTP-prefixed transaction id, then acknowledges with deliveryMethod WIRE, status WIRE_SCHEDULED, and a warning that the wires cutoff has passed: an instant-payment request that has already cascaded two rungs down and slipped to the next business day. The sandbox keeps a ledger of the ids it mints — status reads resolve them and turn away invented ones with a 404 — and the resolved detail is a payment biography: payer, ultimate payer, payee, and payee bank in full, wire IMAD and PAR references beside ACH company detail, a notification of change, and a return reason, all on one record.
That's the product working as designed — fallback is the feature. When RTP can't complete a payment, PaySmart re-routes it down the rail hierarchy, and the fixture pins the outcome at the bottom rung to force the hard case through your client: the payment will arrive, but not instantly, and not today. Code that promises recipients real-time delivery based on the endpoint it called, rather than the deliveryMethod field it got back, is what this acknowledgment exists to catch.
It doesn't — submissions without one sail through, and resubmitting the same GUID mints a brand-new transaction id rather than replaying the first response. So the public instance verifies that your client sends the field, not that duplicates are suppressed; genuine replay protection — same GUID, same response, no second transfer — is a scenario to build in a private WireMock Cloud copy where state is yours to script.
A clean 404 with a transfer-not-found error body. Reads are checked against the ids this sandbox has actually issued, which makes the submit-capture-poll loop testable for real: initiate, keep the returned id, resolve it, and confirm your error path on a fabricated one — four assertions, no setup.
For a rail-hopping product, yes. A payment that entered as RTP and settled as a wire — or fell back to ACH and later came back R01 — accumulates artifacts from every rail it touched, and the fixture presents that full accumulation so reconciliation parsers map each block. When you need one rail in isolation, the library splits them: the Wire Transfers template owns the Fedwire leg, and the Instant Payments template owns RTP and FedNow without any fallback behind them.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.