Skip to main content
When a transaction fails after funds have already moved — a receiving bank rejects the payment, a compliance reversal, an expired transaction — the money comes back. This guide covers how refunds are handled, where the returned funds go, and what to configure so refunds happen without you touching anything.

​
How refunds work

Every transaction gets a refund plan when it’s created. By default, auto-refund is enabled: if the transaction fails after funds moved, Borderless dispatches the refund automatically and the transaction ends in the Refunded status. Refunds are asynchronous — the status updates when the refund completes, and you can follow it on the transaction’s detail page like any other state change. Refund plans can also be dispatched manually through the API — see the Developer Guides if your team wants explicit control over when refunds go out.

​
Where the money goes

A refund plan resolves its destination by hierarchy — the most specific setting wins:
  1. A destination set on the refund itself when it’s dispatched.
  2. A destination set on the individual transaction.
  3. Your organization’s default refund destination.
Depending on what the provider supports, returned funds can go to a specified wallet address, back to the original onchain sender, or stay in your balance with the provider.

​
Set your default refund destination

The organization default is the safety net — it catches every refund that doesn’t specify its own destination. Configure it on the Team page under Organization Settings: Organization Administration covers the steps. Default refund destination modal on the Team page, with destination options and the automatic refund toggle One thing to keep current: the destination needs re-confirming every 90 days. If it lapses, its badge moves to an expired state and automatic refunds stop working until you re-confirm — a two-click task that’s worth a recurring reminder for whoever owns it. Only Owners can manage this setting.

​
See refunds on your transactions

Refunded transactions show the Refunded status in the Transactions list — filter by status to see them all. Open one for the full picture: the original failure reason and the state timeline. Transaction detail page for a refunded deposit, showing the Refunded status and the failure reason

​
Troubleshooting

A failed transaction hasn’t refunded. Check your default refund destination on the Team page first — if its badge shows expired, re-confirm it; automatic refunds don’t run while it’s lapsed. If the destination is healthy and the refund still hasn’t landed, contact your Borderless representative with the transaction ID — refunds are asynchronous and some rails take longer than others. I don’t know where a refund went. The destination hierarchy above tells you where to look: a transaction-specific destination first, then the organization default. The transaction’s detail page shows its state history. I want refunds to go somewhere else for one transaction. Destinations can be set per transaction (and per dispatched refund) through the API — see the Developer Guides. In the platform, the organization default applies.