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