Skip to main content
Every CBPay operation follows an explicit lifecycle. This page gathers all statuses of all products in one place, with the golden rule: never assume success until you see a final state.

Unified table

Payouts: the cycle with money on hold

  • The full debit (total_debit) leaves available and sits in held while the operation is in flight.
  • failed always refunds the full debit (amount + fee) to available, automatically.
  • A processing payout cannot be cancelled through the API: wait for the final state (webhook or GET /v1/payouts/{id}).

status_code catalog on failed payouts

When a payout fails, status_code and status_message explain the cause in neutral terms: The refund already happened in every case: verify it in GET /v1/movements (a payout_refund entry).

Payins: collection statuses

  • pending — the charge exists and awaits payment. QRs and payment pages expire (expired if nobody pays).
  • credited — payment received, converted at your payin_rate and credited.
  • unassigned — a deposit arrived that could not be matched to any account; the administrator routes it manually and it is then credited with the destination account’s rate and fees.
  • failed — the collection failed (e.g. a collect declined by the payer). No money moved.

Crypto withdrawals: on-chain confirmation

A withdrawal reaches completed when the transaction confirms on the network. Typical times: TRON ~1 minute (19 confirmations), Ethereum a few minutes depending on congestion. The tx_id comes in the response and the webhook so you can verify it on the explorer. If the withdrawal fails before broadcasting, the full debit is refunded (a withdrawal_refund entry).

Cards

  • pending_activation — a physical card was issued and ships inactive; it activates with POST /v1/cards/{id}/activate.
  • active — authorizes purchases in real time against the card’s spending asset balance (spending_asset: USDT, USDC, BTC or GOLD).
  • frozen — frozen (manually or for an unpaid monthly fee); purchases are declined with unfunded_card_frozen. It unfreezes by settling the pending charge.
  • cancelled — final; cannot be reverted.

Cross-cutting rules

Final state via webhook or via the resource’s GET — both are equivalent sources of truth. The webhook is push (recommended); the GET is your fallback if a webhook is lost.
Do NOT retry with a new key. Repeat the same request with the same idempotency_key (it returns the original with idempotency_hit: true) or query the resource listing. Details in idempotency.
No. Lifecycles are monotonic: completed and failed are definitive, and an operation never returns to a previous state.
In GET /v1/movements: every transition with an economic effect leaves an immutable entry (payout_debit, payout_refund, payin_credit…). See movements and reconciliation.
Last modified on July 10, 2026