CryptoCheckout documentation

Events

payment_confirmed — fulfil here

The payment reached finality and is irreversible. This is your fulfilment trigger.Connect rail: the deposit transaction reached required confirmations. Deposit rail: the inbound transfer confirmed and our sweep into your pool confirmed.

{
  "id": "payment_confirmed_a1b2c3d4",
  "event": "payment_confirmed",
  "created_at": "2026-08-09T14:32:11.204Z",
  "data": {
    "paymentId": "…",
    "orderId": "your-order-ref",
    "amount": "49000000",
    "token": "EURC",
    "chainId": 8453,
    "txHash": "0x…"
  }
}

amount is in token base units. On most chains these tokens use 6 decimals, so 49000000 is 49.00 — but decimals vary by chain (BNB Chain is 18). Scale by the payment’s tokenDecimals rather than assuming 6.

payment_intent_created

A customer started checkout and an intent exists. Nothing has been paid.Useful for abandonment analytics. Do not treat as a sale.

payment_submitted

A transaction was broadcast but has not reached finality.Good for a “confirming…” state. Not safe to ship on — it can still fail or be reorganised. Finality.

payment_failed

The attempt failed. Nothing was taken from the customer.Show a retry option.

payment_expired

The quote window elapsed with no payment.

Expiry locks the price, not the address. A customer can still pay afterwards and the money still arrives. Don’t cancel the order irreversibly on this event — mark it lapsed and wait.

payment_blocked

The payment was refused by a compliance check. Deliberately non-specific, to avoid coaching evasion.Only fires if you’ve enabled payer screening. Sanctions.

payment_claimed

A payout completed and funds moved to your payout address.Useful for reconciliation and accounting. Not customer-facing.

Handling them

switch (event.event) {
  case "payment_confirmed":
    await fulfilOrder(event.data.orderId);   // the only one that ships
    break;

  case "payment_submitted":
    await markConfirming(event.data.orderId);
    break;

  case "payment_failed":
    await markFailed(event.data.orderId);
    break;

  case "payment_expired":
    await markLapsed(event.data.orderId);    // NOT cancelled — late payment is possible
    break;

  case "payment_claimed":
    await recordPayout(event.data);
    break;

  default:
    break;                                   // ignore unknown events
}

Ignore events you don’t recognise rather than erroring. New event types can be added, and a handler that 500s on an unknown type will look like an outage to our retry logic.

Deposit-rail statuses

The deposit rail carries richer per-invoice states than the events above. They surface in your dashboard and the status API:

Status	Meaning
`waiting`	Address issued, nothing received
`confirming`	Funds seen, awaiting confirmations
`paid`	Correct amount confirmed
`underpaid`	Less than expected — see `confirmed_amount`
`overpaid`	More than expected
`wrong_token`	A token you haven’t enabled
`swept`	Moved into your pool
`expired`	Quote lapsed, nothing received
`expired_paid_late`	Paid after expiry — funds arrived and count
`held_sanctioned`	Frozen pending compliance review

Get started

Core concepts

Integration

Webhooks

Your money

Dashboard

Compliance

Reference

Event reference

Lifecycle

Events

Handling them

Deposit-rail statuses

​Lifecycle

​Events

​Handling them

​Deposit-rail statuses

Lifecycle

Events

Handling them

Deposit-rail statuses