What is recurring billing? Concept, history, and the reasons it stays hard

What recurring billing actually means

At its narrowest, recurring billing is an automated process that charges a stored payment method on a defined schedule for a defined amount, without requiring fresh customer authorisation each cycle. The customer authorises the recurring charge once (typically at signup); the merchant or merchant's billing system executes the charge from then on, indefinitely, until either the customer cancels, the underlying payment method becomes invalid, or the merchant ends the subscription.

That narrow definition hides a lot of operational complexity. The "defined amount" can be fixed (classic Netflix-style $X per month), variable (metered usage like cloud hosting), tiered (different prices at different consumption thresholds), or hybrid (a base fee plus metered add-ons). The "defined schedule" can be calendar-based (the 1st of every month) or anniversary-based (28 days from signup, perpetually). The "stored payment method" requires a payment vault that meets PCI compliance, regional regulatory requirements (PSD2 in Europe, RBI guidelines in India), and card-network mandates for recurring transactions.

• Recurring billing — the overall practice of repeated automated charges
• Subscription billing — recurring billing where the customer-merchant relationship is defined as an ongoing subscription (this is the most common application)
• Recurring payments — sometimes used synonymously with recurring billing, sometimes narrowly to mean the payment-processing side specifically (not the customer state or invoicing)
• Usage-based billing — recurring billing where the amount varies each cycle based on measured consumption
• Installment billing — recurring charges with a defined endpoint (e.g. 12 monthly payments for a single purchase) rather than indefinite continuation

Where recurring billing came from

Recurring billing predates software. The earliest large-scale recurring-billing operations were utility companies (gas, water, electricity), telephone services, and newspaper subscriptions — all of which billed at regular intervals against an account number rather than a card. The accounts were either billed directly (paper invoice mailed monthly, customer mailed a check) or via automated clearing house (ACH) bank-to-bank transfers. The card-network era began in earnest in the 1980s and 1990s as Visa and Mastercard added explicit support for recurring transactions, but the practice remained niche outside utility-type businesses until the late 2000s.

The modern recurring-billing era arrived with software-as-a-service. The 2000s SaaS boom (Salesforce, NetSuite, the early subscription productivity tools) created the demand for a billing layer that could handle monthly and annual SaaS subscriptions with prorated upgrades, downgrades, and trial-to-paid conversions. Stripe (founded 2010) and similar developer-first payment platforms made the underlying card-network mechanics accessible to any startup with an API key, which collapsed the time-to-launch a recurring-billing product from months to days.

The third wave was consumer subscription commerce — physical-product subscriptions like Birchbox (2010), Dollar Shave Club (2011), and Blue Apron (2012), followed by streaming media (Netflix's transition to streaming-first, Spotify's freemium model), and the modern subscribe-and-save pattern adopted across e-commerce. By the mid-2010s recurring billing had moved from utility-bill obscurity to mass-market consumer expectation. By the mid-2020s the bigger question wasn't whether to offer subscriptions but how to manage the operational complexity of running them well.

The dominant recurring-billing models

Recurring billing comes in several models that determine how the amount and schedule are set. Understanding the model matters because it drives most downstream operational complexity — proration logic, refund policy, dunning approach, and revenue-recognition accounting are all model-dependent.

• Flat-fee recurring — fixed amount, fixed schedule (classic Netflix, Spotify, simple SaaS). Easiest to implement, easiest for customers to understand, dominant in subscription commerce.
• Tiered subscription — flat fee with multiple tiers (Basic / Pro / Enterprise). Same mechanics as flat-fee but with upgrade/downgrade proration logic.
• Per-seat / per-user — flat fee multiplied by an account-level variable (number of users, number of locations). Common in B2B SaaS. Adds complexity around mid-cycle seat changes.
• Usage-based / metered — variable amount each cycle based on measured consumption (API calls, storage, bandwidth). Common in infrastructure SaaS. Requires usage-tracking integration and adds significant complexity to invoicing and dunning.
• Hybrid base + usage — a base recurring fee plus metered add-ons (AWS-style). Most flexible, most complex to operate.
• Installment plans — fixed amount, defined number of cycles, defined end (12-month device financing, layaway). Technically recurring billing but with terminal state.
• Annual prepaid — single upfront charge that grants 12 months of service. Recurring at the annual cadence, but operationally similar to one-time purchases with renewal logic.
• Pay-per-cycle (subscription commerce) — recurring physical-product delivery, charged each cycle (every 4 weeks, every month). Dominant model in Shopify subscription commerce.

