CryptoCheckout documentation

curl -X POST $CC_API_BASE/pool-deposit-status \
  -H "Origin: https://yourstore.example" \
  -H "apikey: $CC_PUBLISHABLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "depositIntentId": "9f3c1e02-7b4a-4d18-9c55-2a1b8e6f0d43" }'

async function checkPayment(depositIntentId) {
  const res = await fetch(
    `${process.env.CC_API_BASE}/pool-deposit-status`,
    {
      method: "POST",
      headers: {
        Origin: "https://yourstore.example",
        apikey: process.env.CC_PUBLISHABLE_KEY,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ depositIntentId }),
    }
  );
  return res.json();
}

{
  "id": "9f3c1e02-7b4a-4d18-9c55-2a1b8e6f0d43",
  "status": "swept",
  "expectedAmount": "49000000",
  "confirmedAmount": "49000000",
  "token": "EURC",
  "tokenDecimals": 6,
  "namespace": "eip155",
  "settlementChainId": 84532,
  "forwarderAddress": "0x7a1f…",
  "poolAddress": "0xb42c…",
  "depositTxHash": "0x3d9a…",
  "sweptTxHash": "0x81ce…",
  "refundedTxHash": null,
  "refundTo": null,
  "refundDeadlineAt": null,
  "confirmAtCapture": true,
  "expiresAt": "2026-08-09T15:02:11.204Z"
}

curl -X POST $CC_API_BASE/pool-deposit-status \
  -H "Origin: https://yourstore.example" \
  -H "apikey: $CC_PUBLISHABLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "depositIntentId": "9f3c1e02-7b4a-4d18-9c55-2a1b8e6f0d43" }'

async function checkPayment(depositIntentId) {
  const res = await fetch(
    `${process.env.CC_API_BASE}/pool-deposit-status`,
    {
      method: "POST",
      headers: {
        Origin: "https://yourstore.example",
        apikey: process.env.CC_PUBLISHABLE_KEY,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ depositIntentId }),
    }
  );
  return res.json();
}

{
  "id": "9f3c1e02-7b4a-4d18-9c55-2a1b8e6f0d43",
  "status": "swept",
  "expectedAmount": "49000000",
  "confirmedAmount": "49000000",
  "token": "EURC",
  "tokenDecimals": 6,
  "namespace": "eip155",
  "settlementChainId": 84532,
  "forwarderAddress": "0x7a1f…",
  "poolAddress": "0xb42c…",
  "depositTxHash": "0x3d9a…",
  "sweptTxHash": "0x81ce…",
  "refundedTxHash": null,
  "refundTo": null,
  "refundDeadlineAt": null,
  "confirmAtCapture": true,
  "expiresAt": "2026-08-09T15:02:11.204Z"
}

POST /pool-deposit-status

Use webhooks as your primary signal. Poll only to reconcile stragglers or after your endpoint was down.

Request

string

required

The intent.id UUID returned when you created the deposit. This is the only accepted key and the only accepted identifier — omit it and you get 400 Missing depositIntentId; send the payment ID from your quote and you get 404 Deposit intent not found.

Response

string

Intent ID.

string

Current state. See below.

string

Quoted amount, base units.

string

Actually received. Compare against expected for under- and overpayment.

string

Token.

number

Decimals for that token, so you can render the amounts above.

number

Chain the payment settles on. Null until the chain is known. Every network live today is a test network; the example below is Base Sepolia, 84532.

string

Chain family — eip155 or tron.

string

The customer’s inbound transfer, once seen.

string

The transaction that moved the funds into your pool.

string

Set only if the funds were returned on-chain.

string

The one-time pay-to address issued for this payment.

string

Your settlement pool, where the funds end up.

string

Refund address recorded on the intent, if any.

string

Refund deadline recorded on the intent, if any.

boolean

Whether the payment is complete at paid/overpaid rather than at swept. See the note under Statuses.

string

When this deposit intent lapses — a fixed one hour after it was created. This is the intent’s own window, not the shorter price-lock on your quote.

There is no confirmations field: the endpoint reports the confirmation outcome through status, not a running count.

Statuses

Status	Meaning	Safe to ship
`waiting`	Address issued, nothing received	No
`confirming`	Seen, awaiting confirmations	No
`paid`	Correct amount confirmed	Yes, unless `confirmAtCapture` is false
`swept`	Settled into your pool	Yes
`underpaid`	Less than expected	Your call
`overpaid`	More than expected	Same rule as `paid` — then return the difference
`wrong_token`	Token not enabled	No
`expired`	Window lapsed without a clearing payment	No — check the amounts first
`expired_paid_late`	Paid after expiry	Same rule as `paid` — the funds count
`held_sanctioned`	Compliance hold	No
`tamper_suspected`	Settlement address failed our on-chain re-check	No

