Ask a room of subscription operators what their retry schedule is and most will describe a count: three attempts, five attempts, whatever the platform default shipped with. Ask when those attempts land — which days, at what spacing, relative to what — and the room goes quieter. That asymmetry is strange, because the evidence of everyday billing life says the when carries most of the value. The same card that declines on the 29th approves on the 2nd, and no change in attempt count bridges that gap. Only the calendar does.
Start with the most common soft decline, insufficient funds. It is a statement about a moment, not about a customer. Paydays cluster at month boundaries and on Fridays; balances trough just before them. A retry fired the morning after the failure lands in the same trough that caused it, while the same retry held for the far side of a payday meets a replenished account. This is not cleverness — it is reading the decline as a timestamped fact about a bank balance and scheduling accordingly. Yet default schedules retry on fixed intervals measured in hours, as if the obstacle were the passage of a day rather than the arrival of money.
Other declines carry other clocks. A card replaced by its bank resolves when the network updater posts the new credential, which follows the issuer's schedule, not yours. A temporary fraud hold lifts on the issuer's review timeline. A velocity limit resets on a rolling window. In each case the winning move is to wait for the specific condition to change, and the losing move is to spend the attempt early to feel diligent. Attempts are a budget. Every premature retry is one fewer chance on the day the conditions are actually right.
A small experiment any team can run this month makes the point without a vendor in sight. Take last month's soft declines and split them, on paper only, by the gap between the failure and the successful retry that eventually cleared them. Most teams find the clearances bunch — after paydays, at month turns, a few days out — rather than spreading evenly across the hours following each failure. That bunching is the calendar signature of the real causes. It means the winning attempts were not braver or more numerous; they were later in the right places and absent in the wrong ones. Your own history has already run the timing study. It is sitting in the billing export, waiting to be read as one.
The counterweight is decay. Waiting is not free: the longer a subscription sits unpaid, the more its owner mentally moves on, and the more a late recovery feels like an ambush charge rather than a rescue. Good timing therefore runs in a window — long enough for the causing condition to turn, short enough that the customer still recognises the relationship. The practical rules in evidence-based rules for when to retry a failed payment draw that window decline by decline, which is the only honest way to draw it; a single global interval is a compromise that fits no failure well.
Teams that adopt condition-based timing usually report the same surprise: their attempt counts fall while their recoveries rise. Fewer, better-placed retries do less damage with issuers, generate fewer confused support contacts, and leave budget in reserve for the failures that genuinely need persistence. The schedule stops being a number in a settings panel and becomes what it should have been all along — a set of small hypotheses about why each payment failed and when that reason expires.
Running that calendar failure by failure is the standing work of Swipe Again for Stripe-based subscription stores, at a flat $179 a month: each decline read, each retry placed against its condition, customers written to in the store's own branding, and recovered revenue reported with the arithmetic shown.
Top comments (1)
The bunching experiment is a good one - it costs nothing and usually kills the fixed-interval default in an afternoon.
Two engineering footnotes to "attempts are a budget". First, the networks ration the budget themselves. Visa and Mastercard publish reattempt rules per decline category, and retries on hard declines (stolen card, invalid account) now draw issuer fees and worse treatment on future attempts. A condition-based calendar still needs a hard-decline filter in front of it, or the schedule spends issuer goodwill on failures no timing can fix.
Second, spending the budget needs idempotency. A retry whose response timed out may have succeeded upstream, and without an idempotency key the next attempt can double-charge the very customer you were trying to keep. Stripe's Idempotency-Key header exists for exactly this. The calendar decides when; the key decouples "how many times the wire saw it" from "how many times the customer was charged".