Crypto Subscriptions Without Chargebacks — Recurring Revenue That Stays Collected

Why recurring billing leaks the most revenue of any payment model

A subscription is the only business model where you charge someone who isn't in the room. Every renewal is an authorization made on the customer's behalf, weeks or months after they last thought about you — and that gap is exactly where card rails break down.

The first leak is the dispute. Subscription renewals are the single most disputed transaction type in card commerce, and not usually because of fraud. Someone scans a statement, sees a charge they don't recognize from a descriptor that doesn't match your brand name, and calls the bank instead of your support inbox. Card networks let the issuer look back over months of renewals, so a single call can pull back a whole billing history at once. You lose the revenue, you lose the dispute fee whether you win or not, and you were never given the chance to just cancel the plan.

The second leak is quieter and usually bigger: involuntary churn. Nothing about the customer changed — they still want the product — but the stored credential stopped working. Cards expire on a schedule. Banks reissue them after a breach, a lost wallet, or a product migration. Limits are hit, issuers decline "card-not-present recurring" transactions from a foreign merchant, and prepaid or debit cards run dry mid-cycle. Every one of those is a paying customer who churns without ever making a decision, and recovering them means dunning emails, retry logic and a card-updater service — an entire sub-industry that exists only to patch a credential that decays by design.

The third leak is who you are to your acquirer. Recurring billing carries a risk profile: high dispute propensity, free trials that convert into "I never agreed to this" complaints, and revenue you've already recognized but might have to return. Card networks run excessive-dispute monitoring programs with published ratio thresholds, and crossing them brings escalating fees, remediation plans and, at the end of the line, the loss of the account. Long before that, it brings a rolling reserve — a percentage of your own money held back for months against disputes that may never happen.

And then there's the geography problem. Subscription products sell globally from day one; card rails are national systems bridged together. A $29/month plan renewing on a card issued in another country runs a higher decline rate, an FX spread, and a cross-border assessment on top of interchange — on every single renewal, forever.

What the leak costs a real subscription business over a year

Take a business with 1,000 subscribers at $29/month — $29,000 MRR, $348,000 a year. Model it conservatively.

Involuntary churn on card-billed subscriptions typically runs in the low single digits of the active base each month, and a meaningful slice of it is never recovered. At just 2% failing per month with half recovered by dunning, you lose roughly 1% of the base monthly to a payment problem rather than a product problem. Compounded over a year, that's on the order of $20,000–$25,000 of annualized revenue evaporating because a card number changed.

Now add disputes. Say 0.4% of renewals are disputed — 4 in 1,000. That's about 48 disputes a year at $29, plus a dispute fee commonly in the $15–$25 range applied regardless of outcome. Call it $2,500–$3,000 in direct loss, before the labour of assembling evidence for a charge you'll probably lose anyway, because "I didn't authorize this recurring charge" is hard to rebut without a signed mandate.

Then the processing spread itself: percentage plus fixed fee on every renewal, higher on cross-border cards, applied twelve times a year per customer. On $348,000 of card volume that's routinely $10,000–$14,000, and unlike a one-off sale, you pay it again every month for the same customer you already acquired.

Put together, that's somewhere near $35,000–$40,000 a year — over a month of revenue — lost to the billing rail rather than to the market. And the worst-case scenario isn't in the arithmetic at all: it's the day your dispute ratio crosses a threshold and your acquirer imposes a reserve, holding a slice of every renewal for 90 to 180 days. For a subscription business whose entire operating model is predictable monthly cash, a reserve is not a fee — it's a cash-flow event that reprices your runway.

Why card rails fail subscriptions structurally, not accidentally

None of this is a bad processor or an unlucky month. It follows from four design decisions baked into the rails.

Reversibility is the product. The card network's core promise to a cardholder is an undo button, and the merchant rebuts a dispute with evidence of delivery. For a subscription, "delivery" is intangible and continuous — access to software, a community, a class schedule — so the artifact that wins disputes (a tracking number, a signed receipt) doesn't exist. The rail is structurally tilted against recurring intangibles.

Renewals depend on a decaying credential. Card-on-file billing stores a token that represents a card that has an expiry date, an issuing bank, a fraud model and a replacement lifecycle — none of which you control. Your revenue is downstream of a plastic artefact's calendar. Account-updater services and smart retries reduce the damage; they can't remove the dependency.

The issuer decides, every single month. A renewal isn't a payment you collect; it's a request an issuer approves or declines using a risk model you can't see, that treats recurring card-not-present charges from foreign merchants with suspicion by default. Twelve approval decisions per customer per year, each a chance to churn.

