Recurring Billing

What Is Recurring Billing?

Recurring billing is the practice of automatically charging a customer's stored payment method at predetermined intervals based on a prior agreement. When you subscribe to a streaming service, sign up for a SaaS product, or enroll in a gym membership, you authorize the merchant to pull funds from your account on a regular schedule: weekly, monthly, annually, or on a custom cycle.

The mechanism depends on stored credentials. During the initial signup, the customer provides their payment details (card number, bank account, or digital wallet), which are tokenized and vaulted securely. The merchant never sees the raw card number again. On each billing cycle, the merchant's system submits the token to the payment gateway, which resolves it to the real credentials and requests authorization from the issuing bank.

The global subscription economy was valued at over $500 billion in 2025 and is projected to exceed $1.5 trillion by 2033. Understanding recurring billing mechanics is essential for anyone building in subscription billing infrastructure.

How It Works

Recurring billing relies on a distinction that card networks enforce: the difference between cardholder-initiated transactions (CIT) and merchant-initiated transactions (MIT).

Initial Authorization (CIT)

The first transaction in any recurring relationship is a cardholder-initiated transaction. The customer is present, actively provides consent, and authenticates. This step establishes the mandate for all future charges. Card networks require the merchant to collect explicit agreement specifying:

• How payment details will be stored
• The purpose and frequency of charges
• How amounts are determined (fixed or variable)
• Cancellation policies and procedures

The initial CIT generates a Transaction ID that links all subsequent charges back to this original authorization. In the EU, this first transaction must pass 3D Secure authentication under PSD2 Strong Customer Authentication rules.

Scheduled Charges (MIT)

Every subsequent charge is a merchant-initiated transaction. The customer is not present and does not need to act. The billing system runs on a schedule:

1. The billing engine triggers a charge based on the subscription cycle
2. The system retrieves the stored token from the vault
3. The payment processor submits an authorization request referencing the original CIT Transaction ID
4. The acquirer routes the request through the card network to the issuing bank
5. The issuer approves or declines based on available funds, fraud rules, and account status
6. On approval, the charge enters the clearing and settlement cycle

Card networks classify MITs into subtypes: recurring (fixed schedule, like a monthly subscription), installment (predetermined number of payments, like a 12-month financing plan), and unscheduled credential-on-file (variable timing, like auto-top-ups when a balance drops below a threshold).

Keeping Credentials Current

Roughly one-third of payment cards are reissued each year due to expiration, loss, or fraud. When stored credentials become invalid, recurring charges fail silently. Two services address this:

• Account updater services: Visa Account Updater (VAU) and Mastercard Automatic Billing Updater (ABU) synchronize updated card details between issuers and merchants. VAU operates on a pull model where merchants request updates; ABU uses a push model where Mastercard proactively notifies merchants of changes.
• Network tokenization: card networks issue domain-restricted tokens that persist across card reissuances. When a card is replaced, the network updates its token vault automatically. The merchant's stored token remains valid without any action required. Network tokens also improve authorization rates by 2 to 3 percentage points and reduce fraud by up to 50% compared to raw card numbers.

Most subscription businesses deploy both account updaters and network tokenization together for maximum coverage, since not all cards support network tokens.

Failed Payments and Dunning

Payment failures are the largest operational challenge in recurring billing. The average failure rate across subscription businesses is 7.9%, and failed payments account for roughly half of all involuntary churn: customers who leave not because they chose to, but because their payment silently stopped working.

Decline Categories

Not all declines are equal. The response matters for determining what happens next:

• Soft declines (70 to 90% of failures): temporary issues like insufficient funds, processor timeouts, or generic risk flags. These benefit from retries.
• Hard declines (10 to 30%): permanent failures like stolen cards, closed accounts, or fraud blocks. Retrying these wastes resources and triggers network penalties.

Retry Logic

Smart retry strategies can recover 50 to 65% of failed payments, compared to only 30% for static fixed-schedule retries. Effective approaches include:

• Timing optimization: retrying 24 hours after the initial failure rather than immediately improves recovery rates, especially for insufficient-funds declines that may resolve after payday
• Decline-aware routing: different retry strategies for different decline codes rather than a blanket retry schedule
• Alternate processor failover: routing through a different acquiring processor can recover an additional 2 to 5% of failures
• Network token refresh: retrying with updated network token credentials that reflect recent card reissuances

Card networks impose strict retry limits. Visa allows a maximum of 15 attempts within 30 days for soft declines. Hard declines must not be retried at all. Exceeding these limits triggers financial penalties under Visa's Acquirer Monitoring Program and Mastercard's Excessive Decline Rate program.

Dunning Management

