Most decline codes describe a state. insufficient_funds describes a schedule. The card is fine, the customer is real, the account is simply empty until it is not — and in a paycheck economy, "until it is not" follows a calendar that repeats every two weeks whether your retry engine respects it or not.
The naive response is to retry quickly and often, on the theory that money might land any day. Sometimes it does. More often, the attempts cluster inside the same empty stretch, each one recorded by the issuer, none of them timed for the day the balance actually changes. By payday, the engine has spent its best attempts and, in the worst cases, trained the issuer to dislike the card.
The Stripe recovery schedule in Swipe Again treats insufficient funds as the calendar problem it is: a widening ladder that reaches toward the next pay cycle instead of hammering the empty week, stretching as far as roughly day 25 so late-month and monthly pay cycles get their attempt too. It is deliberately the slowest schedule we run, because for this decline code, patience is not a compromise — it is the mechanism.
The general lesson travels beyond one code. Every decline is a sentence about the future: this will never work (hard declines — stop), this works when the customer acts (expired cards — ask), this works on a different day (insufficient funds — wait, on a schedule). A retry engine that reads those sentences well will always beat one that merely retries harder. The full picture lives in the recovery flow; the short version is that timing is a feature, and for the most common soft decline in subscriptions, it is the whole feature.
Top comments (0)