Common terminology you need to know

Recurring billing has accumulated a vocabulary that practitioners use as shorthand. Understanding the terms helps you read documentation, vendor pitches, and operational reports without constant translation.

• MRR / ARR — Monthly / Annual Recurring Revenue. The total expected recurring revenue across all active subscriptions, normalised to a monthly or annual cadence.
• Churn — Subscriber loss. Subdivided into voluntary (customer cancelled) and involuntary (payment failure caused cancellation).
• LTV / CLV — Lifetime Value / Customer Lifetime Value. Total revenue expected from one subscriber over their entire tenure.
• Dunning — The process of communicating with customers about failed payments and trying to recover them. Originates from medieval English where to dun meant to make persistent demand for payment.
• Proration — Calculating partial-period charges when a subscription is upgraded, downgraded, paused, or cancelled mid-cycle.
• Vaulting / tokenisation — Securely storing a customer's payment method (or rather, a token that represents it) so future charges can run without re-entering card details.
• Anniversary billing — Billing on the same day-of-month as signup, perpetually (vs calendar billing on a fixed day-of-month for all customers).
• Trial — Initial period at reduced or zero cost before recurring billing begins. Trial-end conversion to paid is a key metric.
• ARPU — Average Revenue Per User. MRR divided by active subscribers.
• Net revenue retention — Revenue from existing cohort over time, including upgrades, downgrades, and churn. 100%+ NRR means existing customers grow faster than they leave.

Why recurring billing stays hard even with modern tooling

If recurring billing were just charging the same card every month, the entire category of billing-management software wouldn't exist. The difficulty comes from the cumulative weight of every edge case, every compliance requirement, and every state-management decision that needs to be made correctly the first time.

Payment failures are the single biggest source of complexity. Anywhere from 5% to 12% of recurring charges fail in a given month — expired cards, soft declines, fraud rules, network issues, AVS mismatches. Without active recovery, most of those failures convert directly into involuntary churn. With recovery, the system needs to handle smart retry timing, decline-code routing, network-level account updater integration, customer-facing dunning communication, tokenised update flows, and operational analytics. The recovery infrastructure alone is non-trivial software.

Customer state management is the second-biggest source. A subscription isn't just active or cancelled — it can be active, paused (with various pause durations), past-due (dunning in progress), suspended (retries exhausted but recoverable), trialing, cancel-pending (cancels at end of cycle), and cancelled (terminal). Each state has rules for which operations are valid (you can't pause a cancelled subscription, you can't add a seat to a suspended one), and the state machine has to handle concurrent changes from multiple sources (customer self-service, merchant admin, automated processes).

Tax compliance compounds further. Sales tax in the US is calculated at the renewal-date jurisdiction (which can differ from signup-date jurisdiction if the customer moved). EU VAT requires the customer's billing country, which can change mid-subscription. Digital goods vs physical goods have different tax rules in many jurisdictions. Subscriptions that span fiscal year boundaries create revenue-recognition complications under ASC 606 and IFRS 15. All of this has to work automatically every cycle for every subscriber.

The regulatory landscape practitioners now have to navigate

Recurring billing has attracted significant regulatory attention in the past decade as consumer-facing subscription growth highlighted disclosure and cancellation friction problems. The regulatory environment is now meaningfully more complex than it was in the early 2010s.

