Crypto Refunds 2026: How Merchants Send Money Back

A refund is a new payment, and that changes everything

A customer pays you 0.0013 BTC for a jacket, the jacket does not fit, and now you owe them their money back. On a card you would press refund and the network would unwind the authorisation for you. On-chain there is nothing to unwind, and that is the point — the irreversibility you accepted crypto for is the same property that makes crypto refunds a job rather than a button. We read the published refund documentation of seven gateways for this piece and priced the on-chain leg against live network data, because the cost of getting this wrong is a customer who is out of pocket and a support thread you cannot close.

CoinGate says it as plainly as anyone in its own merchant refunds documentation: a refund "is not a reversal. It is a new payment you send back to the customer, with you choosing the amount and currency." Three consequences fall straight out of that sentence, and most merchants meet them one at a time, in production.

None of that is exotic. It is just that the refund flow is the part of a gateway nobody demos, so it stays invisible until the first return lands. This is the same failure pattern we found on the receiving side in our guide to crypto payments that never arrive: the documented happy path is fine, and the exception path is where the money sits.

Does your gateway even have a refund tool?

Start here, because the answer is not always yes and it follows a rule that nobody states: a refund tool can only exist where the gateway holds a balance for you. If the gateway never touches your money, there is nothing for it to send back, and the refund is your job with your own wallet. That single fact splits the market cleanly in two.

NOWPayments is the clearest case. Its published refund policy states that because it is a non-custodial service, "we do not store your funds and have no control over them", and instructs merchants to "simply send your customer the required amount of money from your crypto wallet", looking the exact sum up by Payment ID. It will step in for deposits that went wrong at the customer's end — wrong asset, wrong network, a missing memo, a payment below the minimum — but a change of mind is not that. Plisio goes further and publishes no refund status whatsoever: its transaction status documentation lists New, Pending, Completed, Underpaid, Cancelled/Expired and Error, and handles overpayment by giving you "the client's actual order and e-mail address in case the seller will have to contact the client to compensate overpayment".

Gateway	Refund mechanism	Partial refunds	Who supplies the address
CoinGate	Refund form on the original order, dashboard or API	Yes, up to order value	Merchant enters it, customer confirms by email
BitPay	Refund request against the invoice ID, six statuses	Yes, plus underpayment and overpayment types	Customer, via an emailed claim link
Cryptomus	POST /v1/payment/refund, completed payments only	Yes, not more than the amount paid	Merchant passes it in the API call
Crypto.com Pay	Refund button on the payment in the dashboard	Yes	Customer, emailed for on-chain payments
BTCPay Server	"Issue a refund" creates a pull payment link	Yes, you set the amount	Customer claims, merchant approves and signs
NOWPayments	None — send it from your own wallet	Whatever you choose to send	You ask the customer yourself
Plisio	None published — no refund status exists	Not applicable	You ask the customer yourself

BTCPay Server sits in an interesting middle. It is self-hosted and nobody holds your keys, yet it does ship a refund flow — built, as its documentation notes, "on top of the Pull Payments feature". You issue a refund against the invoice, share a link, the customer supplies an address and claims it, then you approve and sign. The docs are explicit that "BTCPay Server does not approve and pay a payout automatically", so a refund on BTCPay always costs you a manual step. If the trade-off between these architectures is new to you, our explainer on custodial versus non-custodial gateways covers the same split on the receiving side.

What crypto refunds cost on the wire

This is where the money quietly goes, and it is the section every competing article on this topic skips. A refund is an outbound transaction, so it pays whatever the chain charges that day. We priced each rail against live network data on 10 September 2026: Bitcoin fee estimates from mempool.space, Ethereum's base fee read from block 25,947,632 at 0.305 gwei, TRON's getEnergyFee chain parameter at 100 sun, and spot prices of $77,289 BTC, $2,440.68 ETH, $0.3387 TRX and $100.17 SOL.

Refund sent as	What the chain charges	Cost, 10 Sep 2026	Cost of a $40 refund
USDT on TRON (TRC-20), new recipient	~130,285 energy at 100 sun	$4.41	11.0%
USDT on TRON (TRC-20), existing holder	~64,895 energy at 100 sun	$2.20	5.5%
Bitcoin, next-block priority	141 vB at 5 sat/vB	$0.54	1.4%
Bitcoin, economy	141 vB at 1 sat/vB	$0.11	0.3%
USDT or USDC on Ethereum (ERC-20)	~63,000 gas at 0.305 gwei	$0.047	0.1%
Ether on Ethereum	21,000 gas at 0.305 gwei	$0.016	0.04%
SOL on Solana	5,000 lamports base fee	$0.0005	0.001%

