A WireMock simulation of Chase JPMorgan's REST API — covering Pix payment requests with QR payloads, payment links, revisioned updates, cancellation, bulk submission, and 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 Generate Payment Link
curl -s -X POST 'https://5e3gz.wiremockapi.cloud/payment-links' \
-H 'Content-Type: application/json' \
-d '{}'GET Retrieve Payment Links
curl -s -X GET 'https://5e3gz.wiremockapi.cloud/payment-links'POST Create Payment Request
curl -s -X POST 'https://5e3gz.wiremockapi.cloud/payment-requests' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Request to Pay via QR Code API (1.4.4) · 11 endpoints
| Method | Path | Summary |
|---|---|---|
| GET | /payment-links | Retrieve a List of Payment Links |
| POST | /payment-links | Generate a Payment Link |
| GET | /payment-links/{id} | Retrieve a Single Payment Link |
| POST | /payment-requests | Create a Payment Request |
| GET | /payment-requests/{id} | Retrieve the Details of a Single Payment Request |
| PUT | /payment-requests/{id} | Create a Payment Request by Client Id or Update a Payment Request |
| POST | /payment-requests/{id}/cancel | Cancel a Single Payment Request |
| POST | /payment-requests/bulk | Create Bulk Payment Requests |
| GET | /payment-requests/bulk/{id} | Retrieve Bulk Payment Request Details |
| PUT | /payment-requests/bulk/{id} | Update bulk payment request details |
| POST | /payment-requests/search | Retrieve a List of Payment Requests |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
This is J.P. Morgan's Brazilian Pix request-to-pay surface, and the payment-request store is properly alive. Creation answers 201 with an ETag, revision number zero, a 24-hour expiry, and a requestMethod block whose Pix EMV payload is assembled per call — the minted request id is templated into the br.gov.bcb.pix URL between the merchant "Sample JPM Client" and the city S. PAULO — and the store keeps whatever fields the create carried, custom amounts included. The lifecycle verbs behave like versioned records: an update increments revisionNumber and moves updatedAt while preserving createdAt, and cancellation flips the stored status to CANCELLED for every read that follows. Payment links and bulk submissions keep their own registries with the same read-your-writes contract, and every by-id route — get, update, cancel, across all three stores — has a dedicated JSON Not Found rather than a bare diagnostic.
Not with a Pix app. The EMV text is structurally convincing — correct field ordering, the live request id templated into its URL, BRL as currency 986 — but its declared field lengths drift from the actual values and the CRC is the same four characters on every payload, so a validating scanner rejects it; the accompanying image is a one-by-one pixel PNG despite an imageWidth of 400. What's genuinely testable is the pipeline: extracting the payload, rendering an image, and threading the request id through. Producing a scannable code means computing a real CRC over a corrected payload in your own WireMock Cloud copy.
Yes, and the asymmetry is instructive: create persists your body into the stored record, update does not — PUT advances the revision counter and the updatedAt stamp, then rewrites the record from its template, so the amount you changed never lands. Version-tracking logic (does my client bump and propagate revisions correctly?) tests cleanly; field-level update verification needs a private copy. Cancellation sits between the two: the status flip persists, but revision and updatedAt stay put.
The list and the by-id registry are separate layers. The list is a static one-entry fixture — whose own link id, notably, answers not-found when fetched directly — while ids minted through create resolve individually with their original creation timestamps. Search behaves the same way on the request side, always returning the canonical CNPJ-creditor record whatever criteria you post. Enumerate with ids you minted; leave list-driven reconciliation to a private copy with real collection stubs.
This is the payee-presents model: the merchant mints a request and shows a code, and payment happens in the payer's app — so the API is all request lifecycle, with no payer identity in sight. When the payer's identity is the anchor and the request travels over a network to an enrolled alias, that's the Disbursements via Zelle template's RTP-adjacent world; and when the code sits inside a hosted checkout rather than a Pix payload, the payment-link store in the Online Payments template is the closer cousin.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.