Recurring Crypto Payments: How Subscription Billing Works Without a Custodian

Crypto subscriptions have no auto-charge. There are three substitutes

Card subscriptions are pull-based: you store a card number or token with a platform, the platform initiates the charge on the due date, and the user does nothing. That path does not exist in crypto - wallets have no pull entry point. Without a private key signature, nobody (including any platform) can move assets out of an address. This is a property of the account model, not a feature gap in some product.

Every crypto subscription product on the market is one of three implementations:

• Custodial balance auto-debit. Users deposit funds into a platform's custodial account first (the Crypto.com and Stripe subscription integration takes this route), and the platform debits the balance on schedule. The experience is closest to a card, at the cost of users giving up self-custody and merchants receiving a platform settlement - the platform still sits in the middle of the money path.
• Contract allowance streaming. Users approve a spending allowance for a contract in advance, and the contract pulls from their address each period (the Superfluid family). The cleanest mechanism, but it asks ordinary users to authorize an allowance to a contract they have never read. Four years in, it is still a niche.
• Recurring invoices. Each billing cycle generates a new fixed-amount invoice, and the user pays with two taps after a notification. It sounds manual, but it is the only option that neither sacrifices the user's key sovereignty nor demands pre-authorization.

All three run in production somewhere. My take is blunt: for 95% of subscription SaaS, recurring invoices are the default answer. They put the automation on the merchant side - auto-generate, auto-dun, auto-reconcile - and leave the confirmation with the user. That is what a subscription relationship should look like: the user can stop at any time, and the merchant's cash flow passes through nobody's hands.

Recurring invoices in practice: invoices, webhooks, and a state machine

A minimal recurring billing system needs three things: a scheduler, invoices, and webhooks. Using Xcash's Invoice Collection mode as the example (fixed amount, time-limited, each invoice mapped to its own contract address), each billing cycle does three jobs:

First, a scheduled task calls the API to create the period's invoice - fixed amount (say 25 USDT), fixed window (48 hours). The invoice goes out by email or in-app message with a payment QR code or link. Second, when the user pays, the gateway pushes a webhook callback. Xcash callbacks include automatic retry and nonce-based idempotency: a lost callback gets redelivered, and a duplicate callback never double-posts.

invoice_id: INV-20260901-0842
period: 2026-09
amount: 25.00 USDT
chain: TRON
status: pending → paid
tx_hash: 9f3c2a...

Third, your server extends the membership on a paid status, and drops the user into the dunning queue on expired. Dunning is the real craft of subscription billing: remind three days before expiry, remind again on the due date, grant a 48-hour grace period, then suspend service while keeping the invoice record. Hosted platforms will not write these rules for you - they offer auto-debit from a balance and fail silently when it comes up short. Self-hosting lets you tune dunning to your actual business: how much slack for trials, how much for long-time customers, special handling for large subscriptions.

To be honest about the trade: you give up the hosted platform's full auto-debit, and in exchange you get sovereignty over your billing logic. For a subscription business, that trade is worth it.

The real lesson from SafePal: subscription data is a liability, not an asset

SafePal did not lose keys. It lost order information - names, shipping addresses, order numbers, close to 40,000 records. For a wallet vendor this is a reputation incident. For a subscription merchant, it is a question you can transplant directly onto your own business: what does your hosted subscription processor hold?

A hosted subscription platform holds more than a money rail. It holds your entire subscriber list, emails, invoice amounts, payment history, renewal rates. That data is an asset for the platform - used to price your risk and cross-sell you. When something goes wrong, it becomes your liability - customers get phishing emails, their data leaks, and the anger lands on your brand while the platform issues a statement (exactly like SafePal did). The rule of data breaches: you are on the hook for whatever you handed over.

A self-hosted gateway cuts that chain to the minimum: subscriber data lives only in your own servers and databases. The data boundary equals your machine room. Compliance duties do not shrink - transaction record-keeping and suspicious transaction reporting still apply - but disclosure is minimal and your customer list does not sit permanently with a third party (see our regulatory breakdown).

The money side works the same way. SafePal can honestly say assets are safe because the keys are with the users. Xcash applies the same principle on the merchant side: the smart contract hardcodes the merchant's collection address, so a compromised server cannot redirect funds (see the contract security analysis). Data in your hands, funds straight to your wallet - the two assets a subscription business cannot afford to lose, neither of which needs a third-party custodian.

The three routes compared

Setup notes for self-hosted recurring billing

Deployment has no ceremony: one Docker Compose command, live in three minutes (deployment tutorial). For subscription use, a few configuration notes:

• Use Invoice Collection mode: fixed-amount, time-limited invoices map naturally onto billing cycles.
• Do not set the window too tight. 48 hours is a good starting point for most cases - long enough for users to see the email and pay, short enough to keep your order table sane.
• Reuse the same collection address per subscriber when you can. Reconciling by address is half the work of reconciling invoice by invoice.
• Refunds stay manual: crypto payments are irreversible, so for subscriptions refund the remaining days pro-rated, with the merchant initiating an on-chain transfer (full treatment in our disputes guide).
• Sign your webhook callbacks so forged callbacks bounce.

When is hosted still the right call? If your subscription volume is small, you have no engineering capacity, and your users mostly use custodial wallets, a hosted subscription module is the fastest path - the 1%-2% you save may not cover a VPS plus development time. The decision rule is simple: if subscription revenue is over 70% of your main business, continuity is your lifeline, and you do not hand your lifeline to a platform. If subscriptions are a side channel, start hosted and migrate once volume justifies it. Migration is cheap either way: invoices are standardized, and switching gateways only touches the API layer.

FAQ

Can crypto subscriptions ever be fully automatic?

No - not unless users park their balance with a custodian or pre-authorize a contract. Users of self-custodial wallets must confirm each period. Auto-generated invoices plus one-tap payment is the consensus equilibrium. Know this, and no fully automatic crypto subscription pitch can confuse you.

What do I do when a subscriber keeps not paying?

Run the dunning ladder: pre-expiry reminder, grace period, service suspension, invoice expiry. On-chain payment records are publicly verifiable, so the I paid but it never arrived dispute simply disappears (see our dispute handling guide). Write the suspension triggers into your terms.

Which chains can I collect subscription fees on with Xcash?

The full EVM family - Ethereum, BNB Chain, Arbitrum, Base, Polygon, Avalanche, Optimism (any ERC-20 token) - plus USDT and TRX on TRON. For subscriptions the workhorses are USDT and USDC.

Does self-hosting subscription payments create compliance problems?

Collecting payment for your own goods is not a crypto-asset service provider (CASP) activity under MiCA, so no CASP license is required. But record-keeping, suspicious transaction reporting, and scenario-based due diligence under national AML law still apply. Self-hosting changes where the data lives, not which duties exist. Check your local law (regulatory background here).