A deposit that cannot be fulfilled is returned to refund_address on the source chain, in the token that was deposited. The router pays it from its own balance, the same way it pays fulfillments.

What triggers one

What is deducted

The refund returns the deposit minus the refund fees committed in the quote, carried on the order as refund_fee_bridge: every source-side component (src_refund_gas, plus any src_ata_create, src_burn_cost, and dst_burn_cost) and, on a gasless order, sponsor_gas, because the operator already paid that gas to land the deposit. A Sui swap-first order also deducts src_swap_gas, the gas of the swap the relayer ran to create the deposit. With sponsor_fees the partner’s funding balance covers the relay gas instead and the refund keeps it, except for any part above sponsor_gas_max, which the user paid as sponsor_gas and the refund deducts. The rest of the breakdown is not charged: no spread, no referrer fee, no gas drop.
refund_fee_bridge is the most that can be deducted. If the bridge token’s price rises after the quote, the same fees cost fewer tokens and the deduction shrinks; it never grows past the committed amount, so the refund does not get more expensive if gas rises or the token falls afterwards.

Deferral when gas is high

If the live gas price would push the refund’s cost above the amount committed for it, the refund is not submitted at a loss and it is not taken out of the user’s principal. The order stays in pending_refund and is rechecked later, submitting as soon as gas comes back down. An order sitting in pending_refund for a while is usually this, not a failure.

When it does not happen automatically

Three states mean no refund was paid yet and a human is involved. All three are rare and none of them is silent. Surface these distinctly in your interface. A user seeing “failed” with no explanation will assume the funds are gone, when in practice they are in the escrow and recoverable through support.

Reading refund detail

GetOrder returns a refund message once one exists:
As with fulfillments, src_tx being present means submitted, not confirmed. The order state is the authority; see Order lifecycle.