What is the difference between Authorized and Captured?

Authorized means the bank has put a hold on the funds — the customer cannot spend that money, but you have not received it yet. Captured means you have claimed the funds and the transfer to your account begins. Checkout.com keeps these as separate API calls, which is useful for things like hotels that auth at check-in and capture at checkout.

How long can I hold an authorization before capturing?

In real Checkout.com, authorizations expire after 7 days (Visa) or 30 days (Mastercard) depending on card network rules. In this mock, there is no expiry — you can capture at any point. When you go live, capture promptly or the auth will silently expire and the charge will fail.

What does response_code 10000 mean?

It means approved. 10000 is the only success code. Everything else is a decline. The response_summary field gives you a human-readable explanation like "Approved", "Insufficient funds", or "Do not honor". Always check response_code first — status Authorized guarantees response_code 10000.

How does 3DS work in the Sessions flow?

When you POST a payment session, Checkout.com handles 3DS automatically before the redirect comes back. The customer sees the bank authentication page during the hosted payment session. Your code does not need to explicitly trigger or handle 3DS — you just check the final status after redirect.

When should I fulfill the order?

On the payment_captured webhook, not the success_url redirect. Browser redirects can be dropped, spoofed, or cancelled before they fire. The webhook is a server-to-server call that Checkout.com retries on failure. Only fulfill after you receive and verify the payment_captured event.

Test Checkout.com Payments — Auth, Capture and Webhooks

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.

Use this template Checkout.com docs ↗

Auth→Capture

two-step flow

3DS built-in

sessions handle it

0 API keys

to get started

payment_response.json

{

"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.

How does the Checkout.com authorize-capture flow work?

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

— or —

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.

Which Checkout.com response code means approved?

Checkout.com uses numeric response codes to communicate decline reasons. The response_summary field gives the same information in plain English.

10000Approved

20005Do not honor

20051Insufficient funds

20087Bad Track Data

20153Card expired

30004Pick up card

10000 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.com/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 works →

Request parameters

Sent to POST /api/base/checkout/payments

Request parameters
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