Skip to main content
Advanced events report detail about the underlying on-chain transaction. You only need to subscribe when that detail matters to you — confirmation counts, on-chain transaction fee breakdowns, block information, or replacement (drop, resend, speed-up) information. Read Events overview first for the envelope, deduplication, and the rules that apply to every event.

Events on this page

payment.transaction.created

Trigger condition: a deposit address receives a new deposit. Top-up Mode only. The same fact also reaches you through payment.topup.updated with status Detected. Event content: the shared transaction fields, plus the fields below.

payment.transaction.completed

Trigger condition: a deposit passes compliance screening and is credited. Both pay-in modes. For an order paid in several instalments it fires once per receipt as funds are credited, while the order event reports the cumulative outcome — see Underpayment, overpayment, partial payments, and late payment. Event content: the shared transaction fields, plus the fields below. Which of them are populated depends on the pay-in mode.

payment.transaction.failed

Trigger condition: a deposit failed or was rejected, for example because it did not clear compliance screening. Both pay-in modes. Event content: the shared transaction fields, plus the fields below.
For why it failed, read failed_reason on that business’s own event. The failed_reason in the transaction fields is free text and is populated only for approval and signature failures.

payment.transaction.late

Trigger condition: a deposit that passed screening arrives after its order reached a final state. Order Mode only. It does not reopen the order or change its final status. The same fact also reaches you through payment.order.updated as notice_type LatePaymentReceived — see Underpayment, overpayment, partial payments, and late payment. Event content: the shared transaction fields, plus the fields below.

payment.order.status.updated

Delivered alongside payment.order.updated. Reports detail about the order’s underlying transactions, including the transactions array and the fee fields. Trigger condition: a payment order’s status changes, Order Mode only. The points that fire are Pending (the order is created through a payment link), Completed (full payment received within the validity period), Underpaid (completed deposits exist but fall short), and Expired (no completed deposit within the validity period, or the order was canceled). Event content:
For full details, see Get pay-in order information.

payment.refund.status.updated

Delivered alongside payment.refund.updated. Reports detail about the refund’s underlying transactions, including the transactions array and the fee fields. Trigger condition: the refund order’s status changes. Key points are Pending when the order is created through a refund link, Completed when all refund transactions complete, and Failed when all refund transactions fail. Event content:
For full details, see Get refund order information.

payment.payout.status.updated

Delivered alongside payment.payout.updated. Reports detail about the payout’s underlying transactions, including the transactions array and payout_items. Trigger condition: the payout or transfer request’s status changes. Completed means all transfers completed, PartiallyCompleted means some completed and some failed, Failed means all failed, and RejectedByBank means the recipient bank rejected the Off-Ramp payout. Event content:
For full details, see Get payout information.

payment.bulk_send.status.updated

Delivered alongside payment.bulk_send.updated. Reports detail about the batch’s underlying transactions. Trigger condition: the bulk send request’s status changes. Completed means all sends completed, PartiallyCompleted means some completed and some failed, and Failed means all failed. Event content:
For full details, see Get bulk send information.

payment.bulk_send.item.status.updated

Delivered alongside payment.bulk_send.item.updated. Reports detail about the item’s underlying transaction, including validation_status and tx_hash. Trigger condition: a single bulk send item reaches a final status (Completed, Failed, NotExecuted). No event is sent for Pending or Processing. Event content:
To test delivery to your registered webhook endpoints, use Trigger test webhook event with event_type set to payment.bulk_send.item.status.updated.

Transaction fields

These fields appear in all payment.transaction.* events. Not every field is populated in every scenario.
  • transaction_id (string, UUID, required) — The transaction ID.
  • cobo_id (string, optional) — The Cobo ID used to track a transaction.
  • request_id (string, optional) — The request ID used to track the transaction request.
  • type (string, optional) — The transaction type.
  • status (string, required) — The transaction status (e.g. Submitted, PendingScreening, Confirming, Completed, Failed, Rejected). See Transaction statuses and sub-statuses for the full lifecycle. The PendingAuthorization status covers both manual approval steps and internal automated risk-control/KYT/compliance checks — it does not necessarily require a human action.
  • sub_status (string, optional) — A more granular status alongside status (e.g. PendingApproverCheck, RejectedKYT, FailedOnChain). See the same statuses and sub-statuses guide for the full list.
  • failed_reason (string, optional) — Why the transaction failed. Populated only for approval failures and signature failures. This is a free-text string, unlike the { code, message } object that the events for each payment business carry.
  • initiator (string, optional) — The transaction initiator.
  • chain_id (string, optional) — The chain ID.
  • token_id (string, optional) — The token ID.
  • transaction_hash (string, optional) — The on-chain transaction hash (txid). Populated only after the transaction is broadcast on-chain, so it may be null or absent before then — unlike transaction_id, which is assigned at creation and always present.
  • source (object, required) — Where the deposit came from, typically an external wallet address (source_type: DepositFromAddress).
  • destination (object, required) — Where the deposit went, typically a deposit address (destination_type: DepositToAddress). Key sub-fields:
    • address — The receiving address.
    • amount — The received amount. For example, if 1.5 USDT was deposited, the value is 1.5.
    • memo — The memo identifying which account to credit (only on certain chains).
  • result (object, optional) — The transaction result.
  • fee (object, optional) — The transaction fee. Its shape depends on the chain’s fee model (e.g. EIP-1559, UTXO).
  • confirmed_num (integer, optional) — The number of confirmations this transaction has received.
  • confirming_threshold (integer, optional) — The minimum number of confirmations required to deem a transaction secure (e.g. commonly 6 for a Bitcoin transaction).
  • block_info (object, optional) — Details of the block the transaction was included in:
    • block_number — The block number.
    • block_timestamp — When the block was created, in Unix timestamp (milliseconds).
    • block_hash — The block hash.
  • raw_tx_info (object, optional) — Details of the raw transaction:
    • used_nonce — The transaction nonce.
    • selected_utxos — The UTXOs consumed in the transaction.
    • raw_tx — The raw transaction data.
    • unsigned_raw_tx — The unsigned raw transaction data.
    • utxo_changes — The UTXO change outputs in the transaction.
  • replacement (object, optional) — Populated when this transaction replaced, or was replaced by, another (drop/resend/speed-up):
    • replaced_by_type / replaced_type — The replacement type: Drop, Resend, or SpeedUp.
    • replaced_by_transaction_id / replaced_by_transaction_hash — The ID/hash of the transaction that replaced this one.
    • replaced_transaction_id / replaced_transaction_hash — The ID/hash of the transaction this one replaced.
  • created_timestamp (integer, int64, required) — The creation time, in Unix timestamp format (milliseconds).
  • updated_timestamp (integer, int64, required) — The last update time, in Unix timestamp format (milliseconds).

Example

This example is illustrative and constructed from the field definitions in the Payment spec; optional fields may be absent in actual webhook deliveries.