Transaction webhooks

Transaction events track every observable status transition, including transfers, deposits, and withdrawals. Subscribe to reconcile funding and settlement without polling. The current status is in data.transaction.status. The data object contains:

transaction: the transaction after the transition, including its public status, amounts, chain, timestamps, and any queued withdrawalRequest;
previousStatus: the previous observable status, or null for a first event or a transition out of the internal created / claimed states. Internal states never emit events.

The transaction summary uses camelCase keys and includes nullable keys explicitly as null. It does not duplicate the nested account object returned by transaction queries; accountId remains available. Each transaction event sets transactionId and accountId in related. The other three routing keys are null.

Event types

Event	Observable status
`transaction.withdrawal_initiated`	A signed withdrawal is queued pending vault liquidity.
`transaction.waiting_for_funds`	The transaction is waiting for funds.
`transaction.payment_in_review`	The payment is under review. This is not a completed payment.
`transaction.funds_in_transfer`	Funds are being transferred.
`transaction.funds_received`	Funds have been received.
`transaction.processing`	The transaction is being processed.
`transaction.completed`	The transaction completed successfully.
`transaction.simulation_failed`	Transaction simulation failed.
`transaction.reverted`	The on-chain transaction reverted.
`transaction.refunded`	The payment was refunded.
`transaction.cancelled`	The queued withdrawal was cancelled.

An event reports a persisted transition, not a promise that every transaction passes through every status. For status meanings and polling, see Tracking transactions.

Example: completed transfer

Illustrative event (not a production observation):

transaction-completed

{
  "id": "00000000-0000-4000-8000-000000000001",
  "type": "transaction.completed",
  "occurredAt": "2026-10-20T15:00:00Z",
  "livemode": true,
  "payloadVersion": 2,
  "related": {
    "accountId": "b3f2d2dc-6abc-40fa-b2d2-d6d76b839c09",
    "userId": null,
    "entityId": null,
    "beneficiaryId": null,
    "transactionId": "53f2d2dc-6abc-40fa-b2d2-d6d76b839c09"
  },
  "data": {
    "transaction": {
      "transactionId": "53f2d2dc-6abc-40fa-b2d2-d6d76b839c09",
      "accountId": "b3f2d2dc-6abc-40fa-b2d2-d6d76b839c09",
      "type": "transfer",
      "status": "completed",
      "chainId": 8453,
      "vaultAddr": null,
      "sourceCurrency": "eurc",
      "sourceAmount": "100",
      "destinationCurrency": "eurc",
      "destinationAmount": "100",
      "intermediaryAmount": "100",
      "transactionHash": "0x1111111111111111111111111111111111111111111111111111111111111111",
      "broadcastedAt": "2026-10-20T14:59:50Z",
      "relatedTransactionId": null,
      "destinationAddress": "0x1111111111111111111111111111111111111111",
      "withdrawalRequest": null,
      "createdAt": "2026-10-20T14:59:40Z",
      "updatedAt": "2026-10-20T15:00:00Z"
    },
    "previousStatus": "processing"
  }
}

Reconciliation and replay

Verify signatures against the exact raw request body, acknowledge deliveries idempotently, and deduplicate by the event id. Delivery order should not be used as your only source of truth: retries can arrive after later events. Query the current transaction when reconciling its latest state. GET /v1/query/events exposes the same persisted lifecycle envelope with an additional createdAt. Replays and delivery retries keep the original payload. See Webhook delivery and signatures.

Integrator API

API endpoints

Event types

Example: completed transfer

Reconciliation and replay

​Event types

​Example: completed transfer

​Reconciliation and replay

Event types

Example: completed transfer

Reconciliation and replay