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

Recurring billing can include customer-initiated setup or renewal payments and subsequent merchant-initiated collections under prior consent. A stored credential alone does not make a customer-present payment an MIT. 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, subject to PSP onboarding, banking and market coverage.

Where bank-debit or A2A recurring collection is available to your entity, compare the all-in quote, account requirements and operational cost with card billing. SEPA SDD, UPI AutoPay, Pix Automático and UK VRP can provide additional account-based collection options, but savings and merchant eligibility depend on the actual provider model.

Wallets require their own product assessment. Supported Apple Pay or Google Pay integrations can supply card credentials for recurring PSP billing. PayPal billing agreements may instead use a PayPal balance, bank or card funding source. Do not assume every non-app-store wallet collection runs over a card network.

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: broad coverage through supported PSP relationships.

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 and account updater services can help maintain credentials after reissuance, subject to issuer, scheme and PSP support. They do not guarantee continuity or approval. Confirm lifecycle-event handling and which PSP-tokenised credentials can be updated automatically.

MIT/CIT tagging

Use MIT indicators for card collections initiated by the merchant without customer involvement under a prior agreement. A customer actively initiating a payment with a stored card is still a CIT. Recurring billing describes the arrangement; CIT/MIT describes who initiates the particular transaction.

Genuine payee-initiated transactions without payer involvement are outside PSD2 SCA scope, rather than exempt under Article 14. Remote mandate setup can require SCA; qualifying recurring payer-initiated payments have a separate Article 14 exemption. Confirm authentication and scheme-required stored-credential references with the PSP. 3DS2 is an authentication protocol, not a universal requirement for every initial charge.

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) can supply updated credentials where the issuer, merchant and PSP participate. Network-token lifecycle services may maintain eligible credentials through replacement, subject to token status, issuer and provider support. Neither mechanism guarantees continuity or issuer approval; confirm enrolment, lifecycle handling and fallback with the PSP.

Credential changes can cause failed collections where updates are unavailable or not applied. Monitor actual failure and recovery events rather than assuming every reissuance produces churn or that churn always follows a predictable cohort spike.

Retries and dunning

A failed card collection needs a retry strategy that uses the applicable scheme, issuer response and PSP advice. Retry permissions and limits differ by response category and programme; do not apply one attempt count or interval universally. Stop where retry is prohibited and avoid duplicate collections.

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 is a euro payment scheme available through participating providers across the 41-country-and-territory SEPA area. Two schemes apply to subscription billing.

SDD Core: The creditor holds the mandate and initiates euro collections. The payer can request a no-questions-asked refund within eight weeks of the debit; an unauthorised debit has a separate refund route up to 13 months. Core is not restricted solely to consumer payers. Model the reversal exposure separately from settlement timing.

Payee-initiated direct debit collections are outside PSD2 SCA scope; this is different from claiming an exemption for every activity around the mandate. Electronic setup and customer instructions can involve authentication requirements. Confirm the mandate channel and PSP process rather than asserting that every mandate setup requires the same SCA flow.

SDD B2B: The payer must be a business and the debtor PSP checks the mandate. There is no Core-style refund entitlement for an authorised transaction; returns for specified reasons can occur during the first three business days. This is not a blanket statement that every unauthorised or erroneous debit is immune from correction.

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

ACH (United States)

ACH is the US bank-payment mechanism. Authorisation and retention duties depend on the entry class, consumer or business account, and channel. Confirm the applicable SEC code, mandate evidence, account validation and revocation process with the originating bank or PSP rather than imposing one written-authorisation template on all ACH uses.

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 uses a three-working-day processing cycle. For operators with significant UK subscription volume, assess VRP as an alternative where the provider confirms enabled bank and use-case coverage.

Mandate portability risk

Mandate portability is scheme- and provider-specific. Confirm creditor identity, bulk-change processes, required notices and any need for new consent. A PSP move does not universally require every customer to re-authorize.

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 without the Core authorised-debit refund right, 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 moves money between accounts owned by the same person. Open Banking Limited confirms commercial VRP is live through UKPI as checked on 28 October 2026. Obtain the provider's current bank and eligible-use-case coverage rather than assuming universal merchant access or a future coverage deadline.

VRP avoids card interchange and card-scheme chargebacks, but is not cost-free or free of fraud, refund or reimbursement exposure. Compare provider and service charges, consent limits and contractual loss allocation. Payment execution and customer refund rights are different questions.

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.

AutoPay collection limits and additional-authentication requirements depend on category and current bank/scheme support. Obtain the applicable category limit, pre-debit notice, cancellation and retry rules from your provider before setting subscription tiers.

Do not infer recurring-payment market share from a provider or secondary-source count with an undefined denominator.

Confirm UPI AutoPay merchant eligibility, settlement account, supported category and aggregator access for your entity. A provider listing alone does not establish that an overseas merchant can onboard.

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.

The payer grants recurring consent through the supported banking flow. Confirm scheduling lead times, available balance checks, cancellation, retry behaviour and settlement confirmation with the provider; these are operational requirements rather than an interchangeable card-dunning configuration.

International merchant access depends on the actual provider contract and onboarding model; verify Pix Automático support rather than assuming every Pix provider offers recurring collections.

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

A wallet may provide card-credential capture, a billing agreement or an app-store billing service. Consent, permitted funding sources, credential lifecycle, disputes and refunds depend on both the wallet product and the PSP integration. Treat these as different operating models rather than one universal recurring rail.

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

For a supported Apple Pay or Google Pay card-recurring flow, confirm the credential your PSP retains, the consent needed for subsequent collections and how lifecycle updates are handled. For PayPal, confirm the billing agreement and eligible funding sources. A checkout wallet button alone does not establish recurring capability or remove failed-payment recovery work.

Comparison matrix

When to use which rail

SaaS (global, no local entities)

Start with card-on-file. Broad PSP coverage, 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. Confirm creditor eligibility and banking or PSP access; local incorporation is not a universal requirement for every provider model.

SaaS (local entity in India)

Layer UPI AutoPay where the category and amount are supported. Above the applicable automatic-debit limit, confirm the required authentication or offer another supported method. 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 confirmed provider eligibility.

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) the entity meets the provider's access requirements, 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

Incorrectly classifying card payments. Separate customer-initiated payments from off-session MITs; retain consent and the scheme references your PSP requires. Confirm authentication at setup rather than treating a generic MIT flag as removing all SCA obligations.

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.

Treating every wallet as the same recurring rail. Card-credential capture and PayPal-style billing agreements have different consent, funding and lifecycle rules. Confirm supported recurring behaviour and recovery paths for the actual wallet/PSP product.

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 access requirements. Check merchant-country, account, creditor identifier, sponsor or bureau requirements for the chosen rail and provider. Neither a bank-debit label nor a card or wallet integration establishes universal merchant eligibility.