Recurring Payments: Cards, Direct Debit, A2A, and Wallet Billing Compared

One-time payments are initiated by the payer. Recurring payments are merchant-initiated — the customer authorized collection at setup, and the merchant triggers every subsequent charge. The authorization mechanism varies by rail: a card token, a direct debit mandate, an open banking consent, or a wallet billing agreement. Which mechanism you use determines your failure modes, refund exposure, geographic coverage, and per-transaction cost.

The short answer

If you are building a global subscription product and have no local entity outside your home market, card-on-file is the right starting point. One PSP integration, no banking relationship required, global coverage.

If you have meaningful subscription volume in Europe, India, Brazil, or the UK — and a local entity in those markets — layering local bank-debit rails (SEPA SDD, UPI AutoPay, Pix Automático, or UK VRP) materially reduces per-transaction cost and opens addressable markets that cards cannot reach.

Wallet billing (Apple Pay, Google Pay, PayPal) is not a separate rail decision. Wallets layer over an underlying card or bank credential. For recurring billing outside app-store contexts, the card network is still executing the collection.

What counts as a recurring payment

A recurring payment collects money from a customer on a schedule or trigger the customer authorized in advance, without the customer initiating each individual transaction. The authorization format distinguishes the four rails.

Card mandate (card-on-file): The customer provides card credentials at checkout. The merchant tokenizes and stores them, then charges the card as a Merchant-Initiated Transaction (MIT) on each billing date. The card network handles authorization.

Direct debit mandate: The customer authorizes the merchant to debit a specific bank account. The authorization is a signed mandate — held by the merchant under SEPA, or lodged with the scheme under UK BACS. The banking scheme executes the debit on instruction from the merchant.

A2A / VRP mandate: The customer grants a standing consent through their banking app to a specific merchant to pull amounts from their bank account. In the UK this is the open banking VRP framework. In India, it is UPI AutoPay. In Brazil, it is Pix Automático. Consent is stored at the bank or payment scheme.

Wallet billing agreement: The customer authorizes recurring billing through a wallet provider (Apple Pay, Google Pay, PayPal). The wallet acts as a credential surface — the underlying payment typically routes through a card or bank account the customer has registered with the wallet. Recurring capability depends on the wallet provider, PSP integration, app-store model, and region.

Card recurring

Card-on-file is the default recurring rail for most global operators: universal coverage, no local entity required, single PSP integration.

Card-on-file and credential storage

The customer stores a card at checkout. The card number is tokenized — either by the PSP (PSP token) or by the card network (network token). On each billing date, the merchant charges the stored token as an MIT.

Network tokens — issued directly by Visa Token Service or Mastercard MDES — follow the card when it is reissued. A card is replaced and the token stays valid; no collection interruption, no customer action required. PSP tokens break on card reissuance unless the PSP has enrolled the merchant in card updater services (Visa Account Updater, Mastercard Automatic Billing Updater).

MIT/CIT tagging

Every card recurring charge must be flagged as a Merchant-Initiated Transaction to signal to the issuer that the cardholder is not present. In EEA markets, MIT flagging is also the mechanism that exempts the charge from SCA.

The initial charge — the Cardholder-Initiated Transaction (CIT) — must be SCA-authenticated in EEA markets, and the network transaction ID from that CIT must be stored and passed with every subsequent MIT. Without it, issuers may request SCA on MIT attempts, which fails because the cardholder is not present to complete the challenge.

Full MIT/CIT mechanics, reason codes, and auth rate implications are in the MIT/CIT guide.

Account updater

Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) push new card credentials to merchants when cards are reissued or account numbers change. For PSP-tokenized cards, the PSP manages updater enrollment on the merchant’s behalf. For network tokens, the token lifecycle is managed natively — the token remains valid through card replacement without separate updater enrollment.

Merchants not using network tokens or updater-enrolled PSP tokens experience involuntary churn on each card reissuance cycle. Reissuance is typically done in bank cohorts, so churn appears as a spike rather than steady-state attrition.

Retries and dunning

A failed card recurring charge requires a retry strategy. Visa and Mastercard limit retry attempts: 15 total authorization attempts per transaction, with specific soft decline codes restricting retries to once per 24 hours after the first decline. Retrying beyond scheme limits, or using the wrong MIT flag on a retry, generates a fresh transaction that may trigger issuer blocks.

