A WireMock simulation of U.S. Bank's REST API — covering alias enrollment checks, payment initiation and retries, cancellation, name verification, and payment 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 payment
curl -s -X POST 'https://q4e7e.wiremockapi.cloud/payments' \
-H 'Content-Type: application/json' \
-d '{}'PATCH Update/retrieve failed payment
curl -s -X PATCH 'https://q4e7e.wiremockapi.cloud/payments/your-paymentInstructionID' \
-H 'Content-Type: application/json' \
-d '{}'POST Search payments
curl -s -X POST 'https://q4e7e.wiremockapi.cloud/payments/search' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Disbursements via Zelle B2C API (1.3.0) · 9 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /aliases/enrollment-invitation | Send Enrolment invitation up to 50 recipient's aliases. |
| POST | /aliases/search | Check up to 50 recipient's alias enrollment status. |
| POST | /payments | Initiate a payment through Zelle. |
| PATCH | /payments/{paymentInstructionID} | Retry a payment failed due to insufficient funds. |
| POST | /payments/cancel | Cancel a previously requested payment by PaymentID. |
| POST | /payments/enrollment-invitation | Send enrollment invitation to recipients for pending payments. |
| POST | /payments/name-verification | Allow or reject a payment that is pending name verification approval. |
| POST | /payments/retrieve | Retrieve payment details by paymentID. |
| POST | /payments/search | Retrieve payment details based on 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.
The template models the business-to-consumer payout problem: a company owes money to a person it knows only by email or phone alias. Its cast is one recipient — Abe Lincoln, alias abe@gmail.com, enrolled in-network at U.S. Bank — and one canonical payment, an instant-priority dollar with the memo "Payment for Lunch" and a fifteen-day expiration window. Initiating a payment returns that payment's instruction id inside a 200 that also carries a warning: the transaction arrived after cutoff and will process the next business day. The resting status everywhere is PENDING_ENROLLMENT, which is the state B2C disbursement integrations spend most of their logic on — money waiting for a recipient who hasn't finished signing up.
Send the canonical instruction id in a field named paymentID — that exact field name is what the stub matches on, and bodies that carry the same value under paymentInstructionID draw the payment-not-found error instead. Since initiation hands you PI5465865494968 in its response, the create-then-retrieve chain works as long as your client maps the id into the right request field, which is precisely the mapping worth testing.
Because cutoff times are a fact of disbursement life, and the fixture bakes one in: code 200.xxx.2100, submitted after the processing window, funds move the next business day. Payout code that only branches on HTTP status will read this as pure success and set the wrong expectation for the recipient — surfacing the delay from the warnings array is the behavior this response exists to check.
Key your logic to the status enum and treat the message as display text. The fixture deliberately pairs the two faces of an idempotent invite — the send succeeded, and the recipient didn't need it — so clients that parse prose instead of codes get caught here. The alias-search route is the authoritative enrollment check, reporting ALIAS_ENROLLED for the persona.
A reflection contract: the instruction id you place in the path comes back as the paymentInstructionID of the response, with the canonical Zelle payment id and status beside it. That verifies your retry call is aimed at the right resource. Note there is no insufficient-funds state behind it — simulating the failure that precedes a retry takes error stubs in your own WireMock Cloud copy.
No — aliases and consumer enrollment make this a B2C surface. Supplier payouts where the payee picks a payment method and enrolls through an invitation link are modeled in the Payee Choice template, which trades Zelle's alias directory for payee records and batch payment instructions.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.