DEV Community: QBitFlow

Non-Custodial Crypto Subscriptions: A Real Stripe Alternative for Global SaaS

QBitFlow — Tue, 18 Aug 2026 17:57:04 +0000

Non-Custodial Crypto Subscriptions: A Real Stripe Alternative for Global SaaS

Getting recurring revenue from crypto-native customers should be simple. It isn't.

Your subscription service works great for customers who pay by card. Then a customer in Argentina, Nigeria, or Indonesia tries to subscribe. Their card doesn't clear. Or you're a crypto-native SaaS — a DAO tooling provider, a blockchain analytics API, an AI-compute service — and your customers already hold USDC. They'd rather pay in it than convert to fiat and back again.

Stripe doesn't solve this. It geo-gates by design: if the customer is in the "wrong" country, they literally can't pay you. And even when it works, Stripe holds your payout for 2–7 business days. That's not a bug. It's how every custodial processor works — the money passes through them before it reaches you.

This guide covers how to set up non-custodial USDC subscriptions with QBitFlow — on Ethereum, Base, or Solana — so you collect directly into your wallet, no one holds your funds, and any customer with a compatible wallet and a supported token can subscribe.

What's broken with crypto subscriptions today

"Crypto subscriptions" is a misleading category. Most solutions fall into one of three buckets:

Request-invoice systems. You send a payment link; the customer pays manually each cycle. That's not a subscription — it's a polite request you hope they honor.

Custodial processors. You accept crypto, they convert it to fiat and hold it. You've replaced one payout-delay problem with another, and now you've also lost the on-chain verifiability that was the whole point.

Roll-your-own smart contracts. You build the allowance logic, manage billing cycles, handle retries, cancellations, and state transitions yourself. Weeks of engineering work — and most teams don't have a payments engineer.

QBitFlow is a different approach: a non-custodial recurring billing system. The customer approves a spending cap via a single Permit2 signature. QBitFlow's relayer service then executes the recurring billing at your chosen interval, calling the open-source contract on-chain. The funds move directly from the customer's wallet to yours at settlement — QBitFlow never holds the money at any point.

One thing to be clear about upfront: subscriptions are token-only (ERC-20 on Ethereum/Base, SPL tokens on Solana). USDC, USDT, EURC, and DAI are supported. Native ETH or SOL billing isn't supported for subscriptions. And what the customer pays is exactly what you receive — there's no auto-swap or routing through a liquidity pool. If a customer pays in USDC, you receive USDC.

What ships out of the box

Before you integrate, here's what's live:

Subscriptions on Ethereum, Base, and Solana with USDC, USDT, EURC, DAI, and more (full token list at qbitflow.app/docs)
Custom billing intervals — daily, weekly, monthly, yearly, or any custom interval in seconds
Free trials — the customer starts a trial with a single in-app confirmation — no wallet signature, no spending cap yet. The subscription enters trial status and your backend receives a webhook; if the trial ends without converting, you get a trial_expired webhook. The customer only signs the spending-cap approval (the one wallet interaction) when they upgrade to paid from their self-manage page.
Real-time subscription status webhooks — your backend receives a push when a subscription changes state (active → low_on_funds, active → past_due, past_due → cancelled, etc.) — no polling required
Customer self-manage page — customers can raise their spending cap or cancel on-chain, without contacting your support team
Merchant force-cancel — you can terminate a subscription for cause (ToS violation, fraud) without the customer's signature
One-click CSV export — 28-column transaction history with USD-at-receipt values, ready for QuickBooks or Xero

On security and trust: QBitFlow's contracts are open-source on GitHub — readable and forkable by anyone, including your own engineers. They have not undergone a formal third-party audit yet; that's on the roadmap. Every payment has an on-chain transaction hash you can verify in a block explorer directly — it's not a number in an obscure processor's dashboard you have to take on faith. Funds never pass through QBitFlow custody at any point; QBitFlow's role is to trigger settlement, not to hold or route your money.

How the spending-cap model works

The key difference from card billing: QBitFlow uses a spending cap model, not pull-on-demand.

When a customer subscribes:

They approve a maximum spending cap and a billing interval via a single Permit2 signature.
At each billing cycle, QBitFlow's contract checks the cap and the customer's balance, then executes the transfer — no additional customer action needed.
Money lands directly in your connected wallet. No payout window. No intermediary.

A few things this model gives you that card billing doesn't:

The cap is customer-signed. The maximum billing amount is committed in the EIP-712 digest the customer signs. Your system can't silently vary the charge beyond the approved cap without a new customer signature — a meaningful trust guarantee for subscription customers who've been burned by surprise charges.

low_on_funds is a proactive signal, not a failure. When a customer's remaining spending cap won't cover the next billing cycle, QBitFlow flags the subscription as low_on_funds — and fires a webhook — before the payment fails. You can proactively prompt the customer to raise their cap, rather than discovering a churn after the fact.

No chargebacks. Payments are final on settlement. A customer who wants a refund submits a request through their self-manage page. You review it in your dashboard and accept (signing a transaction that returns the exact amount to their wallet) or deny with a reason. Refund decisions are yours, not a card network's.

Setting up a USDC subscription in ~10 minutes

1. Sign up and connect your wallet

Go to qbitflow.app/get-started. You connect your wallet via WalletConnect — browser extension or mobile QR scan. No seed phrases, no pasting addresses. Your wallet is the settlement destination from day one; QBitFlow never has access to your keys.

Start in Test mode (testnet funds are automatically dropped to your wallet on signup) and flip to Live when you've validated the flow.

2. Create a product

In the dashboard — or via the API:

const product = await client.products.create({
    name: 'Premium Subscription',
    description: 'Access to all premium features',
    price: 29.99,
    reference: 'PROD-PREMIUM',
});

3. Create a checkout session

const subscription = await client.subscriptions.createSession({
    productId: product.id,
    frequency: { unit: 'months', value: 1 }, // Bill monthly
    trialPeriod: { unit: 'days', value: 7 }, // 7-day trial (optional)
    minPeriods: 3, // Minimum commitment periods (optional)
    customerUUID: 'customer-uuid',
    successUrl: "https://yourapp.com/subscribed",
    cancelUrl: "https://yourapp.com/pricing"
});