Authorization optimization — retry timing, BIN routing, and soft decline recovery — is covered in the auth rate guide.

Common failure modes

• Card expired before account updater triggered (latency window between expiry and updater sync)
• MIT chain broken by missing network transaction ID from initial CIT
• Retry limit exhausted before subscriber acts to update card details
• Soft decline on the initial CIT without SCA completion — MIT chain cannot start

Direct debit

Direct debit collects from a bank account rather than a card. Setup requires a mandate — a pre-authorized instruction allowing the merchant to initiate debits. No card network, no interchange, no card expiry risk. The failure modes are different: insufficient funds, closed accounts, mandate disputes, and — in SEPA — the consumer refund right.

SEPA Direct Debit

SEPA Direct Debit covers the eurozone and most of the EEA (36 countries). Two schemes apply to subscription billing.

SDD Core (consumer-facing): The merchant holds the mandate and initiates debits. Settlement takes T+1 to T+5 business days. The defining commercial characteristic is the 8-week no-questions-asked consumer refund right: any consumer can request a full reversal of an SDD Core debit within 8 weeks of settlement, and their bank must comply without requiring justification. For digital subscription services, this creates a revenue reversal window on every collection for two months after each billing date.

SDD Core is entirely exempt from SCA — no Strong Customer Authentication is required at collection, only at initial mandate setup. For operators with significant European subscription volume, this is a structural advantage over card recurring, which requires the MIT/CIT framework with a 3DS2-authenticated setup.

SDD B2B (business-to-business): No consumer refund right — the debit is irrevocable 3 business days after collection. The debtor’s bank must pre-validate the mandate before the first debit executes. Settlement T+1. Restricted to transactions between business accounts.

The European Payments Council’s SDD Core Rulebook 2025 v1.0 entered force on October 5, 2025.

ACH (United States)

ACH (Automated Clearing House), governed by Nacha’s Operating Rules, is the US bank-debit mechanism. Per Nacha’s rules, every recurring ACH debit requires a written or electronic authorization from the payer before any debit is initiated. The authorization must include the merchant name, the amount or amount determination method, the payment frequency, and the payer’s bank account details. Electronic authorizations must meet Nacha’s formatting requirements and be retained for a minimum of two years.

ACH debits settle in 1–3 business days for standard ACH, or same-day under Same Day ACH (three settlement windows per business day). ACH returns use standardized Nacha reason codes — R01 (insufficient funds), R02 (account closed), R03 (no account/unable to locate), R08 (stop payment order). Nacha’s return rate thresholds apply: merchants exceeding specific return rate limits face compliance review.

BACS Direct Debit (UK)

BACS Direct Debit is the UK bank-debit mechanism. Mandate setup requires a Service User Number (SUN), obtained from your bank or through an approved Direct Debit bureau (GoCardless, Bottomline). The mandate authorizes the merchant under the Direct Debit Guarantee, which gives UK consumers the right to an immediate full refund from their bank for any incorrect or unauthorized debit — with no fixed time limit on unauthorized claims.

BACS settles in 3 business days. For operators with significant UK subscription volume, UK VRP is developing as a lower-latency alternative as it reaches full CMA9 coverage.

Mandate portability risk

Direct debit mandates are typically tied to the bureau or PSP that created them. A PSP migration requires re-authorization of all existing mandates — customers must approve the new provider. For subscription businesses at scale, this is churn risk embedded in the PSP selection decision and worth assessing before committing to a bureau at volume.

Best-fit use cases

• SDD Core: Consumer subscription billing in the eurozone where cost matters and the 8-week refund window is modeled
• SDD B2B: B2B invoice collection requiring irrevocability, where both parties are businesses
• ACH: US consumer and B2B recurring billing
• BACS: Established UK B2C subscription billing, insurance, utilities

A2A mandates / VRP

A2A recurring mandates use instant payment rails for bank-account pull payments. The customer authorizes a standing consent once; the merchant draws against it on each billing date without per-collection customer authentication.

UK VRP

