Forem: QBitFlow

How We Solved Chargebacks Without Custody — The QBitFlow Refund Architecture.

QBitFlow — Wed, 20 May 2026 07:00:00 +0000

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:

They provide a written explanation of why they want the refund.
They sign a message from the wallet that made the original payment, proving they own that wallet today.
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.

Crypto Subscription Billing: How Recurring Payments Actually Work On-Chain.

QBitFlow — Tue, 19 May 2026 16:48:40 +0000

Subscriptions are the backbone of SaaS. Recurring revenue, predictable cash flow, lower churn friction. Stripe made this dead simple for fiat: customer enters a card, you bill monthly, done.

Crypto never got this right.

For years, "crypto subscriptions" meant one of three things: emailing an invoice every month and hoping the customer pays, streaming tokens continuously (which doesn't match how most businesses bill), or routing through a custodial processor that holds funds and bills on your behalf — defeating the point of crypto.

None of these are actual subscription billing. They're workarounds.

This post breaks down how recurring crypto payments actually work on-chain using smart contract spending caps, why the alternatives fall short, and what's shipped today versus what's still missing.

The Core Problem: Crypto Wallets Don't Support "Pull" Payments

Credit cards work on a pull model. You give the merchant your card number, and they charge it whenever the billing cycle hits. The customer doesn't do anything after the initial signup.

Crypto wallets work on a push model. Every transaction requires the wallet holder to sign it. Nobody can pull funds from your wallet without your explicit approval — that's the security guarantee of self-custody.

This is great for one-time payments. Terrible for subscriptions.

If every monthly charge needs the customer to open their wallet app, find the right token, approve the transaction, and confirm — you've built a subscription model that depends on the customer remembering to pay every single month. That's not a subscription. That's an honor system.

Three Approaches (And Why Two of Them Break)

1. Manual Invoicing

The simplest version: send the customer an invoice or payment link every billing cycle. They click, connect wallet, pay.

This is what most crypto-accepting SaaS companies do today. It works for small volumes. It breaks at scale because:

Churn by friction. Every invoice is a decision point. Miss one, and you've lost the customer — not because they wanted to cancel, but because they forgot.
No automation. You need a system (or a human) sending invoices, tracking who paid, chasing who didn't.
No spending governance. There's no on-chain commitment from the customer. They can simply stop paying, and you won't know until the invoice goes unanswered.

2. Token Streaming (Superfluid, LlamaPay)

Token streaming sends a continuous flow of tokens from sender to receiver, calculated per second. Think of it as a faucet that drips money at a constant rate.

It's elegant for payroll and vesting schedules — use cases where "X tokens per second over Y months" makes sense.

It's a bad fit for most subscription billing because:

Subscriptions are discrete, not continuous. A $49/month SaaS plan charges $49 on the 1st of each month. It doesn't charge $0.0000189 per second. The billing event matters — it's when you check payment status, update access, send receipts.
Revenue recognition gets weird. Streaming creates a continuous revenue flow that doesn't map to billing periods. Accounting for "we received 2,592,000 seconds worth of tokens this month" is harder than "we billed $49 on May 1st."
Underfunded streams fail silently. If the sender's wallet runs low, the stream stops. No discrete failure event, no "payment failed" webhook — it just dries up.

Streaming solves a real problem. It's just not the subscription problem most SaaS founders have.

3. Spending-Cap Authorization (The Model That Works)

Here's the third approach, and the one that actually maps to how subscriptions work in fiat:

Customer approves a spending cap. They sign one transaction that authorizes the smart contract to spend up to X tokens per billing cycle from their wallet. This is the only wallet interaction the customer needs.
Merchant bills automatically. When the billing cycle hits, the merchant (or an automated system) calls the smart contract to execute the payment. No customer action required.
Funds stay in the customer's wallet. Unlike custodial or escrow models, the customer's tokens sit in their own wallet until each payment executes. No escrow, no custody, no middleman holding the money.
The cap is the cap. The smart contract enforces the maximum. The merchant can bill up to the authorized amount, but never more. The customer can increase the cap, or cancel the authorization entirely — on-chain, at any time.

This is a pull model built on push infrastructure. The customer authorizes a bounded pull via smart contract, and the merchant executes within those bounds.

How This Works in Practice

Here's the actual flow for a $49/month SaaS subscription paid in USDC:

Customer side:

Customer clicks "Subscribe" on the merchant's checkout page
They connect their wallet and see the authorization: "Allow up to 49 USDC per month"
They sign the authorization transaction (one wallet interaction)
Done. No further wallet interaction until they want to change or cancel

Merchant side:

At billing time, the QBitFlow backend automatically triggers the on-chain transaction against the smart contract — the merchant doesn't have to schedule anything, run a billing worker, or sign anything
The contract checks: is the authorization active? Is the amount within the cap? Does the customer have sufficient funds?
If all checks pass, the payment executes — tokens move from customer wallet to merchant wallet, and QBitFlow updates the subscription status accordingly
There are two failure modes the merchant should know about:
- low_on_funds (warning, not a failure yet): the current payment succeeded, but the customer's remaining spending cap won't cover the next billing cycle. The subscription is still active for now — this is a heads-up. The merchant should reach out and ask the customer to raise their spending cap on the self-managed page before the next charge.
- past_due (a billing attempt actually failed): wallet didn't have enough funds, or the cap was too low to cover the bill. QBitFlow automatically retries during a grace period. The merchant nudges the customer to top up their wallet or raise their cap. If a retry succeeds, the subscription goes back to active and continues normally. If the grace period expires with no successful payment, the subscription is cancelled.

What the merchant sees:

Active subscription count, low-on-funds warnings, past-due subscriptions, cancelled subscriptions — all on the dashboard
Subscription status: trial, trial_expired, active, low_on_funds, past_due, cancelled

One honest caveat on status changes today: webhooks not yet on subscription status transitions (free_trial → active, active → low_on_funds, active → past_due, past_due → active, past_due → cancelled, etc.). Today the merchant runs a small cron against the API (daily) — fetch their subscriptions, diff statuses against what's in their database, run whatever logic they need (email the customer that their cap is running low, email them that a payment failed, downgrade a feature flag, etc.). A subscription-status webhook is on the roadmap and will remove the need for the cron entirely. We'd rather tell you what's live than dress it up.

What the customer controls:

Increase their spending cap if they upgrade
Cancel on-chain at any time (no "call to cancel" friction)
View their authorization and payment history on a self-managed page

No account, no email, no password. The customer's wallet is the account — every action above is just a signed transaction from the same wallet that authorized the subscription in the first place.

What's Actually Shipped (Not Vaporware)

This is where most "crypto subscription" articles get fuzzy. They describe an ideal system without telling you what works today. Here's what's live right now on QBitFlow:

Live and working:

Spending-cap subscriptions on Ethereum, Solana, and Base
Custom billing frequencies: daily, weekly, monthly, yearly, or custom intervals
Free trials (customer signs a zero-amount authorization — no wallet interaction during the trial period)
Automatic billing execution by QBitFlow
low_on_funds warnings (next cycle won't fit under the remaining cap), past_due detection with automatic retries during a grace period, and full subscription status tracking
Customer self-manage page: increase cap, cancel on-chain
Merchant force-cancel for cause (ToS violations, etc.)
Full refunds per billing cycle (customer-initiated, merchant-approved)
Webhook notifications on every payment event
SDKs in JavaScript/TypeScript, Python, and Go

Important constraints:

Subscriptions are token-only. You can't bill in native ETH or SOL — the authorization model requires ERC-20 / SPL token approval mechanics. USDC, USDT, DAI, and other supported tokens work. Native currencies don't.
No plan upgrade/downgrade flows yet. Mid-cycle plan changes aren't supported. If a customer wants to switch from $49/mo to $99/mo, they'd cancel and re-subscribe. This is on the roadmap.
No partial refunds. Refunds are full-amount per billing entry. Partial refunds are a future consideration.
No email notifications. There's no email infrastructure yet — no payment receipts, no low-cap alerts sent to customers. Webhooks handle the merchant side; customer-facing notifications are on the roadmap.

We're honest about these gaps because you'll hit them. Better to know now than to discover mid-integration.

Who Needs This Today?

Three categories of businesses where on-chain subscription billing makes practical sense right now:

1. SaaS with crypto-native customers

If your users already hold USDC or USDT in wallets, you're adding friction by forcing them through Stripe. They have to convert to fiat, use a card, and pay the processor's fees — to pay you for a product they use in the crypto ecosystem. On-chain billing removes the conversion step.

2. Creator platforms and membership sites

Membership models (Patreon-style, premium communities, content subscriptions) map cleanly to spending-cap billing. The marketplace trust layer makes this particularly interesting: platforms can onboard creators with zero crypto setup, and when they're ready, they claim their wallet and receive payments directly.

3. API providers preparing for agent traffic

This one is still emerging, but it's worth watching. AWS just launched AgentCore Payments for AI agents to pay for APIs in real-time. The spending-cap model maps directly to agent budgets: an AI agent gets a capped authorization, the API provider bills per-call within the cap, and the user (or the user's organization) controls the maximum exposure. We're actively building this (x402/PAYG) — it's not live yet, but the primitive is the same one that powers subscriptions today.

How to Get Started

If you want to test on-chain subscription billing:

Sign up at qbitflow.app/get-started — email and password, takes 30 seconds
Connect a wallet — you only provide a public address (Ethereum, Solana, or Base). No seed phrases, no private keys
Create a product with a subscription pricing model in the dashboard or via API
Generate an API key and integrate with our SDK (JS/TS, Python, or Go)
Test on testnet first — we drop test funds to your wallet automatically on signup

The full docs are at qbitflow.app/docs. Setup to first test subscription takes roughly 10-15 minutes.

The Honest Take

Crypto subscription billing is real, but it's not mature. The spending-cap model solves the core architectural problem — how to do recurring pulls from a push-only wallet — and it's live and working today.

What's still missing across the industry: upgrade/downgrade flows, email notifications, partial refunds, and the kind of billing management dashboard that Stripe has spent a decade refining. We're building toward that, but we're not there yet, and neither is anyone else doing this non-custodially.

If you're a SaaS founder evaluating crypto payments and subscriptions matter to your model, the spending-cap approach is the one worth betting on. The alternatives — manual invoicing and token streaming — solve different problems.

The pieces are coming together. The question is whether you want to be ready when your customers start asking to pay in USDC, or scrambling to build it after they've already left for a competitor who figured it out first.

QBitFlow is a non-custodial crypto payment gateway with subscription billing, marketplace fee splitting, and hosted checkout on Ethereum, Solana, and Base. Get started free.

Stablecoin Payments for Marketplaces: How Platforms Can Accept Crypto in 2026.

QBitFlow — Mon, 11 May 2026 07:00:00 +0000

How platforms can accept crypto in 2026

Marketplaces have always borrowed someone else's payment rails.

Stripe Connect, PayPal for Marketplaces, Adyen for Platforms — every multi-vendor platform you have ever used is, underneath, paying another company to hold its sellers' money for a few days and then forward it on. The model works. It also costs a 0.5% markup on top of card fees, introduces multi-day payout delays, and leaves every platform exposed to the standing risk that the processor decides one category of seller is too risky to serve.

In 2026, that math finally started shifting. Meta began paying creators directly in USDC. Western Union launched USDPT on Solana for cross-border remittances. The EU's MiCA framework opened the door for euro-denominated stablecoin payments at scale. And a generation of marketplace operators started asking the obvious question: if stablecoins move dollars on rails that settle in seconds and cost cents, what are we still paying card processors 3% for?

This post is for the operators asking that question. It covers what changed, where traditional rails break for marketplaces specifically, the three architectures available today, and how on-chain fee splitting closes the gap that custodial gateways have left open.

Why marketplaces are looking at stablecoins in 2026

A few things stacked up in the last twelve months.

Meta's USDC creator payouts (April 2026). Meta started paying Instagram and Threads creators in USDC for select monetization programs, citing faster international payouts and lower friction than the bank-rails system. Whatever you think of Meta, the signal matters: the largest creator platform on Earth concluded that for a meaningful chunk of payouts, stablecoins beat correspondent banking. That moves "creator paid in crypto" from edge case to category.

Western Union's USDPT on Solana. Western Union, the most legacy player in cross-border money movement, launched USDPT (a USD-pegged stablecoin) on Solana. The pitch was the same one crypto people have been making for a decade — faster, cheaper, programmable settlement — except this time it was coming from inside the building.

MiCA in effect. The EU's Markets in Crypto-Assets regulation is fully live, with stablecoin issuers like Circle holding e-money licenses. That gives EU marketplaces a regulated path to accept and pay out in EURC without the regulatory ambiguity that used to kill these projects in compliance review.

Chargeback math for digital goods. Card chargebacks cost online marketplaces an estimated 1-3% of revenue in disputes, fraud, and operational overhead. Stablecoin transactions are final. For digital goods, services, and downloadable content, that eliminates an entire cost center.

Cross-border without correspondent banking. A platform with sellers in 40 countries pays SWIFT fees, FX spreads, and minimum-balance requirements for every corridor. Stablecoins collapse that into one settlement currency and one rail.

The result is that "should we accept crypto" stopped being a 2024-era conversation and became a 2026 product decision.

How traditional marketplace payments work — and where they break

Most marketplaces run on one of two models: Stripe Connect or PayPal for Marketplaces (Adyen for Platforms is similar). Both are custodial. The platform — Stripe, PayPal — holds the seller's funds, takes the card-network fee, takes a platform fee, and pays the seller on a delay.

For a digital marketplace with a 10% platform cut, the typical fee stack looks like this:

Stripe card processing: ~2.9% + $0.30
Stripe Connect markup: 0.5% on top
Platform's own cut: 10%
Seller take-home: ~86.6%

Then come the operational realities:

Payout delays. Standard Stripe Connect payouts arrive on T+2 to T+7. Instant payouts cost an extra 1.5%. PayPal holds new sellers' funds for up to 21 days. For sellers operating on thin margins, those delays are working-capital expensive.

Account holds and deplatforming. This is the one nobody on the platform side likes to talk about, because the platform is usually the one doing it. When the processor underneath you decides an entire category of seller is too risky, the marketplace inherits that decision. The sellers do not get a vote. Funds in flight can be held; future processing can be cut off entirely. Every marketplace operator I've talked to in the last year has at least one war story.

KYC and dispute overhead. Every seller goes through a custodial onboarding flow that the platform does not control. Disputes get arbitrated by a card network whose incentives do not match the marketplace's.

The custody itself is the root issue. The moment a third party holds the funds between buyer and seller, the marketplace is renting access to its own revenue. Most of the time that rental is fine. The risk shows up at the tail.

The smart-contract alternative

A non-custodial marketplace payment looks structurally different.

When a buyer pays a seller through a non-custodial gateway, the funds move directly from the buyer's wallet to the seller's wallet via a smart contract. There is no intermediate account. The marketplace's cut — say 10% — is split off on-chain, at the same transaction, into the platform's own wallet. The remaining 90% lands in the seller's wallet immediately. Settlement is one transaction, one block, both parties paid.

A few properties fall out of this:

No payout delay. The seller has the funds the moment the buyer signs. No T+2, no instant-payout surcharge, no rolling reserve.
No omnibus account. No third party holds the funds at any point. The platform cannot freeze a seller's revenue, because the platform never holds it. Neither does the gateway.
Automatic fee enforcement. The platform's cut is encoded in the smart contract. There is no monthly reconciliation, no manual invoicing, no risk that a seller forgets to remit.
Auditable rules. Open-source contracts mean both the platform and the seller can read the exact logic that governs every payment. The contract is the agreement.

This is what QBitFlow ships today. The marketplace creates an organization account, adds user-level accounts for its sellers, sets a fee percentage per user, and the smart contracts handle the rest. Every payment that flows through a seller's hosted checkout splits at settlement: platform takes its cut on-chain, seller receives the remainder in the exact token the customer paid with. No auto-swap, no slippage, no conversion fee.

Supported chains today are Ethereum, Solana, and Base, with full token coverage for the stablecoins marketplaces actually want — USDC, USDT, EURC, and DAI across all three. The contracts are on GitHub at github.com/QBitFlow.

Three models for marketplace stablecoin payments

If you are a marketplace operator looking at stablecoin payments seriously in 2026, you have three real options. Each has a place; the right one depends on what you optimize for.

Model 1: Custodial crypto gateways (BitPay, Coinbase Commerce, MoonPay for Business)

A custodial gateway is structurally Stripe-shaped. The gateway holds the funds, takes a fee, and pays out to the seller on a schedule. The customer pays in crypto; the merchant typically receives a payout in the chosen currency.

Pros: familiar operational model, integrations look like existing payment-processor integrations, the gateway absorbs some of the complexity.

Cons: every issue with the custodial model carries over — deplatforming risk, payout delays, account holds, opaque dispute handling. You have replaced the card network with a crypto company that can still freeze your sellers' funds. The architecture has not actually changed.

Best for: marketplaces that want a crypto on-ramp but are not ready to rethink the custody model.

Model 2: Self-hosted, self-custody (BTCPay Server)

Open-source, self-hosted, fully non-custodial. The marketplace runs its own infrastructure, accepts crypto directly, and handles fee splitting in application code.

Pros: maximum control, zero fees to a third-party gateway, no platform risk.

Cons: you are now running payment infrastructure as a side product. Hosting, uptime, key management, smart-contract development (if you want on-chain fee splits), chain support, wallet compatibility — all on you. For a marketplace whose core product is not payments, this is a lot of surface area to own.

Best for: technically deep teams who want to own every piece of the stack and have the engineering bandwidth to maintain it.

Model 3: Non-custodial gateway with smart-contract fee splits (QBitFlow)

This is the model the rest of this post has been describing. A managed service that ships the integration layer — hosted checkout, SDKs, dashboard, webhooks — but settles non-custodially via open-source smart contracts. Fees split on-chain at the transaction. The gateway never holds funds.

Pros: non-custodial settlement (no deplatforming risk, no payout delays, no held funds), but you do not run the infrastructure. Smart-contract fee splits work out of the box — no application-layer reconciliation. The platform gets ten-minute setup time, the seller gets immediate settlement.

Cons: still a managed dependency. If the gateway disappears tomorrow, the smart contracts keep running (they're open-source and on-chain), but the dashboard, hosted checkout, and SDK maintenance go with it. This is a real consideration; it is also why the contracts being open-source matters.

Best for: marketplaces that want non-custodial settlement without becoming a payments company.

The honest version: model 1 is fine if you just want a crypto button. Model 2 is right if payments are core to your product. Model 3 is the middle path — and it is the one most marketplace operators end up at once they have run the numbers.

Setting up marketplace payments with QBitFlow

The integration path for a marketplace looks roughly like this. Numbers below are accurate as of May 2026; check qbitflow.app/docs for the current state.

Create an organization account. Sign up at qbitflow.app/get-started with email and password. Connect a public wallet address — Ethereum, Solana, or Base. The wallet receives the platform's fee splits; QBitFlow never sees a private key.
Add user-level accounts for sellers. Each seller on your marketplace gets a user account inside your org. Two options here:
- Already-onboarded sellers connect their own wallet at signup. Their share of every payment routes directly to that wallet.
- New sellers without a wallet start as unclaimed accounts. Payments to them route to your org wallet, with an off-chain ledger tracking what's owed to whom and an on-chain transaction hash captured for every payment. When the seller is ready, they go through a claim flow (set password, connect wallet, you sign one transaction to release everything they have earned). After that, it's standard non-custodial settlement.

One caveat worth flagging upfront: subscriptions don't work on unclaimed accounts (subscriptions hash the recipient wallet at creation, so the wallet has to exist first). One-time payments work fine for unclaimed users.

Configure your fee percentage per user. Smart contracts enforce it. There is no manual reconciliation, no monthly remittance — your cut lands in your wallet at the same block as the seller's cut.
Integrate via SDK or REST API. Customers always pay through QBitFlow's hosted checkout — the SDK and the API are just the tools your backend uses to manage customers, products, and create checkout sessions. Each session returns a checkout URL you redirect the customer to. The hosted page handles wallet connection, chain selection, and payment confirmation, and ships with theme + logo customization plus custom success/cancel redirect URLs. QBitFlow ships SDKs for JavaScript/TypeScript, Python, and Go at feature parity if you want a typed client; if your stack isn't covered, hit the REST API directly.
Wire up webhooks for your backend. Per-payment webhooks fire on terminal status only — completed, failed, cancelled, expired. Signature verification uses HMAC headers (X-Webhook-Signature-256 + X-Webhook-Timestamp), and the SDKs expose client.webhooks.verify() to handle the check.

Typical time from signup to first live payment is around ten minutes. New merchants get automatic testnet faucet funds at account creation, so the full sandbox flow runs before you touch real money.

For platforms running WordPress, the WooCommerce plugin is available on GitHub today at WooCommerce Plugin — install it directly from there and it works end-to-end. The plugin has also been submitted to the official WordPress plugin directory and is currently under review, so one-click install from the WordPress store is coming soon. A standalone WordPress plugin (for sites not running WooCommerce) is in active development.

Who should consider this

Not every marketplace needs to accept crypto. The model fits some categories better than others.

Creator platforms — content subscriptions, digital goods, paid newsletters, fan platforms. Digital goods are the cleanest fit: no chargebacks matter most where physical fulfillment is not in the dispute path, and creators have been the most vocal about wanting cross-border payouts.

Freelancer marketplaces — design, dev, writing, consulting. International freelancers have been routing around correspondent banking with crypto for years; formalizing that flow with smart-contract escrow and instant settlement is the obvious upgrade.

Multi-vendor e-commerce — especially platforms with international sellers or sellers in categories where card processors are inconsistent.

Gaming asset marketplaces — in-game items, digital collectibles, NFT secondary markets. Stablecoin settlement with on-chain fee splits is already the dominant model here; the question is which gateway, not whether.

SaaS platforms with revenue sharing — anyone embedding payments in a product where part of the revenue routes to a third party (template marketplaces, plugin stores, API resellers).

If you are running one of these and your current payment stack costs you more than 1.5% in gateway fees, has ever held a seller's funds longer than you wanted, or has a category-risk story you would rather not repeat — the math is worth running.

FAQ

What currencies and tokens are supported?
Ethereum mainnet (ETH, WETH, USDC, EURC, USDT, LINK, WBTC, DAI), Solana (SOL, WSOL, USDC, USDT, EURC, LINK, DAI), and Base (ETH, WETH, USDC, USDT, EURC, DAI, cbBTC, AERO). For marketplaces, USDC and USDT cover the vast majority of real volume.

How do sellers receive funds?
Directly to their wallet, in the same token the buyer paid with. No auto-swap, no conversion. If a buyer pays in USDC on Base, the seller receives USDC on Base. The marketplace's fee split also lands in the same token, in the same transaction.

What are the fees?
1.5% flat, paid by the merchant out of the payment. No separate billing, no withdrawal fees, no chargeback fees. Customer pays gas. Volume discounts kick in at $50K+/month. The platform's own marketplace cut is on top of that 1.5%, and it lands in the platform's wallet on-chain.

Is this compliant with regulations?
Stablecoin payment infrastructure under MiCA, EMT/ART rules in the EU, and the relevant US frameworks is workable today — the issuers (Circle, Tether, etc.) hold the licenses; the gateway is settlement infrastructure. As always: talk to your own counsel about your specific jurisdiction and customer mix before going live.

What if QBitFlow disappears tomorrow?
The smart contracts are open-source and live on-chain. Settlement keeps working. You would lose the hosted dashboard, the SDKs, and the support, but the funds and the contract logic are not in QBitFlow's custody at any point — that's the point of non-custodial.

If you are running a marketplace and want to talk through how on-chain fee splitting would fit your stack, the QBitFlow checkout takes about ten minutes to set up and the docs at qbitflow.app/docs cover the full marketplace integration. We'd rather show you the contracts than the slide deck.

Trust = Non-Custodial Great UX. The Two-Pillar Equation for Crypto Payment Adoption.

QBitFlow — Sat, 09 May 2026 08:00:00 +0000

The two-pillar equation for crypto payment adoption

Crypto payment adoption is not blocked by trust. It is not blocked by UX. It is blocked by the assumption that you have to choose one or the other.

For most of the last decade, the industry sorted itself into two camps. On one side, the maximalists: non-custodial, self-custody, "not your keys, not your coins," seed phrases as a feature, the user takes responsibility. On the other side, the abstraction crowd: custodial wallets, exchange accounts, "sign in with email," recoverable accounts, the platform takes responsibility. Each camp pointed at the other and said: that's why crypto is not winning.

Both were half right. And the half they got wrong was the half that mattered.

What trust actually means

Trust in payments is architectural, not emotional. A user does not trust a merchant because the merchant is friendly. A user trusts a payment system because the rules are predictable, the funds are recoverable in the right scenarios, and the parties cannot unilaterally change the terms after the transaction.

Custodial systems break this in one specific place: the moment a third party holds your funds, you have replaced "rules enforced by code" with "rules enforced by a company that can change its mind." Most of the time, that company behaves well. Some of the time, it does not. The deplatforming stories from Stripe, the frozen accounts at Coinbase, the seed-phrase confiscation flows from regulated exchanges — these are not rare events. They are the predictable consequence of a model where someone other than you holds the keys.

Non-custodial fixes this at the settlement layer. Funds rest in your wallet, controlled by your keys. No omnibus account in the middle. No customer-service ticket required to access your own money. That is the architectural truth, and it does not change.

But trust is necessary, not sufficient.

What UX actually means

UX in payments is not "is the button pretty." It is "did the user finish the transaction." Every step between intent and completion is a place where users drop off — and crypto, historically, has had more steps than any other payment method ever invented.

Install a wallet. Write down twelve words you do not understand on a piece of paper you will lose. Buy a token you have never heard of to pay gas. Approve the contract. Approve the spending limit. Sign the transaction. Wait for confirmation. Hope you used the right network.

That is not a payment flow. That is an obstacle course.

The teams winning adoption right now are the ones quietly removing every step. Smart wallets like Coinbase's let users sign up with email, with the underlying wallet still non-custodial. Embedded sign-flows from Privy, Dynamic, and others abstract away the wallet entirely — the user sees a button, the keys live in a passkey or MPC enclave, and the funds settle on-chain. Account abstraction (ERC-4337) makes gas sponsorship, social recovery, and batched transactions a default. Gas abstraction means users never see the word "gas" again. Social recovery means if they lose their device, their friends or a recovery service can help — without anyone ever holding the keys.

These are not concessions to custodial thinking. They are non-custodial systems that learned UX. The keys still belong to the user. The seed phrase still does not exist in any third party's database. The architecture is unchanged. What changed is everything the user sees.

The equation

Adoption needs both pillars:

Trust = non-custodial settlement. The user controls the keys at the layer where funds rest.

Simplicity = UX that matches or beats custodial. No seed-phrase rituals. No mystery gas tokens. No "approve the contract" prompts that nobody reads.

If you have trust without simplicity, you have a product for the converted. The 50,000 people who already understand seed phrases will love it. The 5 billion who do not will never finish the signup flow.

If you have simplicity without trust, you have rebuilt PayPal with extra steps. The user experience is fine until the day the company decides your business is too risky, the regulator decides your country is too risky, or the breach decides your credentials are too valuable.

Trust without simplicity is a club. Simplicity without trust is a trap. The product that wins is the one that delivers both — non-custodial settlement underneath, custodial-feeling UX on top.

What this means for builders

If you are building anything that touches payments, a few practical implications.

Do not pick a side. The "non-custodial vs custodial" debate is the wrong frame. The right question is "where does custody live in your stack." Build non-custodial at the settlement layer and abstract aggressively at the UX layer. Both at once.

Endorse the abstraction layer. Smart wallets, embedded sign-flows, AA, social recovery, gas sponsorship — these are not betrayals of crypto values. They are the work that gets crypto values out of the niche. The maximalist position that rejects them cedes the user-experience layer to whoever ships the cleanest abstraction first, which means the architecture wins on Twitter and loses in market share.

Make the seed phrase optional, not a rite of passage. A user who wants to export their key and run their own wallet should always be able to. A user who does not should never have to. Both should be served by the same system.

Treat "non-custodial because it works better" as the win condition. Not "non-custodial because principles." Principles do not win adoption. Better products do — and the principle, in this case, makes the product better. Lead with the better, not with the principle.

Where QBitFlow sits

We made these calls a while ago, and they were not always obvious.

QBitFlow is non-custodial at the settlement layer — every payment routes directly to the merchant's wallet via open-source smart contracts. We never hold funds. There is no omnibus account, no rolling reserve, no customer-service ticket required to withdraw your own money. That part is non-negotiable.

But we also do not require merchants or customers to have lived through the crypto education arc. Customers pay through a hosted checkout. They can use any compatible wallet. Merchants integrate via three SDKs (JS, Python, Go) without writing a line of smart contract code. Subscription billing is automatic — once the customer signs the cap, the system bills on schedule with no manual action from anyone.

We also recently shipped a trust-layer flow for marketplaces: the platform can create user accounts with zero crypto setup on the user's side. No wallet, no password, no seed phrase, no education curve. The account starts receiving payments immediately. When the platform decides the user has earned the right to take custody, one signed transaction transfers everything to a wallet they connect at that moment. Until then, the platform's own ledger keeps the records, with on-chain transaction hashes for every payment.

That feature was built for a specific marketplace partner. But it is the equation in product form — non-custodial settlement, custodial-feeling onboarding, with a clean handoff at the moment the user is ready.

The honest version

The maximalist version of the non-custodial position is right about the architecture and wrong about the strategy. The custodial-UX version is right about the strategy and wrong about the architecture. The equation is the version that gets both.

Adoption is not blocked by trust. It is not blocked by UX. It is blocked by the assumption that you have to choose. You do not.

Build both.

If you are a builder shipping non-custodial infra, we would love to hear what you are working on. If you are a merchant tired of the custodial trade-offs, the QBitFlow checkout takes about ten minutes to set up. qbitflow.app

We Built On Two Chains From Day One — Adding Base Six Months Later Was a Weekend.

QBitFlow — Thu, 07 May 2026 07:00:00 +0000

The Solana-vs-Ethereum debate is a trap for builders

You're building a crypto payments product in 2026. Which chain do you launch on?

Pick Solana, and a chunk of your users will tell you (often loudly, on Hacker News) that:

The validator set is too centralized
There's no mempool, so transactions silently drop during congestion
Light clients can't cryptographically verify state
"It's not even significantly cheaper than L2s anymore"

Pick Ethereum L1, and a different crowd tells you:

L1 fees are insane for anything under $50
Confirmation times are too slow for checkout UX
Your users pay $5 in gas to send $20

Pick a single L2 (Base, Arbitrum, Optimism), and you trade L1's problems for new ones:

Sequencer centralization
Bridge risk
Fragmented liquidity
"What if Coinbase deprecates Base?" is a real question merchants ask. Yes, really.

Every chain has tradeoffs. Picking one means inheriting all of its tradeoffs and all of its critics.

So we picked the two that mattered most — and built the codebase so adding more later wouldn't require a rewrite.

What "two chains from day one" actually meant

We launched QBitFlow with two chains live in the first version of the product:

Ethereum mainnet — for users who care about decentralization, censorship resistance, and the "real" Ethereum
Solana — for users who want sub-second confirmations and fees measured in fractions of a cent

A merchant signs up, picks which chains and tokens to accept (USDC on both? ETH on L1? SOL on Solana?), and customers get a hosted checkout where they pick what to pay with. The smart contracts handle the rest. No bridges. No swaps. The merchant receives payment in the same token the customer paid with.

That's it. No ideological lock-in for the merchant or the customer.

The two-chain choice wasn't accidental. Ethereum and Solana represent the two largest stablecoin economies that don't share an execution model. Covering both meant we could plausibly serve almost any merchant who wanted crypto payments — and, more importantly, it forced the codebase to be honest about chain abstraction from the very first commit.

Then merchants asked for Base

Six months in, a clear pattern emerged in support tickets and sales calls:

"We want USDC. We want EVM-grade security so our users can pay from their existing Coinbase Smart Wallet. We want fees that don't kill micropayments. Do you have a plan for that?"

L1 Ethereum was too expensive for sub-$50 invoices. Solana was great on cost but a different ecosystem with its own wallet UX. Base — Coinbase's L2 — answered the merchant ask precisely: Ethereum's security model, Coinbase Smart Wallet onramp, USDC-native settlement, and fees in cents.

Adding Base took a weekend.

That sentence sounds like marketing, so let me show the work.

How a weekend was enough

Three reasons the Base addition was small instead of large.

1. Same EVM contracts, new deployment target

Base is an OP Stack L2 that runs the EVM. The smart contracts we'd already written, tested, and deployed on Ethereum mainnet were valid bytecode on Base. Adding Base on the contract side was a deployment script, a few configuration constants (chain ID, RPC endpoints, USDC contract address), and a deploy-and-verify run.

Solana would not have been a weekend. Solana would have been weeks at minimum — different language, different account model, different signature scheme, different audit story. We did Solana on day one specifically so we never had to do it as a "later" project. Base was the easy case because we'd already paid the hard cost.

2. The codebase was structured for new chains, not for two chains

This is the part most "we built multi-chain from day one" posts gloss over. There's a meaningful difference between:

"We support Ethereum and Solana" — two specific chains hardcoded into your data model, your webhooks, your SDKs, your dashboard
"We support multiple chains, currently Ethereum and Solana" — chain identifiers as first-class values, chain-specific behaviors isolated behind interfaces, no "if EVM else Solana" branches scattered through the business logic

We aimed for the second from commit one. It cost more upfront because every "just do it for Ethereum first" temptation had to be resisted in favor of an extra layer of abstraction. But the payoff was that adding a chain later wasn't a refactor. It was filling in implementations behind interfaces that already existed.

When Base showed up, the codebase asked: "What's the chain ID? What's the USDC contract address? Which RPC providers do we trust?" It didn't ask: "How do I express the concept of an L2 in a system that previously only knew about L1 and Solana?" That second question is the one that takes a quarter to answer in most multi-chain retrofits. We'd already answered it.

3. EVM means real code reuse, not just contract reuse

Beyond the smart contracts themselves, a lot of the off-chain code path for Base was identical to Ethereum:

Transaction construction, signing, and submission
Event log parsing
Address validation
Webhook payload schemas
SDK methods
Dashboard wallet configuration

The L2-specific differences exist (different gas dynamics, different finality assumptions, sequencer-specific edge cases) but they're additions on top of an existing EVM code path, not parallel implementations. Adding Base was something like a 10% incremental code surface — not 50%, not 100%.

The reason this worked is that we'd already spent the day-one cost of separating "EVM-shaped logic" from "Ethereum-mainnet-specific logic." On day one, you do that for nobody — there's only one EVM chain. Six months later, when an EVM L2 shows up, that distinction pays for itself in a weekend.

What it actually cost us upfront

Two-chains-from-day-one wasn't free. Here's where it actually hurt — honestly.

Two execution models doubled the cognitive load

Every architectural decision had to satisfy both EVM and Solana semantics. ECDSA on one side, Ed25519 on the other. Addresses on one side, program-derived addresses on the other. Gas on one side, compute units and priority fees on the other. RPC reliability quirks differ across providers and chains.

If we'd only done EVM, we'd have shipped faster. We'd also have written code that quietly assumed EVM forever, and Solana would have become a "v2 rewrite" project that never quite got prioritized.

RPC reliability eats more time than you think

Every chain has RPC providers. Every RPC provider has outages. With two chains, you have 2x the surface area for "the customer's transaction looked successful but the webhook never fired." With three, it's 3x — and Base in particular has its own L2-specific edge cases (sequencer hiccups, batch posting delays, withdrawal-window confusion in user support).

We run redundant RPC connections per chain (multiple providers + a public fallback) with health-check rotation. Months of work nobody asks about until a webhook is missing.

Fee abstraction is harder than it looks

EVM has gas. Solana has compute units and priority fees. L2s have gas plus L1 data costs that fluctuate independently of L2 gas. Showing a merchant "this will cost about $X to your customer" needs real-time data feeds for every ecosystem and graceful degradation when they disagree.

Testing surface multiplies

Unit tests, integration tests, fork tests, Solana localnet tests, L2 sequencer simulations — every PR has to pass on every chain. CI takes longer with each chain added. Local dev environment setup is more involved for new contributors.

Documentation gets thin in unexpected places

Most blog posts, tutorials, and Stack Overflow answers assume EVM L1. When a Solana-first dev hits an issue, or an L2-first dev hits an L1 assumption, they often need help we have to write ourselves.

On audits

A note on audits, because most multi-chain posts hand-wave this and we don't want to.

Our smart contracts are open-source on GitHub today. They have not been formally audited yet. Audits are real money — the kind of money that pencils out cleanly when you have meaningful merchant volume backing them, and feels expensive to commit pre-revenue when iteration speed still matters more than the audit certificate.

Our plan is straightforward: as merchant adoption grows and contract changes stabilize, we'll commission a formal audit across both EVM (covering Ethereum + Base — same bytecode, same audit) and Solana (separate review, different ecosystem). Doing both in the same window will be cheaper than doing them sequentially, and the EVM-on-EVM-L2 reuse means Base doesn't add meaningful audit cost beyond Ethereum.

Open-source-without-formal-audit isn't ideal. We're not pretending it is. It's the honest tradeoff for a small team optimizing for shipping over signaling. When the audit happens, we'll publish the report.

What we'd do differently

If we were starting QBitFlow today, we'd ship Ethereum + Solana and Base in v1, even if Base demand wasn't fully proven yet.

Three reasons:

The L2-specific code paths are real, and getting them in while the codebase is small is even cheaper than the weekend it took us six months in. A few extra days on day one beats a weekend later.
Base merchants converted faster than any other chain we've added. The Coinbase Smart Wallet onramp halved customer-side friction overnight. We left months of revenue on the table by waiting.
The infra delta would have been negligible upfront — same redundant RPC setup, same monitoring, just one extra connection per layer.

The original "multi-chain from day one" thesis was right. Our application of it was just slightly too conservative on the L2 side.

When multi-chain from day one is the wrong call

I'm not pretending this is universal advice. Multi-chain from day one is the right call only if:

Payments are your core product. If chains are just a deployment target for your dapp's logic, pick one and ship.
Your users care about chain choice. If they'll use whatever you give them, multi-chain is wasted effort.
You can afford the upfront discipline. If you're solo-bootstrapping with $5K of runway and three weeks before a demo, ship on one chain and prove demand first. The discipline is real and the discipline costs time.

For us, all three were true. QBitFlow is a payment rail. Our users (merchants) absolutely care about which chain their customers can pay on. We chose to take the upfront discipline cost so we'd never have to take the upgrade-rewrite cost.

What's next

We'll add more chains as merchant demand justifies them. Polygon, Optimism, Arbitrum, and a few non-EVM chains are on our roadmap. Each new EVM L2 should be in the same weekend-of-work range as Base was. Non-EVM chains will be more — but the day-one discipline of "chain identifiers as first-class values, no hardcoded execution-model assumptions" makes them additions rather than rewrites.

If you're building anything that touches payments and you're stuck on the "which chain" question, our answer is this: don't pick one. Architect for several from the start, even if you only ship two — and structure your code for adding chains, not for the chains you've shipped. The cost of being wrong about one chain is much smaller than the cost of being locked into one. The cost of architecting for "the chains we currently support" instead of "any chain we might add" is the difference between a weekend's work and a quarter's work, six months later.

QBitFlow is a non-custodial crypto payment rail for one-time payments, subscriptions, and marketplace fee splits — live on Ethereum, Base, and Solana. Smart contracts are open-source on GitHub. Try it →

Zero Chargebacks, Forever: Why Crypto Payments Eliminate the $40B Chargeback Problem

QBitFlow — Wed, 22 Apr 2026 07:00:00 +0000

Visa just made it harder to be a merchant.

Starting April 2026, the Visa Acquirer Monitoring Program (VAMP) drops the "Excessive" chargeback threshold from 2.2% to 1.5% across the US, Canada, and the EU. Merchants above that line face fines starting at $25,000 per month, mandatory remediation programs, and potential account termination.

Shopify sellers are already scrambling. Riskified launched a new product called Dispute Resolve specifically for this change. Chargebacks911 is running webinars. An entire industry is mobilizing to help merchants survive a problem that crypto payments don't have.

Not "reduced chargebacks." Not "chargeback protection." Zero. The concept doesn't exist.

Here's why.

The Chargeback Problem in 2026

Chargebacks cost merchants over $40 billion per year globally. That number has grown every year for the past decade.

The mechanics are brutal:

A customer disputes a charge with their bank
The bank reverses the payment immediately
The merchant loses the product, the revenue, AND pays a $15-25 dispute fee
Even if the merchant wins the dispute (which happens less than 30% of the time), they've spent hours gathering evidence

And here's the part that makes merchants furious: 70% of all card fraud is "friendly fraud." The customer received the product. They just decided to dispute instead of requesting a refund.

Visa's new threshold makes this worse. Previously, you could have a 2.2% dispute rate before getting flagged. Now it's 1.5%. For merchants selling digital goods, subscriptions, or international products — categories with naturally higher dispute rates — this is a ticking clock.

Shopify recently changed its policy so that refunded disputes still count against your chargeback ratio. You can give the money back and still get punished.

Why Chargebacks Exist (And Why They Can't Be Fixed)

Chargebacks aren't a bug. They're a feature of how card networks work.

Credit card payments are "pull-based." You give a merchant your card number. The merchant pulls money from your account. If something goes wrong, the only recourse is to reverse the pull — a chargeback.

This made sense in 1974 when the Fair Credit Billing Act was written. Consumers needed protection from unauthorized charges. But the system was designed for a world where you handed your card to a waiter and hoped for the best.

Fifty years later, the same architecture powers internet commerce. And the 90-day dispute window that protected consumers from shady restaurants now lets anyone reverse any online purchase for almost any reason.

The fraud prevention industry — Riskified, Kount, Sift, Chargebacks911 — exists to patch this design flaw. They're building increasingly sophisticated tools to predict, prevent, and fight disputes. But they're treating symptoms. The underlying architecture guarantees chargebacks will always exist.

You can't fix a pull-based payment system's chargeback problem. You can only manage it.

How Crypto Payments Eliminate Chargebacks

Crypto payments work differently at the architecture level.

Instead of pull-based, they're push-based. The customer sends funds from their wallet. The transaction settles on the blockchain. Done.

There's no intermediary holding the payment. No bank to call. No 90-day window. No dispute process. The smart contract executes, funds transfer, and the transaction is final.

This isn't a policy decision. It's how the technology works. You can't chargeback a blockchain transaction for the same reason you can't un-send cash — once it's transferred, it's transferred.

For merchants, this means:

0% chargeback rate. Not low. Zero.
No dispute fees. The $15-25 per dispute disappears entirely.
No VAMP monitoring. Visa's thresholds don't apply to transactions that don't go through Visa.
No friendly fraud. Customers can't reverse a completed crypto payment.
No evidence gathering. No hours spent compiling shipping receipts and email logs.

"But My Customers Want Refunds"

This is the most common objection. And it's based on a misunderstanding.

Refunds and chargebacks are different things.

A refund is merchant-initiated. The customer asks, the merchant agrees, money goes back. This works fine with crypto payments. The merchant sends funds back to the customer's wallet. Simple.

A chargeback is customer-initiated through a third party (the bank). The merchant has no say. The bank decides.

With crypto payments, merchants keep full control over their refund policy. Want to offer 30-day refunds? Great — you can do that. Want to offer no refunds on digital goods? That's your call, not Visa's.

The difference: the merchant decides when to refund. Not a bank. Not a card network. Not a customer who filed a dispute because they forgot about the purchase.

At QBitFlow, refunds work through smart contracts. The customer creates a refund request, the merchant validates it, the contract executes, and the customer receives funds. Faster than card refunds (which take 5-10 business days) and with zero fees.

The Math: When Crypto Payments Save You Money

Let's run the numbers for a merchant doing $100,000/month in revenue.

Traditional card processing (1% dispute rate):

Processing fees: $2,900 (2.9%)
Chargeback fees: $1,500 (100 disputes × $15)
Lost product value: ~$5,000 (assuming 50% of disputes are on $100 orders)
Staff time fighting disputes: ~$2,000 (20 hours × $100/hr)
Total monthly cost: ~$11,400 (11.4% of revenue)

Crypto payments through QBitFlow:

Processing fees: $1,500 (1.5% flat)
Chargeback fees: $0
Lost product value from disputes: $0
Staff time fighting disputes: $0
Total monthly cost: $1,500 (1.5% of revenue)

That's $9,900/month in savings. $118,800/year.

Even at a 0.5% dispute rate — half the industry average — the savings are significant. And the operational simplicity of never dealing with disputes is worth something that doesn't show up in a spreadsheet.

The break-even point: if chargebacks cost you more than 1.5% of revenue (including fees, lost product, and staff time), crypto payments are cheaper. For most merchants in high-dispute categories, that threshold was crossed years ago.

The Hybrid Approach

Nobody's saying you should stop accepting credit cards tomorrow. Most customers still pay with cards, and that's fine.

The smart move: add crypto as a payment option alongside cards. Then shift your highest-dispute segments to crypto.

Selling digital downloads? Offer a 5% discount for crypto payments. International subscriptions? Make crypto the default with a card fallback. High-ticket items with frequent "item not as described" disputes? Crypto eliminates the risk.

Over time, as more customers hold stablecoins and crypto wallets become mainstream, the percentage naturally shifts. But you don't have to wait for mass adoption to benefit. Even shifting 10-20% of your volume to crypto meaningfully reduces your overall dispute rate.

Getting Started

QBitFlow is non-custodial crypto payment infrastructure. Here's what that means in practice:

Funds go directly to your wallet. We never hold your money. Smart contracts handle the transfer.
1.5% flat fee. No monthly fees. No withdrawal fees. No hidden costs.
Setup in under 10 minutes. API integration, hosted checkout, or WooCommerce plugin.
Ethereum + Solana + Base. 15+ tokens including USDC, USDT, ETH, SOL.
Subscriptions built in. On-chain spending caps — customers authorize, billing happens automatically.
Open-source smart contracts. Audit them yourself. Don't trust, verify.

Visa just made chargebacks more expensive. The trend is clear — thresholds will keep tightening, fines will keep growing, and the chargeback prevention industry will keep selling patches for a broken system.

Or you can accept payments on infrastructure where chargebacks don't exist.

Start accepting zero-chargeback payments today → qbitflow.app

QBitFlow Now Supports Base: Ethereum Security at L2 Prices

QBitFlow — Wed, 08 Apr 2026 11:35:58 +0000

Today we're announcing support for Base — Coinbase's Layer 2 network built on the OP Stack. QBitFlow merchants can now accept payments on Base alongside Ethereum and Solana.

The short version: same non-custodial security, same API, same 1.5% fee — but gas costs drop from dollars to fractions of a cent.

Why Base Matters for Payments

If you've ever processed a crypto payment on Ethereum, you know the pain. A simple USDC transfer can cost $0.50 to $5 in gas fees. For a $10 product, that's a 5-50% surcharge just to move money — before any processing fees.

Base changes the math entirely.

	Ethereum	Base	Difference
Gas per USDC transfer	$0.50 – $5.00	$0.001 – $0.01	~100x cheaper
Block time	~12 seconds	~2 seconds	6x faster
Security model	L1 consensus	Ethereum L1 settlement	Same security guarantees

Base inherits Ethereum's security through L1 settlement while running transactions at a fraction of the cost. For payment processing, this is the sweet spot: you get Ethereum's trust model without Ethereum's gas bills.

What's Supported

Tokens on Base:

USDC (native) — The most widely used stablecoin on Base, with over 8.6 million holders
USDT — Tether's stablecoin, bridged to Base
WETH — Wrapped ETH for merchants who want to accept ETH-denominated payments

Payment types:

One-time payments
Subscriptions with spending caps
Pay-as-you-go billing

Everything that works on Ethereum and Solana now works on Base. Same SDK, same API, same webhooks.

How to Accept Payments on Base

If you're already using QBitFlow, there's nothing to change. Base appears automatically as an option on your hosted checkout page. Your customers choose their preferred chain and token — the payment goes directly to your wallet.

from qbitflow import QBitFlow

client = QBitFlow(api_key="your_api_key")

session = client.one_time_payments.create_session(
    product_name="Premium Plan",
    price=49.99,
    description="Awesome features",
    webhook_url="https://yoursite.com/webhook",
    success_url="https://yoursite.com/success",
    cancel_url="https://yoursite.com/cancel"
)

# Customers see Base as an option on the checkout page
print(session.link)

That's it. No separate integration for each chain. One API call, and your customers can pay on Ethereum, Solana, or Base.

The Cost Comparison Nobody Asked For

Let's run the numbers on a $50 payment:

Processor	Merchant Fee	Customer Gas	Total Merchant Cost
Stripe	$1.75 (2.9% + $0.30)	—	$1.75
PayPal	$1.79 (3.49% + $0.49)	—	$2.24
BitPay	$1.25 (2% + $0.25)	—	$1.25
QBitFlow (Ethereum)	$0.75 (1.5%)	~$2.00	$0.75
QBitFlow (Base)	$0.75 (1.5%)	~$0.005	$0.75
QBitFlow (Solana)	$0.75 (1.5%)	~$0.001	$0.75

With QBitFlow, the merchant always pays 1.5% flat — that's it. Gas fees are paid by the customer as part of the transaction, just like any on-chain transfer.

On Base and Solana, gas is negligible for customers too — under a cent per transaction. On Ethereum, gas is higher, which is exactly why L2 support matters.

The result: merchants pay less than half of what Stripe charges, and nobody can freeze your funds, reverse your payments, or shut down your account.

The Timing

We won't pretend the timing is a coincidence.

Coinbase shut down Commerce on March 31, 2026. Over 8,000 merchants lost their crypto payment processor overnight. The replacement — Coinbase Business — is custodial, requires KYC, and only works in the US and Singapore.

One week later, QBitFlow deploys on Base — Coinbase's own Layer 2.

Non-custodial. Global. No seed phrases. No deplatforming risk.

If you're one of those 8,000 merchants looking for a new home, we built one. And it runs on the same chain Coinbase built.

Three Chains, One Philosophy

QBitFlow now supports three chains, each with different strengths:

Ethereum — Maximum security and liquidity. Best for high-value transactions where settlement guarantees matter most.

Solana — Fastest confirmations and lowest absolute fees. Best for high-frequency, lower-value payments.

Base — Ethereum's security model at L2 prices. Best for merchants who want the Ethereum ecosystem without the gas costs.

The philosophy stays the same across all three: non-custodial, open-source smart contracts, funds go directly to your wallet. We don't touch your money. We just make it easy for your customers to send it to you.

What's Next

Base is our first L2, but it won't be the last. We're evaluating Arbitrum, Polygon, and Optimism based on merchant demand and ecosystem maturity.

We're also working on x402-compatible payment infrastructure for AI agent transactions — but that's a post for another day.

For now: if you're building on Base, accepting payments just got a lot simpler.

Get started: qbitflow.app
API docs: qbitflow.app/docs/api
GitHub: github.com/QBitFlow

QBitFlow is non-custodial crypto payment infrastructure. 1.5% flat fee. No withdrawal fees. No chargebacks. Ethereum, Solana, and Base supported.

Best Coinbase Commerce Alternatives in 2026 — Complete Guide

QBitFlow — Sat, 04 Apr 2026 15:55:55 +0000

Coinbase Commerce is dead. As of March 31, 2026, the service that thousands of merchants relied on for non-custodial crypto payments no longer exists.

Coinbase's replacement — Coinbase Business — is a different product entirely. It's custodial (Coinbase holds your funds), restricted to the US and Singapore, and requires full KYB verification. If you're outside those two countries, there's no migration path. If you valued self-custody, there's no migration path either.

So what are the actual alternatives?

We spent weeks researching every viable crypto payment processor on the market. This guide covers six options — including QBitFlow, which we built — with honest assessments of each. No fluff, real numbers, genuine tradeoffs.

Quick Comparison

Provider	Custody	Base Fee	Subscriptions	Chains/Tokens	Plugins	Fiat Settlement	KYB Required
BitPay	Custodial	1–2% + $0.25	❌	16 tokens	Shopify, WooCommerce, Magento, BigCommerce	✅ USD/EUR/GBP	✅ Yes
CoinGate	Custodial	1% flat	❌	70+ tokens	Shopify, WooCommerce, Magento, PrestaShop, WHMCS	✅ EUR/USD	✅ Yes
LlamaPay	Non-custodial	Low/variable	Streaming only	EVM chains	None	❌	❌
NOWPayments	Custodial	0.5–1%*	❌	200+ tokens	20+ plugins	✅ (via partners)	✅ Yes
QBitFlow	Non-custodial	1.5% flat	✅ Smart contract	ETH, SOL, Base	WooCommerce, SDKs	❌	❌
Request Network	Non-custodial	Variable	❌	EVM chains	Limited	❌	❌

*NOWPayments: advertised rates. Actual costs often higher due to network fees on both legs — see detailed review below.

Detailed Reviews

1. BitPay

What it is: The oldest crypto payment processor, operating since 2011. BitPay is fully custodial — they receive crypto from your customers, convert it, and settle in fiat to your bank account. Think of it as the PayPal of crypto payments.

Pricing:

Under $500K/month: 2% + $0.25 per transaction
$500K–$1M/month: 1.5% + $0.25
Over $1M/month: 1% + $0.25

Pros:

Most established player — 15 years in business, unlikely to disappear overnight
Fiat settlement means no crypto volatility risk
Solid plugin ecosystem (Shopify, WooCommerce, Magento, BigCommerce)
Supports settlement in USD, EUR, and GBP
Good for merchants who want crypto as a payment method but don't want to hold crypto

Cons:

Fully custodial — BitPay holds your funds during processing
Requires full KYB verification (business documents, bank details, the works)
Limited token support (16 tokens vs. the hundreds others offer)
2% fee at lower volumes is steep compared to alternatives
Settlement delays — funds don't hit your bank instantly

Best for: Established businesses that want fiat settlement, don't mind KYB, and process enough volume to qualify for lower fee tiers. If you just want crypto converted to dollars in your bank account, BitPay is the safe, boring choice.

2. CoinGate

What it is: A Lithuanian crypto payment gateway founded in 2014. Like BitPay, it's custodial with fiat settlement — but with better token variety and a European focus. Licensed and regulated in the EU.

Pricing: 1% flat fee on all transactions. No volume tiers, no per-transaction fixed fee. Simple.

Pros:

1% flat fee is competitive and predictable
70+ supported cryptocurrencies — far more than BitPay
Fiat settlement in EUR and USD
Strong plugin support (Shopify, WooCommerce, Magento, PrestaShop, WHMCS)
EU-regulated, which matters for compliance-conscious businesses
Supports SEPA payouts for European merchants

Cons:

Custodial — CoinGate holds funds during processing
Requires KYB verification
Primarily European-focused — less ideal for merchants in other regions
Settlement times can vary (1–3 business days for SEPA)

Best for: European merchants who want fiat settlement with good token variety at a flat 1% rate. If you're EU-based and BitPay's tiered pricing annoys you, CoinGate is the cleaner option.

3. LlamaPay

What it is: Built by the DefiLlama team, LlamaPay is a non-custodial streaming payment protocol. It's designed for continuous money flows — think payroll, vesting schedules, and recurring payments that stream by the second.

Pricing: Low protocol fees, varies by chain. No traditional per-transaction pricing.

Pros:

Truly non-custodial — smart contract based
Built by the DefiLlama team (strong reputation in DeFi)
Streaming payments are genuinely innovative for payroll use cases
Multi-chain support across EVM networks

Cons:

Not a merchant checkout solution. This is the big one. LlamaPay has no hosted checkout page, no payment links, no webhooks, no merchant dashboard. It's a protocol for streaming payments, not a Coinbase Commerce replacement.
No plugins for e-commerce platforms
Requires technical integration at the smart contract level
Customer UX assumes DeFi familiarity

Best for: DeFi-native teams paying contributors or running token vesting. If you're looking for a Coinbase Commerce replacement for your online store, LlamaPay isn't it. Including it here because it shows up in "crypto payment" searches, and you should know what it actually does before evaluating it.

4. NOWPayments

What it is: A crypto payment gateway supporting 200+ cryptocurrencies with auto-conversion features. NOWPayments routes payments through their own wallets before forwarding to yours — making it custodial in practice, despite some marketing suggesting otherwise.

Pricing:

Single-currency payments: 0.5%
Multi-currency (auto-conversion): 1%

The fee reality: Those advertised rates look great on paper. In practice, NOWPayments charges network fees on both the incoming and outgoing transactions. Depending on the chain and token, your actual cost per transaction can land between 2–5%. Multiple merchant reports confirm this. The base fee is low, but the total cost often isn't.

Pros:

200+ supported cryptocurrencies — the widest selection available
20+ e-commerce plugins (Shopify, WooCommerce, and many more)
Auto-conversion between cryptocurrencies
Mass payouts feature for businesses paying multiple recipients
Crypto-to-fiat settlement available through partners

Cons:

Effectively custodial — funds route through NOWPayments wallets
Hidden network fees can 3–5x your expected costs
Requires KYB for full features
Auto-conversion adds slippage on top of fees
Support quality varies based on merchant reports

Best for: Merchants who need to accept obscure tokens and want maximum cryptocurrency variety. Just go in with eyes open about the real fee structure — budget 2–3% per transaction, not the 0.5% on the landing page.

5. QBitFlow

What it is: A non-custodial crypto payment processor built on open-source smart contracts. Funds go directly from customer wallet to merchant wallet — QBitFlow never touches your money. Full disclosure: this is our product, so take this section with appropriate skepticism and verify claims yourself.

Pricing: 1.5% flat fee. No hidden network fees, no per-transaction fixed costs, no volume tiers. The fee is taken at the smart contract level during the transaction.

Pros:

Truly non-custodial — funds go straight to your wallet, verified by open-source smart contracts
Smart contract subscription billing — customers approve a spending cap, and billing happens automatically each cycle. No other payment processor offers this on-chain.
Marketplace/platform model — on-chain fee splitting lets platforms take a percentage automatically via smart contracts. Build your own marketplace with built-in revenue sharing.
Hosted checkout with brand customization (your logo, your colors)
No KYB required — start accepting payments in minutes
Webhooks, SDKs (Python, Go, JavaScript), WooCommerce plugin
Test mode available — try everything without real funds
Zero withdrawal fees, zero chargebacks

Cons:

Fewer plugins than established players — WooCommerce only for now (Shopify and others coming)
No fiat settlement — you receive crypto and manage conversion yourself
Supports Ethereum, Solana, and Base — fewer chains than NOWPayments or CoinGate
Newer product — less track record than BitPay or CoinGate
Smaller token selection compared to custodial alternatives

Best for: Merchants who value self-custody and want subscription billing or marketplace fee splitting — features nobody else offers on-chain. Also a strong fit if you're outside the US/Singapore and KYB requirements lock you out of other options. Weakest fit if you need fiat settlement or support for dozens of altcoins.

6. Request Network

What it is: A non-custodial, invoice-based payment protocol. Request Network focuses on creating verifiable payment requests on-chain — closer to invoicing than checkout. They've partnered with Kryptos for compliance and tax reporting features.

Pricing: Variable fees depending on the integration path. No simple flat-rate pricing published.

Pros:

Non-custodial — payments settle directly between parties
Strong B2B invoicing features with compliance tooling
On-chain payment verification and audit trails
Partnership with Kryptos for tax reporting
Good for businesses that need payment documentation for accounting

Cons:

Not designed for consumer checkout flows — no "Buy Now" button experience
No subscription billing
Limited e-commerce plugins
More complex integration than hosted checkout solutions
Better suited for invoicing than real-time payment processing

Best for: B2B companies that need compliant invoicing with on-chain verification. If you're sending invoices to other businesses and need audit trails, Request Network is purpose-built for that. If you're running an online store and need a checkout page, look elsewhere.

Which One Should You Choose?

Skip the analysis paralysis. Here's the decision tree:

Want fiat settlement (crypto in, dollars out)? → BitPay or CoinGate
European merchant wanting simple pricing? → CoinGate (1% flat, EU-regulated)
High volume and want the lowest custodial fee? → BitPay (1% at $1M+/month)
Need maximum token variety? → NOWPayments (but budget 2–3% real costs, not 0.5%)
Want true non-custodial with no KYB? → QBitFlow
Need subscription billing on-chain? → QBitFlow (only option)
Building a marketplace or platform? → QBitFlow (on-chain fee splitting, only option)
DeFi-native team doing payroll/vesting? → LlamaPay
B2B invoicing with compliance needs? → Request Network

No single provider replaces everything Coinbase Commerce did for everyone. The right choice depends on what you actually need.

Migrating from Coinbase Commerce

If you're coming from Coinbase Commerce specifically, we wrote a step-by-step migration guide: How to Migrate from Coinbase Commerce in 10 Minutes

The short version:

Export your data from Coinbase Commerce before they fully shut down access
Set up your new provider — most take under 30 minutes
Update your integration — swap API endpoints and webhook URLs
Test thoroughly — use test/sandbox mode before going live
Update your checkout flow — redirect customers to your new payment page

If you're migrating to QBitFlow specifically, the guide above walks through the exact API changes, webhook mapping, and checkout redirect setup.

The Bottom Line

Coinbase Commerce shutting down is frustrating, but it's also a chance to pick a provider that actually fits your needs — not just the one that was convenient because you already had a Coinbase account.

The honest truth: there's no perfect 1:1 replacement. Every option involves tradeoffs. Custodial providers like BitPay and CoinGate give you fiat settlement but take custody of your funds. Non-custodial options like QBitFlow keep you in control but don't convert to fiat for you.

If you value self-custody, subscription billing, or marketplace fee splitting, give QBitFlow a try. Test mode is free, no credit card required, no KYB paperwork. You can have a working checkout in under 10 minutes and decide if it fits.

Whatever you choose — don't paste your seed phrase into a web form. That part of the Coinbase migration was a bad idea, and it's still a bad idea.

Why the Coinbase Commerce Shutdown Proves You Need Non-Custodial Payments

QBitFlow — Fri, 27 Mar 2026 18:06:52 +0000

On March 31, 2026, Coinbase Commerce shuts down for good. Thousands of merchants — from indie SaaS founders to established e-commerce stores — are scrambling to find alternatives.

But the real lesson isn't "find another payment processor." It's this: if someone else controls your payment infrastructure, they control your business.

What Happened

Coinbase launched Commerce in 2018 as a way for merchants to accept crypto payments. It worked. Merchants integrated it, built checkout flows around it, and processed real revenue through it.

Then Coinbase decided it wasn't worth maintaining. One email. Roughly 30 days notice. Migrate or lose access.

The replacement — Coinbase Business — is a different product entirely:

Custodial (Coinbase holds your funds)
US and Singapore only (international merchants are out of luck)
Requires seed phrase management (the exact thing merchants wanted to avoid)
No subscription support (Commerce never had it either, but still)

For merchants outside the US, there is no migration path. Coinbase just... stopped serving them.

The Custodial Trap

This isn't unique to Coinbase. It's the fundamental flaw of custodial payment processing — whether crypto or fiat.

When you use a custodial processor, you're renting access to your own revenue. The company sits between your customer's money and your wallet. They can:

Change terms unilaterally (Stripe does this regularly)
Freeze your funds (PayPal is notorious for this)
Shut down entirely (hello, Coinbase Commerce)
Restrict your industry (try accepting payments for CBD, adult content, or supplements through Stripe)

You don't own your payment rail. You're borrowing someone else's.

Non-Custodial: The Alternative That Can't Be Shut Down

Non-custodial crypto payments work differently. There's no middleman holding funds. The money moves directly from your customer's wallet to yours, enforced by smart contracts on the blockchain.

Here's what that means in practice:

No one can freeze your funds. The payment goes to your wallet. Not a company's wallet. Not an escrow account. Yours.

No one can shut down your payment rail. Smart contracts live on Ethereum and Solana. They don't have a CEO who can decide they're not profitable enough.

No seed phrase exposure. You provide a public wallet address. That's it. No private keys, no seed phrases, no custody risk.

Open-source and auditable. The smart contracts are public. You can verify exactly what they do. No black box.

How QBitFlow Does It

We built QBitFlow around this principle from day one:

Direct wallet-to-wallet payments via open-source smart contracts
Ethereum + Solana with support for USDC, USDT, ETH, SOL, and more
Subscriptions — spending cap model where customers authorize recurring billing via smart contract. Coinbase Commerce never had this.
1.5% flat fee — no setup fees, no monthly fees, no withdrawal fees
WordPress + WooCommerce plugins — install and go live in minutes
Python, Go, and JavaScript SDKs for custom integrations
Hosted checkout — customers are redirected to a branded checkout page, then back to your site

The merchant never needs to manage private keys, handle custody, or trust a third party with their funds.

Migrating from Coinbase Commerce

If you're one of the merchants affected by the shutdown, here's the practical path:

Sign up at qbitflow.app (takes 2 minutes)
Connect your wallet — just provide your public address (Ethereum or Solana)
Swap the integration — replace Coinbase Commerce API calls with QBitFlow SDK calls. The flow is similar: create a session, get a checkout URL, handle webhooks.
Test in test mode before going live

If you're on WordPress or WooCommerce, we have plugins that handle everything — no code needed.

Early adopter pricing: 0.99% for 6 months for the first 50 merchants. Get started →

The Bigger Picture

The Coinbase Commerce shutdown is a symptom, not the disease. The disease is dependency on platforms that can change the rules whenever they want.

Non-custodial payments aren't just a crypto ideology thing. They're a practical business decision: your revenue should flow to your wallet, not through someone else's infrastructure that can disappear with 30 days notice.

Your wallet. Your funds. Your business.

Coinbase Commerce Is Shutting Down — Here's How to Migrate in 10 Minutes

QBitFlow — Sun, 22 Mar 2026 14:54:39 +0000

March 31, 2026. That's the deadline. Coinbase Commerce is done.

If you're one of the 8,000+ merchants who built your crypto payment flow on Coinbase Commerce, you have 10 days to figure out what comes next. Coinbase's answer is "Coinbase Business" — a custodial service limited to the US and Singapore. For most of you, that's not an answer at all.

We built QBitFlow as a non-custodial crypto payment processor. When Coinbase announced this shutdown, our inboxes started filling up. This post is the migration guide we keep sending people — now public so everyone can use it.

What's Actually Happening

Coinbase is folding Commerce into a new product called Coinbase Business. Here's what that means in practice:

Your self-managed wallets are gone. Coinbase Commerce was non-custodial — you held your own keys, funds went to your wallet. Coinbase Business is custodial. Coinbase holds your funds. Full stop.

Geographic lockout. Coinbase Business is only available in the United States and Singapore. If you're a merchant in Europe, Asia, Latin America, Africa, or anywhere else — there is no migration path. You're just... cut off.

The seed phrase disaster. This is the part that made security researchers lose their minds. Coinbase published a migration form asking merchants to paste their 12-word seed phrases into a web page. Your seed phrase. Into a browser form. On the internet.

ZachXBT flagged it. evilcos (SlowMist founder) called it out as dangerous. And they're right — this goes against every security principle in crypto. Your seed phrase is the master key to your wallet. You don't type it into web forms. Ever. Not even if Coinbase asks nicely.

The fact that a company as large as Coinbase shipped this tells you something about how much thought went into this transition.

Why This Should Worry You

You chose Coinbase Commerce for a reason. Probably several:

Self-custody. You controlled your funds. No intermediary could freeze, delay, or seize your money.
Simplicity. Clean API, hosted checkout, webhook notifications.
Trust. The Coinbase brand gave your customers confidence.

Coinbase Business throws away the first one. And without self-custody, the other two don't matter much — there are plenty of custodial payment processors out there, most of them better established than a brand-new Coinbase product.

Here's what migrating to Coinbase Business actually means:

Someone else controls your money. Coinbase can freeze your account, delay withdrawals, or comply with seizure orders — all without your consent.
KYB/KYC friction. Custodial means compliance requirements. More paperwork, more delays, more reasons for your account to get flagged.
Geographic exclusion. Not in the US or Singapore? You literally cannot use it.
The seed phrase risk. If you already pasted your seed phrase into that form, you should move your funds to a new wallet immediately. That key is compromised.

QBitFlow: The Non-Custodial Alternative

QBitFlow is what Coinbase Commerce should have become. Here's the short version:

Non-custodial, for real. Payments flow directly from your customer's wallet to yours through open-source smart contracts. We never touch your funds. We never hold your keys. We can't freeze your account because there's nothing to freeze.

No seed phrases. Ever. You give us a public wallet address. That's it. We don't need your private keys, we don't want your seed phrase, and we will never ask for them.

Global by default. No geographic restrictions. If you have a wallet and an internet connection, you can accept payments through QBitFlow. Merchants in 100+ countries already do.

Multi-chain support. Ethereum and Solana, with a wide range of tokens on each:

Ethereum: ETH, WETH, USDC, USDT, LINK, UNI, ARB, POL
Solana: SOL, WSOL, USDC, USDT, LINK, DAI, JUP, RAY, HNT, BAT, PUMP

You choose which chains and tokens to accept. Your customers pay in their preferred token, and you receive that exact token — no forced conversions, no auto-swaps eating into your margins.

Subscription billing. This is something Coinbase Commerce never offered. QBitFlow supports recurring payments enforced by smart contracts — spending caps, automatic billing cycles, trial periods. More on this below.

Marketplace model. If you're a platform (think: creator economy, multi-vendor marketplace), QBitFlow supports organization-level accounts with automatic fee splitting. Set a platform fee percentage, and smart contracts enforce the split on every transaction. No manual reconciliation.

1.5% flat fee. No withdrawal fees. No conversion fees. No monthly minimums. No premium tiers. One number.

Side-by-Side: Coinbase Commerce vs QBitFlow

Feature	Coinbase Commerce	QBitFlow
Custody model	Non-custodial (was) → Custodial (forced migration)	Non-custodial — always
Seed phrase required	Yes (migration form)	Never — public address only
Geographic availability	US + Singapore only (Coinbase Business)	Global
Supported chains	Ethereum, Bitcoin, Litecoin, others	Ethereum + Solana (expanding)
Supported tokens	Limited	8 on Ethereum, 11+ on Solana
One-time payments	✅	✅
Subscription billing	❌	✅ (smart contract-enforced)
Marketplace / fee splitting	❌	✅ (org→user model)
Hosted checkout	✅	✅ (customizable theme + logo)
API & SDK	REST API	REST API + SDK (Python, JavaScript, Go)
Webhook verification	HMAC-SHA256	HMAC-SHA256 + timestamp
Fee	1% (but now custodial)	1.5% flat
Withdrawal fees	Varies	$0
Hidden fees	Conversion fees on some tokens	None
Open-source contracts	No	Yes
KYC/KYB required	Yes (Coinbase Business)	No
Status after March 31	Shut down	Fully operational

Migration Guide: 4 Steps, 10 Minutes

This is the part you came for. Here's exactly how to move from Coinbase Commerce to QBitFlow.

Step 1: Sign Up on QBitFlow (2 minutes)

Go to qbitflow.app/get-started
Sign up with your email
Connect your wallet — just paste your public wallet address (Ethereum, Solana, or both)
Grab your API key from the dashboard

No seed phrases. No private keys. No KYC forms. Just a wallet address.

Step 2: Create Your First Product (2 minutes)

You can do this through the dashboard UI or via the API. Set your product name, description, and price in USD — conversion between USD and the currency the user chooses to pay with is handled automatically during checkout. Done.

Step 3: Swap Your API Integration (5 minutes)

If you're using Coinbase Commerce's API to create charges, here's the before and after.

Coinbase Commerce (old):

import requests

response = requests.post(
    "https://api.commerce.coinbase.com/charges",
    headers={"X-CC-Api-Key": "your-api-key"},
    json={
        "local_price": {"amount": "100.00", "currency": "USD"},
        "redirect_url": "https://merchant.com/success",
        "cancel_url": "https://merchant.com/cancel",
        "metadata": {"order_id": "12345"}
    }
)
checkout_url = response.json()["data"]["hosted_url"]

QBitFlow (new):

from qbitflow import QBitFlow

client = QBitFlow(api_key="your_api_key")

response = client.one_time_payments.create_session(
    product_name="Your Product",
    description="Product description",
    price=100.00,
    success_url="https://merchant.com/success",
    cancel_url="https://merchant.com/cancel",
    webhook_url="https://merchant.com/webhook",
    customer_uuid="customer-uuid"
)

checkout_url = response.link

The structure is nearly identical. You're swapping one SDK call for another. If you had a wrapper function around Coinbase's API (and you probably did), you're changing the internals of one function.

Step 4: Update Your Webhook Handler (1 minute)

Coinbase Commerce webhooks used a single X-Cc-Webhook-Signature header with HMAC-SHA256 verification and events like charge:confirmed and charge:failed.

QBitFlow webhooks use two headers (X-Webhook-Signature-256 and X-Webhook-Timestamp) and fire on status: completed and failed.

Here's a complete FastAPI webhook handler:

from fastapi import FastAPI, Request, Header, HTTPException
from qbitflow import QBitFlow
from qbitflow.dto.transaction.session import SessionWebhookResponse
from qbitflow.dto.transaction.status import TransactionStatusValue

app = FastAPI()
client = QBitFlow(api_key="your_api_key")

@app.post("/webhook")
async def handle_webhook(
    request: Request,
    x_webhook_signature_256: str = Header(),
    x_webhook_timestamp: str = Header()
):
    body = await request.body()

    if not client.webhooks.verify(
        payload=body,
        signature=x_webhook_signature_256,
        timestamp=x_webhook_timestamp
    ):
        raise HTTPException(status_code=401)

    event = SessionWebhookResponse.model_validate_json(body)

    if event.status.status == TransactionStatusValue.COMPLETED:
        # Payment successful — fulfill the order
        pass
    elif event.status.status == TransactionStatusValue.FAILED:
        # Payment failed — notify the customer
        pass

    return {"received": True}

Map your existing Coinbase event handlers:

charge:confirmed → TransactionStatusValue.COMPLETED
charge:failed → TransactionStatusValue.FAILED

That's it. Four steps. Your checkout flow is now running on QBitFlow.

Bonus: Subscriptions (Something Coinbase Commerce Never Had)

One of the most requested features Coinbase Commerce never shipped was recurring billing. If you were hacking together subscription logic on top of one-time charges, you can stop.

QBitFlow handles subscriptions natively with smart contract-enforced spending caps:

from qbitflow import QBitFlow, Duration

client = QBitFlow(api_key="your_api_key")

response = client.subscriptions.create_session(
    product_id=1,
    frequency=Duration(value=1, unit="months"),
    trial_period=Duration(value=7, unit="days"),
    webhook_url="https://your-domain.com/webhook",
    customer_uuid="customer-uuid",
)

print(response.link)  # Send this to your customer

Here's how it works:

Your customer clicks the checkout link and authorizes a spending cap via smart contract
The smart contract allows your merchant wallet to pull payments on the defined schedule
Billing happens automatically each cycle — no manual triggers, no cron jobs on your end
Funds stay in the customer's wallet until each payment executes
The customer can revoke authorization at any time

No seed phrases involved. No custody. The smart contract is the escrow, and it's open-source so anyone can audit it.

This is genuinely new infrastructure that didn't exist on Coinbase Commerce. If you've been wanting to offer crypto subscriptions, now you can.

Pricing: The Real Math

Let's talk numbers honestly.

QBitFlow: 1.5% flat. That's the whole pricing page. No withdrawal fees, no conversion fees, no monthly fees, no premium tiers. You pay 1.5% on each transaction. Period.

Coinbase Commerce was 1% — but that product is dead. Coinbase Business pricing hasn't been fully disclosed, and it comes with custodial strings attached.

How does this compare to traditional payments?

Stripe charges 2.9% + $0.30 in the US, or 1.5% + €0.25 in Europe. Add international card fees (1-2%), currency conversion fees, and chargeback fees ($15 per dispute whether you win or not).

Quick math: on a $100 transaction, Stripe takes $3.20 (US) or €1.75 (EU). QBitFlow takes $1.50. On a $50 transaction, Stripe takes $1.75 (US). QBitFlow takes $0.75.

QBitFlow is cheaper than Stripe for any transaction over ~$17. And there are zero chargebacks in crypto — that alone saves some merchants thousands per year.

What about other crypto processors? Many advertise rates below 1%, but read the fine print. Withdrawal fees, conversion fees, premium plan requirements, and minimum thresholds add up fast. QBitFlow's 1.5% is the real number — what you see is what you pay.

Time's Running Out

March 31 is 10 days away. Coinbase Commerce will stop processing payments. If you haven't migrated, your checkout breaks.

You have three options:

Move to Coinbase Business — if you're in the US or Singapore and you're okay with custodial. Paste your seed phrase into their form if you want (please don't).
Find another processor — there are several. Do your research.
Move to QBitFlow — non-custodial, global, 10-minute setup, and you keep your keys.

We built QBitFlow because we believe merchants shouldn't have to choose between convenience and self-custody. You can have both.

Start your migration →

Setup takes about 10 minutes. If you hit any snags, reach out to us at support@qbitflow.app — we're helping merchants migrate all week.

Your keys. Your funds. Your business.

Stablecoin Regulation Is Here: What It Means for Merchants Accepting Crypto Payments in 2026

QBitFlow — Tue, 10 Mar 2026 12:44:28 +0000

For years, the biggest objection to accepting crypto payments was the same: "It's not regulated."

That objection just expired.

The GENIUS Act — the Guiding and Establishing National Innovation for U.S. Stablecoins Act — was signed into law in July 2025. The OCC published its implementation framework in February 2026. And the ripple effects are already reshaping how businesses think about crypto payments.

If you're a merchant, SaaS founder, or anyone processing payments online, here's what you need to know — and why 2026 might be the year stablecoin payments go from "interesting experiment" to "obvious choice."

What the GENIUS Act Actually Does

The GENIUS Act creates the first comprehensive federal regulatory framework for payment stablecoins in the United States. Here's what matters for merchants:

1. Stablecoins Are Legally Defined — and They're Not Securities

The Act explicitly excludes compliant payment stablecoins from the federal definitions of "security" and "commodity." This means they fall outside SEC and CFTC jurisdiction, creating a clear legal category for the first time.

For merchants, this is huge. You're no longer accepting a payment in a legally ambiguous asset. Compliant stablecoins like USDC now have a defined regulatory status.

2. One-to-One Reserve Backing Is Required by Law

Every payment stablecoin must be backed 1:1 by U.S. dollars or other low-risk assets (like short-term Treasuries). Issuers must maintain and prove these reserves.

Circle, the issuer of USDC, has published 41 consecutive monthly attestation reports audited by Deloitte. Under the GENIUS Act, this level of transparency isn't optional — it's the law.

3. Federal Oversight Is Real

The OCC (Office of the Comptroller of the Currency) now oversees federal stablecoin issuers directly. On February 25, 2026, the OCC published a comprehensive proposed rule to implement the GENIUS Act, establishing licensing requirements, reserve standards, and supervisory frameworks for "Permitted Payment Stablecoin Issuers" (PPSIs).

This isn't self-regulation. It's the same agency that oversees national banks.

4. Banks Can Issue Stablecoins

The Act allows federally chartered banks to issue their own stablecoins. Stripe's Bridge subsidiary has already received initial approval for a national bank trust charter, which would let it issue stablecoins, custody digital assets, and manage reserves under direct federal oversight.

When Stripe — the company that processes payments for millions of businesses — is building stablecoin infrastructure, the signal is clear.

The Numbers Tell the Story

The regulatory shift isn't happening in a vacuum. The market is already moving:

39% of U.S. merchants already accept cryptocurrency at checkout, according to a January 2026 PayPal/NCA study. That's roughly 14 million merchants.
84% of merchants believe crypto payments will become mainstream within 5 years.
72% of merchants who accept crypto reported revenue increases.
741 million people globally now hold cryptocurrency.
The crypto payment gateway market is projected to grow from $1.69B in 2024 to $4B by 2029 — an 18.9% CAGR.
Solana alone processed $650 billion in stablecoin volume in February 2026 — more than 2x its previous record.

These aren't projections from crypto enthusiasts. These are numbers from PayPal, Visa, and market research firms.

Big Tech Is All In

The GENIUS Act didn't just give merchants confidence — it gave Big Tech the green light.

Meta: Stablecoin Payments Across 3 Billion Users

Meta is planning to integrate stablecoin payments across Facebook, Instagram, and WhatsApp in H2 2026. After the Libra/Diem debacle, Meta is taking a different approach — partnering with a third-party stablecoin provider rather than issuing their own.

When stablecoin payments are available natively in WhatsApp, the question for merchants won't be "should I accept crypto?" — it'll be "how do I accept it?"

Stripe + Bridge: Stablecoin Cards in 100+ Countries

Stripe acquired Bridge, a stablecoin infrastructure platform, and they're now rolling out stablecoin-linked Visa cards to over 100 countries. Bridge has also received initial approval for a national bank trust charter from the OCC.

Stripe is betting its future on stablecoins. If you're already using Stripe, stablecoin payments are coming to you whether you planned for them or not.

Visa + Mastercard: Card Networks Embrace Stablecoins

Visa partnered with Bridge to bring stablecoin-linked cards globally. Mastercard partnered with MetaMask to launch self-custodial crypto spending cards across 49 U.S. states.

The card networks aren't fighting stablecoins — they're integrating them. They see the writing on the wall: stablecoin rails are faster and cheaper than traditional payment networks.

Kraken: First Crypto Company With Fed Access

On March 4, 2026, Kraken Financial became the first digital asset bank to receive a Federal Reserve master account. This gives Kraken's banking arm direct access to the Fed's core payment systems — the same rails that traditional banks use.

Crypto is no longer a parallel financial system. It's plugging directly into the existing one.

What This Means for Merchants

The Risk Equation Has Flipped

A year ago, accepting crypto payments felt risky. Unclear regulations, volatile assets, uncertain legal status.

Today:

Stablecoins have a clear legal framework (GENIUS Act)
Reserves are audited and backed 1:1 (required by law)
Federal oversight exists (OCC)
Major payment companies are building on stablecoins (Stripe, Visa, Mastercard)
39% of your competitors already accept crypto

The risk is no longer "what if I accept crypto and something goes wrong?" The risk is "what if I don't accept crypto and my competitors do?"

Stablecoins Solve the Volatility Problem

The #1 merchant concern with crypto payments has always been price volatility. Nobody wants to accept a payment in ETH and have it lose 15% overnight.

Stablecoins eliminate this entirely. USDC is pegged 1:1 to the U.S. dollar, backed by cash and short-term Treasuries, and audited monthly. Accepting USDC is functionally identical to accepting dollars — except it settles instantly, costs less, and has no chargebacks.

The Fee Advantage Is Real

Traditional payment processing:

Stripe: 2.9% + $0.30 per transaction (domestic), plus 1% for international, plus $15 per chargeback
PayPal: 2.99% + $0.49 per transaction
International wires: $15-50 per transfer + 1-3% FX conversion

Stablecoin payments:

QBitFlow: 1.5% flat. No per-transaction fixed fee. No international surcharges. No chargebacks. No withdrawal fees.

For a business processing $50,000/month, switching from Stripe to stablecoin payments saves roughly $700-1,000/month. For businesses with international customers, the savings are even larger.

No Chargebacks. Period.

Blockchain transactions are final. Once a payment is confirmed on-chain, it cannot be reversed by a third party. There's no "dispute" process, no chargeback fees, no rolling reserves.

For merchants in high-dispute verticals — digital goods, subscriptions, international sales — this alone can justify the switch.

Custodial vs. Non-Custodial: Why It Matters More Now

With regulation comes scrutiny. And one of the most important distinctions in crypto payments is whether your payment processor is custodial or non-custodial.

Custodial Processors

Most crypto payment gateways (Coinbase Commerce, BitPay, CoinPayments) are custodial. They receive your customers' payments, hold the funds, and then transfer them to you on their schedule.

Sound familiar? It's the same model as traditional payment processors — with the same risks:

Your funds sit in someone else's account
You're subject to their withdrawal schedule and limits
If they get hacked, frozen, or go bankrupt, your funds are at risk
They can freeze your account at their discretion

Non-Custodial Processors

Non-custodial processors never touch your funds. Payments go directly from your customer's wallet to yours. The processor facilitates the transaction but never takes custody.

This is how QBitFlow works. Smart contracts enforce the payment logic — amounts, timing, spending caps — but funds always flow directly between wallets. We can't hold, freeze, or delay your money because we never have it.

In a regulated world, non-custodial is the model that aligns with the spirit of crypto: you control your money.

How to Start Accepting Stablecoin Payments Today

If you're ready to start accepting stablecoin payments, here's what the setup looks like with QBitFlow:

Create an account at qbitflow.app (takes 2 minutes)
Connect your wallet — this is where payments will be sent directly
Create a product with your pricing (one-time or subscription)
Share your checkout link or integrate via API

That's it. No lengthy onboarding. No KYC for merchants (you're receiving payments to your own wallet). No minimum volume requirements.

You can test the entire flow in test mode before going live — no real funds needed.

For Developers

QBitFlow provides SDKs in Python, Go, and TypeScript/JavaScript, plus a REST API with webhook notifications. If you've integrated Stripe before, the concepts are familiar — products, prices, subscriptions, webhooks — just without the custodial middleman.

For Non-Technical Users

The QBitFlow dashboard lets you create products, generate checkout links, and manage subscriptions without writing a single line of code. Share a link, get paid.

The Bottom Line

Stablecoin regulation isn't a threat to crypto payments — it's the catalyst. The GENIUS Act removed the biggest barrier to merchant adoption: regulatory uncertainty.

The infrastructure is being built by the biggest names in finance. The adoption numbers are already significant. And the economics — lower fees, instant settlement, no chargebacks — have always favored crypto.

The only question left is timing. And for merchants watching Stripe, Visa, Mastercard, and Meta all move into stablecoins simultaneously, the answer is becoming obvious.

The future of payments is stablecoins. The regulation is here. The infrastructure is ready.

Ready to start accepting stablecoin payments? Get started with QBitFlow — non-custodial, 1.5% flat, live in minutes.

QBitFlow vs Stripe: A Complete Fee Comparison for 2026

QBitFlow — Wed, 04 Mar 2026 12:42:21 +0000

Stripe is the default payment processor for most online businesses. It's reliable, well-documented, and ubiquitous. But "default" doesn't mean "optimal" — especially when it comes to fees.

If you're running a SaaS, marketplace, or any online business, you've probably accepted Stripe's pricing as a cost of doing business. But in 2026, there's a real alternative — and the math is worth looking at.

Stripe's Fee Structure in 2026

Stripe's pricing looks simple on the surface: a percentage plus a fixed fee per transaction. In practice, it's more layered than that.

Base Transaction Fees

Region	Domestic Cards	International Cards
🇺🇸 USA	2.9% + $0.30	3.9% + $0.30
🇪🇺 EU	1.5% + €0.25	2.5% + €0.25
🇬🇧 UK	1.5% + £0.20	2.9% + £0.20
🇦🇺 Australia	1.75% + A$0.30	2.9% + A$0.30

These are the rates you see on Stripe's pricing page. But they're not the full picture.

The Hidden Costs

Currency conversion: If your customer pays in EUR and you settle in USD, Stripe charges an additional 1% conversion fee. For businesses with a global customer base, this adds up fast.

Chargebacks: Every disputed transaction costs $15 — win or lose. If you're in a high-dispute vertical (digital goods, subscriptions, international sales), chargebacks can become a significant line item.

Payout timing: Stripe holds your funds for 2-7 business days before settlement. That's not a fee, but it's a cost — your money is sitting in Stripe's account, not yours.

Premium features: Stripe Radar (fraud detection), Stripe Tax, Stripe Billing advanced features — these all come with additional per-transaction or monthly fees.

QBitFlow's Fee Structure

1.5% flat. That's it.

No per-transaction fixed fee. No international surcharges. No currency conversion fees. No chargeback fees (blockchain transactions are final). No withdrawal fees. No monthly fees. No setup fees.

Your customer pays, and 98.5% of the payment goes directly to your wallet. Instantly.

The Real Comparison: What You Actually Pay

Let's run the numbers across different transaction sizes and scenarios. We'll compare Stripe US rates (the most common) against QBitFlow.

Small Payments ($10)

	Stripe (US)	QBitFlow
Fee	2.9% + $0.30 = $0.59	1.5% = $0.15
Effective rate	5.9%	1.5%
You receive	$9.41	$9.85
Savings with QBitFlow		$0.44 per transaction

The fixed $0.30 fee hits small transactions hardest. At $10, Stripe's effective rate is nearly 6%. This is why microtransactions are painful on traditional rails.

Medium Payments ($50)

	Stripe (US)	QBitFlow
Fee	2.9% + $0.30 = $1.75	1.5% = $0.75
Effective rate	3.5%	1.5%
You receive	$48.25	$49.25
Savings with QBitFlow		$1.00 per transaction

Large Payments ($100)

	Stripe (US)	QBitFlow
Fee	2.9% + $0.30 = $3.20	1.5% = $1.50
Effective rate	3.2%	1.5%
You receive	$96.80	$98.50
Savings with QBitFlow		$1.70 per transaction

Enterprise Payments ($1,000)

	Stripe (US)	QBitFlow
Fee	2.9% + $0.30 = $29.30	1.5% = $15.00
Effective rate	2.93%	1.5%
You receive	$970.70	$985.00
Savings with QBitFlow		$14.30 per transaction

The International Scenario

This is where the gap widens dramatically. Say you're an EU-based SaaS with US customers paying with international cards:

Stripe: 2.5% + €0.25 (international card) + 1% (currency conversion) = 3.5% + €0.25

On a €100 payment: €3.75 in fees (3.75% effective rate)

QBitFlow: 1.5% flat = €1.50 in fees

Savings: €2.25 per transaction (60% less)

Crypto doesn't care about borders. There's no such thing as an "international" transaction on the blockchain.

Beyond Fees: The Structural Differences

Chargebacks: $0 vs $15+

Blockchain transactions are final. Once a payment is confirmed on-chain, it cannot be reversed by the customer, their bank, or anyone else. This eliminates chargebacks entirely.

For context, the average chargeback rate across industries is 0.6%. If you process 1,000 transactions per month and 6 result in chargebacks, that's $90/month in Stripe dispute fees alone — regardless of whether you win the disputes.

With QBitFlow: $0. Always.

Settlement: Instant vs 2-7 Days

When a customer pays through QBitFlow, the funds arrive in your wallet immediately. There's no holding period, no rolling reserve, no payout schedule.

With Stripe, standard settlement is 2 business days in the US, up to 7 days in other regions, and up to 14 days for new accounts. That's your money, sitting in someone else's account.

Custody: Your Wallet vs Their Account

This is the fundamental architectural difference.

Stripe is custodial. Your customers pay Stripe. Stripe holds the funds. Stripe pays you on their schedule. If Stripe freezes your account (which happens more often than you'd think), your funds are locked.

QBitFlow is non-custodial. Your customers pay you directly. Funds go from their wallet to yours. QBitFlow never touches, holds, or has access to your money. The smart contracts that handle billing are open-source and verifiable on-chain.

There is no scenario where QBitFlow can freeze your funds, because QBitFlow never has your funds.

When Stripe Still Makes Sense

We're not going to pretend crypto payments are the right choice for every business. Stripe is still the better option when:

Your customers don't have crypto wallets. If your audience is non-technical consumers, most won't have a wallet or stablecoins. Stripe's card processing is still the path of least resistance.
You need fiat settlement. QBitFlow pays you in crypto (USDC, USDT, etc.). If you need USD/EUR in a bank account, you'll need an off-ramp — an extra step that Stripe doesn't require.
You rely on Stripe's ecosystem. Stripe's plugin ecosystem (billing, invoicing, tax, fraud detection) is massive. If you're deeply integrated, switching has a real cost.

When QBitFlow Is the Clear Winner

Your customers are crypto-native. Web3 tools, DeFi platforms, NFT marketplaces, crypto SaaS — if your users already have wallets, QBitFlow is a no-brainer.
You sell internationally. No cross-border fees, no currency conversion, no international card surcharges. One rate, everywhere.
Chargebacks are a problem. Digital goods, subscription services, and international sales are chargeback-heavy verticals. Eliminating them entirely changes the economics.
You want to offer crypto as an additional option. You don't have to choose. Run Stripe for card payments and QBitFlow for crypto. Give your customers the choice.
You process recurring payments. QBitFlow's smart contract subscriptions handle recurring billing on-chain — automated, transparent, and non-custodial.

The Monthly Impact

Let's put it in real terms. Say you're a SaaS doing $50,000/month in revenue with an average transaction of $50:

With Stripe (US):

1,000 transactions × $1.75 = $1,750/month in fees
Plus ~6 chargebacks × $15 = $90
Total: ~$1,840/month

With QBitFlow:

1,000 transactions × $0.75 = $750/month in fees
Chargebacks: $0
Total: $750/month

Annual savings: $13,080

That's real money. Enough to hire a contractor, run ad campaigns, or just keep more of what you earn.

Getting Started

QBitFlow works on Ethereum and Solana, supporting major stablecoins (USDC, USDT) and native tokens.

You can integrate via:

API + SDKs (Python, Go, TypeScript) — for developers
No-code web app — for non-technical merchants
Hosted checkout — drop-in payment page, similar to Stripe Checkout

Try the full payment flow without spending real funds: Test Mode →

Smart contracts are open-source. Verify everything: GitHub →

Ready to see how much you could save? Calculate your savings →