API template library

U.S. Bank Instant Payments mock API and live sandbox

A WireMock simulation of U.S. Bank's REST API — covering credit transfer initiation and tracking, requests for payment, and RFP cancellation on the RTP and FedNow networks.

Vendor
U.S. Bank
Functionality
Instant transfers and RFPs
Spec version
2.3.0
Endpoints
5
Stubs
7
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 Instant Payments

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

Base URL
https://w2l41.wiremockapi.cloud

POST Initiate credit transfer

curl -s -X POST 'https://w2l41.wiremockapi.cloud/credit-transfers' \
  -H 'Content-Type: application/json' \
  -d '{}'

PATCH Cancel request for payment

curl -s -X PATCH 'https://w2l41.wiremockapi.cloud/requests-for-payment/your-transactionID' \
  -H 'Content-Type: application/json' \
  -d '{}'

POST Initiate request for payment

curl -s -X POST 'https://w2l41.wiremockapi.cloud/requests-for-payment' \
  -H 'Content-Type: application/json' \
  -d '{}'
Method Path Summary
POST /credit-transfers Initiate an Instant Payments credit transfer Transaction.
GET /credit-transfers/{transactionID} Retrieve details of an inbound or outbound credit transfer.
POST /requests-for-payment Initiate an Instant Payments request for payment (RFP).
GET /requests-for-payment/{transactionID} Retrieve status and details of an RFP sent.
PATCH /requests-for-payment/{transactionID} Cancel an RFP transaction.

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 Instant Payments template

Both intakes — credit transfers and requests for payment — mint a fresh RTP-prefixed transaction id on every submission, and the sandbox remembers what it mints: retrieval resolves ids it has issued and answers a plain 404 for everything else, RTP-shaped or not. The detail bodies are where the fixture earns its keep. A credit transfer reads back as an inbound FedNow payment whose statusCode says In Process while its message reports a rejection for participant unavailability, code AG11 — two fields telling different stories on purpose. The RFP detail is a request that came back REJECTED with reason AC01, and the two fixtures share a thread: the credit transfer's originalRFPTransactionID is the very id sitting in the RFP detail's requestDetails block, so the pay-in-response-to-a-request relationship is traceable across routes.

  • Credit transfers — initiation with per-call minted ids and full inbound-payment detail retrieval
  • Requests for payment — RFP submission and status reads covering the rejected-request case
  • RFP cancellation — the PATCH route that confirms a COMPLETED cancellation for the id addressed
  • Idempotency handling — a replay warning built into every intake acknowledgment

Frequently asked questions

The warning is welded into the acknowledgment — it appears whether or not the request carries an Idempotency-Key header, including keys nothing has used before. Instant-payment APIs lean hard on idempotent submission, and this fixture forces the replay branch through your code on every single call: a client that logs the warning, keeps the returned transactionID, and continues is doing exactly what production replay handling should do.

statusCode is the machine-readable truth; message and rejectReasonCode are context. The credit-transfer detail pairs them contradictorily so that any client parsing prose for state — or surfacing raw messages to end users as if they were status — fails visibly in test rather than in production. Branch on the enum, log the reason code, and treat the sentence as display material.

They describe one conversation. The RFP detail carries the request's transaction id inside its requestDetails block, and the credit-transfer detail names that same value as its originalRFPTransactionID — a payment answering a request for payment. Reconciliation code that joins the two record types on that field can be exercised against the sandbox without any setup.

Yes. The cancel route reflects whatever id sits in the path and confirms a completed cancellation with a fixed rfpCancellationID, with no registry lookup in front of it. That keeps the cancellation request contract testable in isolation; verifying that unknown ids are refused belongs in a private WireMock Cloud copy with a not-found stub added. For scheduled, high-value moves over Fedwire rather than the instant rails, the Wire Transfers template is the sibling to reach for.

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