console.log(subscription.link);

// Redirect the customer to session.url

The customer lands on your hosted checkout page (theme and logo customizable), approves the spending cap with a single signature, and you're billing.

4. Handle events via webhook

Configure your endpoint once in the dashboard under Settings → Webhooks — one URL for transaction events, one for subscription state changes. No per-session webhook_url argument:

// Transaction webhook — fires when a billing cycle completes or fails
import express from 'express';
import {
    QBitFlow,
    SessionWebhookResponse,
    TransactionStatusValue,
    OneTimePaymentSession,
    SubscriptionSession,
} from 'qbitflow';

const app = express();
const qbitflowClient = new QBitFlow('your-api-key');

app.use(express.json());

app.post('/webhook', async (req, res) => {
    const signature = req.headers[qbitflowClient.webhooks.signatureHeader.toLowerCase()] as string;
    const timestamp = req.headers[qbitflowClient.webhooks.timestampHeader.toLowerCase()] as string;
    const webhookId = req.headers[qbitflowClient.webhooks.webhookIdHeader.toLowerCase()] as string;

    if (!signature || !timestamp) {
        res.status(400).json({ error: 'Missing required headers' });
        return;
    }

    if (!(await qbitflowClient.webhooks.verify(req.body, signature, timestamp))) {
        res.status(401).json({ error: 'Invalid signature' });
        return;
    }

    // Reachability check from the dashboard "Test webhook" action — acknowledge and stop.
    if (webhookId === qbitflowClient.webhooks.testWebhookId) {
        res.status(200).json({ received: true });
        return;
    }

    const event = req.body as SessionWebhookResponse;
    // event.session is typed as SessionCheckout (OneTimePaymentSession | SubscriptionSession | PaygSubscriptionSession)
    const session = event.session as OneTimePaymentSession | SubscriptionSession;

    if (event.status.status === TransactionStatusValue.COMPLETED) {
        // `session.reference` echoes back the reference you set when creating the session,
        // so you can match the transaction to your own order/invoice without storing our UUID.
        console.log('Payment completed for product:', session.productName, 'ref:', session.reference);
    } else if (event.status.status === TransactionStatusValue.FAILED) {
        // Handle failed payment
    }

    res.status(200).json({ received: true });
});

Full webhook reference: qbitflow.app/docs?section=webhooks

5. The customer self-manage page

Every subscription ships with a hosted customer page where subscribers can:

View billing history and the next payment date
Increase their spending cap before it runs low
Cancel on-chain, without contacting your support

You don't build or host this. It's included.

Pricing

Pricing: 1.5% flat per transaction, enforced on-chain. QBitFlow's fee is deducted from each settlement — a 100 USDC payment means 98.5 USDC lands in your wallet. No monthly platform fee, no setup cost. Customers pay their own gas costs for wallet interactions.

