// FRAMING
'Best' is the wrong question — pick the stack, not the brand
Search results for “best recurring payment processor” collapse into two failure modes. One is the listicle that ranks a list of vendors by superficial criteria — fee transparency, dashboard polish, support hours. The other is the case study disguised as an evaluation, where the verdict is preordained by the vendor sponsoring it.
Neither helps. What actually determines whether a recurring-billing stack performs is a set of five architectural decisions — most of which a vendor either makes possible or makes impossible. The processor with the prettiest dashboard can still leave approval rate on the table if it doesn't support network tokens; Visa reports a lift in authorization rates using network tokens compared to PANs. The processor with the deepest vault can still ruin your subscription business if it doesn't let you migrate cards out.
This guide walks through the five criteria that matter and the criteria that don't. It deliberately doesn't rank vendors — by the time you read this, your shortlist and pricing landscape will have shifted. The framework holds either way.
// CRITERION 1
Network token coverage — Visa VTS + Mastercard MDES, not gateway-only
Network tokens are payment credentials issued by the card networks — Visa describes them as generated by the major payment networks like Visa to replace personal account numbers (PANs) — scoped per merchant per cardholder, that stay valid when the underlying card gets reissued. Visa reports that they lift authorization rates compared to PANs and automatically update card-on-file credentials with lifecycle management. They are the single highest-impact lever in subscription billing.
What to ask a vendor:
- Do you support Visa Token Service (VTS) and Mastercard MDES directly, or are you proxying through a partner? Direct integration means the token is registered under your merchant of record, which is what makes the lift portable if you ever leave.
- When the underlying card gets reissued, does the token auto-update or does it require my team to re-vault? Auto-update is the only answer worth taking; manual re-vault is functionally the same as not having network tokens.
- What fraction of my recurring volume currently runs on network tokens? “Up to 100%” is a marketing claim. The real number is lower, limited by issuer participation and BIN coverage — ask for your own figure, not a platform average.
Be specific about the distinction between a network token and a gateway vault token. The latter is a pointer into one processor's database — useful for storage convenience, not for approval-rate lift. Vendors sometimes use “tokenization” for both. Push back.
// CRITERION 2
Retry intelligence — decline-code-aware, not fixed-schedule
When a recurring charge fails with a soft decline (insufficient funds, exceeds approval amount limit, do-not-honor), the retry strategy determines whether you recover the customer or burn issuer goodwill. Fixed retry schedules — “try again in 24 hours, then 72 hours, then mark past-due” — work for some declines and actively harm others.
A retry engine worth paying for branches on the original authorization response code. Insufficient funds retries when the cardholder is likely to have been paid, exceeds-approval-amount-limit retries after the issuer's limit window resets, do-not-honor retries once then escalates to dunning, and a stop-payment decline doesn't retry at all. It also stays inside the networks' limits: Visa permits up to 20 reattempts in 30 days after a temporary decline and none after a “never approve” decline.
Questions to ask:
- Show me how the retry scheduler decides when to retry. If the answer is “configurable schedule” with no mention of the decline code that triggered the original failure, the retry strategy is generic — not intelligent.
- What's the soft-decline recovery rate on your platform, measured on merchants like you? Ask how it's calculated. A low number means the retry engine is either too aggressive (burning issuer goodwill) or too passive (not retrying at all).
- Do you suppress retries when the issuer signals cardholder-initiated stop-recurring? On Visa that is R0, R1 and R3, after which a merchant must never resubmit for the same payment credential; on Mastercard, Merchant Advice Code 21, where Mastercard recommends acquirers cease resending the same authorization request. If not, you're breaking network rules and inviting disputes over the cardholder's own action.
// CRITERION 3
Vault portability — can you take your tokens with you?
The least-discussed criterion is the most consequential long-term: vault portability. The processor you pick today stores your customers' payment credentials. Three years from now you may want to switch — for pricing, for acquirer fit, for a vertical-specialty feature you don't have today. If you can't migrate the vault out, you're locked in by your own customer base.
Token-migration capability splits into two questions:
- Can you export? The processor should be able to bulk-deliver your stored card data to another vault, in writing, on a stated process. Some processors refuse to do this. Others charge per-token migration fees that effectively price you out.
- Can you import? When migrating in, can the new processor accept and re-tokenize your existing vault without forcing customers to re-card-up? If re-vaulting requires a customer-facing flow, a share of subscribers will not come back through it.
The default assumption among growing subscription operators is that processor switches happen rarely and the export question is hypothetical. Plan as if it isn't: pricing changes, acquirer fit changes when your vertical shifts, and the export terms you sign on day one are the ones you live with. Lock-in is the silent line item.
// CRITERION 4
Chargeback program inclusion — alerts, RDR, representment built-in or bolted on?
Subscription businesses carry more dispute exposure than one-time eCommerce: Visa's merchant guide calls recurring transactions particularly susceptible to cardholder disputes, and an unrecognized charge on a statement is a common route to a fraud dispute — Visa lists an unclear or confusing merchant name among the most common causes. The processor either treats chargeback management as a first-class concern or leaves it as your problem.
Specifically check:
- Verifi CDRN (owned by Visa) + Ethoca (owned by Mastercard) alerts wired in, with a resolution workflow that meets the window — CDRN cases are resolved within 72 hours by seller-initiated refund, and Ethoca shares brand-agnostic dispute data. Bonus if the processor handles the alert response on your behalf; base requirement is that the alert feed reaches your team in real time.
- Visa RDR rule management. The processor should let you configure Rapid Dispute Resolution rules — Visa describes RDR as auto-refunding pre-disputes based on customizable rules — rather than forcing you to handle every dispute manually.
- Representment workflow. Either a built-in representment team or seamless integration with one. For subscription businesses, the “cancelled recurring transaction” reason code is high-volume, and it is winnable only with the right records: Visa's guidance is to accept the dispute when the cardholder withdrew permission and you issued no credit, and to respond with a prior credit or proof the cardholder used services after the withdrawal of permission to bill date. That only works if the workflow exists.
See the full chargeback tools breakdown for the math on each filter. A processor that omits any of the three layers is pushing the work onto your team — it's not a fair price comparison.
// CRITERION 5
Settlement timing + reserves — the cash-flow side
Recurring revenue depends on predictable settlement. A processor that holds funds for days beyond what you planned for, or institutes a rolling reserve that grows with volume, can quietly choke a subscription business's working capital. Settlement timing matters even more in subscription than in eCommerce because the rebill batch is large and predictable — your cash-flow forecast depends on knowing when it lands.
Questions to ask:
- What's the standard settlement timing for my vertical? It varies by acquirer and by your risk profile — get the number of days in writing.
- Will there be a rolling reserve? If yes — what triggers it, what's the cap, and what releases it? An open-ended “reserve as needed” clause is a red flag. Specific terms tied to chargeback ratios are normal industry practice.
- How are returned-deposit (NSF) and chargeback offsets applied? Same-day net-settlement vs. delayed-reconciliation changes how you forecast.
Settlement isn't a dealbreaker by itself — every specialty acquirer has some version of a reserve for elevated-risk merchants. What matters is whether the terms are stated upfront in writing and don't change at the processor's discretion.
// WHAT DOESN'T MATTER
The criteria that look important on a comparison spreadsheet
A few criteria show up in every “how to pick a processor” checklist but don't actually predict subscription performance:
- Brand recognition. The big-name aggregator processors are great for low-volume SMB and a poor fit for subscription merchants as they scale — the per-transaction price is fine, but the lack of acquirer choice and the shared-MID structure caps performance.
- Small per-transaction price differences. At subscription scale, a few basis points of rate are small next to the approval-rate gains from network tokens done right.
- Dashboard UI quality. You'll spend most of your time looking at decline reports and chargeback ratios, both of which export to CSV regardless of dashboard polish.
- Support hours / SLA. Worth checking, but serious processors generally offer round-the-clock support for production issues. The differentiator is response quality, not hours.
// RED FLAGS
Watch for these during evaluation
Specific behaviors during the sales process that predict future operational pain:
- Opaque pricing. “Interchange-plus, call us for rates” with no published numbers and no rate card after the discovery call. Pricing should be on the table by the end of the second meeting.
- No mention of network tokens. If the vendor doesn't bring up VTS / MDES unprompted when you describe a recurring-billing use case, they either don't support it or don't consider it important. Both are disqualifying.
- Vague answers on vault migration. If the vendor can't describe specifically how a future migration off the platform would work — process, fees, timeline, customer-facing impact — assume the answer is “you can't.”
- Decline-code reporting that doesn't exist. Ask to see a sample decline report. If it just shows “X% declined” without the reason-code breakdown, the retry engine is operating blind.
- Generic chargeback “protection.” Vendors that promise “chargeback protection” without specifying whether they mean alerts, RDR, or representment — and what the per-case economics look like — may be selling repackaged alerts at a markup — ask for the per-case price of each layer.
// DECISION FRAMEWORK
Match the stack to your stage
Three rough stages:
- Early stage, low volume, generic vertical: An aggregator-model platform is fine. Network tokens are nice but not yet make-or-break at this volume. Pick the one with the easiest integration and don't overthink the long term.
- Growing, subscription-shaped: Move to a processor with direct VTS / MDES support and real retry intelligence. The aggregator stack starts to cap your approval rate around here. Settlement terms matter; reserves don't usually apply yet.
- At scale, multi-acquirer or specialty vertical: Network tokens are a baseline requirement, not a feature. Multi-acquirer routing becomes meaningful. Chargeback program integration is non-negotiable. Vault portability matters because vendor switches happen.
One bias worth naming: every guide on processor selection is written by someone who sells processors, including this one. The framework above is the one we'd use if we were buying — pick whichever vendor checks the five boxes with the fewest red flags. If that ends up being us, see what we offer subscription merchants and talk to underwriting. If it ends up being someone else, save the export plan for when you want to switch back.