Reference · built on requestConnectorPayments, billing & fraud

Checkout.com

Payments, captures, refunds, voids, and disputes from Checkout.com, with workflow webhooks signed per event.

Request accessPricing ↗

About

Checkout.com is a payment processor whose Payments API authorizes, captures, refunds, voids, and reverses card and alternative payments. Its Workflows product sends webhooks when events occur: you define conditions and a webhook action, and Checkout.com posts each matching event with a Cko-Signature header.

An operator on Fibric consumes those events and the payment record from GET /payments/{id}, then proposes the next action for your approval: capture inside the seven-day window, issue a partial refund, void an uncaptured authorization, or provide dispute evidence. Approved actions are sent once and recorded, with the returned action id kept so the outcome webhook can be matched to it.

This is a reference listing. It documents what Fibric would read from Checkout.com and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Payment detail from GET /payments/{id} and the list of captures, refunds, and voids from GET /payments/{id}/actions
  • Payments found by reference, date, or status through POST /payments/search
  • Workflow webhook events for approvals, captures, refunds, and voids, such as payment_captured, payment_refunded, and payment_voided
  • Dispute records from GET /disputes and GET /disputes/{dispute_id}, including scheme files from GET /disputes/{dispute_id}/scheme-files
  • Evidence already provided on a dispute from GET /disputes/{dispute_id}/evidence
  • Any event and its payload from GET /workflows/events/{event_id}

Proposed actions

  • Target capability: propose a full or partial capture through POST /payments/{id}/captures, using capture_type NonFinal when more captures will follow
  • Target capability: propose a refund through POST /payments/{id}/refunds, up to the original payment amount
  • Target capability: propose a void of an authorized, uncaptured payment through POST /payments/{id}/voids
  • Target capability: propose dispute evidence: PUT /disputes/{dispute_id}/evidence to provide it, then POST /disputes/{dispute_id}/evidence to submit
  • Target capability: propose accepting a dispute through POST /disputes/{dispute_id}/accept

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Provide dispute evidence in time

    When a dispute appears in GET /disputes with evidence required, the operator assembles delivery proof and customer communication, proposes the evidence set, and after approval provides and submits it in two calls.

    With Chargeback Evidence

  • Capture before the window closes

    For authorizations approaching the seven-day limit, the operator checks fulfillment status and proposes a capture, a NonFinal partial capture, or a void.

    With Order Risk, Cancellation Window

  • Refund without exceeding the payment

    A return is approved. The operator reads prior refunds from /payments/{id}/actions, proposes a partial refund that keeps the total inside the original amount, and records the action id.

    With Refund Policy, Returns Triage

Requirements

  • A Checkout.com account and the keys created for it in the Dashboard
  • A secret key or OAuth client with the scopes for each endpoint used, kept separate for sandbox and production
  • Your account prefix, since requests go to {prefix}.api.checkout.com or {prefix}.api.sandbox.checkout.com
  • A workflow whose webhook action points at your HTTPS endpoint, with a signature key set on the action
Authentication
A secret API key sent as a Bearer token, or an OAuth 2.0 client credentials token from the access server with scopes such as gateway and disputes.

Limits

  • Captures, refunds, and voids return 202 Accepted; the result arrives later in a webhook, so the record is provisional until then.
  • An authorization not captured within seven days is voided.
  • A payment allows at most 150 partial actions, captures and refunds combined.
  • Webhooks arrive at least once and possibly out of order; a failed delivery is retried up to eight times, from 5 minutes to 12-hour intervals.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Checkout.com ↗

Questions and answers

How are Checkout.com webhooks signed?
Checkout.com hashes the webhook payload with the key you set in the workflow's webhook action and sends the HMAC, hex encoded, in the Cko-Signature header. The connector recomputes it and drops any event that does not match.
Why does a refund return 202 instead of a result?
Refunds, captures, and voids are asynchronous. The API accepts the request with 202 and processes it afterwards; the outcome arrives as a webhook such as payment_refunded or payment_refund_declined. Once processed, a refund cannot be cancelled.
Can the connector refund a payment it did not process?
Only for card payments in the United States, where Checkout.com supports unreferenced refunds. Elsewhere a refund must reference the original payment id.
Ask about Checkout.com

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Checkout.com through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy