Recurring Billing for SaaS: How It Works

Recurring billing is the engine behind every SaaS subscription. It charges your customers automatically, on schedule, without you lifting a finger. Until it doesn’t — and a failed payment silently kills your MRR.

Recurring Billing = Automated charge at fixed intervals
                    (monthly, quarterly, or annually)

Failed Payment Rate = Failed Charges / Total Charges × 100

Understanding the billing lifecycle isn’t optional. It’s the difference between clean revenue data and a dashboard full of noise.

What Is Recurring Billing?

Recurring billing is the automatic collection of payments from customers at regular intervals — typically monthly or annually — based on a subscription agreement. The customer authorizes the charge once, and the billing system handles every subsequent payment.

This is what separates SaaS from one-time software sales. Instead of selling a license for €500, you charge €49/month indefinitely. The business model depends entirely on the reliability of that automated billing cycle.

Subscription billing comes in a few flavors: fixed-amount (same charge every cycle), usage-based (metered at the end of the period), tiered (price changes with plan level), and hybrid (base fee plus usage). Most bootstrapped SaaS products start with fixed monthly billing and add annual plans later.

The critical point: recurring billing is infrastructure, not just a payment. It involves invoice generation, payment method validation, tax calculation, proration for plan changes, and retry logic for failures. Get any of these wrong and your revenue numbers become unreliable.

How Stripe Handles Recurring Billing

Stripe is the default billing system for most indie SaaS founders, so it’s worth understanding exactly what happens under the hood.

When a customer subscribes, Stripe creates a Subscription object tied to a Customer and a Price. At the start of each billing cycle, Stripe automatically:

Generates an Invoice with line items, taxes, and any prorated amounts
Finalizes the invoice (makes it immutable)
Attempts to charge the customer’s default payment method
Records the result as a Charge (succeeded, failed, or pending)
Updates the Subscription status accordingly

If the charge succeeds, the invoice is marked paid and the subscription continues. If it fails, Stripe enters its retry logic — called Smart Retries — which uses machine learning to pick optimal retry times over the next few weeks.

The entire cycle runs without any action from you. That’s the beauty of automated billing in SaaS. But it also means problems can accumulate silently if you’re not watching the right signals.

The Billing Lifecycle

Every recurring payment follows a predictable path. Knowing each stage helps you spot where things break.

Stage	What Happens	Stripe Status
Invoice created	Stripe generates the invoice for the upcoming period	`draft` → `open`
Payment attempted	Charge sent to customer’s card or bank	`open`
Payment succeeds	Invoice marked paid, subscription renews	`paid`
Payment fails	First attempt fails, retry schedule begins	`open` (past_due on subscription)
Retries exhausted	All retry attempts failed	`uncollectible`
Subscription canceled	No payment recovered, subscription ends	`canceled`

For annual billing, the stakes are higher. A failed €588 annual charge (€49 × 12) is twelve months of revenue at risk in a single transaction. That’s why many founders offer both monthly and annual plans but keep a close eye on annual renewal dates. Annual billing also creates deferred revenue complexities — you collect the cash upfront but recognize it over 12 months.

What Can Go Wrong: Recurring Payment Failure Modes

Failed payments are the silent killer of SaaS revenue. They don’t show up as angry support tickets. Customers often don’t even notice. Your MRR just quietly drops.

Expired cards. The most common failure. Credit cards expire every 3–4 years. If a customer signed up 3 years ago and never updated their card, the next charge will fail. Visa and Mastercard’s Account Updater service handles some of these automatically, but not all.

Insufficient funds. The card is valid but there’s no money. This happens more often with debit cards and in certain markets. Stripe’s Smart Retries are specifically designed to retry these at times when the account is more likely to have funds (like after payday patterns).

Bank declines. The issuing bank rejects the charge for fraud risk, velocity limits, or regional restrictions. International customers trigger these more often. A customer in Brazil paying with a card issued in Germany will sometimes get declined for geographic mismatch.

3D Secure failures. European Strong Customer Authentication (SCA) requires two-factor authentication on many charges. If the customer doesn’t complete the 3DS challenge within the timeout window, the payment fails. This is particularly painful for recurring billing because the customer isn’t actively on your site when the charge happens.

Network errors. Temporary issues between Stripe, the card network, and the issuing bank. These usually succeed on retry.

The average involuntary churn rate from failed payments is 2–4% of MRR per month for SaaS businesses (Baremetrics, 2024). That’s revenue walking out the door with no decision from the customer. Understanding involuntary churn from billing failures is essential for any founder tracking retention.

Dunning: Recovering Failed Payments

