CASE STUDY — METHOD
When a recurring payment fails and the customer isn't present, the recovery system takes over. It retries on an escalating schedule and, when retries are exhausted, escalates to account-level consequences. The state machine formalization turned an implicit process into an explicit, verifiable lifecycle.
A failed charge enters the retry loop. Each retry either succeeds (resolving the invoice) or fails again. When retries are exhausted, the system escalates to account-level consequences.
The billing system generates an invoice on schedule and charges the customer's saved payment method. The customer is not present — no interactive authentication, no real-time resolution.
A failed charge creates a recovery event. Common failure reasons include expired cards, insufficient funds, issuer declines, and network errors.
The system retries the payment on a schedule, incrementing the retry counter and escalation level with each attempt.
When retries are exhausted, the system sets a delinquency flag on the account record via a synchronous cross-service call. This can trigger payment method enforcement or account restrictions.
A single engine evaluates all recovery signals for an account — multiple event types converge into one computation. Coverage went from partial to complete. Disagreement between handlers is structurally impossible.
The escalation produces binary outcomes — delinquent or not, restricted or not. A customer whose card expired last week and one who hasn't paid in six months receive the same treatment.
When recovery flags an account, entitlement revocation is a separate process. The recovery system decides an account is delinquent — whether that actually affects what the customer can use is someone else's problem.
The cross-service call to set the delinquency flag is synchronous. If the target service is down or slow, the escalation path is blocked.
An expired card (permanent) gets the same retry cadence as insufficient funds (transient). The recompute engine can see the difference, but the retry logic doesn't use it.
Instead of setting a delinquency flag, the recovery system produces payment outcome events. These feed into payment-driven entitlements — the same pipeline that handles on-session payment results.
Entitlement consequences scale with severity and duration. Early failures may restrict premium features while preserving core access. The blunt binary is replaced with a spectrum.
Retry schedule accounts for failure reason. Permanent failures are fast-tracked to resolution. Transient failures get appropriate retry windows.
Three workstreams cover the full payment lifecycle — no overlap, complete coverage. Recovery owns the off-session segment.
The state machine above was authored as a YAML diagram spec and rendered by the platform's SVG engine. The formalization forced precision — every state, every transition, every guard condition made explicit. The diagram isn't documentation of the design. The diagram is the design.
The recovery system owns the off-session long tail — what happens when payment fails and the user isn't there. The recompute engine gave it complete visibility. The transformation connects that visibility to entitlement consequences through payment-driven decisions.