Chapter 1. Billing architecture: plans, trials, proration.

A mature subscription system separates two engines. The billing engine decides what to bill, when, and how much (catalog, cycles, trials, proration, credit notes, taxes). The payment engine collects the money (stored credentials, authorizations, retries). Mixing the two produces fragile architectures, where a simple promotional discount can break the payment collection chain.

📚

Catalog and plans

Products, prices, currencies, billing intervals, and discounts make up a versioned catalog, because a price change must never rewrite the history of existing subscribers (grandfathering).

🔄

State machine

Every subscription moves through the lifecycle trialing → active → past_due → canceled/churned, and each transition is a timestamped event that serves as the source of truth for metrics.

🧾

Fees

Invoice generation, proration, credit notes, taxes (VAT OSS in Europe), and sequential numbering that meets accounting requirements.

📣

Events and webhooks

Payment succeeded or failed, trial ending, card expiring. Billing publishes the events; the CRM and dunning consume them.

Subscription lifecycle

Customer

Signs up with a free trial

Authenticated CIT (SCA): the payment mandate is set up

Billing engine

Converts the trial into a paid subscription

First invoice on day 14, amount notified to the customer before the charge

Payment engine

Charges each cycle as an MIT

Renewals with no customer action

Billing engine

Handles upgrades and proration

Mid-cycle plan change, credit note or additional invoice

Dunning

Responds to every failed charge

Retries + customer messaging, before the account is churned

Model	Example	Billing complexity
Flat rate	€9.99/month	Low: fixed amount, simple proration
Per seat	€12/user/month	Medium: proration on every seat added or removed
Usage-based	€0.04 per API call	High: meter aggregation, billing in arrears
Hybrid	Flat rate + overage	High: two billing logics on one invoice

Pricing models and what they mean for billing

🔑

The proration formula

For a mid-cycle upgrade, the formula is amount due = (days remaining ÷ days in the cycle) × (new plan price − old plan price). From there, two schools of thought compete: bill the difference immediately, or add it to the next invoice. What matters is consistency. The customer must be notified of the exact amount before any charge.

Subscription object (simplified data model)

{
  "subscriptionId": "sub_9f27",
  "status": "active",
  "plan": { "id": "pro-monthly", "amount": 2900, "currency": "EUR", "interval": "month" },
  "trialEnd": "2026-06-15",
  "currentPeriod": { "start": "2026-07-01", "end": "2026-07-31" },
  "paymentMethod": { "type": "networkToken", "expiry": "2028-11" },
  "mandate": { "citAuthenticatedAt": "2026-06-01", "initialSchemeTxId": "MCC4XR..." },
  "pendingProration": { "amount": 1450, "reason": "upgrade-pro-to-max" }
}

≈ $1.5T

estimated size of the subscription economy in 2025

UBS

3.7×

faster growth for subscription companies than for the S&P 500 over the 11 years from 2012 to 2022

Zuora, Subscription Economy Index

🎯 Quick question

A customer upgrades from the Pro plan (€29/month) to the Max plan (€49/month) mid-cycle (15 days left out of 30). How much proration do you charge?

Chapter 2. CIT, MIT, and SCA compliance for recurring payments.

Visa and Mastercard's stored credential framework distinguishes two types of transaction. In a CIT (customer-initiated transaction), the customer is present and takes action. In an MIT (merchant-initiated transaction), the merchant acts alone under a prior agreement. SCA compliance for recurring payments rests entirely on this pair: SCA is mandatory on the initial CIT, and later MITs are out of SCA scope, provided the chain is built correctly.

Criterion	CIT (initial)	MIT (renewals)
Initiator	The customer, in session	The merchant, customer absent
SCA	Mandatory (3DS), with a credential-on-file storage indicator	Out of SCA scope
Network flags	“Initial storage,” CVV present	“Recurring” or “unscheduled COF” + reference to the initial transaction
Chaining	Generates the initial scheme transaction ID	Must reference that scheme transaction ID on every billing date
Amount	Can be €0 (account verification) or the first charge	Fixed (recurring) or variable (UCOF), depending on the accepted agreement

CIT vs. MIT: the recurring payments reference

⚠️

Mis-flagged MITs are the top cause of “SCA required” declines on recurring payments

If a renewal goes out without the right indicators (the MIT flag and the reference to the initial transaction), the issuer treats it as an unauthenticated customer transaction. Many European issuers will then return a 1A/65 soft decline every time. Chaining is not a technical detail. It is the foundation of recurring payment collection.