Read the top two rows against the fifth, because that comparison is the finding. Refunding a stablecoin over TRC-20 cost between 47 and 94 times what the same refund cost on Ethereum on the day we measured. TRON's energy price is fixed by a chain parameter rather than an auction, so it does not fall when the network is quiet, while Ethereum's base fee at 0.305 gwei is a fraction of what it was in the years when "use TRON, it's cheaper" became received wisdom. If your refund volume is meaningful and your customers hold USDT, the chain you default to is worth re-checking rather than inheriting — our USDT acceptance guide goes through the same choice on the inbound leg.

One caveat we will not paper over: the two TRON energy figures are the well-known typical consumption of a TRC-20 transfer to an address that already holds the token and to one that does not. The 100 sun energy price is read from the chain today; the energy quantity is a standard figure rather than one we measured, so treat those two rows as a close estimate and the direction of the gap as the point. Note also that a merchant refunding an ERC-20 token from a self-custody wallet needs the network token to pay gas — Coinbase Commerce's help centre spells this out for its own self-custody flow, warning that refunding USDC on Ethereum requires a sufficient ETH balance. An empty gas tank stops a refund as effectively as an empty balance.

The gateway's fee, and who actually pays it

On top of the chain, the gateway takes its own cut for issuing the refund — and the more interesting question is whose pocket it comes out of, because on two of the major gateways that is a parameter with a default you probably have not looked at.

Gateway	Published refund fee	Who pays by default	How you change it
CoinGate	0.25 EUR to issue, plus 0.1% on conversion only	Merchant	Refund in the currency you hold and the 0.1% disappears
BitPay	Refund fee, amount not published on the API reference	Merchant — buyerPaysRefundFee defaults to false	Pass buyerPaysRefundFee: true on the refund request
Cryptomus	Commission on the refund transaction	Whichever you set	is_subtract: true takes it from your balance, false from the refund
Crypto.com Pay	Network fees may apply, excluded from its value guarantee	Customer absorbs the network fee	Not configurable
BTCPay / NOWPayments	None — no platform sits in the middle	Merchant pays the network fee	Send less, or pick a cheaper chain

CoinGate's structure is the one worth studying because it is fully published: 0.25 EUR per refund plus 0.1% that applies only when a conversion happens, and, in its own words, "refund in the same currency you hold, and there is no conversion fee at all." Run that against order size and the flat component dominates at the bottom of the range — 0.26 EUR on a 12 EUR refund is 2.2% of the order, while 1.25 EUR on a 1,000 EUR refund is 0.13%. Low-ticket sellers processing returns are paying a percentage that would look alarming on a card statement, and it is invisible until you total it. That flat-fee-versus-percentage dynamic is the same one we mapped across the whole market in our gateway fee comparison.

Refund the coins or refund the value?

Here is the question that generates the arguments. A customer paid 0.0013 BTC for a $100 jacket. By the time they return it, bitcoin has moved 20%. Do you send back 0.0013 BTC, or $100 worth of BTC at today's price? Those are different numbers, and someone is worse off either way.

What surprised us is how completely the industry has converged, and how quietly. Every gateway we checked refunds the fiat value at the current rate, not the original quantity of coins. CoinGate states that "the entered amount will be converted to a cryptocurrency a customer wants to get back using its current exchange rate". Crypto.com Pay "guarantees the refund cryptocurrency amount to be the same value as the original pricing value (excluding blockchain network fees, if applicable)". BitPay's refund reference lists a full refund "at current rate" as the live option and marks its fixed-rate refund type deprecated — a design decision, not an omission. BTCPay, characteristically, hands you the choice and then warns in its pull payments documentation that once you confirm a payout "the rate is then fixed, even if you don't complete the payment".

