Authorization expires
in seven days. Know your
Checkout.com flow before it does.
Checkout.com holds funds when you authorize and takes them when you capture — two separate API calls. If you don't capture within seven days, the authorization voids automatically. This mock covers the full flow: auth, capture, void, and webhooks — no API keys needed.
Auth→Capture
two-step flow
3DS built-in
sessions handle it
0 API keys
to get started
{
"status": "Authorized",
"response_code": "10000",
"response_summary": "Approved",
"balances": {
"authorized_amount": 4500,
"captured_amount": 0
}
}
// authorized — now call /captures to take funds
Checkout.com splits payments into two steps: authorize and capture. Authorization puts a hold on the customer's card — the money doesn't move yet. Capture is when it actually does. This matters for businesses where the final amount isn't known at checkout — hotels, car rentals, subscription upgrades. You can also void an authorization before capture to release the hold entirely.
Checkout.com uses numeric response codes, not string statuses. Code 10000 means approved. Every other code is a decline with a specific reason. Don't check the status field for success — check response_code === '10000'. Most integration mistakes happen here.
The Payment Sessions API handles the checkout page for you. One POST call creates a session and returns a payment_link. You redirect the customer, Checkout.com handles 3DS and card collection, then fires payment_approved or payment_declined webhooks to your server. This mock covers that entire flow — no Checkout.com credentials required.
The authorize → capture flow
Checkout.com separates authorization from capture. You auth now (the bank holds the funds), then capture later (the transfer happens). Or void to release the hold without charging anyone.
POST /init
Authorize
status: "Authorized"
Bank approves and holds
funds on the card
POST /captures
Capture
status: "Captured"
Funds transferred to
your account
POST /voids
Void
status: "Voided"
Hold released, customer
never charged
Practical note: Most e-commerce setups capture immediately after authorization. But if you run a pre-order or hotel booking, you can authorize at purchase time and capture when the item ships or the guest checks out. The balances.authorized_amount field tracks what is held, balances.captured_amount tracks what has been taken.
Response codes
Checkout.com uses numeric response codes to communicate decline reasons. The response_summary field gives the same information in plain English.
10000Approved20005Do not honor20051Insufficient funds20087Bad Track Data20153Card expired30004Pick up card10000 is the only approval code. Every other code is a decline. Display response_summary directly to your support team or logs — it is always a readable English phrase. Do not attempt to map every code to a custom message; the summary does that for you.
Integration code
curl -X POST https://mockgateway.dev/api/base/checkout/payments \
-H "Authorization: Bearer YOUR_MOCK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"amount": 4500,
"currency": "USD",
"reference": "ORD-CKO-0042",
"description": "Pro plan — annual",
"success_url": "https://yourapp.com/checkout/success",
"failure_url": "https://yourapp.com/checkout/failed"
}'New to testing webhooks locally? Read how webhook delivery and retries work →
Request parameters
Sent to POST /api/base/checkout/payments
| Parameter | Type | Required | Description |
|---|---|---|---|
amount | integer | required | Amount in minor units e.g. 1000 |
currency | string | required | ISO 4217 currency e.g. USD |
reference | string | optional | Your payment reference e.g. ORD-12345 |
description | string | optional | Payment description |
Response fields
| Field | Type | Description |
|---|---|---|
id | string | Checkout.com payment ID |
status | enum | Payment status |
created_at | datetime |
Questions about Checkout.com
Other gateway templates
Looking for a different provider?