A correctly chained MIT renewal

{
  "amount": 2900,
  "currency": "EUR",
  "storedCredential": {
    "initiator": "merchant",
    "usage": "subsequent",
    "reason": "recurring",
    "initialSchemeTransactionId": "MCC4XR9T20260601"
  },
  "credentialOnFile": true,
  "cvvPresent": false
}

What about SEPA direct debit?

SDD (SEPA Direct Debit) relies on a signed mandate (paper or electronic) with a unique mandate reference (UMR). It is the functional equivalent of the initial CIT.
Pre-notification of the debtor (amount and date) is mandatory before each direct debit, unless another notice period has been agreed.
Failures show up as R-transactions (reject, return, refund). The payer can request a refund for up to 8 weeks with no reason required, or 13 months if the mandate is invalid.
SDD is unbeatable on cost for domestic recurring payments, but its slow feedback loop and the payer's right to a refund call for dedicated risk management.

Recurring payment rails in EuropeVisaMastercardCACartes Bancaires CBPayPalWEWero

🎯 Quick question

What makes a subscription's MIT renewals exempt from SCA?

Chapter 3. Involuntary churn: why renewal charges fail.

Voluntary churn is a customer decision. Involuntary churn is a payment accident: the card expired, the balance was too low, the issuer declined. The customer wanted to keep the subscription and leaves anyway. It is the most frustrating revenue loss in a subscription business, and the easiest to fix.

20 to 40%

share of total churn that is involuntary (payment failures) in subscription businesses

ProfitWell/Paddle studies, 2023–2024

≈ 2-3 %

of cards in circulation change every month (expiration, loss, theft, reissue)

Industry estimates

5 to 14%

typical failure rate on renewal charges, depending on the market and card mix

Subscription PSP benchmarks, 2024–2025

Driver	Common code	Typical share	Main lever
Insufficient funds	51	≈ 40–50% of failures	Retry timed to paydays
Card expired/reissued	54	≈ 15-25 %	Account updater, network tokens
Generic issuer decline	05	≈ 15-20 %	Richer data, correct MIT flags, rerouting
Card lost/stolen/closed	41, 43, 46	≈ 5-10 %	Ask for a new payment method (no retry)
Suspected fraud / SCA	59, 1A/65	≈ 5-10 %	Resubmit with 3DS, clean MIT chaining

Typical breakdown of failure causes on card renewals

From failed charge to preventable churn

Payment engine

The cycle's charge fails (code 51)

The subscription moves to past_due

Dunning

Retry sequence + customer messaging

Grace period: the service stays on

Customer

Updates their card, or their balance is topped up

The update link must take 2 clicks at most

Payment engine

Charge recovered, subscription reactivated

Otherwise: involuntary churn recorded when the window closes

💸

Insufficient funds

The leading cause of failure, and closely tied to pay cycles, so a retry on the 28th or the 1st of the month clearly outperforms one on a fixed date.

💳

Outdated credentials

Expired or reissued cards: a mechanical cause that account updaters and network tokens can almost entirely eliminate (chapter 5).

🛡️

Issuer risk

Code 05 declines and suspected fraud are handled through data quality, MIT chaining, and step-up authentication.

⚙️

Engineering

Timeouts, configuration errors, and mis-flagged MITs are invisible in the averages but visible in the logs. Track them continuously.

🔑

Every point of churn you prevent goes straight to LTV

With LTV ≈ ARPU ÷ monthly churn, a €29/month subscription with 5% monthly churn has an LTV of ≈ €580. At 4%, it is ≈ €725. Cutting churn by one point raises LTV by 25% here, without acquiring a single new customer. And involuntary churn is the easiest kind to reduce.

🎯 Quick question

What is the leading cause of failed card renewal charges?

Chapter 4. Advanced dunning: retries, sequences, messaging.

Dunning orchestrates the recovery of a failed payment. On the machine side, it runs smart retries. On the human side, it runs a messaging sequence and a grace period. The two halves reinforce each other. The best retry in the world recovers nothing if the card is closed, and the best email is useless if the update link takes ten steps.