Gateway	Rate policy	Who carries the price move
CoinGate	Converts the entered amount at the current exchange rate	Customer
BitPay	Full refund at current rate; fixed rate deprecated	Customer
Crypto.com Pay	Guarantees the original pricing value, net of network fees	Customer
BTCPay Server	Store rate at the moment you confirm, then fixed	Whoever you decide
NOWPayments / Plisio	None — you choose the number by hand	Whoever you decide

The convergence makes commercial sense — refunding the original coin quantity would let a customer buy at a low and return at a high, which is a free option written by your returns desk. But it does hand the customer a loss when the coin has fallen, and none of the four gateways says so in plain language. If you accept crypto and you refund at value, say it in your policy in one sentence so nobody discovers it during a return. The one genuinely clean escape is stablecoins: refund a USDC payment in USDC and the question never arises, which is a quiet argument for the stablecoin-first posture we describe in our stablecoin payments guide.

The refund address is where the money gets lost

Of everything in this article, this is the one that costs real money, and it is a single instinct that causes it: sending the refund back to the address the payment came from. It looks like the obvious move. It is often wrong.

If the customer paid from an exchange account, the sending address belongs to the exchange, not to them. It is a hot wallet or a shared deposit address, and coins arriving there unannounced may never be credited to the person who bought your jacket. They cannot be recalled either. This is precisely why every gateway with a refund tool refuses to reuse the sending address and goes back to the customer instead — CoinGate takes wallet details on the form and then "sends a confirmation request to the customer" who "must also confirm the refund request via email"; BitPay emails a claim link and collects the address there; Crypto.com Pay says that for on-chain payments "we will email the customer to ask for a valid wallet address before proceeding".

Worth noting that these are the same failure modes NOWPayments will actually help unpick on the inbound side — wrong asset, wrong network, missing memo, below minimum — and it maintains an address whitelisting arrangement so merchants who refund often do not repeat a validation step every time. On the outbound side, though, nobody is checking your work. The chain does what you tell it.

The deadlines nobody puts on a pricing page

Refund flows expire, and the windows are short enough to matter. BitPay's support centre documents that a refund email link expires within three days, after which the customer must contact support through the BitBot to be issued a new one, and that a refund which cannot be processed — a merchant with an insufficient balance, for instance — expires after ten days. Once the address is in, BitPay says the refund should complete within one to two business days.

Cryptomus has a different and more surprising blocker. Its refund documentation requires that payouts are not blocked on your merchant account, and notes that a password change blocks payouts for 24 hours. Rotate a credential on a Friday afternoon and your refunds are frozen until Saturday, which is not a sentence anyone expects to read in a payments runbook. The rest of its conditions are sensible: refunds only for completed payments, no more than the amount paid, and the merchant wallet attached to the invoice still has to exist.

A note on sourcing, since this niche punishes sloppy figures. BitPay's support pages sit behind a bot challenge that returns a block page to automated fetchers, so the three-day and ten-day windows were read through search results on BitPay's own support domain rather than fetched directly, and everything else here comes from documentation we retrieved in full on 10 September 2026. Check the current page before you write either number into a customer-facing policy.

Writing a refund policy that survives a real customer

Most crypto refund policies are a card refund policy with the word "crypto" pasted in, which is why they fall apart on first contact. Four sentences fix it, and each one answers a question this article has raised.

Then do the operational half, which takes about an hour. Confirm your gateway actually has a refund tool before you launch, not on the day of the first return. Keep a small float in the currencies you sell in, plus the native gas token on any chain where you accept tokens, because a refund you cannot fund is worse than one you have to explain. And keep the customer's email attached to every order, since on BitPay a missing contact detail means the refund path does not exist at all.

Refunds sit next to disputes without being the same thing, and the difference is worth internalising: a refund is you choosing to send money back, while a dispute is a customer trying to make you. Crypto only removes the second one. Our guide to crypto chargebacks and payment disputes covers what replaces the card networks' arbitration, and it pairs directly with what you have just read.

FAQ

Affiliate disclosure: payyd.co earns a commission on sign-ups made through our /go/ links, including the NOWPayments link in this article. We have no affiliate relationship with BitPay, BTCPay Server or Crypto.com Pay and include them where they genuinely fit. Every fee, parameter and time limit in this article was read from the provider's own published documentation on 10 September 2026, and network costs were priced against live chain data the same day — both change, so check the current page and the current fee market before relying on a number here. Gateway ordering reflects payyd's editorial criteria, not commission rates.