Event catalogue (`eventType`)

Matches code StableWebhookEvent literally.
Envelope: Virtual Account Overview.

Full table

eventType	Product	Scenario	Guide
`VIRTUAL_ACCOUNT_UPDATED`	VA	Account status	virtual-account
`VIRTUAL_ACCOUNT_ORDER_UPDATED`	VA	Payin/Payout order	virtual-account
`SUB_VIRTUAL_ACCOUNT_RFI_REQUIRED`	VA	RFI required	virtual-account
`STABLE_ORDER_UPDATED`	Convert	FX order	convert
`DEPOSIT_ORDER_NOTIFICATION`	Wallet	Deposit progress and completion — carries `whiteListStatus`	wallet
`DEPOSIT_SENDER_DETAIL_UPDATED`	Wallet	Deposit sender	wallet
`WALLET_ADDRESS_UPDATED`	Wallet	Address update	wallet
`WALLET_WITHDRAW_UPDATED`	Wallet	Withdraw	wallet
`WALLET_TRANSFER_ORDER_UPDATED`	Wallet	Internal transfer	wallet
`SUB_WALLET_UPDATED`	Wallet / V2	Sub-wallet	wallet / excluded
`PAYMENT_LINK_UPDATED`	Payment Link v1	Payment link	excluded
`UNALLOCATED_FUND_RECEIVED`	Payment Link v1	Unallocated funds	excluded
`COLLECT_ORDER_UPDATED`	Collect v2	Collect order — carries `whiteListStatus`	excluded
`USD_PAYOUT_ORDER_UPDATED`	Collect v2	USD payout	excluded

Convert example

{
  "eventId": "550e8400-e29b-41d4-a716-446655440000",
  "eventType": "STABLE_ORDER_UPDATED",
  "referenceId": "ord_123",
  "status": "success",
  "timestamp": 1690000000000,
  "data": {
    "orderId": "ord_123",
    "merchantOrderId": "m_001",
    "orderStatus": "success",
    "businessType": "STABLE_BUY"
  }
}

VA refund events (this release)

VIRTUAL_ACCOUNT_ORDER_UPDATED covers original pay-in/payout and independent RE* refund children.

Terminal refund notification is the RE* payload (businessType PAYIN_REFUND / PAYOUT_REFUND).

Do not treat original-order orderStatus=REFUNDED as the refund terminal event.

Webhook envelope status follows the child's orderStatus: PROCESSING / REFUNDED / FAIL. Order state in data is orderStatus.

Wallet deposit-whitelist events (this release)

Deposited funds stay in the unavailable balance of the receiving wallet until the payer source address is
whitelisted and the payer details pass review.

There is no standalone whitelist event. The gate rides on the order webhook you already consume, as
data.whiteListStatus.

Your flow	eventType	Payer details needed	Order finished
Plain wallet deposits	`DEPOSIT_ORDER_NOTIFICATION`	`status` `PROCESSING` with `whiteListStatus` `init` or `rejected`	`status` `SUCCESS`, normally `whiteListStatus` `approved`
Collection / payment-link orders	`COLLECT_ORDER_UPDATED`	`orderStatus` `PROCESSING` with `whiteListStatus` `init` or `rejected`	`orderStatus` `SUCCESS`
Source-address review	`WALLET_ADDRESS_UPDATED`	—	Address moved to `ACTIVE` or `FAILED`

Answer a gate with POST /v1/wallet/deposit-whitelist/transactions/{transactionId}/submit.

A deposit from an already whitelisted address never shows a gate. Once the source address is ACTIVE,
later deposits from it skip the whitelist flow and arrive with whiteListStatus approved or null. A
handler that waits for a gate before booking repeat deposits will stall.

Whitelist approval is not announced on its own, and neither is the moment the funds become spendable.
Completion is the order webhook reaching SUCCESS.

whiteListStatus replaces submitStatus and is lowercase: init · pending · approved · rejected.
Poll GET /v1/wallet/transaction/list?whiteListStatus=init|rejected when webhooks are missed; pending-list was removed.

COLLECT_ORDER_UPDATED also carries whiteListStatus for gated collection orders.

Guide: Wallet · Deposit whitelist.

Event catalogue

Event catalogue (eventType)#

Full table#

Convert example#

VA refund events (this release)#

Wallet deposit-whitelist events (this release)#

Event catalogue (`eventType`)

Full table

Convert example

VA refund events (this release)

Wallet deposit-whitelist events (this release)