Day	System action	Customer action	Service status
J0	Charge fails, decline code classified	–	Active (grace period)
D+1	Retry if the code allows it (optimized time)	“Payment failed” email + 2-click update link	Asset
D+4	Retry timed to the next likely payday	In-app/push reminder	Asset
D+8	Retry with a mutation (network token, 3DS on a soft decline)	Warning email: suspension coming	Active, warning banner
D+14	Final retry	Last reminder + possible win-back offer	Suspended (limited access)
D+21	Closed: involuntary churn recorded	Goodbye email, 1-click reactivation for 90 days	Canceled

Typical dunning sequence (monthly B2C subscription)

Data-driven retry scheduling

{
  "dunning": {
    "graceDays": 14,
    "retries": [
      { "at": "+1d", "window": "09:00-11:00 local", "if": "retryable" },
      { "at": "payday-next", "if": "code == 51" },
      { "at": "+8d", "mutations": ["useNetworkToken", "force3dsOnSoftDecline"] },
      { "at": "+14d", "final": true }
    ],
    "hardStops": ["category1", "chargeback", "mandateRevoked"],
    "notifications": ["email:D1", "push:D4", "email:D8", "email:D14"]
  }
}

⚠️

Network rules apply to dunning too

A failed renewal is still a transaction. Visa allows at most 15 reattempts in 30 days, and no retries on category 1 codes (card lost, stolen, expired, or invalid); otherwise integrity fees apply. Aggressive, blind dunning costs more than it recovers, and it hurts your reputation with issuers.

Payday timing: for code 51, retrying around the 28th to the 1st (or mid-month, depending on the country) far outperforms fixed intervals.
Local time and day of the week: approval rates vary by time of day, and specialist PSPs' ML models exploit these patterns issuer by issuer.
Attempt mutations: resubmit differently (switch to the network token, force 3DS on a soft decline, change rails) instead of repeating the same attempt.
Grace period: keeping the service on for a few days sharply improves recovery; cutting it off abruptly on day 0 frustrates customers into voluntary churn.
Useful messaging: every message must include a card update link that takes 2 clicks at most, designed mobile-first.

Recovering a failure with an attempt mutation

Billing

Renewal declined: soft decline 1A

The issuer requires authentication

Dunning

Sends the customer a confirmation link

3DS session starts on click, frictionless when possible

Customer

Confirms in one step

Completes SCA in their banking app

Payment engine

Resubmits and collects

The subscription stays active, with no interruption

≈ 70 %

of at-risk revenue recovered by the best machine-learning retry programs

Recurly, State of Subscriptions 2024

30 to 60%

range of recovery rates observed depending on dunning maturity (fixed retry vs. full sequence)

Paddle/ProfitWell studies, 2023–2024

🎯 Quick question

Why is timing a retry to the customer's likely payday so effective on code 51 declines?

Chapter 5. Account updaters and credential freshness.

With 2 to 3% of cards changing every month, a subscriber base goes stale on its own. After a year, nearly a third of stored credentials can be outdated. The networks offer two fixes. First, account updater services: VAU (Visa Account Updater) and ABU (Mastercard Automatic Billing Updater). Second, and more fundamentally, network tokens, which update themselves.

Strategy	How it works	Drawbacks
Batch updater (VAU/ABU)	Card file sent to the network periodically; new PANs/expiration dates returned	Latency (processing cycles), coverage depends on issuer participation, per-request cost
Real-time updater	On-the-fly lookup at the time of the charge (PSP offering)	Higher unit cost; same dependence on issuer participation
Network tokens	The issuer and the TSP keep the token ↔ account link up to date continuously	BIN coverage still uneven outside major markets; re-provisioning required if the token requestor changes

Three ways to keep credentials up to date

Typical updater responses: new PAN, new expiration date, account closed (stop charging and ask the customer for a new payment method), contact cardholder.
Acting on the responses matters as much as requesting them: an ignored “account closed” turns into a string of billable retries on a category 1 code.
Run the updater before the month's big charge runs, not after.
Wallets (Apple Pay, Google Pay) already run on network tokens, so their credentials almost never go stale on the merchant side.

Account updater response (batch)

{
  "responses": [
    { "merchantRef": "cust_1204", "result": "NEW_EXPIRY", "newExpiry": "2029-04" },
    { "merchantRef": "cust_0873", "result": "NEW_PAN", "panToken": "tok_new_8842" },
    { "merchantRef": "cust_2210", "result": "ACCOUNT_CLOSED", "action": "stop-billing" },
    { "merchantRef": "cust_1567", "result": "CONTACT_CARDHOLDER" }
  ]
}

