Get a payin
Authorizations
Session JWT (from register/login) or API key (pk_...).
X-API-Key: <token> is accepted as an alternative header.
Path Parameters
Response
The payin.
qr, collect, push, card, checkout, pos Amount in the local currency, as a plain decimal string (for example "5000000"). Never scientific notation.
The virtual balance the payin settles into. Checkout and POS payins denominate the charge in this per-link asset (no currency/local_amount until a local payment method is used; the charge amount is asset_amount in this asset). Other credited payins carry it when the account configured a default_payin_asset other than USDT — the net credit is auto-converted into this asset.
USDT, USDC, BTC, GOLD Checkout and POS payins only — the charge amount denominated in settlement_asset (present in every status, including pending and expired).
Auto-conversion state — for checkout/POS payins when the payment arrived in a different asset than settlement_asset, and for other payins when the account configured a default_payin_asset other than USDT. pending_retry is retried automatically. Omitted when no conversion applies.
pending_retry, done pending, credited, unassigned, expired, failed Card payins with a configured settlement delay only — when this payin's balance becomes available (created_at plus the payin_card fee config's settlement_hours). The payin itself is confirmed right away: the status is credited and the payin_credited webhook fires at payment time; what waits until settle_at is the BALANCE credit (and the auto-conversion, when configured). A payin whose delay has already elapsed when it is approved or assigned settles immediately. Absent when the balance settles on confirmation.
Present (true) while a credited card payin's balance is still scheduled for settle_at. While set, the payin cannot be refunded (422 settlement_pending) — the funds are not in your balance yet. Absent once the balance lands.
When the balance of this credited payin actually landed in your ledger — right at confirmation for payins without a settlement delay, or when the scheduled settlement ran (or was released early by your org admin) for delayed card payins.
Your payin rate at credit time (present once the payment was received and converted).
Amount credited to the balance. Also present WITHOUT fx_rate on checkout/POS charges settled in crypto or via a CBPay transfer (no FX quote applies).
Present only once the payin has refunds or a chargeback. Derived from the accumulated amounts — the payin status is never rewritten.
partial, full Accumulated USDT debited by refunds and chargebacks on this payin.
Accumulated amount refunded in the original local currency.
Present only when the payin is failed on active collections: where the rejection originated (provider = the payer's bank, core = pre-charge validation) plus the concrete code and message.
Announced transfers and unassigned deposits — where the payer identity came from. declared you sent it, account_identity the account holder's verified tax id was used as the default, none no identity was available (only the reference can match), bank_event (unassigned deposits) it was read from the arriving transfer.
declared, account_identity, none, bank_event Payer identity attached to the payin, when known.
Frozen snapshot of the destination bank account announced to the payer (announced bank_transfer payins on corridors with configured instructions — today CL, PY and US). The text never changes after creation; the QR image is regenerated on read with your current branding. On the US/USD corridor this block is the domestic rail (ABA routing number).
Frozen snapshot of the international SWIFT rail (BIC + correspondent bank), present only on the US/USD corridor when your organization has the swift variant configured. The payer picks either rail; both share the same reference.
How the arriving transfer was matched to this payin (audit trail). charge_link means the deposit settled the charge created for this payin (QR, checkout link or card) and was linked one-to-one by that charge - the strongest signal, no heuristics involved. manual_assign means an org admin routed the deposit by hand.
charge_link, reference, payer_document, payer_account, payer_name, amount_single_candidate, dedicated_clabe, collect_settlement, manual_assign Why the deposit could NOT be matched automatically, on unassigned payins — no_match, ambiguous_amount (two or more announcements share the amount), ambiguous_payer, claim_lost (another event claimed the announcement first) or assigned_to:<payin_id>.
Number of pending announcements that matched the amount and currency of an unassigned deposit (2 or more means the deposit was ambiguous).