A WireMock simulation of Chase JPMorgan's REST API — covering asynchronous payment initiation with detail and status retrieval by end-to-end id or firm root id.
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 - 202 Accepted
curl -s -X POST 'https://w2dg3.wiremockapi.cloud/payments' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Global Payments API (1.2.0) · 3 endpoints
| Method | Path | Summary |
|---|---|---|
| GET | /payments | Retrieve payment details |
| POST | /payments | Payments Initiation API |
| GET | /payments/status | Retrieve payment status |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
Three endpoints model the async contract of J.P. Morgan's first-generation payments API. Initiation is fire-and-forget: any submission — every payment type from RTP to SEPA to Fedwire, any amount, any currency — draws the same 202 whose body pairs your echoed endToEndId with a freshly minted eighteen-character firmRootId. The retrieval pair then answers by query parameter. Looking up by firmRootId serves the template's showcase record: a 650-pound RTP credit to Emily Davis, debtor account at BIC CHASGB2L, creditor addressed through UK clearing 185008, status COMPLETED with its creation timestamp — the full detail on one route, the bare paymentStatus object on the other. Omit both parameters and either route answers a proper GCA-095 validation error naming the requirement. The endToEndId branch of both lookups is broken outright, which the FAQ covers in detail.
firmRootId, exclusively. Both endToEndId stubs — details and status alike — render a templating failure instead of their response: HTTP 200, content-type application/json, and a body that is the literal string of a formatJson helper error. No value escapes it, including the fixture's own end-to-end id, and because the endToEndId stub outranks the other when both parameters are present, sending both breaks a request that firmRootId alone would have served. There's an upside: this is a ready-made invalid-JSON-under-200 case, and response parsers that survive it have covered a failure mode production APIs do produce.
No — nothing is registered. Query the exact firmRootId the 202 just minted and the response is the same Emily Davis record as for any other value, reporting firm root id FIRMROOT0000000001 regardless. The two halves are independent fixtures: initiation verifies your submission and id-extraction plumbing, retrieval verifies your parsing of the full detail shape, and the join between them is a convention your test asserts rather than a behavior the sandbox enforces. There is likewise no not-found path — every non-empty firmRootId answers 200.
Absence, not badness. Calling either GET with no query parameters returns 400 with errorCode GCA-095 — "endToEndId or firmRootId is required" — in the nested errors/errorDetails envelope the real gateway uses. Malformed values won't produce it, and the intake accepts anything up to and including malformed JSON with a 202. That makes GCA-095 the place to verify your error-envelope parsing, and a private WireMock Cloud copy the place for declines, duplicate rejections, and amount-validation failures.
Match whichever contract your integration targets. This v1 surface is query-parameter retrieval over static fixtures — good for pinning response models and the async initiate-then-poll shape. The Global Payments v2 template is the stateful sibling: echo-storing creates, path-parameter reads gated on minted ids, and a returns ledger. A migration test bench benefits from both — same payment scenario, two contracts, one diff.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.