Custody creates the reserve. Money that flows through an acquirer's balance is briefly their liability, which is why holds, rolling reserves and account reviews exist at all. Every "we're holding 10% for 180 days" is only possible because your revenue passed through a balance you don't own.

What recurring revenue actually needs is a rail where a payment collected is a payment kept: final on confirmation, not dependent on a credential that expires, priced the same in every country, and owned by the recipient from the first second.

How Payzum runs crypto subscriptions without chargebacks

Payzum is a non-custodial, crypto-only payment processor. Non-custodial means settlement is the payment: when a subscriber pays, funds route directly to a wallet you control. Payzum never pools, holds or touches the money — so there's no processor balance to reserve against, no payout schedule, and no intermediary re-underwriting your business mid-cycle. The mechanic is the same one explained in non-custodial crypto payment processing, applied to recurring revenue instead of one-off sales.

Recurring subscriptions are a first-class collection method alongside hosted checkout, payment links and invoices. You define the plan, the subscriber pays each cycle from their own wallet, and each payment settles on-chain. Because on-chain settlement is final, the two questions that dominate card billing — "will this renewal be reversed later?" and "is this credential still alive?" — simply stop applying. There is no card to expire, no issuer approving the charge, and no 120-day window in which collected revenue can walk back out.

The failure mode changes shape, and it's worth being precise about it: on cards, a subscription dies silently when a credential decays; on-chain, a subscription lapses visibly when a subscriber doesn't renew. The second is a retention conversation, not a payments bug — and you can drive it automatically, because signed webhooks fire on confirmed payments so your app, Discord bot, LMS, gym door system or CRM grants and revokes entitlement without anyone touching a spreadsheet.

Auto-convert settles every cycle as USDC or USDT no matter what the subscriber sent, so a $29 plan is $29 of stablecoins in your wallet — a subscription price is a fixed number, and your billing shouldn't turn it into a position you didn't choose to take. USDC is issued fully reserved against dollar-denominated assets, which is what makes it usable as a unit of account for pricing rather than just a settlement token.

The rest of the lifecycle is covered by the same account. Hosted checkout (redirect, modal or inline) and no-code payment links and buttons handle signup — from a pricing page, an email, a link-in-bio or a sales conversation. Invoices with expiration and overpayment detection handle annual plans, enterprise seats and retainers, where "we'll pay next week" needs a deadline that either resolves or expires. The POS covers hybrid businesses whose members also pay at a counter: a fresh QR per transaction, any phone as a terminal, PIN cashiers with per-cashier analytics. And mass payouts — CSV batches in BTC/LTC/DOGE plus EVM stablecoin payouts on Polygon, Arbitrum, Optimism, Base, BNB Chain and Avalanche — pay the affiliates, resellers and contributors funded by that MRR, the pattern covered in crypto mass payouts.

Underneath, it's ordinary infrastructure: a REST API with API keys, an integration playground, signed webhooks, 2FA, encrypted secrets and a full audit log. Payzum settles across nine networks — Bitcoin, Ethereum, Solana, Polygon, Base, Arbitrum, Optimism, BNB Chain and Avalanche — with typical confirmations around 0.4 s on Solana and about 2 s on Base and Polygon, so a renewal is confirmed and access is granted while the subscriber is still on the page. If your product is an API rather than an app, the same account also makes it agent-payable per call over x402.

How it works, step by step

1. Sign up and connect your wallet. Create a Payzum account and point it at a wallet you control — a hardware wallet for a solo operator, a multisig or treasury wallet for a company. There's no acquirer application, no underwriting of your subscription model, and no reserve negotiation. Switch on auto-convert so every cycle lands as USDC or USDT.
2. Define your plans. Set up your recurring subscriptions — monthly and annual tiers, the price in stablecoin terms, and which chains you accept. Create an invoice template for annual and enterprise deals so the same plan can be sold as a self-serve subscription or as an invoice with an expiry date.
3. Put signup where your customers already are. Drop hosted checkout into your pricing page as a redirect, modal or inline widget, or publish a no-code payment link for email, chat and sales calls. Existing plugins and snippets keep working — this is a payment path you add, not a stack you migrate.
4. Wire entitlement to webhooks and go live. Point signed webhooks at your application so a confirmed payment provisions the account, adds the Discord role, unlocks the course, opens the gym door or extends the licence — and a lapsed cycle downgrades it. For in-person members, open the POS on a phone and take a fresh QR per payment with a PIN cashier per staff member. When it's time to pay affiliates or partners, upload one CSV.

Use cases: who runs subscriptions this way

