Skip to main content
We never hold your money, so we can never send a refund on your behalf. Every refund is signed by you, from your wallet, to an address the customer gives you. The dashboard does help you do it: Payments has a per-order Refund action that prepares the transfer, blocks unsafe destinations, and records it against the order once you’ve signed.
Never refund to the address the payment came from.Exchange withdrawals come from a shared hot wallet belonging to the exchange, not from your customer. Sending funds back there is unattributable and almost always a permanent loss for the customer.Always ask the customer for a self-custody address at refund time.

The process

Customer requests a refund

Through your own support channel. We’re not in that conversation — the dashboard only helps you carry out and record the refund you decide to give.

Ask for a receiving address

Their own wallet, on a chain they can access, for the token you’ll send. Ask at refund time rather than reusing anything on file.

Verify it

Have them confirm the address independently — a message from a known account, not just a reply in a ticket. Address-swap fraud is common.

Send from your wallet

On Payments, the Refund action on the order prepares the token transfer, requires the address the customer supplied, blocks your own settlement wallet as a destination, and — once you sign it in your own wallet — records the transaction hash against the order so it shows as refunded in your ledger. It warns against returning funds to the inbound sender on every refund, but it can’t block that address for you: the payer’s wallet isn’t recorded on the order, so confirming the destination is a fresh customer-supplied one is your check to make. Sending the transfer by hand from any wallet still works if you prefer; keep the transaction hash against the order yourself if you do.

Why it works this way

Your money goes from customer to your pool to your wallet. At no point is it ours to return.
For a large share of payments the sender address belongs to an exchange, so “send it back where it came from” is actively harmful. There’s no way to automate around a customer who must supply an address.
An on-chain window during which a payment can be reversed is a free option: pay, watch the market, reverse if it moves against you. Removing it protects merchants and settles funds faster.

The fee — and what has to happen first

You can only refund from money you physically hold. A refund is a transfer you sign from your own wallet, so the funds have to be in it: your pool must have been released — split, with your share credited to you — and that credited share must then have been withdrawn to your payout address. Until both have happened, the money for that order is still sitting in the pool and there is nothing in your wallet to send. Most of the time both happen without you. Our keeper releases your pool and sends your share on, normally within minutes and at the latest when your maximum wait elapses — 24 hours by default. What can catch you out is a very recent order, or a pool still holding less than 1.00 of your settlement token, which cannot be released at all until the balance builds. Before you promise a customer a same-day refund, open Pool and look for an unreleased or not-yet-withdrawn balance: on the EVM networks Release now and Withdraw move it immediately, at the cost of two transactions you sign and fund in that chain’s native token. On TRON both steps are automatic. Claiming.
Fees are not returned on refunds. The platform fee is taken on-chain at distribute() — 0.75% to us and 0.25% to your partner, on the gross — and on the deposit rail, the network fee is taken separately at sweep(), before the pool ever sees the money. Neither is reversible: the pool is immutable and ownerless, so nothing can uncredit a distribution after the fact. Refunding a customer in full means absorbing that yourself: on a connect-rail €100 order you received €99.00 and would be refunding €100.
Because a refund is a transfer you sign from your own wallet, it also can’t happen before you’ve claimed — settle → distribute → claim → refund, in that order. “Claimable but unclaimed” shows in the order as the blocker until you press Claim.
This is a stated policy (CRY-274), not a placeholder: the fee is not returned, ever, on any refund. It’s incumbent-normal — card processors stopped returning fees on refunds in 2019 — and it’s worth putting in your own terms so it isn’t news to a customer mid-dispute.

Cases

Put it in your terms

Customers should know before paying that crypto payments are final, refunds are handled directly by you, and a refund requires them to supply an address.
Also worth stating: refunds go to an address the customer provides at refund time, and you will never ask for a private key or seed phrase. It sets an expectation that makes later impersonation attempts easier for them to spot.

Chargebacks don’t exist

Nobody can reverse a confirmed payment — not the customer, not their bank, not us. You’re protected from fraudulent reversals, and you also cannot claw back a payment you’d rather not have accepted. For customers, this is a genuine reduction in protection compared to a card. Being upfront about it is both fairer and better for your dispute rate.