How We Solved Chargebacks Without Custody

The QBitFlow refund architecture

Every conversation about non-custodial crypto payments hits the same wall.

You walk through the architecture — funds settle directly from buyer wallet to merchant wallet, no escrow, no holding period, no processor sitting in the middle. Someone in the room nods along until you finish, then asks the question that ends most of these conversations: "but what about chargebacks?"

The assumption underneath the question is that chargebacks equal consumer protection. Remove them and you remove the safety net. No safety net means scams, exit-scams, and customers left holding the bag. The dichotomy is clean: card rails protect buyers, crypto rails do not, and that gap is why crypto cannot replace cards.

Chargebacks aren't consumer protection. They're forced arbitration with a tax baked into every transaction the merchant processes — clean or not. Removing them isn't removing a safety net; it's removing a tax. The interesting question isn't whether to keep them. It's what you build instead — a dispute-resolution layer that protects buyers without seizing funds, taxing merchants, or putting an opaque arbiter between two willing parties.

This is what we shipped at QBitFlow. The architecture, the trade-offs, and why we think it's a better deal for both sides than the chargeback model it replaces.

What chargebacks actually are

Strip away the consumer-facing marketing and a chargeback is three things stacked on top of each other.

One: a fraud-reserve tax. Roughly 1% of card interchange goes into the fraud-reserve bucket that funds chargeback resolutions. Every merchant pays this, on every transaction, whether they cause a chargeback or not. The honest sellers subsidize the dishonest ones. There is no opt-out. If you process cards, you pay the tax.

Two: an opaque arbitration process. When a chargeback is filed, the card network's arbitration process decides who's right. The merchant submits evidence through a portal, the cardholder submits their side, and the network rules. Merchants regularly report decisions that contradict the evidence they provided, with no explanation, no appeal path that works at scale, and no transparency on the decision criteria. The arbiter is the same company that benefits from the fee structure, which is a conflict structure most regulators would not let stand in any other industry.

Three: a stack of penalties layered on top. Stripe holds reserves for 7+ days. Chargeback fees run $15–$25 per dispute, whether you win or lose. Adverse decisions claw back the original transaction amount plus the fee. A merchant with a chargeback ratio above 1% gets flagged, throttled, or shut down — and "1%" is the ratio across all transactions, meaning a single bad month against a small base is enough to trigger the algorithm.

Sum it up and the "protection" narrative starts to look like marketing. Buyers get a recourse mechanism, yes. But the cost of that mechanism is paid by every merchant on every transaction — and the mechanism itself is run by an entity that profits from the fee structure, makes decisions in private, and reserves the right to deplatform you if its statistics say so.

The right framing isn't "chargebacks protect consumers." It's "chargebacks redistribute fraud loss from buyers to merchants, with a tax for the privilege of being inside the system." That's a defensible product. It's not the only possible product.

What we built instead

The design constraint was straightforward: keep the dispute resolution that buyers actually need, drop everything that exists to serve the processor rather than either party, and never custody funds.

Here's the flow.

The customer side

Every QBitFlow payment lands the buyer on a self-managed payment page. The page shows the transaction hash, the amount, the merchant, the product, and — for any payment that resolved successfully — a "Request Refund" button.

When the buyer clicks Request Refund, three things happen:

1. They provide a written explanation of why they want the refund.
2. They sign a message from the wallet that made the original payment, proving they own that wallet today.
3. The refund request lands on the merchant's dashboard, attached to the original transaction.

The wallet signature step matters. Without it, anyone with the transaction hash could pose as the buyer. With it, the merchant has cryptographic proof that the request is coming from the wallet that paid — no email account takeover, no impersonation, no social-engineering path.

The merchant side

Refund requests don't sit in an email queue or a hidden tab. They surface at the top of the merchant dashboard, before revenue charts and customer counts, because they're the only thing on the dashboard that needs a decision. A refund request is a required action. Required actions get top billing.

The merchant sees the full context: the original transaction, the buyer's wallet, the written explanation, and the timestamp. From there, two paths:

Accept. The dashboard prepares a signed refund transaction for the exact original amount (including the network fees the customer paid), returning funds to the buyer's wallet. The merchant signs from their wallet, the transaction broadcasts, and both parties get an on-chain record of the refund. Accounting is recorded in the dashboard automatically.

Refuse. The merchant must provide a written explanation for the refusal. That explanation is visible to the buyer on their payment page, alongside the original transaction record. There's no path to refuse silently and leave the buyer wondering.

That's the whole flow. No escrow. No reserves. No processor sitting in arbitration. No fee per dispute. Two parties, one transaction history, and a written record of every step.

Why this is structurally better

The chargeback model and the refund model both resolve disputes. The difference is who pays, who decides, and what the record looks like when it's over.

The merchant decides, not the processor. The merchant has full context — they shipped the product, ran the service, talked to the buyer. They're closer to the truth than a Visa arbitration team that has never seen either party. When the merchant gets it wrong, the buyer has the receipts: the on-chain payment, the request they filed, the merchant's written refusal and stated reason — all surfaced on a public payment page anyone can pull up with the link. That record is portable. The buyer can show it to future buyers researching the merchant before they purchase.

