Why recurring billing is a different job for a gateway.
Every payment gateway does the same core thing: it takes a charge request, carries it to the card networks and the issuing bank, and brings back an approval or a decline. For a one-time purchase, that's the whole job. The customer is present, they typed their card in, and if it fails they can try another one.
A subscription flips almost every one of those assumptions. The customer is present exactly once — at signup. Every charge after that happens without them: no card entry, no chance to retype a digit, no second card in their wallet to fall back on. In card-network terms, the signup charge is a customer-initiated transaction, and every renewal after it is a merchant-initiated transaction (MIT) — a charge you run against a stored credential, under rules the card networks define for exactly this situation.1 That changes what you need from the gateway in three ways:
- Card-on-file via tokenization. You can't store raw card numbers on your own servers without taking on the heaviest tier of PCI DSS compliance. So the gateway (or a vault above it) stores the card and hands you back a token — a reference you can charge later. No token support, no subscriptions.
- Stored-credential compliance. The networks require merchant-initiated charges to be flagged as such and tied back to the original transaction — Visa and Mastercard use network transaction identifiers from the initial authorization for this.1 A gateway built for recurring handles these fields for you; one that isn't leaves you assembling them by hand, and getting them wrong hurts your approval rates.
- Charges that succeed unattended. When a renewal fails, nobody is standing at a checkout to fix it. Whatever the gateway and billing stack can do automatically — refresh an expired card, retry intelligently, fail over to a healthy gateway — is the difference between keeping and losing that subscriber.
Hold onto that last point. It's the theme of this entire guide.
02 / The checklistThe gateway features that matter for subscriptions.
Filter any gateway shortlist through these six capabilities. Most big-name gateways check most boxes — but "most" is doing a lot of work, and the details differ.
1. Tokenization and a card vault
The foundation. The gateway stores the card, you store a token. Ask where the vault lives and — critically — whether you can take your tokens with you. Tokens locked to one gateway make it painful to ever switch or add a second gateway; a portable vault (or one held at the billing layer above the gateways) keeps your customer base yours.
2. Real recurring / MIT support
Not just "you can charge a token" — proper support for the stored-credential framework: transaction flagging, network transaction IDs carried from the initial authorization to every renewal, and correct handling of recurring vs. unscheduled card-on-file charges.1 This is table stakes at the majors: Authorize.net, for example, documents card-on-file transaction types and handles the stored-credential fields automatically for its recurring billing product.1
3. An account-updater service
Cards die of natural causes: they expire, get reissued after fraud, get upgraded. For a one-time merchant that's irrelevant; for you it's a slow leak. The card networks run services — Visa Account Updater and Mastercard's Automatic Billing Updater — that let enrolled gateways fetch the new card number and expiry directly from the issuing bank, so the renewal charges the current card instead of the dead one.2 Gateways productize this differently: NMI sells it as Automatic Card Updater on top of its Customer Vault (supporting Visa, Mastercard, and Discover, but not American Express), and Stripe describes its equivalent card-account-updater behavior in its own documentation.3,4 Ask specifically: which networks, which schedule, what does it cost per update?
4. Rich decline data and retry-friendly behavior
When a charge fails you need to know why — a raw decline code, not a flattened "payment failed." Whether the failure was insufficient funds, an expired card, or a hard "do not retry" determines what your billing layer should do next. A subscription-grade gateway passes decline reasons through cleanly and doesn't get in the way of scheduled retries.
5. 3-D Secure that knows about subscriptions
3DS (Visa Secure, Mastercard Identity Check) authenticates the customer — which is only possible when the customer is present. A gateway that handles subscriptions properly runs 3DS on the initial signup where required (it's mandated for most European traffic under SCA rules) and then correctly exempts the merchant-initiated renewals that follow, rather than challenging a customer who isn't there.
6. Multi-currency and local payment support
If you sell internationally, check which currencies the gateway can settle in, not just display. Charging customers in their own currency and processing through an appropriately located acquirer generally treats cross-border subscribers better than forcing everything through one domestic path — and the difference shows up in your approval rates, which is the subject of the next section.
03 / The silent killerDeclines, not cancellations,
are where subscription revenue dies.
Subscription operators obsess over voluntary churn — the customer who decides to cancel. But there's a second kind: involuntary churn, the customer who never chose to leave. Their renewal charge failed, the failure was never recovered, and the subscription lapsed. They wanted the product. The billing just broke.
This is uniquely a subscription problem. In one-time ecommerce, a declined card is friction — the customer retries and you usually still get the sale. In subscriptions, a declined renewal is a cancellation by default: there's no customer at the keyboard, so unless something in your stack acts, the failure simply stands. And renewals fail for the most mundane reasons — an expired card, a temporarily maxed limit, an issuer being cautious about an unattended charge, a gateway hiccup at 3 a.m. when your billing run fires.
Declines split into two families, and the response to each is different:
- Soft declines — temporary conditions like insufficient funds or issuer time-outs. These are recoverable: a retry a few days later (say, after a typical payday) often succeeds. This is what dunning — the schedule of retries and "please update your card" messages — exists for.
- Hard declines — the card is closed, stolen, or the issuer says never retry. Retrying these is worse than useless; it damages your standing with the issuer. The right response is an account-updater refresh or a customer outreach for a new card.
Put the pieces together and decline recovery is a layered defense: an account updater fixes cards before they fail, smart retries recover the soft declines, dunning messages catch what retries can't, and clean decline codes tell each layer which case it's looking at. A gateway contributes the data and the rails; the orchestration lives in your billing layer. We've avoided quoting industry-wide loss percentages here deliberately — published figures vary widely by study and business type — but the mechanism is not in dispute: for any merchant whose revenue arrives as unattended renewals, failed payments are a first-order lever on revenue, and it's the lever most operators look at last.
Gateway redundancy, done right.
Here's the uncomfortable dependency at the heart of a subscription business: your revenue is a scheduled batch of unattended charges, and every one of them flows through your gateway. If that gateway has an outage, degrades, or suffers a configuration problem during your billing window, renewals fail through no fault of the card, the customer, or you — and as section 03 established, a failed renewal left alone is a lost subscriber.
The same reliability engineering that applies to servers applies here: don't build a single point of failure into your revenue. A redundant payment setup connects more than one gateway behind your billing layer, so that:
- Automatic failover catches outages. If a charge fails for a reason that points at the gateway rather than the card — connection errors, processor downtime — the billing layer resubmits it through a backup gateway instead of letting the renewal die.
- You can route around trouble without a fire drill. When a gateway is degraded, misbehaving after an update, or being migrated, you shift traffic to a healthy one and your renewals never notice.
- Approval rates get an optimization surface. Gateways differ — in acquirer relationships, in currency and regional coverage, in how they handle specific card types. With more than one connected, you can route each charge through the path that historically performs best for that kind of charge, and measure the difference.
- Switching costs drop to zero. With cards vaulted at the billing layer and two gateways live, renegotiating rates or leaving an underperforming provider is a routing change, not a migration.
Two things make redundancy real rather than theoretical. First, the vault has to sit above the gateways: if your tokens live inside gateway A, gateway B can't charge them, and your "backup" is decorative. Second, failover has to be automatic: an outage at 3 a.m. during your billing run doesn't wait for someone to notice a dashboard.
Single gateway
- Gateway outage = failed renewals across the billing run
- Tokens usually locked to the provider
- One approval-rate path, no way to compare
- Switching providers is a migration project
Multiple gateways + billing-layer vault
- Automatic failover keeps renewals flowing through outages
- Cards vaulted above the gateways — portable by design
- Route each charge via the best-performing path, and measure it
- Changing providers is a routing change
Where the gateway ends
and the billing layer begins.
By now a pattern should be visible: almost everything that protects subscription revenue — retry schedules, dunning, failover, routing — is orchestration, and orchestration is not the gateway's job. The cleanest way to think about the stack:
The gateway moves money. It authorizes and settles individual charges, holds tokens, and reports results. The billing platform decides which money to move, and when. It owns the subscription schedule, plan changes and pauses, the retry and decline-recovery logic, the dunning sequence, which gateway each charge routes through, and the customer's whole state — what they're subscribed to, what they've paid, what failed and why.
| Responsibility | Payment gateway | Billing platform / CRM |
|---|---|---|
| Authorize & settle a charge | Yes — core job | Requests it |
| Store the card | Token vault | Portable vault above the gateways |
| Subscription schedules & plans | — | Owns them |
| Retries, dunning, decline recovery | Passes decline codes | Owns the logic |
| Failover & gateway routing | Is one of the routes | Chooses the route |
| Customer state & reporting | Per-transaction records | Full lifecycle view |
This is the layer Admoji occupies. It's a CRM and billing platform that sits on top of your own merchant account and gateways rather than replacing them: recurring billing and subscription management, decline recovery, and multi-gateway redundancy with automatic failover, alongside the checkout and funnel tooling. It works with major US processors — Stripe, Authorize.net, and NMI gateways among them — routing to the merchant account you've been approved for. Pricing is published: $79/mo + 0.35% of volume on the Launch plan, no long-term contracts, with a 14-day free trial and no credit card required.5
If you're running a subscription box specifically, the box-model mechanics — cohort billing dates, skip months, prepaid terms — are covered in our companion guide to subscription box billing. And if you're evaluating billing platforms against each other, see how Admoji compares to Sticky.io.
06 / Due diligenceQuestions to ask any gateway before you sign.
Print this, and don't accept "yes, we support subscriptions" as an answer to any of it:
- Tokens: Where is the card vault, and if we leave, can we export our tokens? On what terms, and in what timeframe?
- Stored credentials: Do you handle network transaction IDs and stored-credential flagging automatically for merchant-initiated charges, or do we pass those fields ourselves?
- Account updater: Which card networks does your updater cover, how often does it run, and what does each update cost?
- Declines: Do we get raw decline codes on every failed charge? Do you distinguish hard from soft declines in a way our billing system can act on?
- 3DS: How do you handle 3-D Secure on the initial subscription payment, and how do you exempt the merchant-initiated renewals that follow?
- Currencies: Which currencies can you settle in — not just present — and through which acquirers?
- Coexistence: Do you play well in a multi-gateway setup behind a billing platform, or does anything in your terms or architecture assume you're the only gateway?
- Uptime: What's your published uptime history, is there a public status page, and what's the SLA?
- Pricing: What's the full per-transaction cost including gateway fees, token storage, updater fees, and any monthly minimums?
- Support: When a billing run fails at 3 a.m., who picks up?
Common questions.
What is a subscription payment gateway?
Do I need a special payment gateway for subscriptions?
Can I use more than one payment gateway for subscriptions?
What's the difference between a payment gateway and a subscription billing platform?
Your gateways, orchestrated.
Your renewals, recovered.
Recurring billing, decline recovery, and multi-gateway redundancy with automatic failover — on top of your own merchant account, with a full CRM underneath. $79/mo + 0.35%.
Start your free trial →or see everything Admoji does →
14-DAY FREE TRIAL · NO CREDIT CARD REQUIRED · CANCEL ANYTIME
Sources — all observed September 3, 2026
- developer.authorize.net — Card-on-File Transactions — customer- vs. merchant-initiated transaction types, network transaction IDs from the authorization response, and stored-credential handling for recurring billing.
- developer.mastercard.com — Automatic Billing Updater — Mastercard's network service for keeping stored card credentials current for billers.
- nmi.com — Automatic Card Updater — NMI's account-updater product on top of its Customer Vault; per NMI's support documentation, supported card types are Visa, Mastercard, and Discover (American Express not supported).
- stripe.com — What is a card account updater — Stripe's explanation of how card account updaters refresh expired and reissued cards for recurring charges.
- admoji.com — Admoji's published features and Launch pricing: recurring billing, decline recovery and reporting, gateway support (Stripe, Authorize.net, NMI, and high-risk specialists), $79/mo + 0.35% of volume, no long-term contracts, 14-day free trial.
Card-network rules and vendor features change; statements reflect what these vendors published on the date above. If you spot something outdated, email info@admoji.com and we'll correct it promptly.