"Subscription" covers very different businesses, and the same building blocks cover all of them:

• SaaS and developer tools: monthly and annual plans billed in USDC, with signed webhooks provisioning seats and licence keys on confirmation. Global customers pay the same way from every country — no cross-border assessment, no issuer declining a foreign recurring charge — and no renewal you booked last quarter can be reversed this quarter. Same playbook as accepting USDC payments in a SaaS.
• Paid communities and memberships: a Discord, a research group, a trading education community, a private forum. The subscription is the access, so the webhook that confirms payment is the webhook that adds the role — and because payments are final, a member can't consume three months of a community and then claw the money back.
• Gyms, studios and clubs with hybrid members: online signup with hosted checkout for people who join from the website, and a QR at the front desk for people who join in person, with PIN cashiers so each staff member's takings reconcile separately. Monthly memberships renew on the same rail either way — the flow described in accepting USDC payments in a gym.
• Course creators and cohort programs: monthly access to a library, or an instalment plan for a high-ticket cohort where each instalment is final on payment. Course businesses are disproportionately hit by "I finished the material, now I'll dispute it" — see accepting crypto payments for online courses.
• Creators, newsletters and sponsorware: monthly supporter tiers and corporate sponsorships. Small recurring amounts stay economic because moving a stablecoin on Base, Polygon or Solana costs cents, and there's no platform taking a second cut — the same economics as accepting crypto donations.
• Agencies and consultants on retainer: a recurring subscription for the monthly retainer plus expiring invoices for project work, with overpayment detection so a client's rounding doesn't become a reconciliation task. Cross-border retainers arrive same-day instead of on a wire's schedule — see accepting crypto in a digital agency.
• Infrastructure, hosting and VPN providers: customers who chose you for privacy and independence, paying on a rail that doesn't require them to hand a card number to a chain of intermediaries — and, if your product is an API, an x402 per-call option for the AI agents that increasingly do the buying.
• Marketplaces and platforms with seller plans: recurring seller subscriptions in, mass stablecoin payouts to sellers out, both non-custodial, both on the same nine networks.

Card-billed subscriptions vs crypto subscriptions — side by side

Common objections, answered

Without a card on file, doesn't every renewal become a chance to churn?

It becomes a chance to churn visibly, which is different from the card model in a way that favours you more often than people expect. Card billing doesn't prevent churn — it hides it, then converts a slice of your retained customers into involuntary churn nobody asked for, plus a dunning workflow to claw them back. On-chain, a subscriber who wants the product renews and the payment is final; a subscriber who doesn't, lapses, and your webhook downgrades them cleanly. You still run retention — reminders, annual plans at a discount, usage nudges — but you're running it against real intent rather than against an expired card number. In practice the highest-leverage move is the same one card businesses use: sell annual. An annual cycle collected on-chain is twelve months of revenue that is genuinely yours from day one.

My subscribers pay by card today. I can't just migrate them.

Don't. Payzum is crypto-only and doesn't settle to a bank account, so this isn't a rip-and-replace for a fiat billing stack — it's a second rail that earns its place where the first one is weakest: customers abroad whose renewals decline, crypto-native users who'd rather pay in USDC anyway, high-ticket plans where a single dispute hurts, and any segment where your dispute ratio is the thing keeping your acquirer nervous. It's drop-in — hosted checkout, links, existing plugins and webhooks — so adding it costs a page and a webhook, not a migration.

Is my money safe if Payzum never holds it?

That's precisely what makes it safe from the risks subscription businesses actually face: there's no pooled balance to reserve against, nothing to freeze mid-cycle and no payout to approve. The trade-off is real and worth stating plainly — you're responsible for the wallet's keys, so match the setup to the business: a hardware wallet for a solo operator, a multisig for a company treasury. The account itself is protected with 2FA, signed webhooks, encrypted secrets and a full audit log.

What about the price moving between cycles?

Turn on auto-convert. Every cycle settles as USDC or USDT whatever the subscriber sent, so a $49 plan is $49 of stablecoins in your wallet each month. Your pricing stays a dollar number and your revenue stays a dollar number.

How do we do revenue recognition and accounting on this?

Each cycle produces an on-chain record plus the transaction history and audit log in your account, which is what your bookkeeper reconciles against — and because there are no chargebacks, no reserve and no payout lag, recognized revenue and received funds finally describe the same thing on the same date. How digital assets are treated for tax and reporting depends on your jurisdiction: in the United States, for instance, the IRS treats digital assets as property rather than currency, which affects how each receipt is valued. Confirm the specifics with your own accountant.