Day zero, 2 a.m.: a renewal charge meets an empty account. Nothing about this moment is a decision; the subscriber is asleep, paid on Fridays, and three days from solvent. The decline code knows all of this in outline. The schedule reads it, and the first retry is set where the money will be — not tomorrow morning, where it won't.
Day one: a message goes out in the merchant's voice, fix-first, deadline stated once. Day three: the payday retry runs and fails on a limit instead — the mix shifts, and so does the plan; the text message joins, short and plain. Day five: the subscriber taps the update link from the text and replaces the card in under a minute. Day six: the confirmation closes the loop. Days seven through nine never happen — which is the point. A well-run recovery is mostly days that don't occur.
Swipe Again lives inside those nine days for every failure: the recovery flow reads each decline, re-plans around it, and writes down everything it did. Narrate any real failure this way and the system's character shows — most recoveries are not dramas. They are calendars, kept well.
Top comments (1)
The day three pivot is the detail most dunning schedulers miss. A limit-exceeded decline is not a soft decline and treating the next retry as if it were the same problem wastes the one attempt that would have worked after payday. Mixing channels at the failure-type boundary rather than the day boundary is the right instinct too, since the card problem and the cash-flow problem need different messages even from the same subscriber. Day six closing the loop is what turns the whole sequence into something the customer experiences as competent rather than nagging.