A one-off purchase is easy to reason about: the user looked at a cart, agreed to a number, and a charge happened once. Recurring payments break every one of those assumptions. The user consents once and is charged many times, possibly for years, often for an amount they never explicitly saw, while they are asleep and their agent is acting alone. That gap between one act of consent and an open-ended series of charges is where subscription billing goes wrong: surprise renewals, cards that quietly expire, price rises nobody agreed to, cancellation flows engineered to exhaust. AP2’s answer is to make the standing authorization an explicit, signed object and hang a disciplined lifecycle off it — the state machine each billing cycle moves through, the recovery loop after a failed charge, the changes that require fresh consent, and the audit trail that proves any given charge was authorized.
A standing authorization is not a cart mandate
A cart mandate is closed: this basket, this total, this merchant, now. It is trivially verifiable after the fact because everything it authorizes is written into it. A recurring mandate cannot work that way: the thing being authorized has not happened yet and will happen repeatedly. The artifact itself — its fields, signing, and verification — is covered in the companion piece on AP2 mandates; what matters here is how its shape differs.
Three differences drive everything downstream. First, the amount is often open-ended or bounded rather than fixed: a metered plan authorizes a ceiling and a billing rule, not a number. Second, the mandate carries a schedule — cadence, anchor date, and an end condition, which may be ‘until cancelled.’ Third, it carries notice requirements: what the user must be told before a charge, a price change, or the renewal of a long term. A cart mandate needs none of these because it expires the moment it is used. A recurring mandate is a policy that must stay legible for its whole life.
The billing cycle as a state machine
The most useful discipline in subscription billing is to stop thinking about ‘charging the customer’ and start thinking about a subscription that occupies exactly one state at a time, with explicit transitions. The states that matter:
| State | Meaning | Service access |
|---|---|---|
trialing | Mandate signed, no charge yet | Full |
active | Last cycle paid, next charge scheduled | Full |
past_due | A charge failed; recovery in progress | Usually full |
grace | Recovery continuing, user notified | Degraded or full |
suspended | Recovery exhausted, mandate still alive | Blocked |
cancelled | Mandate revoked, no further charges | Ends at period end |
Explicit states buy three things. Entitlement becomes a single lookup instead of a scatter of boolean flags. Every transition becomes an event you can sign, log, and notify on. And the awkward questions — does a past-due user keep access, does suspension end the mandate or pause it — become product decisions in a transition table rather than accidents of whichever code path ran first.
What the mandate authorizes at charge time
Each cycle produces a charge event, legitimate only if it falls inside the envelope the mandate defined. The check is mechanical and belongs before money moves: is the mandate still valid and unrevoked, is this the date the schedule predicts, is the amount within the authorized bound, and has the required notice gone out?
This matters more with an agent in the loop. A merchant-initiated renewal is, by construction, a transaction the user is not present for — which is why the industry treats the initial transaction as the authenticated one, with subsequent fixed-amount charges on the same standing authorization falling outside the step-up flow. That exemption is only defensible if the later charges genuinely match what was authenticated. The moment a charge exceeds the envelope — a metered bill above the ceiling, an off-cycle attempt, a different merchant — it is not a renewal but a new authorization, and it needs its own consent rather than a quiet reuse of the old one.
Dunning: recovering a failed charge inside the cycle
Charges fail constantly, and most failures are not the customer refusing to pay: insufficient funds at the wrong moment, an issuer’s risk model twitching, an expired card. Dunning is the recovery loop between a failed charge and a suspended subscription, and its placement in the state machine is the design decision. A failure moves the subscription to past_due and starts a bounded recovery window; only when that window closes without success does it become suspended.
Two rules keep the loop honest. First, separate the decline reasons: a hard decline (account closed, stolen card, invalid account number) should never be retried, because the answer will not change; a soft decline (insufficient funds, temporary issuer failure) is worth another try. Second, keep the user in the loop. A dunning sequence that talks only to the issuer and never to the cardholder is optimising the wrong half of the problem — most recoverable failures are recovered by the customer updating a credential, not by the retry itself.
Why naive retries burn goodwill, and what smart timing looks like
The instinct after a decline is to retry immediately and often. It is close to the worst thing you can do. Networks and issuers monitor reattempts of declined transactions and treat a merchant who hammers a dead card as a risk signal; schemes impose limits on how often a declined authorization may be reattempted and penalise excessive retries. Beyond the rulebook, a string of declines degrades the issuer’s model of you as a merchant, so future legitimate charges are approved less often.
Smart retry means fewer attempts, better placed. Space them out, and aim them at moments when the underlying condition is likely to have changed — a few days after an insufficient-funds decline lands closer to the customer’s next payday than an attempt an hour later ever will. Skip the retry entirely on hard declines, cap total attempts as a stated policy, and measure recovery rate per attempt: past the second or third try the marginal recovery is usually small and the reputational cost is not.
Price and plan changes: what needs fresh consent
A mandate authorizes a specific bargain. Change the bargain and the question is how far you have moved from what the user agreed to. The practical test: would a reasonable user consider the new terms materially different from the ones they signed?
Changes the user initiates — upgrading a plan, adding seats, switching cadence — are self-consenting: the user is present and acting, so you capture the new terms and issue an updated mandate. Changes the merchant initiates split in two. A price increase, a cadence change, or a cut in what the plan includes is material: it needs advance notice with a clear window in which the user can cancel before the new price applies, and continued use should count as acceptance only when that notice was genuinely conspicuous. Immaterial changes — a renamed tier, a feature added at no cost — need notice at most. The architectural consequence is that a mandate must be versioned: a change supersedes rather than mutates, so every past charge still points at the exact terms in force when it ran.
Proration: charging for the part of a cycle you used
Mid-cycle changes create a stub period, and proration prices it. The mechanic is simple arithmetic — credit the unused remainder of the old plan, charge the rest of the cycle at the new one — but the decisions around it are where implementations differ.
Decide, and document, four things. When the adjustment lands: immediately as a one-off charge, or as line items on the next invoice? Rolling it forward avoids surprise off-cycle debits. Whether downgrades refund or credit: most services issue account credit rather than money back, defensible if stated up front. What the unit is: daily proration is common and easy to explain; per-second precision creates rounding noise nobody thanks you for. And whether to prorate at all for small deltas, since a trivial adjustment can cost more in support questions than it recovers. Whatever you pick, show the arithmetic on the invoice — an unexplained prorated line is a common trigger for a customer disputing a charge they actually owe.
Cancellation, and the obligation to make it easy
Cancellation is the part of the lifecycle most often built badly on purpose. Retention flows that hide the cancel button, demand a phone call to end a subscription bought in two clicks, or bury the option under layers of offers are not clever growth engineering; regulators in several jurisdictions now require that cancelling be no harder than signing up. Design for symmetry: a mandate an agent created in one interaction must be revocable in one interaction.
Mechanically, cancellation is a signed revocation event against the mandate; treating it as a first-class artifact rather than a database flag is what makes it provable later. Three details matter: cancellation should stop future charges but normally leave access running to the end of the paid period; the confirmation must state plainly when access ends and that no further charges will occur; and the revocation must propagate to the credential or network token on file so a stray retry cannot resurrect a dead subscription.
Involuntary churn, account updater, and the audit trail
A large share of subscription attrition is not a decision at all. Cards expire, get reissued after a breach, or are replaced when a customer switches banks, and the subscription dies quietly because the credential on file stopped working. This is involuntary churn — the cheapest churn to fix, because the customer still wants the product.
The structural fix is the account updater pattern: the card networks operate services that refresh a merchant’s stored credential when the issuer replaces a card, so the renewal succeeds without the customer touching anything. Network tokenization does much the same by keeping the token stable while the underlying card number changes. Pair either with expiry reminders sent before the failure rather than apologies after it.
Underneath it all sits the requirement that makes the rest defensible: an audit trail that can answer, for any single charge, which mandate version authorized it, when and how the user consented, which schedule entry it corresponds to, what notice was sent, and what the state machine did next. That chain turns ‘we believe the user agreed’ into something you can show.