QBitFlow
    Back to Blog
    Guides

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

    QBitFlow Team
    2026-08-18
    Non-Custodial Crypto Subscriptions: A Real Stripe Alternative for Global SaaS

    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:

    1. They approve a maximum spending cap and a billing interval via a single Permit2 signature.
    2. At each billing cycle, QBitFlow's contract checks the cap and the customer's balance, then executes the transfer — no additional customer action needed.
    3. 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:

    3. Create a checkout session

    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:

    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

    Back to Blog
    Talk to us