Crypto chargebacks and refunds: the merchant's playbook

Every merchant who has taken card payments knows the letter. A transaction from four months ago, reversed. A fee on top. A note that your dispute ratio is now a problem. Crypto payments do not work that way: there is no issuer to appeal to, no acquirer holding a reserve, and no mechanism anywhere that pulls settled funds back out of your balance. That is the headline, and it is genuinely the reason a lot of businesses move. The half nobody writes about is the other one — customers still change their minds, still overpay, still send USDT on the wrong network — and once the bank is gone, the process for handling all of it is yours to write. This guide is that process.

Chargeback, refund, reversal: three words merchants use interchangeably#

They are not synonyms, and the difference is exactly where crypto changes the economics. A chargeback is a forced reversal decided by someone else. A refund is a payment you choose to send. Card rails bundle the two so tightly that merchants stop distinguishing them; on-chain, only one of them exists.

Read that last column again, because it is the whole guide in four rows. Moving to crypto does not remove your obligation to make customers whole. It removes the third party who could make that decision for you, at a cost, months later, on evidence you never got to see.

Why an on-chain payment cannot be pulled back#

A card payment is a message: a promise to move money between accounts that two banks reconcile later, and either bank can revisit that promise for months. Most card networks allow roughly 120 days from the transaction — longer for some reason codes — during which a settled sale can become a debit. A blockchain payment is not a message about money; it is the money. Once the transaction is mined and buried under enough blocks, no participant in the system has the authority to undo it, because there is no account to debit and no operator with a reverse button. Control follows the keys.

Finality is therefore a clock, not a committee. Different networks tick at different speeds: Solana and Tron settle in seconds, Ethereum in roughly a minute, Bitcoin, Monero and Dogecoin in about twenty. CryptoPayIn credits a payment when it crosses that network's confirmation threshold, and the live thresholds are published on the currencies page. After that point the sale is closed, permanently, and three things you have quietly been paying for on card rails disappear at the same time:

• The rolling reserve. Nobody needs to hold 5–10% of your revenue for six months against future disputes, because there are no future disputes.
• The dispute ratio. Card monitoring programmes start applying penalties at roughly one dispute per hundred transactions and can end in termination. There is no ratio to breach here — which is precisely why the industries card processors call high-risk can be served at a normal price.
• The 120-day tail. Your revenue from March is yours in March. Cash-flow planning stops carrying an invisible liability.

The refund policy you now have to write yourself#

On CryptoPayIn a refund is not a special object with its own workflow: it is a payout to an address the customer gives you, sent from your balance like any withdrawal. That simplicity is the point — there is no dispute queue, no evidence upload, no 30-day wait for a verdict. It also means every judgement call the bank used to make is now a line in your terms. There are four of them.

1. In what amount — the coin or the fiat value?

A customer paid 0.004 BTC for a €300 order three weeks ago. Bitcoin has moved 15% since. Do you send back 0.004 BTC, or €300 worth of BTC at today's rate? Both are defensible; only one can be in your terms, and a policy that stays silent will be read in whichever direction costs you money.

Whichever you pick, one sentence in your terms settles it forever. And note the reason stablecoin acceptance keeps showing up in operational guides rather than ideological ones: refund 100 USDT against a 100 USDT payment and the question never arises. For most merchants, the majority of refund headaches are volatility headaches wearing a costume.

2. To which address — never the one you assume

The most expensive refund mistake in crypto is sending money to the address the payment came from. Plenty of customers pay directly from an exchange account, and an exchange withdrawal address is not a deposit address: funds returned there are frequently unattributable and occasionally unrecoverable. Some assets do not even offer you the option — Monero has no visible sender address at all, by design.

So the rule is universal and simple: always ask the customer, in writing, for the return address and the asset, and repeat both back before you send. Include the network in that confirmation (USDT on Tron and USDT on Ethereum are different destinations), and treat the message that supplies it as the authenticated instruction it is — from the account or email that placed the order, never from whichever channel a stranger happens to use.

3. Who pays the network fee

A refund is an on-chain transaction and someone funds it. On CryptoPayIn the payout's network fee is deducted from the amount sent, at cost, with the live figure shown before you confirm — no margin is added. Deducting it from the refund is standard and fair; absorbing it is a nice gesture on a $200 order and a bad habit on a $5 one. Say which you do, and prefer refunding on the cheap rail: returning a $30 order over Ethereum can burn a meaningful slice of it in gas, while the same refund on Tron or Solana costs a rounding error.

4. Gross or net of the processing fee

The 1% was charged when the money settled; sending it back is a new payout, so a full refund costs you the original 1% plus the return transaction's network fee. Most merchants refund the gross amount and book the difference as the price of goodwill — which, next to a $25 chargeback fee plus the lost goods plus the ratio damage, it comfortably is. Just make the choice deliberately instead of discovering it at month-end.

The seven things that actually go wrong#

In practice, almost every "problem payment" is one of seven situations. None of them is a dispute; all of them have a deterministic answer.

Underpayment

The customer sends less than the invoice — a mistyped amount, or a wallet that quietly subtracted its own fee. The invoice stays open and shows the exact remainder, at checkout and in your dashboard, and it never silently settles as paid. Nudge the customer for the difference; if they walk away, refund what arrived minus the network fee, or credit it. An invoice that never completes costs you nothing in processing fees.

Overpayment

The full received amount is credited and the invoice settles as paid. Keep the overage, or return it as a payout — for a few cents, keeping it is the sane answer; for a decimal-point accident, returning it immediately buys a customer for life.

