A WireMock simulation of Chase JPMorgan's REST API — covering card payment authorization, captures, refunds, account verifications, fraud scoring, hosted checkout, notifications, and payment links.
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 Payments health check - 200 OK
curl -s -X GET 'https://lo8y6.wiremockapi.cloud/api/v2/healthcheck/payments'POST Create payment - 200 OK
curl -s -X POST 'https://lo8y6.wiremockapi.cloud/api/v2/payments' \
-H 'Content-Type: application/json' \
-d '{}'GET Refunds health check - 200 OK
curl -s -X GET 'https://lo8y6.wiremockapi.cloud/api/v2/healthcheck/refunds'Spec catalog — Chase Online Payments APIs (1.0.0) · 29 endpoints
| Method | Path | Summary |
|---|---|---|
| GET | /api/v2/captures | Get a capture by request ID |
| GET | /api/v2/captures/{id} | Get a capture by transaction ID |
| GET | /api/v2/fraudcheck | Get a fraud check by request ID |
| POST | /api/v2/fraudcheck | Perform a fraud check |
| GET | /api/v2/fraudcheck/{id} | Get a fraud check by transaction ID |
| GET | /api/v2/healthcheck/payments | Health check for payments |
| GET | /api/v2/healthcheck/refunds | Health check for refunds |
| GET | /api/v2/healthcheck/verifications | Health check for verifications |
| GET | /api/v2/payments | Get a payment by request ID |
| POST | /api/v2/payments | Create a payment |
| GET | /api/v2/payments/{id} | Get a payment by transaction ID |
| PATCH | /api/v2/payments/{id} | Update a payment by transaction ID |
| POST | /api/v2/payments/{id}/captures | Capture a payment |
| GET | /api/v2/refunds | Get a refund by request ID |
| POST | /api/v2/refunds | Create a refund |
| GET | /api/v2/refunds/{id} | Get a refund by transaction ID |
| GET | /api/v2/verifications | Get a verification by request ID |
| POST | /api/v2/verifications | Verify a payment instrument |
| GET | /api/v2/verifications/{id} | Get a verification by transaction ID |
| POST | /v1/catalog/products | Create a product in the merchant catalog |
| GET | /v1/checkout/healthcheck | Health check for the checkout service |
| POST | /v1/checkout/intent | Set up a checkout intent |
| GET | /v1/checkout/notifications | List notifications for a given time period |
| POST | /v1/checkout/notifications/ack | Acknowledge notifications |
| GET | /v1/checkout/notifications/receive | Receive notifications (deprecated) |
| GET | /v1/payment-links | List payment links |
| POST | /v1/payment-links | Create a shareable payment link |
| GET | /v1/payment-links/{linkId} | Retrieve a payment link |
| PATCH | /v1/payment-links/{linkId} | Update a payment link |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
Two product layers share this base URL, and six of their resources run live stores. On the processing side, an authorization answers in Chase's production shape — transactionState AUTHORIZED, responseCode APPROVED, a six-character approval code minted per call, and a VISA ending 1111 as the card on every response — and the record persists: the by-id read returns your exact authorization, approval code and all. Captures mint their own CLOSED transactions into a second store without touching the parent payment, refunds and standalone verifications follow the same pattern, and the fraud check files a risk decision scored LOW_RISK with its score, tellingly, as the string "10". The commerce layer's payment links go furthest: the list starts empty, grows as you create, and a PATCH to INACTIVE survives re-reads — the closest thing in this template to full resource management. Hosted checkout hands back a decodable session JWT whose signature is literally "mockSignature".
Target identity and state: minted transaction ids, approval codes, transactionState, and the not-found bodies on unknown ids all behave. Avoid amounts and card data: whatever you submit, authorizations return the canned VISA ending 1111, captures settle at 20000, refunds at 5000, and payment links price at 9900 — the single request field a link echoes is merchantOrderNumber. A test that posts $12.00 and asserts $12.00 back fails here by design; assert the flow, template the arithmetic in a private copy.
The mutation verbs on payments are acknowledgments. PATCH with isVoid returns the stored record unchanged, and a capture mints a separate CLOSED transaction while the parent authorization stays AUTHORIZED forever. Payment links prove the sandbox can persist a PATCH when it wants to — their INACTIVE flip is durable — so the payments behavior is a deliberate line: lifecycle transitions on money movement are yours to model with scenario stubs in your own WireMock Cloud copy.
Structurally yes, cryptographically no. It decodes to a payload with a merchant order number and currency, but the signature segment is the string "mockSignature" — so libraries that parse claims succeed while any verification step fails, which is exactly the boundary a checkout integration should place its trust logic on. The redirect URL beside it points at Chase's hosted payment page; nothing is served behind it from the sandbox, so treat it as a value to thread, not a page to load.
As a fixed inbox. The feed returns the same two messages with their receipt handles regardless of the time window, the deprecated receive route still answers with one, and every acknowledgment reports zero failures without draining anything — so consume-and-ack code can run its full loop, but dedup logic is what actually gets tested, since the messages return on every poll. The 3-D Secure authentication and network-token layer that sits in front of authorizations like these is modeled in the Optimization & Protection template.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.