Dunning combines automated retries with customer communication: emails, SMS, and in-app notifications urging customers to update their payment method. Comprehensive multi-channel dunning can recover 70 to 80% of failed payments and reduce involuntary churn by up to 34% compared to email-only approaches.

Regulatory Requirements

PSD2 and Strong Customer Authentication

In the European Economic Area, PSD2 mandates Strong Customer Authentication (SCA) for electronic payments: two of three factors from knowledge (password), possession (phone), and inherence (biometric). For recurring billing:

• The initial payment requires full SCA, typically via 3D Secure
• Subsequent fixed-amount recurring charges to the same merchant are exempt when processed as MITs
• Variable-amount subscriptions fall outside SCA scope when properly flagged as MITs, provided the first payment was authenticated and explicit consent was obtained
• Exemption flags are requests, not guarantees: the issuing bank makes the final decision based on its own risk assessment

ACH and Regulation E (United States)

For ACH-based recurring debits, Regulation E and Nacha Operating Rules require merchants to provide 7 to 10 days advance notice before any change in timing or amount. Customers can revoke authorization at any time, and merchants must retain proof of authorization for two years after the last transaction.

Use Cases

• SaaS subscriptions: monthly or annual software licenses with fixed or usage-based pricing tiers
• Media streaming: entertainment services charging a flat monthly fee with automatic renewal
• Installment payments: buy now, pay later services splitting a purchase into scheduled payments
• Insurance premiums: monthly or quarterly policy payments debited from stored credentials
• Membership organizations: gyms, professional associations, and clubs collecting dues on a recurring schedule
• Utility billing: metered services like cloud computing or telecommunications billing based on usage each cycle

Bitcoin and Recurring Payments

Traditional recurring billing depends on the merchant's ability to pull funds from a stored credential. Bitcoin's architecture inverts this: every transaction is a push payment that requires the holder of the private key to actively sign and broadcast. There are no stored credentials for a merchant to charge, no account numbers to reference, and no protocol-level mechanism for third-party withdrawals.

The UTXO model compounds this: there is no persistent account balance that a billing system can draw from. Each payment is a discrete transaction consuming specific unspent outputs, requiring explicit authorization every time.

BOLT-12 Recurrence

BOLT-12 offers introduced a draft specification for recurring payments on the Lightning Network. The original proposal included a recurrence field using TLV (Type-Length-Value) encoding:

offer_recurrence:
  time_unit: 2       # 0=seconds, 1=days, 2=months, 3=years
  period: 1          # every 1 month

offer_recurrence_paywindow:
  seconds_before: 86400   # accept payment 1 day early
  seconds_after: 86400    # accept payment 1 day late

offer_recurrence_limit: 12  # 12 total payments

Under this design, a customer's wallet would store the offer, wake up at each interval, fetch a fresh invoice from the merchant via onion messages, and pay it automatically. Each invoice request would include an incrementing recurrence_counter to track the payment sequence.

The recurrence fields were deferred from the initial BOLT-12 specification due to implementation complexity: wallets would need new scheduling logic, offline handling, and failure recovery. The current spec lists recurrence under "possible future extensions." Some experimental support exists in Core Lightning, but it is not part of the ratified standard.

For now, recurring Bitcoin payments rely on custodial solutions or services that send payment reminders to the customer at each interval. Layer 2 protocols like Spark could enable new approaches to subscription billing by combining fast, low-cost transfers with programmable payment logic, though native recurring pull functionality remains a protocol-level challenge.

Risks and Considerations

Involuntary Churn

Failed payments account for 25 to 40% of total subscriber churn across industries, reaching as high as 68% in subscription box businesses. Without robust retry logic and dunning, a subscription business can lose 9% or more of its revenue to payment failures alone.

Chargeback Exposure

Recurring charges carry inherent chargeback risk. Customers who forget about a subscription, fail to cancel before renewal, or dispute a price increase may file chargebacks rather than contact the merchant. Since recurring charges are typically card-not-present transactions, the merchant bears the fraud liability burden.

Regulatory Compliance Complexity

Operating across jurisdictions means navigating overlapping regulations: PSD2 SCA in Europe, Regulation E in the US, and emerging frameworks elsewhere. Each has different requirements for consent collection, notification timing, and cancellation rights. Mishandling these requirements can result in forced refunds, fines, or loss of processing privileges.

Network Penalty Programs

Excessive retry attempts or high decline rates trigger monitoring programs from card networks. Visa's Acquirer Monitoring Program (VAMP), launched in April 2025, imposes financial penalties starting at $0.10 per excessive re-attempt. Merchants with persistently high decline rates risk account restrictions or termination from their acquirer.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.