🔑

A network token is a continuous account updater

VAU and ABU periodically fix the existing card file. The network token solves the problem at the source: the issuer carries a card reissue over to the token without any action from the merchant. For a subscription business, that argument settles the case for network tokenization. Code 54 declines (expired card) almost disappear from dunning.

≈ 1/3

of stored credentials can go stale within a year without an updater (at 2–3% a month)

the “expired card” decline code, nearly eliminated by combining updaters and network tokens

🎯 Quick question

An account updater returns “ACCOUNT_CLOSED” for a subscriber. What should the billing system do?

Chapter 6. Migrating PSPs and managing by the metrics.

The stored credential file is a subscription business's most valuable asset, and its biggest source of PSP lock-in. A poorly prepared migration can wipe out whole points of MRR through lost credentials, broken MIT chains, and double charges. Negotiate portability before you sign, not when you are leaving.

Audit the asset: how many PSP tokens, network tokens, and SEPA mandates do you have? What share of MRR depends on each type of credential?
Export the PANs: the outgoing PSP sends the PANs and expiration dates, encrypted (PGP), directly to the incoming PSP's PCI DSS Level 1 environment, never through the merchant's systems. This is standard practice, and a PSP that refuses it in the contract is a red flag.
Transfer the MIT metadata: also export the initial scheme transaction IDs and the mandate indicators so the new PSP can chain MITs correctly.
Re-provision the network tokens: they are tied to the outgoing PSP's token requestor, so they cannot be copied. They are recreated from the exported PANs (or via the PAR), usually with no friction for the customer.
Switch over gradually: dual-run by cohort (5%, 25%, 100%), compare authorization rates at each step, and keep a rollback plan until parity is proven.

⚠️

The MIT chain is where migrations usually break

If the initial scheme transaction ID is not transferred, every renewal reaches the issuer as an unauthenticated transaction, and a wave of 1A/65 soft declines is guaranteed. When the references are lost, the fallback is to trigger a re-CIT, meaning the customer authenticates again. It works, but it adds a lot of friction. Hence the rule: from the day you sign, require contractual portability of the PANs and the chaining metadata.

S1-S2

Audit and contract

Credential inventory, portability clauses, and a PCI workstream opened between the outgoing and incoming PSPs.

S3-S6

Transfer

PGP export of PANs + MIT metadata, import and re-tokenization at the incoming PSP, network token re-provisioning.

S7-S9

Dual-run

5%, then 25% of renewals on the new PSP; approval rates compared by BIN, MIT chains checked.

S10-S12

Cutover and close-out

100% of traffic, an observation period, and a certified data purge at the outgoing PSP.

The recurring revenue dashboard

Metric	Option	Benchmark (order of magnitude)
Gross monthly churn	Subscribers lost ÷ subscribers at the start of the month	B2C: 3–7%; B2B: < 1–2%
Involuntary churn	Churn caused by payment failures ÷ total churn	20–40%; every point can be won back
Recovery rate	Recovered payments ÷ failed payments (by value)	30–60%; ≈ 70% for the best ML programs
MRR / ARR	Monthly / annualized recurring revenue	The go-to metric for valuation
NRR	Revenue from existing customers after 12 months ÷ starting revenue (upsells − churn)	> 100% = the installed base grows on its own
LTV	≈ ARPU ÷ monthly churn (approximation)	Compare with acquisition cost (LTV/CAC > 3)

Key metrics for running a subscription business

Monthly recovery rate by failure cohort

SELECT
  DATE_TRUNC('month', failed_at)                    AS cohort,
  SUM(amount_eur)                                   AS failed_eur,
  SUM(CASE WHEN recovered THEN amount_eur END)      AS recovered_eur,
  ROUND(100.0 * SUM(CASE WHEN recovered THEN amount_eur END)
        / NULLIF(SUM(amount_eur), 0), 1)            AS recovery_rate_pct
FROM renewal_failures
GROUP BY 1
ORDER BY 1;

> 100 %

an NRR above 100% means the installed base generates more revenue every year, net of churn

LTV/CAC > 3

classic benchmark for a viable subscription model

Billing and recurring payments ecosystemStripeAdyenPayPalGOGoCardless

🎯 Quick question

In a PSP migration, why can't network tokens be transferred directly?

Recurring payments and subscriptions, level 2. 6 chapters and a final quiz.

Chapter 1. Billing architecture: plans, trials, proration.