Dunning is the process of recovering failed recurring payments before the subscription cancels. It’s part automated retry, part customer communication.

Stripe’s built-in dunning retries failed charges up to 4 times over approximately 3 weeks (configurable in your Stripe dashboard under Billing settings). Smart Retries optimizes the timing using payment success probability models.

Email notifications are your best tool. Stripe can send automated emails when a payment fails, before retries exhaust, and before the subscription cancels. These emails should be simple and direct: “Your payment failed. Update your card here.” Include a direct link to your billing portal.

In-app banners work even better for active users. If a customer logs in while their payment is past due, show a prominent banner with a one-click path to update their payment method. This converts at a higher rate than email because the customer is already engaged.

Recovery rates vary, but well-configured dunning recovers 40–70% of initially failed payments (Stripe Revenue Recovery Report, 2024). The biggest factor is how quickly you notify the customer. Charges that get recovered in the first retry attempt have a 65% success rate. By the fourth attempt, it drops below 15%.

The math is straightforward. If you have €30,000 MRR and 3% fails each month, that’s €900 at risk. Recovering 60% through dunning saves €540/month — €6,480/year. For a bootstrapped SaaS, that’s meaningful.

How Billing Affects MRR Accuracy

Here’s where recurring billing connects directly to your metrics. Every billing event — successful charge, failed payment, retry, refund — changes your MRR. If your analytics tool doesn’t handle these events correctly, your MRR number is wrong.

Past-due subscriptions are the biggest source of MRR noise. When a payment fails, should that customer’s subscription still count toward MRR? Technically the subscription is active (Stripe keeps it in past_due status during retries). But the revenue hasn’t been collected.

Some analytics tools count past-due subscriptions as active MRR. Others exclude them immediately. The “right” answer depends on your recovery rate, but the honest approach is to flag past-due revenue separately so you can see how billing affects MRR with full transparency.

Proration creates another accuracy problem. When a customer upgrades mid-cycle, Stripe generates a prorated invoice. If your MRR calculation doesn’t handle proration correctly, you’ll see a spike in the upgrade month and a dip in the next month — even though the customer’s ongoing MRR increased smoothly.

Annual-to-monthly normalization is critical. A €588 annual payment should show as €49/month in your MRR, not as a €588 spike in January and zero for the next 11 months. Any recurring billing software worth using handles this normalization, but check yours. Wrong MRR math leads to wrong decisions.

NoNoiseMetrics separates involuntary churn (failed payments) from voluntary churn (cancellations) automatically when you connect Stripe. You see exactly how much revenue is at risk from billing failures versus customers who actively chose to leave.

FAQ

What is recurring billing?

Recurring billing is the automatic collection of subscription payments from customers at regular intervals. The customer authorizes the payment once — usually when they first subscribe — and the billing system charges their payment method every month, quarter, or year without requiring any manual action from either party.

What happens when a recurring payment fails?

When a recurring payment fails, Stripe enters a retry cycle called Smart Retries. It attempts to charge the card again at optimal times over approximately three weeks. During this period, the subscription moves to “past_due” status. If all retries fail, the subscription is either canceled or marked unpaid depending on your Stripe configuration.

How does recurring billing affect MRR?

Every billing event directly impacts your MRR calculation. Failed payments can create phantom MRR if past-due subscriptions are still counted as active. Prorated charges from mid-cycle upgrades can cause artificial spikes. Annual payments must be normalized to monthly amounts. Clean MRR requires your analytics tool to handle all of these billing edge cases correctly.

What is a good failed payment recovery rate?

A well-configured dunning system recovers 40–70% of initially failed payments according to Stripe’s 2024 Revenue Recovery Report. The key factors are retry timing, customer notification speed, and how easy you make it for customers to update their payment method. Most recovery happens in the first retry attempt.

What is the difference between voluntary and involuntary churn?

Voluntary churn is when a customer actively cancels their subscription. Involuntary churn is when a subscription ends because of a billing failure — the customer never chose to leave, their payment just stopped working. Involuntary churn typically accounts for 20–40% of total churn in SaaS businesses, which is why dunning and payment recovery matter so much.

NoNoiseMetrics separates involuntary churn from voluntary churn automatically — so you know exactly where to act. Free up to €10k MRR →

Next: How failed payments create fake growth in your MRR → What Is MRR — The Clean Version

Free Tool
Try the MRR Dashboard Template →
Interactive template — no signup required.

Sources: Stripe Revenue Recovery Report 2024, Baremetrics SaaS Benchmarks 2024, Stripe Billing Documentation 2025.