Skip to main content
Webhooks notify your server when events happen — user KYC status changes, card transactions, wallet deposits, and collateral updates.

Setup

Configure your webhook endpoint using the Set Webhook endpoint. You’ll receive a webhookSecret (prefixed whsec_) that you’ll use to verify webhook signatures.

Events

KYC Events

Transaction Events

Wallet Events

Card Events

Payload Format

All webhooks are delivered as POST requests with a JSON body.

KYC Webhook

Approved
Denied
Needs Verification

Transaction Webhooks

Successful debit (USD merchant)
Declined transaction
Successful debit (non-USD merchant) Non-USD transactions produce two webhooks: the debit itself, followed by a separate cross-border FX fee webhook.
FX Fee (follows the debit)
The FX fee transaction ID is the original transaction ID with _fx appended. Use this to correlate the fee with its parent transaction.
Reversed transaction Sent when a previously approved transaction is reversed (e.g. merchant-initiated refund, chargeback, or authorization release). The reversal credits the original amount back to the card balance.
The reversal transaction ID is the original transaction ID with _rev appended. Use this to correlate the reversal with the original debit. If the original transaction had an FX fee, only the debit is reversed — the FX fee is not refunded.

Crypto Deposit Webhook

Sent when a stablecoin transfer to your deposit address is confirmed and credited to your wallet balance.
Your wallet balance is credited automatically when the deposit is confirmed on-chain. You can check your updated balance via the Get Balance endpoint.
chain and token are no longer fixed values. Do not assume base/usdc — read both fields, and treat an unrecognised pair as a deposit you should not act on.

Card Withdrawal Wallet Credit Webhook

Sent when a card withdrawal (POST /partner/card/withdraw) or full card liquidation (DELETE /partner/card/terminate/:serviceCardId) credits funds back to your partner wallet. Use data.reference to match the credit to the originating user transaction on your side.
Withdrawal
Liquidation
This event also fires for partner card liquidations when the terminated card has a positive balance. Use the source field to distinguish liquidations from regular withdrawals.

Crypto Withdrawal Webhook

Sent when a withdrawal request reaches a terminal state. The data.status field tells you which:
  • completed — USDC was sent on-chain. Includes txHash and explorerUrl.
  • cancelled — You cancelled the request via Cancel Withdrawal. Wallet was refunded.
  • rejected — An admin rejected the request. Wallet was refunded. reason may be present.
Completed
Cancelled
Rejected
Pre-terminal transitions (pendingapproved) do not fire webhooks. You only receive a webhook when the withdrawal reaches a terminal state.

Card Crypto Deposit Webhook

Sent when a stablecoin transfer to a crypto card’s deposit address is confirmed and credited to the card’s balance.

Supported networks

Deposit addresses are EVM addresses, so the same address receives on every EVM chain. Only the chain/token pairs below are credited — anything else that arrives has to be recovered manually, so check this list before sending. Staging uses the corresponding testnets: base-sepolia (84532), polygon-amoy (80002) and optimism-sepolia (11155420), which carry usdc only. Every deposit-address endpoint also returns a supportedNetworks array with the same information, so clients can read it at runtime rather than hardcoding this table.
Polygon has two USDC contracts and both are credited, but they are tracked separately because each reports the symbol USDC on-chain:The token field in the webhook tells you which one arrived, so match on it rather than assuming usdc. Bridged USDC.e exists on Polygon mainnet only — there is no equivalent on Amoy.
Optimism bridged USDC.e is not credited. Optimism also has two contracts reporting the symbol USDC, but only the native one is supported:A USDC.e transfer on Optimism produces no deposit and no webhook — it has to be recovered manually, so contact support if you send one. Check the contract your wallet or exchange is sending before you use Optimism: some label the bridged token simply “USDC”.

Signature Verification

Every webhook includes an X-Webhook-Signature header containing an HMAC-SHA256 hex digest. Always verify this signature before processing the webhook.

Retry Policy

If your endpoint doesn’t respond with a 2xx status code, the webhook is automatically retried with exponential backoff: After all retry attempts are exhausted, the webhook is marked as permanently failed. All webhook deliveries — including every retry attempt — are logged with status codes and response bodies for debugging.
Your webhook endpoint must respond within 30 seconds. Long-running processing should be handled asynchronously after acknowledging the webhook with a 200 response.
Retries are processed automatically every 30 seconds. If your endpoint comes back online within the retry window, pending webhooks will be delivered on the next retry cycle without any manual intervention.