Monday, 6 a.m.: the overnight batch settles and the log fills with the usual mixture — most renewals approved without drama, a scatter of declines behind them. Reading the failures out loud is a useful discipline, because a log line compresses a person into a code. Insufficient funds at 2 a.m. is rarely a verdict about the product; it is a salary that lands on Friday meeting a charge that arrived on Tuesday. The retry log knows the code. It does not know the calendar, and that gap is where recoverable revenue quietly expires.
Tuesday brings the expired cards, the politest failures in the file. Nothing is wrong with these subscribers except a date printed on a piece of plastic they replaced in March. Stripe's account updater heals some of them silently, and those never appear as work at all. The ones that remain need a message, not another attempt: retrying an expired credential on a schedule is the billing equivalent of knocking on a door you know is empty. The log shows three attempts in nine days against a card that expired in June, each one logged, none of them capable of succeeding.
Wednesday is the generic declines, the shrugs. A generic decline tells you the issuer objected and declined to say why, which makes it a reading problem rather than a timing problem. Sometimes a spaced retry clears it; sometimes the subscriber has to call their bank; sometimes a new payment method is the only honest answer. Teams that treat every generic decline as 'try again tomorrow' burn attempts and learn nothing. Teams that sort them — first failure or repeat, new card or old, large amount or small — start to see which shrugs are temporary. Working through stripe dunning is mostly this sorting work: matching the response to the reason instead of the calendar.
Thursday, the authentication failures arrive, concentrated in European cards. These subscribers often never learn their renewal failed, because the challenge that would have told them expired in an app they were not looking at. No retry cadence fixes an unfinished authentication; only a clear, well-timed request to complete it does, sent while the subscriber still recognises the charge. The log records these as failures identical to the others. The recovery work could not be more different.
Friday is for counting what the week actually taught. Of the failures still open, how many are waiting on the calendar, how many on the subscriber, and how many on nobody at all because the credential is dead? That three-way split is the real dashboard. Attempt counts flatter activity; the split measures understanding. A team that can say, on Friday, exactly which pile each open failure sits in does not need a more aggressive schedule. It needs to work the piles in the right order, with the right tool for each: patience for the first, a good message for the second, and a clean card-update path for the third.
One more habit separates the teams who learn from the log from the teams who merely archive it: they annotate it. When a subscriber replies explaining that the charge hit a closed account, or that the bank blocked the payment pending a phone call, that explanation belongs beside the failure it describes. Six months later, the patterns in those annotations are worth more than any benchmark report, because they describe this business's actual subscribers rather than the industry's average ones. Benchmarks can suggest where to look; only your own annotated log can tell you what you found. The teams that recover steadily better each quarter are, almost without exception, the teams whose log has become a record of reasons instead of a record of attempts.
The log will fill again on Monday. It always does. The question the week answers is whether anyone read it as a set of different problems wearing the same label, or as one problem to be retried louder. The rest of the material at Swipe Again keeps returning to that distinction, because most recovery gains hide inside it.
Top comments (0)