Stop losing subscribers to expired cards
Bill every renewal as an invoice paid from the customer's own wallet — nothing stored to expire or reissue — so a renewal never fails because a card expired.
Where subscription MRR leaks before retention can save it
Why do you lose subscribers who never meant to leave?
Four ways card-on-file billing churns subscribers who fully intended to stay.
Card expiry alone churns a chunk of MRR every year
Card networks rotate numbers on multi-year schedules. Automatic updater services catch most replacements but miss BIN changes, lost cards, fraud reissues, and many international issuers. The rest hit "card declined" at renewal. Industry data puts this single failure mode at several percent of annual involuntary churn — subscribers gone not because they cancelled, but because the network didn't tell you the number changed.
EU re-authentication quietly fails renewals every single cycle
EU strong-customer-authentication rules require a re-auth step on many transactions unless a merchant-initiated exemption applies. The exemption flag works most of the time, but the rest get pushed into a challenge the customer ignores, and the renewal fails. For SaaS selling into the EU above the threshold, that's a meaningful share of EU renewals dropping straight into the dunning queue.
A recurring-billing surcharge compounds on top of processing
A recurring-billing add-on charges a percentage per recurring invoice on top of the percentage-plus-fixed processing. On a small monthly plan, that pushes the all-in well above the headline rate every single renewal, multiplied across every active subscriber — a recurring tax separate from anything your retention tooling costs on top.
Dunning sequences burn engineering and brand without recovering MRR
When a renewal fails, the standard playbook is several retry attempts over weeks plus emails asking the customer to update their card. Industry recovery rates sit below half. The other half churn. You pay for the retention tool, the dunning emails, the support tickets ("why am I being charged again?"), and the engineering time to maintain it — all to recover half the cards you lost to a problem that doesn't exist on a wallet rail.
How invoice-per-renewal removes involuntary churn
What changes when there's no card on file?
Four things that go right when each renewal is a payment, not a stored-card pull.
Nothing on file means nothing to expire
Paymos never stores a card or a standing charge permission. Each period, your system asks Paymos to issue the renewal invoice and the customer pays it from their wallet — the same wallet, the same amount. No card number to rotate, no BIN to chase, no issuer to consult. The renewal is a payment the customer makes, not a charge pushed at a stored credential — and it credits your Paymos balance final on confirmation.
No EU re-authentication, no exemption to apply for
Strong-customer-authentication and the card challenge step apply to card payments, not stablecoin transfers. Each renewal payment is signed by the customer's own key — that is the strong authentication. No re-auth friction, no challenge the customer ignores, no dependency on a merchant-initiated exemption flag. EU customers renew at the same rate as everyone else.
One rate per renewal — no separate recurring-billing fee
Paymos charges its percentage per settled renewal, period — no recurring-billing premium, no per-invoice fixed fee, no exemption discount that disappears at scale. On the recurring leg, that's a meaningful cut versus a card stack that stacks a percentage-plus-fixed processing charge and a recurring-billing add-on on every single renewal. The payment is yours the moment it clears.
A missed renewal is a real signal, not a card-network artifact
A failed card renewal is often a network artifact — an expiry, a reissue, a false-positive decline. An unpaid wallet renewal means the customer didn't pay: an empty balance or a real second thought. The follow-up is honest — "your renewal invoice is waiting" — and recovery is cleaner because there's no card to hunt down. You stop paying for dunning tooling that exists only to chase card-network noise.
How subscription products wire Paymos in
Which integration fits how you bill renewals?
Three ways to wire stablecoin renewals into your billing flow.
Host-to-host API — renewal invoices from your billing engine
Your engine owns the subscription schedule and the renewal amount. The host-to-host API lets you issue each renewal as an invoice, hand it to the customer's wallet, and watch settlement across the networks they hold funds on. HMAC-SHA256 webhooks fire on confirmation so your subscription state updates automatically. This is invoice-per-period billing, not a stored-card auto-pull — the renewal logic stays in your code.
See details
Hosted Checkout — self-serve plans and first payment
For self-serve plans, create a Paymos invoice for the period and redirect the customer to a hosted page, where they pay from their wallet and return. The first payment and each renewal use the same flow — no payment screen to build, no card vault to maintain, and the same surface scales from a single plan to a team.
See details
Payment Links — annual prepay and enterprise plans
For annual prepay or an enterprise plan, generate a Payment Link for the full term with your PO or order reference attached as the payment's order reference. The customer pays from their wallet, your receivable closes on confirmation, and an annual prepay replaces a year of renewal cycles with a single settlement.
See detailsSubscription flows on stablecoins today
Which subscription models run cleanly on a wallet rail?
Four flows from real subscription setups — flat monthly, freemium-to-paid, annual prepay, multi-seat.
Flat-rate monthly — standard self-serve plans
A standard monthly plan settles in stablecoins each cycle. The customer pays the first invoice from their wallet, and each renewal is a new invoice they pay on the billing date — nothing stored to expire between cycles. The payment confirms in seconds and credits your Paymos balance, and a renewal never fails because a card lapsed.
Freemium-to-paid — a crypto-native audience self-selects
SaaS targeting crypto-curious or crypto-native audiences often sees materially higher paid conversion when wallet payment sits alongside cards. The customer who'd hesitate to give a card to a SaaS based abroad pays in stablecoins in under a minute — no country mismatch, no currency-conversion surcharge, and the payment lands final on confirmation.
Annual prepay — one-shot settlement, no renewal cycle
For annual prepay plans, the customer pays the year upfront via Payment Link or embedded checkout. There's no renewal cycle to manage: the customer locks in price, you lock in cash flow, and a single settlement replaces twelve monthly invoices. The payment is final the moment it clears, so the prepaid year stays paid.
Multi-seat — team plans billed per period
For per-seat pricing, the team admin pays the team invoice each period for the current seat count. Add or remove seats during the period via your admin API; your engine bills the prorated amount on the next invoice at period close. No per-seat card-on-file storage, no re-authentication surprise, and each settled invoice is final.
Subscription billing on stablecoins
Frequently asked questions
If there's no card on file, how does a recurring subscription actually renew?
Doesn't requiring the customer to pay each renewal hurt retention?
How does this handle EU strong-customer-authentication?
Which networks and stablecoins fit small monthly plans versus annual enterprise?
Can we run card subscriptions and stablecoin subscriptions side by side?
How do refunds and cancellations work?
Honest disqualifier
When NOT to use Paymos for subscription billing
Four cases where card-on-file subscriptions are the right call.
Your audience expects a silent auto-renew and won't pay actively
If your subscribers expect a completely hands-off auto-renew and any active payment step would hurt conversion, card-on-file may fit better despite the involuntary churn. Invoice-per-period billing asks the customer to authorise each renewal — great against silent card failures, but a change in habit. Weigh your audience's tolerance before moving the renewal flow, or offer annual prepay to minimise the touchpoints.
Renewal failures are already rare in your book
Some subscriber bases just don't have the problem: domestic cards, strong issuers, exemption flags that work. If your involuntary-churn line is already negligible, moving renewals to a wallet flow swaps a working habit for a new one without much upside. The rail pays off where card rotation, re-auth, and international issuers genuinely bleed MRR.
You need a built-in subscription engine with proration and trials
If you rely on a card processor's full subscription engine — automatic proration, trial management, dunning, plan migrations — Paymos doesn't replace that product. It settles invoices your engine generates; the subscription logic has to live in your engine or a billing platform. For teams that want subscription management out of the box, keep that engine and use Paymos for the settlement rail where it helps.
Wallet-first checkout would scare off your card-happy majority
If most subscribers carry a card and no wallet, defaulting to stablecoins at signup costs more conversions than failed renewals ever did. Put the wallet option behind a second button, aim it at international and crypto-native users, and let the data tell you when to widen it. A rail is an option, not an ideology.
Related flows
Other SaaS & Digital Products sub-niches on Paymos
Pricing
1.0% per settled renewal. No separate recurring-billing fee
Same rate for the small self-serve plan and the large enterprise contract, at any size. High-volume tier at 0.3% on request. Card billing runs about 3% all-in, and a recurring-billing add-on stacks its own percentage on top of every renewal.
See pricing