A failed Stripe renewal leaves a paper trail, and most teams read it backwards. They start at the final state — subscription cancelled, customer gone — and treat everything before it as one undifferentiated failure. Open the attempt log in order instead, and a failed renewal turns into four or five separate events, each with its own cause and its own correct response. The log is not an obituary. It is a debugging trace.
Event one: the initial attempt. Note the decline code before anything else, because the code decides whether the rest of the sequence is a retry problem or a messaging problem. Insufficient funds and generic declines are timing events; the credential is alive and the conditions around it will change. Expired and invalid cards are credential events; no schedule of retries fixes them, and the only productive move is getting the customer to a card-update page quickly.
Event two: whatever Radar and your retry settings did next. Stripe's automatic retries run on their own logic, and a surprising number of teams cannot say how many attempts fired, on which days, or whether the customer heard anything between them. If the log shows three attempts in four days and zero emails, the failure is not the customer's card. It is a sequence that spent its chances before payday arrived and never told the one person who could have fixed the problem outright.
Event three: the customer's own signals, which the attempt log does not show but your other systems do — logins during the failure window, a support visit, an opened email. A subscriber who logged in twice while their renewal was failing was not churning. They were failing to pay, which is a different bug with a different fix. Correlating these two views is most of what a disciplined Stripe dunning setup actually consists of: attempts, messages, and account activity read as one story instead of three.
Event four: the ending. Every failed renewal should close in exactly one of three ways — recovered on a retry, recovered on a new card, or closed deliberately at the end of a defined sequence. The fourth ending, the one where the subscription just drifts until some cleanup job cancels it, is where revenue and data quality both go to die. Accounts that end deliberately produce records; accounts that drift produce archaeology.
Read enough attempt logs in order and patterns stop being anecdotes. You learn that your third retry almost never lands and your spaced fifth one does, or that one decline code is eating a third of your failures and nobody had ever messaged it specifically. That is the compounding part: each log you read properly makes the next sequence shorter, calmer, and more likely to end at event four, first ending.
One more habit separates the teams that improve from the teams that just process failures: they write the ending down where the next person can find it. Not a dashboard state — a sentence. "Recovered on the second spaced retry after the payday message." "Closed after the full sequence; customer replied in March on a new card." Six months of those sentences become the only honest documentation of what your recovery sequence actually does, and they make the next redesign an argument about evidence instead of taste. Dashboards count outcomes. Sentences explain them, and explanations are what you redesign from.
We built Swipe Again to run that reading automatically — decline codes triaged as they land, retries spaced to when conditions actually change, card-update messages written like notices instead of alarms, and a clean stop at the end. But the log-reading habit works with no tooling at all. Pick last week's ugliest failure, read it forwards, and count how many of its events were ever really the customer's fault.
Top comments (0)