• California AB-390 (Automatic Renewal Law) — Requires clear disclosure of recurring price, frequency, and cancellation method before signup, in confirmation emails, and via a one-click cancel mechanism in the customer-facing portal. Has triggered multi-million-dollar settlements with major subscription brands.
• FTC Click-to-Cancel rule (US, 2024) — Federal-level requirement that cancellation must be at least as easy as signup. Cancellation flows that require phone calls when signup didn't are now prohibited.
• EU Consumer Rights Directive — Requires summary of subscription terms before checkout, 14-day cooling-off for first orders (with consumable-product exceptions), and clear disclosure of recurring terms.
• PSD2 / Strong Customer Authentication (EU) — Requires multi-factor authentication for many card transactions, including some recurring scenarios. Card networks have mandated specific recurring-transaction flags to handle this.
• RBI guidelines (India) — Requires explicit per-transaction authentication for recurring charges above certain thresholds, which disrupted the operational pattern of vault-once-charge-forever in the Indian market.
• PCI DSS — Payment Card Industry Data Security Standard. Mandatory compliance framework for anyone storing or transmitting card data; most modern billing implementations rely on tokenisation to limit scope.

Build vs buy: when does owning recurring billing pay off?

Every recurring-billing operator faces a build-vs-buy decision. Buy is the default for good reason — modern billing platforms (Stripe Billing, Recurly, Chargebee, Zuora, and category-specific tools like Shopify's native subscriptions) handle the bulk of operational complexity, are continuously updated for regulatory changes, and provide tested integrations with payment processors. Build is rarely worth it.

Build only makes sense when one of three conditions holds. First, when the pricing model is so unusual that no off-the-shelf platform supports it (rare — most exotic pricing fits within some commercial platform's capabilities). Second, when the integration with your core product is so deep that the billing logic has to live inside your domain code (some infrastructure SaaS, some marketplaces). Third, when scale makes percentage-of-revenue platform fees more expensive than headcount investment in a billing team (typically $50M+ ARR before this flips).

Common mistakes practitioners make at every stage

Some mistakes show up so reliably in recurring-billing operations that they are worth flagging explicitly.

1. Treating involuntary churn as voluntary churn — Many dashboards combine all cancellations into one number, hiding the fact that 30-50% of churn is actually payment failures with active recovery potential
2. Building the state machine implicitly — Subscription state spread across boolean flags (is_active, is_paused, is_past_due) drifts into inconsistency under concurrent writes. Use an explicit state field with documented valid transitions
3. Not separating subscription state from invoice state — A subscription can be active while its current invoice is past-due. Treating them as one field causes painful bugs
4. Ignoring tax on renewals — Sales tax and VAT at renewal date might differ from signup date. Recalculating on every renewal is the only safe approach
5. Hardcoding the dunning flow — Different decline codes warrant different communication. Treating all failures with the same email burns customer attention and reduces recovery rate
6. Not designing for pause as a first-class state — Pause is the highest-converting cancel-save tactic. Adding it later requires migration; designing for it from day one is much cheaper
7. Skipping retention until it is a fire — Retention features (pause, skip, swap, win-back) are far cheaper to add at launch than retrofitted at scale when the team is already firefighting

Where recurring billing is going

Several trends are reshaping recurring billing in 2025-2026. Network tokens (replacing card numbers with network-issued tokens that survive card reissuance) are becoming the default for stored payment methods, which over time will materially improve recovery rates by eliminating most expired-card failures. Real-time payment systems (FedNow in the US, instant SEPA in EU) are emerging as alternatives to card-based recurring billing for some use cases, particularly in B2B and high-value subscriptions where card-network fees are significant.

Regulatory pressure is increasing rather than decreasing. The FTC Click-to-Cancel rule (2024) federalized requirements that previously varied by state. EU and UK are tightening rules around dark patterns in subscription signup flows. India and Brazil are leading regional shifts toward stricter recurring-charge authentication. Practitioners building today should expect regulatory complexity to continue growing.

On the product side, the line between subscription and flexible recurring purchase is blurring. Customers want subscription benefits (discount, convenience) without subscription lock-in (perpetual commitment). The successful models offered easy skip, easy pause, transparent terms, and one-click cancel; the unsuccessful models leaned on friction. The pattern that emerged is that customer-flexibility predicts retention more reliably than discount depth.