No interchange tax for the 99% of clean transactions. Honest merchants stop subsidizing dishonest ones. The cost of dispute resolution is paid by the disputes that happen, not socialized across every transaction. If you process a thousand payments and have zero refund requests, you pay zero dispute costs. That's not how cards work and never will be.

No 7-day reserve, no $25 dispute fee, no chargeback ratio. Funds settle to the merchant immediately on payment. There's no holding period, no per-dispute penalty, no algorithm watching your ratio and deciding whether to throttle your account this quarter. The merchant's relationship is with the buyer, not with a processor's risk team.

Auditable, end to end. Visa's chargeback decisions are opaque by design. QBitFlow's are not. The settlement layer — original payment and any refund transaction — is on-chain and immutable, queryable from any block explorer. The dispute layer — the buyer's request, the merchant's accept-or-refuse, the stated reason, the timestamps — lives on a public payment page anyone can pull up with the link. Two layers, both transparent. Auditors get a block-explorer link for the money movement and a URL for the dispute trail. Tax authorities get the same. Disputes about whether a refund happened end in fifteen seconds.

Buyers keep a meaningful recourse. The buyer can request a refund from any successful payment, with no time window or merchant gating. If the merchant refuses without grounds, the buyer has the receipts — and the buyer's written request, the merchant's written refusal, and the on-chain payment record together form a portable reputation signal. The protection is real. It's just not enforced by a third party seizing funds the merchant has already earned.

Trade-offs we accept

This isn't a clean-sweep win.

Refunds are full-amount only, today. We don't yet support partial refunds. If a buyer wants 30% back on a partially-delivered service, the merchant has to refund 100% and request 70% as a new payment, or work out the difference off-platform. Partial refunds are on the roadmap, contingent on a real merchant pulling at it; we haven't built it speculatively.

No automated arbiter when the merchant goes silent. The chargeback model has an end-state — Visa rules, money moves, the case closes. The QBitFlow model relies on the merchant responding. If the merchant ghosts a refund request, the buyer's recourse is the written record, not a forced settlement. For most merchants this is fine; the dashboard surfaces refund requests first, exactly to make ghosting unlikely. For pathological cases, the reputation signal does the work — but that's slower than a 30-day Visa cycle.

Gas economics shift in the refund flow. Across the rest of QBitFlow, the customer pays network fees. Refunds are the inverse: the refund transaction broadcasts from the merchant wallet, so the merchant pays gas on the refund itself. The customer's "Request Refund" step is a wallet signature (proving ownership of the paying wallet), not a transaction — so it costs the customer nothing. Net effect: the merchant absorbs a small on-chain cost when they accept a refund. Negligible on L2 or Solana, more noticeable on Ethereum mainnet. Worth pricing in.

We name these because they're real. The point isn't that the chargeback model has no virtues. The point is that the virtues it has come bundled with a fee structure and an opacity that most merchants would not voluntarily sign up for if they were pricing them honestly. Trade off the opacity and the tax, accept the response-required-from-merchant model, and you end up with something that respects both parties' time and money more than the existing system.

The bigger thesis

The cardinal sin of crypto payments thinking was treating "non-custodial" as synonymous with "no protection." That framing concedes the entire dispute-resolution layer to the legacy rails and tries to compete only on settlement speed and fees. It loses the conversation in the second sentence.

The right framing is that non-custodial is a settlement architecture, not a recourse architecture. The recourse layer can be rebuilt — better, more transparently, with the merchant as decision-maker instead of an opaque third party — on top of non-custodial settlement. You don't have to choose between "buyer keeps Visa-style protection" and "merchant keeps the funds the buyer sent them." Both can be true.

QBitFlow's broader product thesis is exactly this: the rails are the easy part. The interesting work is the tools around the rails — subscriptions that don't custody, marketplace fee splits that settle on-chain, refund architectures that don't tax clean merchants. Each one rebuilds a piece of the payments stack that custodial processors charge a premium for, on terms that respect the architecture underneath.

The refund flow is live in QBitFlow today. Every payment processed through the platform — one-time or subscription — supports the request-and-respond dispute flow described above. Open-source smart contracts on GitHub — readable, forkable, and available for review by anyone who wants to dig in. Formal third-party audit is on the roadmap; until then, the code is open.

If you've been turning away from non-custodial crypto payments because "but chargebacks," this is the answer. Chargebacks aren't a feature you pay 1% interchange forever to keep. They're a feature you ship — and shipping it differently turns out to be cheaper, more transparent, and more respectful of both parties.

Try the flow on testnet. See for yourself.

Try it: Sign up at qbitflow.app — testnet wallet funded automatically, full refund flow available end-to-end.

Builders: Refund implementation details and SDK reference at qbitflow.app/docs/api.

Smart contracts: Open-source on github.com/QBitFlow — readable, forkable, auditable. Formal audit on the roadmap.