What happens to a subscription after the last failed retry?

A decline is not one event

When a recurring charge fails, the issuer returns a response code. Payment processors group those codes into classes, and the classes carry different meanings. Some indicate a condition that may clear on its own — an insufficient balance, a temporary hold, a velocity rule. Others indicate that the stored credential itself has been refused, because the card was reported lost or stolen, the account was closed, or an authorization was revoked. The first class describes the moment. The second describes the credential.

That distinction is the whole design problem. A retry is an attempt to charge the same stored credential again. Applied to the first class it is a reasonable bet on time passing. Applied to the second it is a request the issuer has already answered. Where a billing platform runs one schedule across both classes without branching, attempts accumulate against a credential that will not be accepted, and the one thing that would change the outcome — a new payment method — is never asked for on a separate track. Read your own processor's decline documentation before assuming which codes it will retry. Decline taxonomies and retry semantics are processor-specific and are not safe to generalise from one platform to another.

The dunning sequence is a state machine with an end

A dunning sequence is the ordered set of things that happen between a failed charge and a resolved subscription: scheduled retry attempts, notices sent to the customer, an optional grace period during which access continues, and a defined end. The middle of that sequence — the emails — is the visible part, and the schedule reads like a slider. The two ends are where the design decisions actually live. The front end decides which declines enter the sequence at all. The back end decides what the subscription becomes when the sequence stops.

• Entry rule — which decline classes enter the retry track, and which are routed straight to a credential-replacement request.
• Schedule — how many attempts, over what window, and whether the platform's own recommended default was kept or replaced.
• Grace behaviour — whether the customer keeps access, product or entitlement while attempts continue.
• Notice track — which messages are sent, on which channel, from which sending domain, and whether their delivery is measured.
• Terminal state — the status written when the sequence ends, and the systems that are told about it.
• Mirror rule — whether that status is propagated to the CRM, the ESP, the storefront and the fulfilment system, or stays inside the billing platform.

The terminal state is a configuration decision with a downstream contract

Where a billing platform exposes an end-of-retry setting, the options are of this shape: cancel the subscription, mark it unpaid, or leave it past due and keep generating invoices. Each is defensible. Each produces a different downstream reality. Where that choice was made at installation by whoever wired up payments, and no change record was kept alongside it, the person who later owns retention inherits the setting without a record that a decision was taken at all.

None of these is the wrong answer in the abstract. The failure is structural: a terminal state that is never mirrored outside the billing platform means the event that ends a customer relationship is recorded in a system that does not send messages and does not hold tasks. Task queues, lifecycle sends and entitlement rules can only act on states they are told about, and that propagation is integration and orchestration work — an explicit event contract per receiving system, not an assumption.

The notice track is infrastructure, and it carries consent

The message asking a customer to replace a card is generated by the billing platform and sent from the billing platform's sending infrastructure. The marketing email programme runs from a separate provider, on a separate sending domain, with SPF, DKIM and DMARC alignment that someone deliberately configured and someone monitors. Where the billing platform's sending domain was never brought under the same authentication and reputation discipline, the notice that carries the money sits outside the surface where sending problems would be detected — because it is filed under transactional, and transactional mail is assumed to arrive.

Where the dunning track includes SMS, or where winback messages follow a cancellation, the message layer inherits a consent architecture. Messaging rules differ by channel and by jurisdiction, and which of them reaches a given dunning or winback send is a question for qualified counsel rather than for this page. What is answerable inside the system is narrower and mechanical: the subscriber record has to carry a consent state, a revocation state and the date each changed, and the sending system has to read them before every send, because a single boolean has no history and no clock. One named example of that shape: where personal information is sold or shared, California's privacy regulator describes an opt-out exercisable through a user-enabled opt-out preference signal, requires the Global Privacy Control to be honored, and sets compliance "as soon as feasibly possible, up to a maximum of 15 business days" ^[SRC-15].

Lifecycle messaging in a recurring business is also not only marketing. California's Automatic Renewal Law, as amended, requires an annual reminder disclosing the product or service, "The frequency and amount of charges" and "The means to cancel", at Bus. & Prof. Code section 17602(h); the amendments apply to a contract "entered into, amended, or extended under this article on or after July 1, 2025" ^[SRC-26]. Structurally that is a scheduled job keyed on each subscription's own start date, rendering fields pulled from the plan record — which places it in the automation and agent layer beside the dunning sequence, not in the campaign calendar. On the federal side this page reports one fact as history and stops. The Federal Trade Commission published an Advance Notice of Proposed Rulemaking on 2026-03-13 on "the need for amendments" to the Commission's 'Rule Concerning the Use of Prenotification Negative Option Plans' at 16 CFR Part 425, and its comment period closed on 2026-04-13 ^[SRC-27]. The cited rule page was retrieved for this record on 2026-08-16. Nothing on this page states what any current federal obligation is, and a status recorded on one date is not a status today — read the cited rule page as it now stands, with qualified counsel, before relying on it.

What you can check without new tooling

1. Open the billing platform's dunning settings and write down the end-of-retry behaviour it is currently set to. Then find someone who remembers choosing it.
2. Export failed invoices with their processor decline codes for a chosen period and sort them by code. The classes that will never clear on a retry need a credential-replacement track, not a longer schedule.
3. For the same period, pull every subscription that reached the end of a dunning sequence and check which status each one now holds.
4. Ask which other system received that status. Query the CRM, the ESP and the storefront for the same subscription identifiers and see whether the state agrees.
5. Check the DNS authentication records for the domain your payment-failure notices are sent from, and compare them with the domain your marketing email is sent from.
6. Read the subscription commerce revenue architecture page for the surrounding leak map, then take the reconciliation into a Revenue Scan if you want the public-visible layer checked alongside it. The scan's boundary — public signals only, no internal data — is stated there.