Variable Recurring Payments (VRP) is the UK open banking mechanism for merchant-initiated pull payments from a bank account. The customer authenticates once via their banking app — specifying maximum amount per payment, consent period, and merchant identity. The merchant’s PSP requests payment against that consent on each billing date. Settlement via Faster Payments in seconds, 24/7.

Sweeping VRP (the customer moving money between their own accounts) has been mandated for all CMA9 banks since January 2022. Commercial VRP (merchant collections from customers) is rolling out through bilateral PSP–bank agreements. As of mid-2026, commercial VRP is live bilaterally with major UK banks through select partners (Volt, TrueLayer, Token.io, GoCardless Open Banking). Full CMA9 coverage is targeted for late 2026 or 2027.

VRP has near-zero MDR, no card expiry risk, and no card network chargeback mechanism — payments initiated under valid consent are irrevocable. Consumer protection frameworks for VRP are still being developed by the FCA and Open Banking Limited. The UK and EU regulatory context for open banking VRP is covered in detail here.

UPI AutoPay

UPI AutoPay enables bank-account recurring mandates in India on the UPI 2.0 infrastructure, operated by NPCI. Mandate setup: the customer authenticates once with their UPI PIN in their banking app. Each subsequent debit sends a pre-debit notification at least 24 hours before collection — the customer can block individual collections within that window.

Standard category cap: ₹15,000 per debit for OTT, SaaS, utilities, and mobile bills. Above this threshold, per-collection MPIN authentication is required, removing the automatic mechanism. Elevated limits of ₹1,00,000 per debit apply to insurance premiums, mutual fund SIPs, credit card bill payments, and loan EMIs per NPCI Circular UPI-OC-151A.

UPI AutoPay processed 175 million transactions in January 2025, up 3× year-on-year from January 2024. It holds an estimated 53% share of all recurring payment transactions in India as of early 2025.

Requires Indian entity presence or integration through a local payment aggregator (Razorpay, PayU, Cashfree). Not directly accessible to international operators without local infrastructure.

Pix Automático

Pix Automático launched on June 16, 2025, operated by the Banco Central do Brasil (BCB). It is a pull-debit layer on the existing Pix instant payment infrastructure.

How it works: the merchant’s PSP sends a recurrence record through BCB’s infrastructure to the payer’s PSP. The payer authorizes once in their banking app. Subsequent debits execute automatically and settle via Pix rails in seconds. Collections must be scheduled 2–10 days before the due date. BCB mandates a dedicated cancellation path in every participating bank app.

Available to international merchants via Brazilian-certified PSPs: EBANX, PagBrasil, PayRetailers.

UPI AutoPay, Pix Automático, SEPA SDD, and eGIRO in full regional depth are covered in the subscription rails comparison.

EU direction (PSD3/PSR)

The EU’s Payment Services Regulation (PSR), accompanying PSD3, proposes A2A recurring payment mechanisms across the EEA. This is a regulatory direction, not a live product as of mid-2026. Implementation timeline and mechanics are subject to finalization.

Wallet billing

Wallet billing is not a standalone recurring pull rail. Apple Pay, Google Pay, and PayPal are credential layers — or in app-store contexts, billing intermediaries. Recurring billing capability, dispute handling, and refund mechanics all depend on the underlying credential and PSP integration, not the wallet.

How wallets handle recurring billing

Apple Pay: In web and non-App-Store contexts, Apple Pay passes the customer’s stored card to the merchant’s PSP at checkout. Subsequent recurring charges use card-on-file MIT mechanics — Apple is not in the collection loop. In the App Store context (iOS in-app subscriptions), Apple processes billing directly via StoreKit: the subscription is between the customer and Apple, and Apple remits revenue to the developer. The merchant’s PSP does not handle App Store subscription billing.

Google Pay: On the web, Google Pay passes the customer’s stored card to the merchant’s PSP. Recurring billing uses card-on-file mechanics through the PSP — Google is not involved in subsequent collections. Google Play handles in-app subscription billing directly, on the same model as the App Store.

PayPal: PayPal supports recurring billing via billing agreements, which authorize merchants to charge a PayPal account on a schedule. The underlying collection routes through the customer’s PayPal balance, linked bank account, or registered card. PayPal’s recurring API availability and behavior varies by merchant tier, integration type, and region.

