Checkout.com
Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.
Capabilities
| Error decoding | supported |
| API response parsing | supported |
| Webhook / notification parsing | limited |
| Timeline | limited |
| Event correlation | supported |
| Diagnostic rules | limited |
Supported input
| Format | Description | Status |
|---|---|---|
checkout.api_error | API error responses ({ request_id, error_type, error_codes[] }) | supported |
checkout.payment_response | Unified Payments API request responses and payment details (pay_ id, status, approved, response_code) | supported |
checkout.action_accepted | Capture, refund and void accepted responses ({ action_id, reference, _links }) | limited |
checkout.webhook | Workflows webhooks for gateway payment events (created_on envelope, or timestamp + source envelope) | limited |
checkout.webhook.payment_setup | Payment Setup API events (flat event_type / event_data envelope) | unsupported |
Notification delivery
- Repeated deliveries are recognized by event id (evt_); Checkout.com documents that notifications can be delivered more than once.
- Delivery order: not guaranteed by the provider.
- Make your webhook handler idempotent: record processed event ids, and because it is not documented whether retries and manual resends keep the same event id, also check the payment id and action id before acting.
Known limitations
- Checkout.com documents at-least-once delivery and warns that manual resends may cause duplicates, but does not document whether a retried or resent webhook keeps the same evt_ id. Repeated deliveries are only recognized when they share the event id.
- Delivery order is not guaranteed and there is no sequence number. The timeline orders events by data.processed_on, then created_on or timestamp, then input order.
- Webhooks carry no payment status; the lifecycle state is inferred from the event type.
- Payment Setup events (flat event_type / event_data envelope) are recognized but not analyzed.
- Dispute, authentication, fraud and other non-gateway event types are shown without lifecycle semantics.
- Legacy (previous platform) payloads cannot be verified because that documentation is no longer published, so they are not recognized.
- Declines are decoded from response_code only; response_summary text varies between endpoints and is not used for decoding.
- The error_type list is incomplete in the documentation, and error codes for captures, refunds and voids beyond the /payments list are not documented.
- Capture, refund and void accepted (202) responses do not say which action was requested, and a 202 does not confirm that the action succeeded.
- Mastercard merchant advice codes other than the documented retry-after codes (24 to 30) are shown but not interpreted.
- Category and retry guidance per code are PandaPayLens suggestions; only the soft/hard/risk classification, Smart Dunning and downtime-retry eligibility, 3DS retry codes and recommendation codes are Checkout.com retry signals.
- Webhook signatures (Cko-Signature) cannot be verified from pasted payloads.
Examples
- Checkout.com: declined payment: A 201 response with approved=false, decoded from response_code.
- Checkout.com: capture and refund webhooks: Gateway webhooks linked through the pay_ payment id and act_ action ids.
Provider documentation
- API response codes
- Error codes
- Recommendation codes
- Accept a payment using the Payments API
- Get payment details
- Receive webhooks
- Resend webhooks
- Event types
- Retry a payment
- Idempotency
PandaPayLens is not affiliated with Checkout.com. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.