A WireMock simulation of Chase JPMorgan's REST API — covering bank-provider discovery per market, Open Banking payment initiation with hosted payment links and QR codes, acknowledgment, and payouts.
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
GET List Providers - Germany (DE)
curl -s -X GET 'https://zez4d.wiremockapi.cloud/providers?market=DE'GET List Providers - United Kingdom (GB)
curl -s -X GET 'https://zez4d.wiremockapi.cloud/providers?market=GB'GET List Providers - Sweden (SE)
curl -s -X GET 'https://zez4d.wiremockapi.cloud/providers?market=SE'Spec catalog — Pay by Bank UK and EU API (2.0.8) · 6 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /payments | Initiate Payments |
| GET | /payments/{id} | Retrieve Payments |
| POST | /payments/{id}/acknowledge | Acknowledge Payments |
| POST | /payouts | Create Payouts |
| GET | /payouts/{id} | Retrieve Payouts |
| GET | /providers | List providers for a market |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
Every route in this UK-and-EU Open Banking surface answers — no dead stubs, no broken templates — and the center of it is a payment store that keeps what you send. A create needs only an Idempotency-Key header; the 202 merges your echoed request body with the server's contribution: a fresh UUID id, status NONE, acknowledged UNKNOWN, and the two hosted-checkout artifacts — a paymentLinkURL on J.P. Morgan's pay-direct page carrying your id as its payment_request_id, and a paymentQRCode URL whose final path segment is that same link base64-encoded. Retrieval returns the stored record with your amounts and creditor details intact, the acknowledge verb durably flips the record to ACKNOWLEDGED, and ids the store never issued draw a designed Resource Not Found body naming the offending path field.
Its presence is; its semantics aren't. Omit the header and both intakes answer a structured 400, code 10106, naming the missing header and its HEADER location — so the sandbox proves your client sends the key and survives the designed rejection when it doesn't. Resubmitting with the same key, though, mints a brand-new payment rather than replaying the first response. If your retry logic depends on true replay-safety, model same-key-same-response in a private WireMock Cloud copy; here, assert that the key goes out on every create.
Yes — this store keeps bodies, not just ids. Retrieval serves the stored record verbatim, original timestamps included, so assertions on your own amount, creditor block, and endToEndId hold on every later read, and an acknowledged flag flipped once stays flipped. That's the inverse arrangement of the Plaid Payment Initiation template, whose store honors ids but serves canonical bodies — pointing the same test suite at both is a quick way to check your assertions are aimed at the right layer.
Three, one institution each: DE resolves to Sparkasse Hegau-Bodensee — an embedded flow with password credentials, a regex-validated username field, and a German-language pattern error; GB to HSBC Kinetic — a redirect flow for business banking over Faster Payments; SE to Bink, a fictional krona institution with a masked PIN field. Omitting the market parameter draws the designed 400, code 10001; any other market falls through to WireMock's not-matched diagnostic. Telling those two responses apart matters: the first is API behavior your client must handle, the second just means no stub exists.
No — both are fixture data to parse and present, not pages to complete. What's testable is the plumbing around them: that your integration surfaces the link, renders the QR, and that the two agree — decoding the QR URL's final segment yields the payment link exactly. For the flow where a scannable code *is* the payment request — a payee presenting QR codes for others to pay — the Request to Pay via QR template models that product end to end.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.