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:

1. 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.
2. 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.
3. 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.
4. 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:

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

Merchant side:

1. 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
2. The contract checks: is the authorization active? Is the amount within the cap? Does the customer have sufficient funds?
3. If all checks pass, the payment executes — tokens move from customer wallet to merchant wallet, and QBitFlow updates the subscription status accordingly
4. 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:

1. Sign up at qbitflow.app/get-started — email and password, takes 30 seconds
2. Connect a wallet — you only provide a public address (Ethereum, Solana, or Base). No seed phrases, no private keys
3. Create a product with a subscription pricing model in the dashboard or via API
4. Generate an API key and integrate with our SDK (JS/TS, Python, or Go)
5. 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.