A WireMock simulation of Chase JPMorgan's REST API — covering payment initiation, by-id and by-reference payment retrieval, and payment returns.
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 Create Payment - 201
curl -s -X POST 'https://zez4q.wiremockapi.cloud/payments' \
-H 'Content-Type: application/json' \
-d '{}'POST Create Payment Return - 201
curl -s -X POST 'https://zez4q.wiremockapi.cloud/payments/returns' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Global Payments (2.2.5) · 5 endpoints
| Method | Path | Summary |
|---|---|---|
| GET | /payments | Query Payments by endToEndId or paymentId |
| POST | /payments | Initiate Payments |
| GET | /payments/{paymentId} | Retrieve Payment by paymentId |
| POST | /payments/returns | Payment Returns |
| GET | /payments/returns/{returnId} | Retrieve Payment Return |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
Version 2.2.5 of J.P. Morgan's cross-rail payments API, modeled as two record stores that keep the whole submission. Initiating a payment answers 201 with your body back — debtor, creditor, amounts, the endToEndId inside paymentIdentifiers — plus a minted UUID paymentId, the RECEIVED/RECEIVED status pair, and a statusUpdatedAt stamped at the moment of the call; filing a return does the same under a returnId. Both stores gate their reads on what they issued: a minted id resolves to the full stored record, while an id the store never saw — even a perfectly formed UUID — draws a problem-style Not Found whose traceId is a string of zeros. The query route splits down the middle: asking by paymentId consults the real store and wraps the record in a payments array, while asking by endToEndId always serves the one canonical completed payment, status COMPLETED_BY_JPM, dated April 2026.
They answer from different layers. paymentId consults the live store — your created payments come back complete, unknown values 404 — while endToEndId matches any non-empty value and serves the static fixture, whose own reference reads STATICENDTOENID001 (the spec's spelling, one D short). Send both parameters and paymentId wins, because the endToEndId stub only matches when paymentId is absent. One practical consequence: reconciliation-by-reference flows can't find in-session payments here — thread the minted id, not the endToEndId, through your test assertions.
Not in this sandbox — a stored record keeps the status pair it was minted with, however long you poll. The terminal state exists as the endToEndId fixture's COMPLETED / COMPLETED_BY_JPM, so both ends of the lifecycle are observable, just never on the same record. Status-ladder testing — RECEIVED through PENDING to COMPLETED or REJECTED on one id — is scenario work for a private WireMock Cloud copy, where WireMock's stateful scenarios can advance a payment per poll.
Yes — the return intake is deliberately unguarded. It accepts any body, stores it under a fresh returnId, and never checks that the referenced paymentId is real, so orphaned returns are constructible on purpose. The return record itself round-trips faithfully: reason code and amount read back exactly as filed. Enforcement of the payment-return relationship is the kind of cross-record validation a private copy models with request matching on known ids.
The Global Payments v1 template models the earlier three-endpoint surface: fire-and-forget 202 initiation with query-parameter lookups over static fixtures. This v2 sandbox trades that for genuine state — echo-storing creates, id-gated path reads, and a returns ledger. Teams migrating between API versions can hold both templates side by side and diff the contract their client actually exercises.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.