conversion_notification_update, on every status change. It covers both on-ramps and off-ramps.
This page documents the payload. For what each status means and when it changes, see Conversions. For delivery, retries, and sender verification, see Webhooks.
Envelope
The two IDs do different jobs. The top-level
id identifies the event; data.id identifies the conversion and stays the same across all of its events. Deduplicate your own logic on data.id plus data.status.
Conversion object
Source object
Destination object
Fee object
Refund details object
Present only whenstatus is RETURNED. The object is always included on RETURNED; individual keys inside it may be omitted when Bastion has not populated that value yet (for example on some US domestic returns).
Refund failure details object
Always present onrefund_details.
Enumerated values
Examples
US off-ramp
USDC to USD by wire. Fees are deducted, so the recipient getsamount minus fees_total.
International off-ramp
USDC to MXN via SPEI, with a developer fee added on top.source.total is higher than amount because the fees sit on top of it.
Returned off-ramp
The payout went out and the receiving bank sent it back.failure_reason and refund_details are set; there is no completed_at, and destination.amount and exchange_rate are omitted because settlement did not complete.
refund_details.tx_hash is the on-chain hash of the cross-app credit from Bastion’s intermediary account back to the customer. It is not the inbound refund transaction from the payment provider.
On-ramp
USD to USDC via a Virtual Account. There is no submit call, so the first event is where you learn the conversion’s ID. Fees are deducted from the wire, sodestination.amount is amount minus fees_total.
destination.amount and completed_at are empty.