A card payment is a loan the network can recall for up to 120 days. An on-chain payment is a fact that confirmed at a specific block. Those are not the same kind of money, and pretending they are is how teams get the refund flow wrong.
The first question every merchant asks us about crypto is some version of "what's the chargeback rate?" The honest answer surprises them: there isn't one. Not low. Zero. There is no mechanism for it. And the second half of that answer is the part that actually matters: the absence of chargebacks doesn't make disputes disappear, it moves the entire dispute problem from after you've shipped to before, and it replaces the forced reversal with a deliberate one you control.
What a chargeback actually is
A chargeback is a forced reversal initiated by the cardholder's bank, not by you. The customer disputes a charge, the issuer pulls the funds out of your account, and you're left arguing your case to a network you don't control, weeks or months after the goods left the warehouse. You can win the representment. You often don't. Either way you've paid for the dispute in fees, staff time, and a reserve the acquirer holds against future ones.
The thing to internalize is that the money was never settled in the first sense of the word. Card authorization and capture create a provisional claim. The network reserves the right to recall it. Friendly fraud — "I don't recognize this charge," from someone who absolutely placed the order — works precisely because the reversal mechanism exists and the burden of proof sits on the merchant.
That is the world card-native businesses operate in, and they build entire teams around it: fraud scoring, manual review queues, reserve accounting, dispute representment. It's a tax on every transaction whether or not a given one is ever disputed.
On-chain payments settle, and settled means settled
When a customer pays a halfin invoice, the deposit lands on-chain and we wait for the per-chain confirmation threshold before we mark it paid. Once it's confirmed, that transaction is part of the ledger. There is no issuer, no acquirer, no network operator with the authority to reach into a block and undo it.
This is what "settlement finality" means in practice, and it's worth being precise, because crypto finality is probabilistic near the tip of the chain and practical once you're past the confirmations:
- A freshly-seen deposit can still be reorganized out if the chain reorgs. We're reorg-aware on every gate for exactly this reason — we don't credit on sight, we credit after the chain has settled enough blocks deep that a reversal is not a realistic risk.
- Past that threshold, the payment is final in the way that matters operationally: no third party can reverse it, and the only way value moves back to the payer is a brand-new transaction that you send.
So the chargeback simply has no socket to plug into. There's no claim to recall because the money isn't a recallable claim — it's a settled transfer. We wrote about the confirmation-vs-finality nuance from the engineering side in designing webhooks that survive everything; the short version is that we don't tell you a payment is final until it actually is.
What you gain, stated plainly
Stripping out forced reversals removes a whole layer of operational drag:
- No fraud reserve held against your balance. No acquirer parking a slice of your revenue for 90 days in case a dispute lands.
- No representment treadmill. You're not assembling shipping records and chat logs to argue a case to an arbiter who's seen ten thousand of them today.
- Friendly fraud as a category mostly evaporates. "I never authorized this" doesn't work against a signed transaction from the customer's own wallet. The payment carries its own proof.
- Your cash-flow picture is the real one. What's in your balance is yours. It's not provisional revenue waiting out a dispute window.
For high-risk verticals this is the entire pitch. We dug into it for online stores in no chargebacks: final on-chain settlement for online stores — the businesses that feel this most are the ones acquirers price as risky: digital goods, cross-border, anything with a thin physical-proof trail.
What you don't get to skip
Here's where teams trip. They read "no chargebacks" as "no disputes," shut off their fraud thinking, and get hurt by the part that didn't go away. Two things still demand attention.
You no longer have a network absorbing legitimate refund requests. A customer who paid for the wrong thing, overpaid, or cancelled before fulfilment still needs their money back. With cards, the chargeback was a crude-but-automatic backstop for that. On-chain, there's no backstop — you are the mechanism. If you don't build a clean way to send money back, your support team will improvise one by pasting wallet addresses out of emails, and that improvisation is its own fraud and error surface.
Finality cuts both ways. The same property that protects you from a clawback protects a mistaken or fraudulent outbound payment just as completely. Send a refund to the wrong address and there's no network to call. This is why the refund path has to be controlled, not casual.
The deliberate refund replaces the forced reversal
This is the trade we think every team should make consciously: you give up the bank's ability to reverse a payment against you, and in exchange you take full ownership of reversing one deliberately. The forced, adversarial reversal becomes an intentional, attributable one.
halfin refunds are built around that ownership. A refund isn't a free-form transfer you eyeball into existence — it's bound to the invoice the customer already paid. Because the original invoice carries who paid, how much, in which asset, and on which network, the refund inherits that context instead of asking an operator to reconstruct it from memory. Practically:
- It's anchored. A refund references a specific paid invoice, so finance never sees an orphaned outbound transfer they can't map to a sale.
- It can be full or partial. Return the whole paid amount on a cancellation, the surplus on an overpayment, or a slice for a missing line item.
- It's operator-approved, not auto-fired. Moving money out of a balance is the most sensitive thing a payment system does. A person with the right scoped permission initiates and approves it — a read-only reporting key cannot trigger one.
- It's logged. Actor, amount, destination, and source invoice, every time. When a refund is questioned weeks later, the record answers the obvious questions without anyone digging through chat history.
And because refunds ride the same spec-first API and HMAC-signed webhook envelope as the rest of your events, your back office reacts to a signed event rather than polling and guessing. As always: verify the signature over the raw bytes before you act on it.
How to think about the migration
If you're coming from cards, don't port your dispute apparatus over wholesale — most of it solved a problem you no longer have. Do this instead:
- Re-spend the fraud budget upfront. Card fraud defense is reactive, because the loss happens after settlement. On-chain, settlement is the finish line, so your effort moves to the front: address validation, sane invoice expiry, and not over-trusting an unconfirmed deposit. Get those right and the back-end dispute machinery you used to run becomes unnecessary.
- Make the refund path a real feature, not a support hack. Decide who can approve refunds, scope the keys that can move funds, and route every return through the invoice it came from. The goal is that your month-end reconciliation is one record away, never a forensic exercise.
- Set customer expectations. Tell buyers that crypto payments are final and that returns are handled as deliberate refunds. It's not a downside to hide — it's why your prices don't carry a chargeback tax. Plenty of customers prefer paying a business that isn't pricing in everyone else's friendly fraud.
The chargeback button was never free. It was a shared insurance pool the card networks ran, and you paid the premium on every transaction. On-chain, you opt out of the pool and self-insure with a refund flow you control. Done well, that's a better deal — fewer reversals, no reserve, no representment, and a clean audit trail from the sale to the payment to the return. Done carelessly, it's a wire transfer with no undo. The difference is entirely in how seriously you take the refund path, which is exactly why we made it a first-class product instead of a footnote.