When is a payment final? paid means the customer’s transfer reached the required confirmation depth at the one-time pay-to address. That address can only forward funds to your settlement pool — there is no refund window and no other destination — so the sweep that follows is our step, not a window in which the customer can pull the money back. For most merchants paid is therefore ship-safe, and the hosted checkout already tells the buyer the payment is complete at that point.The one exception is a merchant running payer screening set to Enforce: that screen runs on the sender at sweep time, so for them a paid payment can still become held_sanctioned, and swept stays the fulfilment signal. The confirmAtCapture field on the status response tells you which case you are in — true means confirm at paid/overpaid, false means wait for swept.Either way swept means the money is settled in your pool. The webhook stream follows the same rule: pool.deposit.confirmed fires at paid, before the sweep, and is the fulfilment signal on this rail; pool.swept fires once the sweep lands. There is no payment_confirmed event. Finality · Events.

expired does not mean nothing arrived. Expiry outranks both underpaid and wrong_token, so an invoice that received a short payment, or a token you haven’t enabled, reports expired once its window closes — while those funds sit at the pay-to address. Always check confirmedAmount on an expired row before treating it as empty.

tamper_suspected is a terminal hold, not a transient error. We independently re-derive your settlement addresses from the payout configuration committed to your pool, and separately cross-check that payout address against what the on-chain registry reports for your wallet. If either check contradicts the stored address, the payment is frozen rather than reported as settled, and a pool.tamper_suspected webhook is sent. A held intent stops being scanned and is never swept, so any funds already at the pay-to address wait for manual review — contact us.There is no on-chain attestation step for you to perform. The registry returns your own wallet address unless you have explicitly pointed it somewhere else, and that default is a valid answer. The cross-check can therefore only contradict — and only freezes on that ground — when you have set an explicit payout address on-chain and the stored one disagrees with it. A transient failure to read the chain never triggers the hold. Self-service release tooling is Coming; today the review is manual on our side.

curl -X POST $CC_API_BASE/pool-deposit-status \
  -H "Origin: https://yourstore.example" \
  -H "apikey: $CC_PUBLISHABLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "depositIntentId": "9f3c1e02-7b4a-4d18-9c55-2a1b8e6f0d43" }'

async function checkPayment(depositIntentId) {
  const res = await fetch(
    `${process.env.CC_API_BASE}/pool-deposit-status`,
    {
      method: "POST",
      headers: {
        Origin: "https://yourstore.example",
        apikey: process.env.CC_PUBLISHABLE_KEY,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ depositIntentId }),
    }
  );
  return res.json();
}

{
  "id": "9f3c1e02-7b4a-4d18-9c55-2a1b8e6f0d43",
  "status": "swept",
  "expectedAmount": "49000000",
  "confirmedAmount": "49000000",
  "token": "EURC",
  "tokenDecimals": 6,
  "namespace": "eip155",
  "settlementChainId": 84532,
  "forwarderAddress": "0x7a1f…",
  "poolAddress": "0xb42c…",
  "depositTxHash": "0x3d9a…",
  "sweptTxHash": "0x81ce…",
  "refundedTxHash": null,
  "refundTo": null,
  "refundDeadlineAt": null,
  "confirmAtCapture": true,
  "expiresAt": "2026-08-09T15:02:11.204Z"
}

Polling sensibly

// Backstop only — webhooks are the primary path.
async function reconcile(order) {
  const p = await checkPayment(order.depositIntentId);

  const settled =
    p.status === "swept" ||
    (p.confirmAtCapture && (p.status === "paid" || p.status === "overpaid"));

  if (settled && !order.fulfilled) {
    await fulfil(order);            // webhook was missed
  }

  if (p.status === "underpaid") {
    await flagForReview(order, p);
  }
}

Do

Poll pending orders on a schedule — every few minutes, backing off over time. Reconcile daily against the dashboard ledger.

Don't

Poll in a tight loop from the browser, or poll every order forever. You’ll hit rate limits and gain nothing.

Status polling allows roughly 120 requests a minute, and the limit is keyed by calling IP address, not by account — so a server-side poller puts every one of your orders in the same bucket. Exceeding it returns 429 with Retry-After. Respect it.

Using the API

Endpoints

Check payment status

Request

Response

Statuses

Polling sensibly

Do

Don't

​Request

​Response

​Statuses

​Polling sensibly

Do

Don't

Request

Response

Statuses

Polling sensibly