On-chain reversibility: refunds without chargebacks

Card networks have chargebacks. Real-time bank transfer rails and stablecoin rails largely don't. This is celebrated as a cost saving, and it is — but it also means merchant refund flows have to be designed rather than inherited.

Written June 2025 from an implementation review.

What the merchant loses

• Automated consumer dispute mechanism. No 90-day chargeback window; no representment process; no scheme-managed dispute resolution.
• The dispute stick. Consumers who dispute chargebacks have leverage. Consumers on a chargeback-less rail have less.

What the merchant gains

• Cost predictability. No chargeback fees, no reserves against chargeback risk.
• Final settlement. Once the payment settles, the money is really the merchant's.
• Simpler reconciliation. No pending disputes, no reserved balances.

What the merchant has to build

• A clear refund policy. In the absence of a scheme-managed dispute mechanism, the merchant's own policy is the customer's entire recourse. Publishing it clearly is a customer expectation.
• A refund initiation mechanism. The merchant sends funds back on the same rail. Operationally simple; the tricky part is the customer experience if the customer's wallet has changed.
• A dispute resolution process. For cases where the customer and merchant disagree, some kind of resolution is needed. Some merchants use escrow; some use third-party mediation; some rely on legal recourse.

What good policies look like

• Refund window (typically 30 days).
• Refund destination (usually the same wallet used to pay; the merchant should handle the "customer no longer controls that wallet" case).
• Partial refunds supported.
• Dispute resolution path if the customer isn't satisfied.

The absence of chargebacks is not a design principle; it's an operational reality that the merchant has to build around. The merchants who do this well have refund policies that are competitive with card-network merchants.