Payment after expiry

Invoices expire after 30 minutes by default, and you can set anything up to 24 hours. An expired invoice cannot be paid — but funds that already landed on-chain still credit, so late money is never lost. Match it to the order manually and either fulfil or refund.

Right asset, wrong network

The classic: USDT sent over Ethereum to a Tron deposit address. The tokens exist, but on a chain where that address means nothing to your invoice. Whether anything can be done depends entirely on who controls the receiving key on the other chain — sometimes the answer is a manual recovery, sometimes it is genuinely nothing. This is why a good checkout names the network in large type next to the address, and why your support macro for it should exist before you need it.

Wrong asset entirely

Bitcoin sent to a Litecoin address, or an arbitrary token to an ETH deposit address. Same logic: recovery is a key-control question, not a policy question. Set expectations honestly and quickly rather than promising a fix you may not be able to deliver.

Dust and minimums

Very small payments can cost more to move than they are worth, which is why each asset carries a small minimum — typically from about $0.50 to a few dollars — shown at checkout and through the API. Below it, a "refund" would consume itself in fees; credit it instead.

The double payment

A customer whose first transaction looked stuck pays a second time. Both land. Refund one in full, immediately, without deducting anything — this is the single case where absorbing the network fee is not generosity but basic hygiene, because the duplicate was caused by an interface that did not reassure them.

Fraud without chargebacks: what disappears, what remains#

Two entire categories of card fraud vanish on the day you switch. Friendly fraud — "I never authorised this" on a legitimate purchase — has no mechanism to travel through. Stolen-instrument fraud goes with it: there are no card numbers in your checkout to test, so carding attacks, BIN attacks and the authorisation-fee bleed they cause stop being your problem. For digital goods merchants, that is usually the majority of all fraud loss, gone.

What remains is smaller, and it is concentrated in one place: the refund path is now the only way money leaves you involuntarily, so that is where attackers go.

• Refund-address swapping. A request to send the refund "to my new wallet", from an email that is not the buyer's, or a message that arrives after a real complaint has been posted publicly. Verify through the channel the order was placed on.
• The unconfirmed-payment refund. Someone asks for a refund on a payment that has not reached finality. Never send anything before the payment is confirmed and credited.
• Over-refunding. A partial-payment claim of a full amount, or a refund on an underpaid invoice treated as complete. Always reconcile against the received amount, not the invoice amount.
• Support social engineering. Urgency, a sob story, a slightly different address. Card rails trained a generation of agents to defer to the customer because the bank would rule against them anyway; that reflex is expensive here.
• Takeover of your own dashboard. The only remaining way to drain a balance is to become you. Turn on TOTP 2FA — every withdrawal then requires a fresh code, from the dashboard and the API alike.

Codified, that is a five-line policy your support team can follow without thinking:

• Refund only against a payment ID that shows completed.
• Refund only up to the amount actually received.
• Refund only to an address confirmed through the order's own channel, with the network named.
• Refund only after 2FA — which the platform enforces for you on every payout.
• Record the refund's transaction hash against the order, always.

Disputes when there is no arbiter#

The fear merchants voice about finality is that an unhappy customer has nowhere to go and will therefore be louder. In practice the opposite tends to happen, for a reason that surprises people: your evidence got much stronger.

A card dispute is argued with screenshots and shipping PDFs in front of an adjudicator with a few minutes per case. An on-chain payment comes with a payment ID, a transaction hash, a block timestamp, an exact amount and a confirmation count — all independently verifiable by anyone, forever, without your cooperation. Paired with an append-only ledger where every balance is explainable line by line and exports show gross, fee and net per transaction, "what happened and when" simply stops being contestable. What remains contestable is whether you delivered — which was always the real question, and which no chargeback ever settled well either.

Three practices make that hold up:

• Publish the policy where the money moves — on the checkout page, not only in a terms document. Finality, refund window, refund method, and how to reach a human.
• Answer fast. Most escalations are a response-time problem wearing a refund costume. There is no 30-day bank process to hide behind, and no need for one: a refund is a payout that leaves within minutes.
• Use escrow or milestones for large custom work. Finality is the wrong default for a $40,000 build. Split it into staged invoices so neither side is ever holding all the risk.

Wiring it into the checkout and the runbook#

Three integration details do most of the work. First, treat the webhook as truth and the browser redirect as decoration — the redirect can be abandoned, repeated or forged. Second, handle the full status set rather than the happy path: pending, confirming, completed, underpaid, overpaid, expired and failed each mean something different to your order state, and underpaid in particular must never be allowed to fulfil. Third, make the handler idempotent — retries are expected, and a duplicate completed event must not become a duplicate shipment or a duplicate refund.

The runbook that follows is short enough to keep, which is the only kind that gets kept:

• A refund clause in your terms naming the amount basis, the window and the method.
• A refund macro that asks for address, asset and network, and repeats them back.
• A rule that no refund is sent on an unconfirmed or underpaid invoice.
• TOTP 2FA on the account, so every payout needs a live code.
• Transaction hashes logged against orders, both directions.
• A checkout line that says finality out loud — customers respect it, and it prevents the conversation you would rather not have.

None of this is heavier than the chargeback handling it replaces; it is simply yours. And it comes with the arithmetic that made you read this far: 1% when you get paid, no chargeback fees, no reserve, no ratio — on an account that takes thirty identity-free seconds to open.