Who this is (and isn't) for

Good fit:

SaaS products with crypto-native customers: Web3 tools, blockchain analytics APIs, AI-compute services, DAO tooling
Subscription businesses with a global customer base where Stripe has limited reach
Developer teams who want a production-ready subscription primitive without building it

Not the right fit today:

You need customers to pay in fiat (credit/debit card, bank transfer) — QBitFlow is crypto-native only
You need partial refunds — full refunds only for now (partial is on the roadmap)
You need mid-cycle plan upgrade/downgrade flows — that's on the roadmap too

If you're unsure whether QBitFlow fits your use case, the fastest way to find out is to run a test transaction: the sandbox is fully functional on testnet, no mainnet funds required.

Get started

Overview: qbitflow.app/recurring-payments
Docs: qbitflow.app/docs
API reference: qbitflow.app/docs/api
Sign up: qbitflow.app/get-started
Open-source contracts: github.com/QBitFlow

Crypto Payments for WooCommerce: Accept USDC and More Without a Custodian

QBitFlow — Wed, 12 Aug 2026 18:29:55 +0000

Crypto Payments for WooCommerce: Accept USDC and More Without a Custodian

WooCommerce gives you control over your store. Your products, your branding, your customer data. Then you get to the payments page and you're back to asking permission.

Stripe doesn't work in dozens of countries. PayPal holds funds during disputes. Even dedicated crypto payment plugins often route your money through a processor's wallet before releasing it to you on their schedule — which trades one middleman for another.

This guide shows a different setup: your customer pays, the money goes straight into your wallet, and the blockchain handles the rest. No intermediary sitting on your funds.

Why accept crypto payments on WooCommerce at all?

Most merchants don't switch payment processors unless something is actually broken.

Here's what's broken:

The geo-gate. Traditional processors gate both sides of a transaction by country. Some customers — in Southeast Asia, Africa, Latin America — literally can't pay you. Their card gets declined or your processor doesn't support their region. Any customer with a crypto wallet, anywhere, can pay you via QBitFlow. No country gates on either side.

The payout delay. Most processors hold your money for 2–7 days before releasing it to your bank. That's their money, temporarily. With direct on-chain settlement, funds arrive in your wallet within minutes of the payment confirming — no separate payout schedule.

No chargebacks. Blockchain payments are final. No reversal after you've shipped. You can still issue refunds yourself — that's your choice — but the customer can't claw it back through a card network. (Merchants are still responsible for applicable consumer laws and disputes in their jurisdiction; this removes the unilateral reversal mechanism, not the obligation to handle genuine disputes.)

The custodian problem with most WooCommerce crypto plugins

There's a subtlety most merchants miss: many "crypto payment plugins" still hold your money in the middle.

The flow looks like: customer wallet → processor wallet → your bank account (days later, via wire). You've changed the customer's experience without fixing your own payout problem.

QBitFlow's model: customer wallet → your wallet, in one transaction. The platform fee (1.5%) is split in the same on-chain transaction — 98.5% routes to your wallet, 1.5% to QBitFlow, simultaneously, with no separate payout step. The contracts handling this are open-source on github.com/QBitFlow and verifiable on-chain.

Your money, the minute it confirms.

What your customers see at checkout

When a customer chooses to pay with crypto, they're shown a checkout modal with a QR code and wallet connection prompt. They scan it from a mobile wallet, or connect a browser extension wallet (MetaMask, Coinbase Wallet, and others supported via WalletConnect). No account creation required on their end.

They choose which supported token to pay with, confirm the amount in their wallet, and submit the transaction. The WooCommerce order status updates automatically once the payment confirms on-chain. Customers don't leave your site for an exchange or a separate payment portal.

Gas fees are paid by the customer in the native currency of the chain they choose (ETH for Ethereum, SOL for Solana, etc.) — separate from the payment amount and your 1.5% fee.

What you can accept

Ethereum: ETH, USDC, USDT, EURC, DAI, WBTC, WETH, LINK

Base (lower gas costs, same security foundation as Ethereum): ETH, USDC, USDT, EURC, DAI, cbBTC, AERO, WETH

Solana (fast, near-zero network fees): SOL, USDC, USDT, EURC, DAI, LINK

You choose which tokens and chains to enable in the dashboard. Customers pay from whichever supported combination you've turned on.

How to accept USDC on WooCommerce in under 30 minutes

The plugin is live in the official WordPress plugin directory, so you can install it in one click straight from your WordPress admin — no ZIP to download, no code to touch.

1. Create your account
Sign up at qbitflow.app/get-started — email and password, no paperwork.

2. Connect your wallet
Browser extension or scan a QR code with your mobile wallet. This is the wallet that receives your payments. You're connecting it so QBitFlow can route funds — you're not pasting a public address, and nothing asks for a seed phrase or private key at any step.

If you'd rather not connect your main treasury wallet first, use a fresh wallet for testing (testnet mode drops free test funds to whatever wallet you connect).

3. Create your API key
In the dashboard under Settings → API Keys.

4. Install the plugin
In your WordPress admin, go to Plugins → Add New, search for "QBitFlow", then click Install Now and Activate. No coding, no ZIP upload. Your existing WooCommerce products don't need to be duplicated — the plugin uses order data from WooCommerce directly.

Prefer to install manually? Download the ZIP from WordPress.org (or the GitHub releases page) and upload it via Plugins → Add New → Upload Plugin.

5. Enter your API key in WooCommerce
Under WooCommerce → Settings → Payments, find QBitFlow and enter the API key.

6. Configure your webhook endpoint
In the QBitFlow dashboard under Settings → Webhooks, add your store's webhook URL. This is how your WooCommerce store gets notified when payments confirm. Set it once — it fires for all transactions.

7. Run a test payment
Switch to test mode and run a full checkout. QBitFlow drops testnet funds to your wallet automatically on signup so you can test without real money.

8. Go live
Flip to live mode in the dashboard. You're accepting payments.

Most stores complete this the same day — often in 30 minutes or less once you have a wallet ready.

Full docs at qbitflow.app/docs.

Accounting — the part most merchants forget

Crypto accounting is painful without the right export.

QBitFlow's dashboard exports every transaction as a 28-column CSV with: the on-chain transaction hash, block explorer link, token symbol, gross amount, USD value at time of receipt (fair market value at confirmation — what most tax authorities want for income recognition), platform fee breakdown, and net amount.

Drop this into QuickBooks, Xero, or your accountant's preferred tool and the historical USD rate reconstruction is already done. No manual block-explorer archaeology.

This doesn't replace tax advice — but it gives your accountant the fields they actually need.

Pricing

1.5% flat per transaction. No setup fee, no monthly fee, no withdrawal fee. The 1.5% is taken in the same on-chain transaction that pays you — you don't receive a gross amount and get invoiced separately.

Volume discounts available at $50K+/month — contact via the dashboard.

How QBitFlow compares to other WooCommerce crypto plugins

	QBitFlow	Coinbase Commerce	CoinGate
Settlement	Direct to your wallet	Custodial (payout schedule)	Custodial (payout schedule)
Subscriptions	Yes (on-chain, token-only)	No	No
WP directory	Yes	Yes	Yes
Fee	1.5% flat	1%	1–1.5%
Fiat conversion	No — crypto stays crypto	Yes	Yes
Chains	ETH, Base, Solana	Base, ETH	ETH, BTC, others

If you need fiat in your bank account immediately, Coinbase Commerce or CoinGate may be a better fit today. If you want payments settling directly into a wallet you control, QBitFlow is built for that.

Is this right for your store?

Good fit:

You want USDC, ETH, or SOL going directly into your wallet — no payout wait
You sell to a global audience and some of your customers can't use card processors
You sell digital subscriptions and want real on-chain recurring billing
You run a standard WooCommerce store and want setup done in under 30 minutes

Not the right fit:

You need automatic conversion to fiat before it hits your bank
Your customers don't hold crypto wallets
You need partial refunds (full refunds only for now)

Support

Questions while setting up? qbitflow.app/docs covers the full technical flow. The docs page links to the support channel if something isn't covered — and if your checkout breaks, there's a human on the other end, not a ticket queue going nowhere.

Frequently asked questions

Does QBitFlow hold my funds?
No. The 1.5% fee is split in the same on-chain transaction as the payment itself. Your 98.5% goes straight to your wallet; QBitFlow's 1.5% goes to ours — in one step, with no intermediate custody.

What happens if a customer sends the wrong token or uses the wrong network?
QBitFlow's checkout doesn't let the customer select an unsupported token or chain — they choose from what you've enabled. If they send from an exchange directly (bypassing the checkout UI), that's a wallet-level operation and would need manual reconciliation. The docs cover the edge cases.

Are the smart contracts audited?
The contracts are open-source (github.com), fully verifiable on-chain, and built with security isolation as a design goal (per-subscription allowance separation, per-cycle caps committed in the signed digest). A formal third-party audit is on the roadmap — it hasn't been done yet. You can review the code before going live.

Does QBitFlow convert crypto to fiat?
No. You receive the exact token the customer paid with, in your wallet. If you want fiat, you'd off-ramp via your own exchange.

Can I refund a crypto payment?
Yes — full refunds. Customer-initiated from their self-management page. No partial refunds yet (roadmap item). You sign a transaction that sends the exact token amount back to the customer's wallet; gas on the refund transaction is a small network cost.

Is the plugin available in the WordPress directory?
Yes — it's live in the official WordPress plugin directory. Install it in one click from your WordPress admin: Plugins → Add New → search "QBitFlow" → Install Now → Activate. No coding, no ZIP upload. (You can still install manually from the ZIP if you prefer.)

What WooCommerce version does it support?
See the plugin GitHub page for current compatibility and release notes.

Install the plugin in one click from the WordPress plugin directory and get started at qbitflow.app/get-started.

Crypto Payments for Marketplaces: Splitting Fees On-Chain Without Holding Anyone's Money

QBitFlow — Fri, 07 Aug 2026 10:41:35 +0000

If you run a marketplace, a platform, or a creator network, your payment problem is different from a single merchant's. You're not just collecting money — you're splitting it. Your cut, the vendor's cut, maybe a referrer's cut, on every single transaction. Do that with a custodial processor and you've become a money-handling middleman, with all the licensing and freeze-risk that implies.

Here's how to take your cut automatically, on-chain, without ever holding anyone's funds.

The split happens at settlement, not after

The clean model is simple: when a customer pays, the smart contract splits the payment at the moment of settlement. Your platform fee routes to you, the remainder routes to the vendor — in the same transaction, on-chain, with no manual reconciliation and no batch payout job at the end of the month.

You set a per-vendor fee percentage. The contract enforces it. Nobody has to trust a spreadsheet.

Vendors who don't have a wallet yet

The hard part of onboarding vendors to crypto is that most of them aren't crypto-native. Making a freelancer set up a wallet before they can earn a cent kills your signup funnel.

A trust layer solves this: your platform can create user-level accounts with zero crypto setup from the vendor — no wallet, no seed phrase, no password required up front. Payments route to your platform's wallet, and an off-chain ledger tracks exactly what's owed to whom, with an on-chain transaction hash captured for every payment so it's all verifiable.

When the vendor is ready, they claim: they set a password, connect a wallet, and you sign one transaction that sends their earned balance to them. From that point on it's fully non-custodial. You never had to gate onboarding behind a wallet setup.

(One honest boundary: unclaimed accounts can receive one-time payments, not subscriptions — subscriptions bind to the recipient's wallet at creation, which unclaimed users don't have yet. It's a security feature, and it's worth knowing up front.)

Books that actually reconcile

Marketplaces have the worst accounting problem in payments: you need to reconcile your cut against every vendor's cut, across every transaction. A proper export gives you that in one file — gross amount, your platform fee, the vendor fee, network fees, and the USD value at the moment of receipt, per transaction, with a direct block-explorer link. Your accountant doesn't have to reconstruct historical exchange rates by hand.

What it costs, what you keep

QBitFlow's fee is a flat 1.5% per transaction, enforced on-chain — no monthly platform bill. Your platform's cut is separate and set by you. Both are taken automatically at settlement. Your vendors receive the exact token the customer paid; no conversion, no slippage. And nobody — not us, not you — ever custodies the customer's money in transit.

Getting started

Connect your wallet (extension or QR, no seed phrases), set your per-vendor fee, and you can run a full split flow on testnet in minutes. The contracts are open-source and auditable on GitHub — not formally third-party audited yet (that's on the roadmap), so you can read exactly how the split is enforced before you trust it.

→ qbitflow.app/get-started

How to Accept Crypto Subscriptions (Without Holding Your Customers' Money)

QBitFlow — Thu, 30 Jul 2026 12:32:54 +0000

If you run a SaaS product or a membership business, "accept crypto" usually means a one-time button. You get paid once, then you're back to chasing the next invoice by hand. Real businesses run on recurring revenue — and that's the part most crypto payment tools quietly skip.

Here's how recurring crypto payments actually work when they're built properly, and what to look for so you're not stuck reconciling a blockchain by hand every month.

The problem with "crypto subscriptions" as usually sold

Most gateways bolt recurring billing onto a card mindset: they hold your customer's funds, or they hold your funds, and drip them out. The moment someone else custodies the money, you've re-created the exact risk you left card processors to escape — freezes, holds, an account that can be shut off.

You want the opposite: money moves straight from your customer's wallet to yours, on a schedule, and nobody in the middle can touch it.

How it should work: spending-cap authorizations

Instead of storing a card, your customer signs a one-time authorization that says: "this merchant may charge up to X per billing cycle, in this token." That approval lives on-chain. Every cycle, the charge executes against that cap — no re-prompting your customer, no stored credentials, no middleman balance.

Two things that matter here:

The cap is committed in what the customer signed. Your customer sets the ceiling; you can't quietly raise it. That's a trust feature, not a limitation — it's why they'll say yes.
Each subscription's budget is walled off from every other. One customer's authorization can't bleed into another's. That isolation is a security boundary, not a nice-to-have.

Free trials with zero wallet friction

The trial-to-paid drop-off usually happens at the wallet prompt. Done right, a free trial requires no wallet interaction at all — your customer signs nothing to start, not even a network fee. They only sign when the trial converts to paid. Fewer prompts, higher conversion.

The lifecycle you actually need to see

A subscription isn't just "active" or "cancelled." A merchant needs to see the states that predict churn before it happens:

low_on_funds — the last charge succeeded, but the customer's remaining cap won't cover the next cycle. That's your cue to nudge them to top up — before it fails.
past_due — a charge actually failed; auto-retry runs during a grace period, and if it clears you're back to active.
Force-cancel — you can terminate a subscription for cause without waiting on the customer.

Seeing low_on_funds a cycle early is the difference between a saved subscription and a silent cancellation.

What you keep

With a non-custodial setup, you receive the exact token your customer paid, with no conversion and no slippage. QBitFlow's fee is a flat 1.5% per transaction, taken on-chain at settlement; there's no monthly platform bill and no separate invoice. You hold the keys to your money the entire time.

Getting started

You can be live on testnet in about ten minutes: sign up, connect your wallet (browser extension or scan a QR — no seed phrases, no pasting keys), create a product, and issue an API key. Our smart contracts are open-source and auditable on GitHub.

If recurring revenue is the business, the payment rail underneath it shouldn't be a one-time button. → qbitflow.app/get-started

Crypto Accounting for Merchants: How to Get Tax-Ready Books Out of On-Chain Payments

QBitFlow — Thu, 16 Jul 2026 12:37:29 +0000

"How do I handle the accounting?" is the question that stops most merchants from accepting crypto. It's a fair one. Card processors hand you a clean monthly statement; a raw blockchain hands you a pile of hashes. If you can't get tax-ready books out of it, the lower fees don't matter.

Here's what crypto accounting actually requires, and what a proper export should give you so your accountant doesn't hate you.

Why raw blockchain data isn't enough

A block explorer shows you that 500 USDC moved from one address to another at a certain time. It does not tell you: what that was worth in USD at the moment you received it, which product it was for, which customer, what your processor's fee was, or whether it was a payment or a refund. Reconstructing all of that by hand — looking up historical exchange rates per transaction — is the painful part everyone warns you about.

That's the problem an accounting-grade export solves.

The one field that matters most: USD value at receipt

Under most tax regimes (the US IRS treats crypto as property valued at fair market value on the date of receipt), the number your accountant needs is the USD value at the moment you received each payment. Capture that at receipt and income recognition is correct out of the box. Miss it, and you're rebuilding historical prices months later.

A good export records USD-at-receipt on every single transaction, so you never reconstruct a rate.

What a tax-ready export actually contains

QBitFlow's one-click CSV export runs to 28 columns — everything an accountant needs, per transaction:

Identity & type: payment ID, transaction type (payment / refund / subscription billing / fee split), UTC timestamp, related payment ID (so refunds and subscription billings link back to the original).
What was sold: product ID, product name, description, customer UUID.
On-chain proof: chain (Ethereum / Solana / Base), block number or slot, transaction hash, from/to address, and a direct explorer link per row.
The money: token symbol, gross amount, gross amount in USD at receipt, platform fee (our 1.5%) in token and USD, organization/marketplace fee columns when applicable, network fees, and net amount.

It drops straight into QuickBooks, Xero, or whatever your bookkeeper already uses. Marketplaces get the fee-split columns broken out, so you can reconcile your cut against a vendor's from one file.

The honest part

This is the piece most crypto processors skip — they expose transaction history, but not in an accountant-ready format with USD-at-receipt and a per-transaction fee breakdown. It's unglamorous. It's also the difference between "we accept crypto" and "we accept crypto and our books close cleanly every quarter."

The rest of the picture

The accounting is clean because the payment model is clean: money moves directly from your customer's wallet to yours, non-custodial, in the exact token they paid — no conversion, no slippage, nobody holding funds in between. Flat 1.5% per transaction, taken on-chain. You hold the keys to your money the whole time. And because the settlement contracts are open-source and auditable on GitHub (not formally third-party audited yet — that's on the roadmap), the fee math in your export is something you can verify against the code.

Getting started

Sign up, connect your wallet (extension or QR — no seed phrases), and you'll have a real transaction and a real export to hand your accountant within minutes on testnet.

→ qbitflow.app/get-started

How to Accept Crypto Payments on WooCommerce (Without a Custodial Processor)

QBitFlow — Thu, 09 Jul 2026 06:00:00 +0000

You built your WooCommerce store. You've got products, a checkout flow, and customers who want to pay in crypto. The question is: which payment gateway do you actually trust with your money?

Most crypto payment plugins for WooCommerce work the same way: they collect your customer's payment, hold it in their own wallet, and send you a payout — minus fees, minus a wait, minus any guarantee they won't freeze your account if something looks "suspicious." That's not crypto. That's a bank with extra steps.

This guide covers how to accept crypto payments on WooCommerce the non-custodial way — funds go directly from your customer's wallet to yours, on-chain, with no middleman holding anything.

What "non-custodial" actually means for your store

When a customer pays through a custodial processor, the money lands in the processor's wallet first. You're trusting them to forward it. If they freeze your account, dispute a transaction, or go under, your money is stuck.

Non-custodial means the smart contract routes the payment directly to your wallet address. QBitFlow never holds your funds — not for a second. Every payment has an on-chain transaction hash you can verify on Etherscan, Solscan, or BaseScan. There's no one to call to "release" your money because no one ever had it.

For a WooCommerce merchant, this matters for three reasons:

No chargebacks. Crypto transactions are final. A customer can't call their bank and reverse a payment you already received.
No holds. There's no processor deciding whether your business is "high-risk" this week.
No conversion. You receive exactly what the customer paid — USDC stays USDC, ETH stays ETH. No auto-swap, no slippage, no surprise exchange rate.

What you need before you start

A WooCommerce store (WordPress + WooCommerce plugin installed)
A crypto wallet — MetaMask, Coinbase Wallet, or any wallet that works with Reown/AppKit (browser extension or mobile QR scan)
About 10 minutes

That's it. No business registration. No KYC. No waiting for approval.

Step 1: Sign up and connect your wallet

Go to qbitflow.app/get-started. Sign up with an email and password.

Once you're in, you'll connect your wallet. This is a one-time step — you connect via browser extension or scan a QR code from your mobile wallet. You're not pasting a public address anywhere; the wallet stays connected so every subsequent interaction is handled automatically.

After connecting, you can request test funds into the wallet of your choice, "the client wallet", so you can run through the full checkout flow on testnet before going live. No real money at risk while you're getting set up.

Step 2: Install the WooCommerce plugin

The QBitFlow WooCommerce plugin is available now on GitHub:

github.com/QBitFlow/qbitflow-woocommerce

Install it the same way you'd install any WordPress plugin from a ZIP file:

Download the plugin ZIP from the GitHub releases page
In your WordPress admin: Plugins → Add New → Upload Plugin
Upload the ZIP, click Install Now, then Activate

Note: The plugin has been submitted to the official WordPress plugin directory and is currently under review. Once approved, you'll be able to install it with one click from the WordPress store. For now, GitHub is the install path.

Step 3: Create an API key and configure the plugin

Back in your QBitFlow dashboard:

Go to API Keys and generate a new key
Copy it — you'll paste it into the plugin settings

In WordPress:

Go to WooCommerce → Settings → Payments
Find QBitFlow in the list and click Manage
Paste your API key
Save

That's the integration. Your checkout now shows a crypto payment option alongside any other payment methods you have enabled.

What your customers see at checkout

When a customer selects crypto payment, they get a hosted checkout page — your logo, your colors — with a wallet connect button. They connect their wallet (browser extension or mobile QR), confirm the payment, and it's done. The transaction settles on-chain and your WooCommerce order updates automatically via webhook.

The customer pays gas fees. You pay QBitFlow's 1.5% flat fee, taken on-chain at settlement. No monthly subscription, no setup fee, no hidden charges.

Chains and tokens you can accept

Ethereum: ETH, USDC, USDT, EURC, DAI, WETH, WBTC, LINK

Base (Ethereum L2): ETH, USDC, USDT, EURC, DAI, WETH, cbBTC, AERO

Solana: SOL, USDC, USDT, EURC, DAI, WSOL, LINK

If your customers prefer stablecoins, USDC on Base is the cheapest to transact — low gas, fast finality, dollar-pegged. If they're paying in ETH or SOL, that works too.

What about subscriptions?

If you sell memberships, digital subscriptions, or recurring products on WooCommerce, QBitFlow supports recurring billing on-chain. Customers authorize a spending cap — they're in control of how much you can charge per cycle — and billing runs automatically on your schedule (daily, weekly, monthly, or custom intervals).

A few things worth knowing:

Subscriptions work with ERC-20 and SPL tokens (USDC, USDT, etc.) — not native ETH or SOL
Customers can cancel on-chain at any time from their self-managed page
You can force-cancel a subscription for cause (ToS violation, etc.) without needing the customer's signature
Free trials are supported — the customer signs a zero-amount authorization, no wallet interaction needed during the trial period

Accounting: the part most crypto plugins skip

Every transaction exports to CSV with 28 columns — including USD value at the time of receipt, on-chain tx hash, block number, and per-transaction fee breakdown. Drop it into QuickBooks or Xero. No manual exchange-rate lookups, no reconstructing fee splits from block explorer data.

This matters because "how do I handle accounting?" is one of the first questions any Stripe-using merchant asks when considering crypto. Most crypto processors give you a transaction list. QBitFlow gives you a file your accountant can actually use.

How it compares to the alternatives

	QBitFlow	Coinbase Commerce	NowPayments	BitPay
Custodial?	No — direct to your wallet	Yes	Yes	Yes
KYC required?	No	Yes	Yes	Yes
WooCommerce plugin	✅ Live	✅	✅	✅
Chargebacks	None (crypto is final)	None	None	None
Fee	1.5% flat	1%	0.5–1% + spread	1–2%
Subscriptions	✅ On-chain	❌	Limited	❌
Chains	ETH, Base, Solana	ETH, Base, Solana, others	Many	BTC, ETH, others
Funds held by processor	Never	Yes (payout cycle)	Yes	Yes

The fee comparison isn't the main point. The main point is that with custodial processors, you're trusting a company with your money. With QBitFlow, you're trusting math.

Get started

Sign up at qbitflow.app/get-started — no KYC, no paperwork
Connect your wallet
Install the plugin from github.com/QBitFlow/qbitflow-woocommerce
Paste your API key into the plugin settings
Run a test transaction on testnet (free test funds included)
Go live

Questions? The docs are at qbitflow.app/docs. If you get stuck, reach out — we'll walk you through it.

How QBitFlow's On-Chain Referral Program Works. Earn 20% of Our Fee, Enforced by Smart Contract.

QBitFlow — Wed, 01 Jul 2026 07:00:00 +0000

We put our referral program on-chain — here's why, and how it works

Almost every referral or affiliate program is, underneath, an IOU.

You refer someone. A dashboard tells you you're owed something. And then payment happens if the company's accounting agrees, when their payout schedule comes around, on terms they can change. You're trusting the same discretionary, custodial machinery that crypto was supposed to make unnecessary.

When we built QBitFlow's referral program, that contradiction was the thing we couldn't ship past. So we didn't.

How it works

Refer someone to QBitFlow — a business that accepts payments, or a creator collecting tips on qbf.cash. When they transact, you earn 20% of our fee on every transaction they make — for six months.

And the referrer can be almost anyone: any QBitFlow user (down to a non-admin role) or any qbf.cash user holds a referral link. You don't have to run a marketplace, or even be a merchant yourself, to earn.

The part that matters: that split is enforced by the smart contract at settlement. It isn't tracked in a spreadsheet we control. It isn't queued for a monthly payout run. The moment a referred merchant's payment settles on-chain, your cut is taken in the same transaction and routed to you. Paid by code, every transaction.

There's nothing to claim, nothing to invoice, and nothing to trust about our bookkeeping. If you want to verify what you're owed, you read the chain.

One deliberate choice worth calling out: that 20% comes out of our fee, not the merchant's. Referring someone costs the person you vouched for nothing — we share our own revenue rather than skimming theirs. A referral program shouldn't make the people you bring in pay more for the privilege of being referred.

Why bother putting it on-chain

Because "trust us, we'll pay you" is exactly the thing crypto was meant to fix. A payout rail that's custodial and discretionary is just Stripe with extra steps. A referrer shouldn't have to trust our accounting any more than a merchant should have to trust that their money won't get frozen.

The whole product already works this way: funds move customer wallet → merchant wallet, directly. We never hold a cent. 1.5% flat. The referral program simply extends that same guarantee to the growth loop — your reward is enforced the same way your payments are.

One primitive, three wedges

The referral split isn't a bolt-on. It's the same on-chain authorization primitive that powers two other things:

Subscriptions — a contract-enforced authorization with a bounded spending cap.
Referrals — a contract-enforced cut taken at settlement.
Agentic payments (x402) — the same authorization that lets an agent spend up to a cap you set, without ever holding your keys. The contract ships with it today; the backend is landing soon. (More on that when it's live, not before.)

One primitive, three product wedges. That's deliberate: fewer moving parts, less surface area to get wrong, and everything inherits the same on-chain guarantees.

Also in this release: cleaner subscription approvals

We moved ERC-20 approvals to Permit2. Previously, some tokens used Permit and others needed a separate approval transaction — two paths, two UX flows, two ways to confuse a user. Now it's one consistent signing flow for every token.

Try it

The contracts are open-source — readable, forkable, auditable: github.com/QBitFlow
Docs: qbitflow.app/docs
Start: qbitflow.app/get-started

If you run a marketplace or a merchant base, your referral math is now something a contract guarantees — not something we promise. That was the whole point.

How to Build an E-commerce Site with WordPress + WooCommerce + QBitFlow. Accept Crypto Payments in Under 30 Minutes.

QBitFlow — Thu, 04 Jun 2026 09:40:20 +0000

Accept crypto payments in under 30 minutes

This is a build guide, not a manifesto. If you run a WordPress store on WooCommerce and you want to add crypto as a payment option — alongside cards, not instead of them — this post walks through the full setup end to end. About 30 minutes from a fresh account to a live checkout that settles directly into your wallet.

Why crypto payments matter for WordPress sites in 2026

Crypto payments stopped being a thought experiment a few years ago. A handful of things changed in 2026 that made the math obvious for anyone running an e-commerce site.

Stablecoin volume crossed Visa-scale on multiple weeks this year. Meta started paying some of its creators in USDC. The EU's MiCA framework went fully into effect, which gave European merchants a real regulatory floor to stand on. Cross-border settlement that used to take three days through correspondent banks now lands in seconds for a few cents in network fees.

None of this means cards are going away. Cards still convert the majority of your customers, and for most stores they should stay the default. What changed is that crypto moved from "novelty" to "useful additional rail" — especially for:

International customers whose cards get declined by your processor's fraud rules
Merchants tired of chargebacks (crypto settlements are final)
Anyone who wants funds in their own wallet within seconds, not in a processor's account for two weeks
Sellers paying suppliers in USDC and wanting to receive payment in USDC to skip the conversion round trip

The point is not "replace cards with crypto." The point is "add a second rail that settles differently and costs less." For some segment of your customers, that rail is the one they actually wanted.

Why WooCommerce specifically

If you already run on WooCommerce, you know the pitch. If you are choosing a stack, here is the short version.

WooCommerce is the largest e-commerce ecosystem on the web — more than a third of online stores run on it. It is self-hosted, which means you own your data, your customer list, your product catalog, and your store. No platform can deplatform you because the platform is your own server. The plugin model lets you stack capabilities — payments, shipping, tax, subscriptions, memberships — without rewriting your stack every time a vendor changes their pricing.

For merchants who want to own their checkout, their data, and their payment rail, WooCommerce is the obvious base layer. QBitFlow plugs into the payments slot the same way Stripe or PayPal does — except settlement happens directly between the customer's wallet and yours, with no intermediate account holding the funds.

What you will have at the end of this tutorial

A working WordPress + WooCommerce store with crypto checkout enabled. Customers will be able to pay with ETH, SOL, or supported tokens (USDC, USDT, DAI, EURC, and others) across Ethereum, Solana, and Base. Settlement is non-custodial — funds move from the customer's wallet directly to yours on-chain. Fees are 1.5% flat per transaction. Setup time, from zero to first test payment, is roughly 30 minutes if WordPress and WooCommerce are already installed.

Prerequisites

Before starting, you need:

A WordPress site. Any hosting works — WP Engine, Kinsta, SiteGround, Bluehost, self-managed VPS, whatever you already use. If you are starting fresh, pick a host with one-click WordPress install and come back when WordPress is up.
WooCommerce installed and activated. Free plugin, available from the WordPress directory. Run through its setup wizard so you have at least one product configured.
A crypto wallet. Public address only — Ethereum, Solana, or Base. Never share or paste a private key or seed phrase anywhere. If you do not have a wallet yet, MetaMask (EVM), Rabby (EVM), or Phantom (Solana) take five minutes to set up.
An email and password for the QBitFlow signup.
About 30 minutes of uninterrupted time. The flow is mostly clicking through forms, but you will want to be able to focus when configuring the API key.

Step-by-step setup

Step 1: Sign up at QBitFlow and connect your wallet

Go to qbitflow.app/get-started. Create an account with email and password.

Signup itself is a guided multi-step flow: create account → connect wallet → create your first product → run a test payment → done. The wallet step is where you connect your wallet that settled payments should land in. QBitFlow never asks for a private key or seed phrase at any point — the public address is all we need to route funds.

You can connect an Ethereum address (which also covers Base, since Base uses Ethereum addresses) and a Solana address. If you only operate on one chain, connect just that one.

New accounts get an automatic testnet faucet drop — small amounts of test funds appear in your wallet on the testnet chains so you can run end-to-end test payments before going live.

Step 2: Create a product (or skip, and use your WooCommerce products)

For most WooCommerce stores, you will let WooCommerce own the product catalog and just use QBitFlow as the payment rail. In that case, skip ahead to Step 3.

If you want to create a standalone product in QBitFlow (useful for one-off sales, donations, or services priced outside your WooCommerce catalog), the dashboard has a Products section. Click Create product, fill in name, price, and description. The product gets a stable product_id you can reuse across checkout sessions.

Step 3: Install the QBitFlow WooCommerce plugin

Two install paths. Pick the one that works for you today.

Path A — Install from GitHub (available today).

Open the plugin repo: github.com/QBitFlow/qbitflow-woocommerce
Click the green Code button → Download ZIP
In your WordPress admin, go to Plugins → Add New → Upload Plugin
Choose the ZIP you just downloaded and click Install Now
Click Activate Plugin

That's it. The plugin is now active on your site.

Path B — Install from the WordPress.org plugin directory (coming soon).

The plugin has been submitted to the official WordPress.org plugin directory and is currently under review. Once it is approved, you will be able to install it the standard way:

In WordPress admin, go to Plugins → Add New
Search for QBitFlow
Click Install Now → Activate

We will update this post the moment the directory listing goes live.

Step 4: Configure the plugin

In WordPress admin, go to WooCommerce → Settings → Payments. You will see QBitFlow in the list of payment methods. Click Manage (or the toggle to enable, then Manage).

Fill in the following fields:

Enable QBitFlow — check the box.
API Key — generated in your QBitFlow dashboard under Settings → API Keys. Click Create API Key, copy the value, paste here. Treat it like a secret — anyone with this key can charge against your account.

Save changes.

One note on API keys behavior: API keys are used to authenticate each request, and every key is bound to a mode when you create it — test or production. The two are not interchangeable: a test key only talks to the test environment, a production key only talks to live. Start with a test key and run the full payment flow against your store end-to-end (place an order → get redirected to the QBitFlow checkout → complete the payment → confirm the WooCommerce order flips to paid). Once you're satisfied, go back to the dashboard, generate a production key, and swap it in the plugin settings.

Quick way to confirm which mode you're on: validate an order in your store and let it redirect to the QBitFlow checkout page. If there's a test mode badge in the top-right of the checkout, the key you pasted is a test key. No badge = production. Check this once after every key swap so you don't ship a store that's still pointing at the test environment (or worse, charge real customers against a test key that won't settle).

Step 5: Run a test payment

With test mode ON and a product in your WooCommerce catalog, place a test order yourself:

Open your store in an incognito window
Add a product to cart and proceed to checkout
At the payment step, select QBitFlow as payment method
You get redirected to the QBitFlow hosted checkout
Pick a chain and a token (use the testnet funds from Step 1)
Connect a wallet on the testnet (MetaMask switched to Sepolia for Ethereum testing, Phantom switched to Solana devnet, etc.)
Approve the transaction
Wait for confirmation (a few seconds on Solana / Base, < 1min on Ethereum testnet)
You get redirected back to your store's success page
In WordPress admin, check WooCommerce → Orders — the order should be marked Paid

Step 6: Go live

Once the test flow works end to end, going live is one key swap:

In your QBitFlow dashboard, go to Settings → API Keys and click Create API Key. This time, select production as the mode.
Copy the new production key.
In WooCommerce → Settings → Payments → QBitFlow, paste it into the API Key field, replacing the test key. Save.

That's it. To confirm: place one order in your store and let it redirect to the QBitFlow checkout. If the test mode badge in the top-right is gone, you're live and accepting real crypto payments. (A $1 USDC self-test is a cheap way to sanity-check the full live flow before sending real customers through it.)

Handling refunds

Refunds work end-to-end inside WooCommerce — you never have to leave the order page to push a refund through, and you never have to chase the customer for their wallet address.

The flow:

Customer requests the refund themselves. Every QBitFlow payment generates a self-managed payment page the customer can come back to (link in the receipt email + accessible from their wallet history). From that page they file the refund request — reason, no support ticket needed.
You get notified inside WooCommerce. A refund-request notice shows up in your WordPress admin against the original order. Clicking it deep-links you straight into the QBitFlow dashboard to the pending request.

Review and decide. In the dashboard you see the original payment, the amount, and the customer's reason. Two options: accept or reject. If you accept, you sign one transaction with your wallet to send the funds back — same non-custodial model as the inbound payment, no intermediary holding anything. If you reject, you need to provide a reason, and the customer will see it through the self-managed payment page.
WooCommerce stays in sync. Once the refund transaction settles on-chain, the order in WooCommerce → Orders → [order] updates automatically — the original payment and the refund both show on the order timeline, so your accounting view is clean and complete.

Customizing the checkout

The hosted checkout page is fully brandable from the QBitFlow dashboard under Settings → Preferences:

Logo — upload your store's logo
Theme colors — primary, accent, background — match your WooCommerce theme

Customers see your branding throughout the payment flow, not QBitFlow's. The only QBitFlow surface they see is a small "Powered by" line in the footer.

Going beyond — subscriptions, marketplaces, dashboards

The WooCommerce plugin covers one-time payments out of the box. The underlying QBitFlow platform supports a lot more, and you can wire any of it into your store with a few lines of PHP using our REST API or one of the SDKs.

Subscriptions. QBitFlow supports recurring subscriptions through a spending-cap model — the customer signs one transaction authorizing a maximum amount per period, and the contract bills on schedule with no further customer action. Custom billing frequencies (daily, weekly, monthly, yearly, or custom intervals). Free trials require zero wallet interaction from the customer (no signature, no gas). Subscriptions are token-only — useful to know if you want to bill in USDC or another ERC-20 / SPL token.

Marketplace fee splits. If you run a multi-vendor store (Dokan, WCFM, WC Vendors), QBitFlow supports automatic fee splits on every transaction. The platform's cut and each vendor's cut are enforced at the smart-contract level — no manual reconciliation, no monthly payout job.

Dashboard analytics. Revenue, active subscriptions, customer count, low-on-funds subscriptions, refund requests. Refund requests and required actions are surfaced first in the dashboard, so you never miss one.

Full integration docs live at qbitflow.app/docs. The REST API reference is at qbitflow.app/docs/api. SDKs in JavaScript / TypeScript, Python, and Go cover most languages directly.

What's next

If you followed the steps above, your WooCommerce store now accepts crypto payments on Ethereum, Solana, and Base, at 1.5% flat, with funds settling directly into your own wallet. No omnibus account in the middle. No two-week payout schedule. No chargeback exposure.

A few things worth doing from here:

Browse the open-source contracts. All payment, subscription, marketplace, and trust-layer logic is on GitHub at github.com/QBitFlow. If you want to read the code that handles your money, it's all there.
Read the docs at qbitflow.app/docs if you want to extend beyond what the plugin does — subscriptions, marketplace splits, custom checkout flows via the API.
Tell us what's missing. This is early infrastructure. If something in the plugin is rough, the feedback loop is short and we ship fast.

If you haven't yet, you can sign up at qbitflow.app/get-started. About 30 minutes from there to a live checkout.

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