The practical framing

An operator who integrates Apple Pay or Google Pay at checkout for a subscription has captured a card credential via a wallet. The recurring charge will use card-on-file MIT mechanics. If the card expires or is replaced, the same churn and updater dynamics apply as for any card-on-file subscription. Verify what your PSP does with wallet-captured credentials for recurring billing — do not assume the wallet handles it.

Comparison matrix

When to use which rail

SaaS (global, no local entities)

Start with card-on-file. Universal coverage, single PSP integration, card network account updater services, MIT/CIT mechanics handled by the PSP. Add UK VRP when UK subscriber volume and MDR savings justify an open banking PSP integration. Direct debit rails require local entity presence — they are not accessible otherwise.

SaaS (local entity in India)

Layer UPI AutoPay for subscribers billing below ₹15,000/month. Card-on-file remains necessary for tiers above the AutoPay cap. Route UPI mandate flows through a local payment aggregator (Razorpay, PayU, Cashfree).

Digital subscriptions (Europe-heavy)

SEPA SDD Core for B2C eurozone subscribers once a SEPA banking relationship and Creditor Identifier are in place. Model the 8-week refund window explicitly — it is a P&L line, not a rounding error. SDD B2B for business customers where both parties qualify and mandate pre-registration is acceptable. Card-on-file for non-eurozone European subscribers (Poland, Sweden, Czech Republic) where SEPA SDD is not the right instrument.

High-value B2B invoices

ACH (US) or SEPA SDD B2B (Europe) for recurring invoice collection where both parties are businesses and amounts are predictable. SDD B2B removes the 8-week refund risk that SDD Core creates for large B2B amounts.

Marketplaces

Direct debit for recurring platform fees from high-value merchants — mandate setup friction is acceptable for large accounts, and B2B relationships reduce refund exposure. Card-on-file for smaller merchants who will not tolerate mandate setup friction at onboarding.

Regional merchants (Brazil, India)

Pix Automático and UPI AutoPay open the non-card addressable market — consumer segments that previously required manual boleto (Brazil) or per-collection card authentication. The integration investment is justified at meaningful local volume with local entity presence.

Global multi-market merchants

Card-on-file as the base rail across all markets. Layer local bank-debit rails market by market when: (a) volume justifies integration cost, (b) local entity is present, and (c) MDR savings and non-card addressable market access exceed operational overhead. Payment routing KPIs — approval rates, cost efficiency, and failover metrics apply to multi-rail recurring billing portfolios in the same way they apply to card routing.

Common mistakes

Not implementing MIT flags on card recurring charges. Unflagged MIT charges are treated by some issuers as fresh Cardholder-Initiated Transactions, potentially triggering SCA challenges the cardholder cannot complete mid-billing-cycle. The initial CIT must be SCA-authenticated in EEA markets, and the network transaction ID from that CIT must be stored and passed on every subsequent MIT.

Not modeling the SEPA SDD Core 8-week refund window. Well-managed SDD portfolios typically see low dispute rates in practice. But the 8-week window is a real P&L liability for high-value subscriptions or cohorts with elevated cancellation rates in the first two months after signup. Gross refund exposure should be modeled before assuming SDD costs less than card.

Assuming wallet billing is an independent recurring rail. An operator who integrates Apple Pay at checkout for a subscription has captured a card credential via a wallet. The recurring charge uses card-on-file MIT mechanics. The same expiry, updater, and dunning dynamics apply.

Mandate portability blindness. Direct debit mandates are often tied to the bureau or PSP that created them. Building a large SDD, ACH, or BACS mandate portfolio on a single provider without understanding migration risk is PSP lock-in by another name.

Applying a card dunning playbook to direct debit. Direct debit failure modes differ from card failures: ACH returns have specific Nacha reason codes, SEPA R-transactions have pre-settlement and post-settlement variants, and retry rules differ by scheme. Card dunning timing and retry logic typically does not map to bank-debit return handling.

Ignoring entity requirements for local rails. SEPA SDD, UPI AutoPay, Pix Automático, and BACS all require local entity presence, a banking relationship, or a certified local PSP. A roadmap that assumes local bank-debit rails without confirming entity availability will stall before integration.