On a card network, a refund is a button: the original charge is reversed, the money finds its way back, and the customer sees a credit a few days later. On a blockchain there is no button, because there is nothing to reverse. A confirmed transfer is final. What merchants call a "crypto refund" is really something else — a new payment, sent the other way, by you, to an address you have to get right. Once you see it that way, most refund questions answer themselves. This guide sets out the three decisions every refund involves, then works through the cases merchants actually meet, one at a time.
Refunds don't reverse. They resend.. A crypto refund is an outgoing transfer from your wallet to the customer. That means three things are yours to decide each time: where it goes, how much of what it is, and who pays the network fee. Write those three down as policy before the first request arrives, and refunds become routine.
Background — why there is no undo: Push payments, final settlement
Cards are a pull system with a referee: the merchant takes money through a network that can also put it back, and a bank stands behind the customer if there's a dispute. A blockchain payment is a push from the customer's wallet, confirmed by the network and then final. Nobody — not the merchant, not the gateway, not the customer — can claw it back. That finality is why crypto has no chargebacks, and it's also why refunds work differently: the only way money goes back is if the merchant sends it.
In practice this is a fair trade for most businesses. You lose the convenience of a reversal button. You gain certainty that a payment, once confirmed, stays paid — and the decision to refund is always yours, made under a written policy rather than a dispute process you don't control.
"Refund" in your CPAY transaction list is not a customer refund. In CPAY's transaction history, the Refund type means something specific and internal: when the system fronts the network fee needed to move funds into your account's wallet, a Refund transaction reimburses the system's fee wallet once your wallet has the native coin to cover it. It has nothing to do with sending money back to a customer, and the notifications you can enable for "Refund — New" are about this internal top-up. A refund to a customer is an ordinary outgoing transfer — a withdrawal.The three decisions: Where, how much of what, who pays
1. Where it goes. The tempting answer is "back to the address it came from." Resist it. Customers often pay from an exchange account, and the address a payment arrives from is then the exchange's own wallet, not anything the customer controls; funds sent there may not reach them at all. The safe rule: ask the customer for a refund address, through a channel where you know it's them (their logged-in account, a verified email thread), and have them confirm the network. Save it as an entry in your address book before sending, so the person approving the refund is checking a named contact, not a pasted string.
2. How much of what. If the customer paid 100 USDT for a $100 order, the answer is easy. If they paid in a volatile asset, it isn't: the token may be worth more or less than when they paid. You need a rule that picks one of two currencies of account — refund the same token amount they sent, or refund the same fiat value the order was priced at, converted at today's rate. Both are defensible; switching between them case by case is not. Stablecoin-priced orders make the question disappear, which is one more reason to price in USDT or USDC.
3. Who pays the network fee. Sending a refund costs a network fee. In CPAY, withdrawal fees are estimated and taken from the wallet on top of the amount you send, so the customer receives exactly the figure you enter. Decide whether that is a cost of doing business (usual for your mistakes) or deducted from the refund (sometimes fair for a change of mind) — and say so in your terms.
The casebook: Six situations, six answers
Most refund requests fall into a handful of patterns. Each has a sensible default; your policy decides the details.
Case 1 — Full refund for a cancelled order
The cleanest case. The customer paid the right amount, on the right network, and the order won't be fulfilled. Collect a refund address through the customer's account, confirm the network, and send the full amount under your currency-of-account rule. If the cancellation is yours, absorb the network fee.
Case 2 — Partial refund for part of an order
One item out of stock, a service partly delivered. Compute the full refund under your rule, then scale it by the refunded share, rounding down to the token's precision — each token has a fixed number of decimal places, and amounts beyond it are rejected. Record the share, the rule and any rate used next to the refund, so the next person to read the ledger can reproduce the number.
Case 3 — Overpayment
The customer sent more than the invoice. You don't owe a reversal; you owe the difference. Many merchants refund overpayments above a small threshold and keep tiny excesses as credit against the next order — either is fine if it's written down. Send the difference to a confirmed address; don't refund the whole payment and ask them to pay again.
Case 4 — Underpayment or late payment
The customer sent too little, or paid after the charge window closed. The choice is to top up or return: ask for the remainder and complete the order, or refund what arrived. The pattern for detecting these cases — and why a gateway reports them separately — is covered in our guide to failed and underpaid transactions. If you return the funds, decide in advance whether the network fee comes out of them.
Case 5 — Wrong token or wrong network
A customer sends a token you don't accept, or the right token on a network you didn't offer. Whether it can be recovered depends on whether the receiving address can access that asset on that chain. If it can, treat it as a refund and send it back to a confirmed address — on the network the customer asks for, not the one they used by mistake. If it can't, be honest quickly rather than promising a recovery you can't deliver. Clear network labels on the payment page prevent most of these.
Case 6 — "The price moved, I want my crypto back"
The customer paid in a volatile asset, the asset moved, and now they'd like a refund that suits the new price. This is exactly why the currency-of-account rule must be written before it's needed. Apply it as written, explain it once, and don't improvise: a refund policy that bends with the market will be tested every time the market moves.
The kindest refund policy is the one written down before anyone asks. (A rule of thumb, not a quote.)
At a glance: The casebook as a table
In CPAY: Sending the refund
Mechanically, a customer refund in CPAY is a withdrawal from the wallet that received the payment. On the Withdrawal page you pick the wallet, press Send, enter the destination and amount, and confirm with 2FA; fees are shown before you confirm and charged on top of the amount. Saving refund addresses in the Address Book first makes the confirmation step a check of a named entry rather than of a raw string. Two practical notes from the documentation: the dashboard sets a minimum withdrawal amount, so check it before promising a small refund, and many small refunds can be grouped into a single Multisend run, covered in our mass payouts guide.
Finally, keep the paper trail. Store the refund's transaction hash with the original order and payment, along with the rule, rate and address confirmation. Transaction exports per currency make month-end matching straightforward.
Before launch: A refund policy in six lines
- Address: refunds go only to an address the customer confirms through their account — never automatically to the sending address.
- Currency of account: stablecoin orders refund in the same stablecoin; volatile-asset orders refund by [same token amount / same fiat value] — pick one.
- Network fee: paid by us when the refund is our fault; deducted when it's a change of mind — or always paid by us. Choose and publish.
- Overpayments: refunded above [threshold]; below it, held as credit.
- Timing: refunds sent within [N] business days of an approved request.
- Records: every refund stores the order, original transaction hash, refund hash, rule, rate and approver.
FAQ — Common follow-ups
Can a crypto payment be reversed like a card payment?
No. A confirmed blockchain transfer is final; nobody can pull it back. A refund is a separate, new transfer that you send from your wallet to the customer.
Why not just send the refund back to the address that paid?
Because that address may not belong to the customer. Payments from exchange accounts arrive from the exchange's own wallets, and funds sent back there may never reach the customer. Always ask for a refund address through a verified channel, and confirm the network.
Do customers get the original token amount or the original price?
Whichever your policy says. For stablecoin-priced orders the two are the same. For volatile assets, pick one rule — same token amount, or same fiat value at today's rate — publish it, and apply it consistently.
What does the "Refund" status in my CPAY transactions mean?
It's an internal transaction: the reimbursement of the system's fee wallet after it fronted the network fee needed to move funds into your account's wallet. It is not a refund to a customer.
Are there chargebacks in crypto payments?
No. Settlement is final, so a customer can't force a reversal through a bank. That removes dispute fees and friendly fraud — and puts the responsibility for fair, clearly stated refund terms on you.
Want crypto payments with final settlement and refunds on your own terms? Book a call with the CPAY team, or read the withdrawal documentation.
Sources: CPAY Documentation — System components, Withdrawal, Address Book, Release 4.7.
