# Recurring Payments: The Complete Guide for SaaS Founders in 2026 > Everything SaaS founders need to know about recurring payments - from payment methods and retry logic to billing models and compliance. - **Author**: Ayush Agarwal - **Published**: 2026-04-04 - **Category**: Payments, SaaS, Billing - **URL**: https://dodopayments.com/blogs/recurring-payments-guide --- Recurring payments are the backbone of subscription businesses. Get them right and you have predictable, compounding revenue. Get them wrong and you hemorrhage customers silently through failed charges, confused users, and compliance gaps you didn't know existed. This guide covers everything a SaaS founder needs to understand: how recurring payments work technically, which payment methods actually support them, how retry logic and dunning protect your revenue, and what compliance looks like in 2026. ## What Are Recurring Payments? Recurring payments are automated charges that happen at a fixed or variable interval without the customer having to re-enter their payment details each time. The customer authorizes a charge once, and the merchant stores the payment credentials (or a token representing them) to initiate future debits. The core mechanics involve three things: - **Initial authorization**: Customer provides payment details and explicitly agrees to future charges - **Credential storage**: Payment details are stored securely, usually as a network token by a payment processor - **Merchant-initiated transactions (MITs)**: Subsequent charges that the merchant triggers without real-time customer input This is fundamentally different from a customer returning to a store and paying each time. The burden of initiating the transaction shifts to the merchant, which creates both opportunity (automation, predictability) and responsibility (compliance, customer trust). ## How Recurring Payments Work Technically Understanding the technical flow helps you build more resilient billing systems and debug failures faster. ```mermaid sequenceDiagram participant C as Customer participant M as Merchant / SaaS App participant G as Payment Gateway participant N as Card Network participant I as Issuing Bank C->>M: Enter card details + accept terms M->>G: Tokenize card credentials G->>N: Request network token N-->>G: Network token issued G-->>M: Return token + setup confirmation Note over M: Billing date arrives M->>G: Initiate MIT with stored token G->>N: Route transaction N->>I: Authorization request (flagged as recurring) I-->>N: Auth response (approve / decline) N-->>G: Auth result G-->>M: Webhook: payment.succeeded or payment.failed M->>C: Receipt or failure notification ``` A few things worth noting in this flow: - The card network issues a **network token** that replaces the raw card number. When a customer gets a new card, issuers can update the network token automatically, which means your stored credentials stay valid even after physical card replacement. - MIT transactions carry a specific flag in the authorization request so that the issuing bank can apply the right rules (no 3DS friction, but also higher scrutiny on unusual amounts). - Your system learns the outcome via [webhooks](https://docs.dodopayments.com/developer-resources/webhooks), not by polling. Building reliable webhook handling is non-negotiable for a production billing system. > The biggest mistake I see SaaS teams make with recurring billing is treating webhook handling as an afterthought. Your retry logic, dunning emails, and access control all depend on processing payment events reliably and idempotently - get that wrong and you leak revenue silently for months. > > - Ayush Agarwal, Co-founder & CPTO at Dodo Payments ## Payment Methods That Support Recurring Payments Not all payment methods support merchant-initiated recurring charges. Here is a breakdown of what works and how. ### Credit and Debit Cards Cards (Visa, Mastercard, Amex) are the most widely used method for recurring billing globally. The rails are mature, network tokenization is widely available, and retry logic is well understood. Cards support three types of recurring transactions: - **Fixed recurring**: Same amount, same interval (classic subscription) - **Variable recurring**: Amount changes each cycle (usage-based billing, metered plans) - **Installment**: Fixed number of charges for a one-time purchase spread over time Card coverage drops significantly outside North America and Western Europe, which is worth planning for if you are expanding globally. See [best payment methods for SaaS](https://dodopayments.com/blogs/best-payment-methods-for-saas) for a fuller breakdown by region. ### ACH (US Bank Transfers) ACH debits let you pull funds directly from a US customer's bank account. They are cheaper than cards (typically a flat fee rather than a percentage) and have virtually no expiry problem since bank accounts rarely close unexpectedly. The tradeoffs: ACH has a 2-3 business day settlement delay, and return rates can be high if you debit before customers expect it. ACH mandates (the authorization record) must be kept for a minimum of two years. Nacha rules require specific language in your authorization agreement. ACH works well for high-value B2B subscriptions where card fees add up meaningfully. ### SEPA Direct Debit (Europe) SEPA Direct Debit covers the eurozone and several other European countries. Like ACH, it pulls directly from bank accounts and carries lower fees than cards. SEPA mandates have strict requirements: a unique mandate reference, specific pre-notification periods (minimum 14 calendar days before the first debit, unless you agree shorter notice with the customer), and a defined dispute window where customers can reclaim funds. For SaaS companies with European customers, SEPA is worth supporting alongside cards. It is especially strong in Germany and the Netherlands where card penetration for online payments is lower. ### UPI Autopay (India) India's UPI Autopay enables recurring debits directly from bank accounts via the Unified Payments Interface. It is the correct way to handle recurring billing for Indian customers, and its adoption has grown substantially since the Reserve Bank of India mandated additional authentication requirements that made card-based recurring harder. [UPI autopay](https://dodopayments.com/blogs/upi-autopay) supports both fixed and variable recurring mandates. Variable mandates require notifying the customer before each debit above the base amount. The notification window is 24 hours for variable amounts. For any SaaS company with meaningful India revenue, UPI Autopay is not optional. The card-based recurring experience in India has significant friction due to RBI mandates on additional factor authentication. > When we talk to SaaS founders expanding into India, Brazil, or Southeast Asia, the number one revenue blocker is not product-market fit - it is payment method coverage. If your billing stack only supports cards, you are invisible to a huge portion of the global market that pays differently. > > - Rishabh Goel, Co-founder & CEO at Dodo Payments ### Direct Debit (UK, Australia, and Others) Bacs Direct Debit in the UK and BECS in Australia follow similar patterns to SEPA: bank-to-bank pulls with mandate requirements and dispute windows. They are popular for subscription businesses in their respective markets and should be considered for region-specific expansion. ## Billing Models for Recurring Revenue How you structure the recurring charge matters as much as the mechanics of collecting it. Different models suit different products. For a deeper comparison, see [subscription pricing models](https://dodopayments.com/blogs/subscription-pricing-models). ### Flat Rate (Fixed Subscription) One price, one set of features, charged every billing cycle. Simple to understand, easy to build, and straightforward to communicate. The limitation is that it leaves money on the table from power users and creates friction with small users who feel they are overpaying. Good for: horizontal SaaS tools where usage is relatively uniform across your customer base. ### Tiered Pricing Multiple plans with increasing feature sets or usage limits. Customers self-select based on their needs. Revenue scales as customers upgrade. Tiered pricing requires careful threshold design. Tiers that are too close together create upgrade confusion. Tiers too far apart create a cliff where customers with moderate needs overpay. ### Usage-Based Billing Customers pay for what they consume: API calls, active seats, data processed, messages sent. Revenue scales naturally with customer success, which aligns incentives well. The billing complexity increases significantly. You need metering infrastructure to track usage accurately, and your billing cycle needs to handle variable amounts rather than fixed charges. [Usage-based billing](https://dodopayments.com/blogs/usage-based-billing-saas) has its own set of engineering and product considerations worth reviewing separately. ### Hybrid Models Most mature SaaS businesses end up combining models: a base platform fee plus usage overages, or a seat-based charge with a usage allowance. Hybrid models optimize for revenue across different customer segments while keeping the base cost predictable for customers. [Billing automation](https://dodopayments.com/blogs/billing-automation-saas) becomes increasingly important as you add model complexity. Manually tracking hybrid charges is error-prone and does not scale. ## Retry Logic and Dunning A recurring payment failing is not the end of the story. How you handle that failure determines how much revenue you recover versus how much becomes [involuntary churn](https://dodopayments.com/blogs/involuntary-churn-failed-payments). ### Why Payments Fail Card failures split into two categories: **Hard declines**: The issuer rejects the transaction definitively. Examples include card reported stolen, account closed, or card number invalid. Retrying a hard decline will not help and may flag your merchant account. **Soft declines**: Temporary failures like insufficient funds, card velocity limits hit, or a temporary hold. These are worth retrying because the underlying cause may resolve on its own. Decline codes from the card network tell you which category you are dealing with. Your payment processor surfaces these as standardized response codes. Treating all declines the same way wastes retries on hard declines and misses recovery opportunities on soft ones. ### Smart Retry Strategy A naive retry strategy retries at fixed intervals: day 1, day 3, day 7. A smart retry strategy considers: - **Decline code**: Only retry soft declines - **Time of day**: Authorization rates are higher at certain times when banks' fraud models are less aggressive - **Day of week**: Midweek tends to have better authorization rates than weekends - **Customer's typical payment pattern**: If they usually pay successfully on salary day, retry around that time Retry windows typically run for 7-14 days before the subscription is flagged for cancellation review. ### Dunning Communication Parallel to retries, your [dunning management](https://dodopayments.com/blogs/dunning-management) system communicates with the customer: - **Pre-dunning**: Warn customers before their card expires (card expiry is visible from the stored credentials) - **Failed payment notification**: Let them know immediately after the first failure, with a direct link to update payment details - **Follow-up sequence**: Spaced reminders that increase in urgency without becoming aggressive - **Final notice**: Before cancellation, give the customer one clear chance to save their subscription Tone matters. Dunning emails that sound accusatory damage the customer relationship even if the failure was a simple card expiry. Keep the communication factual and make updating payment details as frictionless as possible. The goal of dunning is to resolve the payment issue with minimal customer effort, not to shame someone into paying. A customer who updates their card smoothly stays. A customer who feels hassled may cancel even after payment succeeds. ## PCI DSS Compliance PCI DSS (Payment Card Industry Data Security Standard) governs how you handle cardholder data. For most SaaS companies, the right approach is to never touch raw card data at all. If you use a payment processor and their hosted payment fields or SDKs, the card data flows directly from the customer's browser to the processor. Your servers never see raw card numbers. This keeps you in the lowest PCI compliance tier (SAQ-A) where a self-assessment questionnaire is all that is required annually. Key practices for maintaining PCI compliance in a recurring billing setup: - Never log raw card numbers, CVVs, or full magnetic stripe data anywhere - Use network tokens or processor-issued tokens for storing payment credentials, not raw PANs - Scope your PCI assessment carefully: only systems that touch or could touch cardholder data are in scope - Conduct annual penetration testing on in-scope systems - Maintain clear documentation of your data flow [Dodo Payments](https://dodopayments.com) handles PCI compliance at the infrastructure level, which means you inherit the compliance posture without building it yourself. ## Strong Customer Authentication and 3DS for Recurring SCA (Strong Customer Authentication) under PSD2 in Europe requires two-factor authentication for card payments. This creates a tension with recurring billing: you cannot prompt a customer for 2FA on every automated charge. The way this works in practice: - The **first transaction** in a recurring series must go through full [3D Secure](https://dodopayments.com/blogs/3d-secure-3ds-payment-authentication) authentication where the customer completes the 2FA challenge - The customer exempts the merchant for subsequent MIT charges by completing authentication once - The issuing bank can still step-up to SCA on a subsequent MIT if their fraud model flags the transaction, but this is the exception not the rule For recurring payments set up with SCA, you need to pass the correct MIT flags and exemption indicators in the authorization request. Getting this wrong results in either unnecessary 3DS prompts that kill conversion, or declined transactions flagged as SCA non-compliant. Outside Europe, 3DS is optional for recurring but can improve authorization rates in markets where issuers trust authenticated credentials more. The right approach depends on where your customers are and what your authorization data shows. ## Setting Up Recurring Payments If you are building subscription billing from scratch, here is the sequence that matters: **1. Choose your payment infrastructure** You need a processor that supports: network tokenization, MIT transaction types, webhook-based outcome notification, and local payment methods for your target markets. [Subscription management](https://docs.dodopayments.com/features/subscription) documentation is a good starting point for understanding what the API needs to handle. **2. Design your authorization flow** The first checkout must collect the right authorization language. Customers need to explicitly agree to future charges, the billing interval, and how they will be notified before charges. This language is not just UX: it is a legal requirement for ACH, SEPA, and UPI mandates and a strong defense against card chargebacks. **3. Build webhook handling before going live** Payment outcomes arrive via webhooks, not synchronous API responses. Your webhook handler needs to: verify the signature, process the event idempotently (the same event may arrive more than once), and trigger the correct downstream action (provision access, send receipt, queue dunning if failed). **4. Implement retry and dunning logic** Decide your retry schedule by decline code category, your dunning communication sequence, and your cancellation threshold. This should be configurable without code deploys. **5. Test failure scenarios explicitly** Most test suites cover the happy path. For billing, the failure path is where the money is. Test hard declines, soft declines, partial retries, dunning sequences, and card update flows before going to production. If the complexity of building this from scratch sounds daunting, or you are expanding to new markets and need local payment method support, [Dodo Payments pricing](https://dodopayments.com/pricing) is worth reviewing as a managed alternative. ## Alternatives and Complements to Recurring Payments Recurring billing is not always the right model. Some customers prefer paying annually upfront. Some business models work better with invoicing. And some markets have better-fitting payment mechanisms. [Recurring billing alternatives](https://dodopayments.com/blogs/recurring-billing-alternatives) covers scenarios where a pure recurring model creates friction that a different approach would resolve. ## FAQ ### What is the difference between a subscription and a recurring payment? A subscription is a business model where customers get ongoing access to a product or service in exchange for periodic payments. A recurring payment is the technical mechanism that collects those payments automatically. Not all recurring payments are subscriptions: installment plans and automatic top-ups are recurring payments without being subscriptions in the traditional sense. ### How do I handle recurring payments when a customer's card expires? There are two mechanisms that help here. First, network tokenization: when a card is reissued with a new expiry (which is common when a card expires normally), the card network updates the token automatically and your stored credentials stay valid without any action on your part. Second, account updater services: for cards not covered by network token updates, many processors offer account updater which queries the networks for updated card details on a regular cycle. If neither mechanism catches the update in time, your dunning system should detect the expiry from the stored card data and prompt the customer to update before the next billing date. ### Do I need 3DS authentication for every recurring charge? No. Under PSD2 in Europe, you need SCA (typically via 3DS) for the first transaction in a recurring series. Subsequent merchant-initiated transactions are exempt from SCA as long as you set up the initial authentication correctly and pass the right exemption flags in each subsequent charge. Outside Europe, 3DS on recurring transactions is optional. Some merchants apply it selectively based on issuer feedback or risk signals. ### What is the best retry schedule for failed recurring payments? There is no universal best schedule, but a practical starting point is: retry on day 1 (same day as failure, different time if possible), day 3, day 7, and day 14 for soft declines only. Hard declines should not be retried. More sophisticated systems use machine learning to predict the optimal retry time based on decline code, customer history, and issuer patterns. The window for retries before triggering dunning communication is typically 2-5 days after the first failure, with cancellation evaluated after 14-21 days if the charge cannot be recovered. ### How do recurring payments differ across ACH, SEPA, and UPI Autopay? All three are bank-to-bank recurring debit mechanisms, but the details differ meaningfully. ACH (US) has a 2-3 day settlement delay, no pre-notification requirement beyond the mandate terms, and returns processed within 5 business days. SEPA (Europe) requires a 14-day pre-notification period before the first debit (shorter by agreement), has standardized mandate references, and customers can reclaim unauthorized debits for up to 13 months. UPI Autopay (India) supports both fixed and variable mandates, requires 24-hour pre-debit notification for variable amounts above the base, and settlement is near-instant. Each has its own mandate storage and dispute resolution requirements that your billing system needs to account for. --- - [More Payments articles](https://dodopayments.com/blogs/category/payments) - [All articles](https://dodopayments.com/blogs)