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.