A subscription renewal fails on a Tuesday. The platform retries on Wednesday, again on Friday, once more the following Monday, and then gives up and cancels the account. Every one of those attempts was reasonable in isolation. Together they describe a schedule that never once asked the only question that matters for an insufficient-funds decline: when does money actually arrive in this person's account?
Wages do not land randomly. They land on Fridays, on the first and the fifteenth, on the last working day of the month — in patterns that are boring precisely because they are predictable. A retry calendar built on business-day arithmetic ("wait two days, try again") treats a calendar as a counting exercise. A retry calendar built on pay cycles treats it as a map. The difference shows up in recovery rates, because an attempt made the morning after payday and an attempt made the day before it are not two versions of the same attempt. One of them was never going to work.
Start by sorting your failures. Insufficient funds is the decline that payday timing fixes. Expired cards, closed accounts, and do-not-honor responses do not care what day it is, and retrying them on a payday schedule wastes attempts and trains issuers to see your retries as noise. The calendar only governs the timing-sensitive share of your failures — but in most consumer subscription businesses that share is the largest single bucket, and it is the bucket where a day either way changes the outcome.
Then look at the shape of a month. The first of the month carries rent and mortgage payments; the days immediately after a common payday carry a brief window where balances are as high as they will get all month. Retrying into the first of the month because your dunning sequence happens to land there is a quiet own goal. Retrying on the second, or on the morning of a Friday payday, is the same attempt with a materially better chance — same card, same customer, same amount, different day.
There is a worked version of this at a payday retry calendar that maps attempts to actual paydays, and it is worth building your own copy even if you never use anyone's tool: the exercise of writing your retry dates next to the common paydays in a month changes how the schedule looks on paper, which is where schedules get fixed.
Two disciplines keep the calendar honest. First, cap the attempts. A payday-aware schedule is not permission to retry indefinitely; it is a way to make a small number of attempts count. Eight attempts spread across two pay cycles is a plan. Twenty attempts across one week is a hammer, and issuers notice hammers. Second, stop the clock when the customer acts. A card update, a reply, a pause — any of these should reset the schedule, because the calendar was only ever a guess about a stranger's bank balance, and the customer just gave you facts.
The uncomfortable part is that none of this is visible in a standard retry report. Your platform will happily tell you the recovery rate by attempt number — attempt one recovered this much, attempt two that much — while saying nothing about the day each attempt landed on. Rebuild that report with the calendar date attached and a pattern usually appears within one month of data: recoveries cluster on a few weekdays and a few dates, and the dead attempts cluster on others. That cluster map, not a vendor's default sequence, is what your schedule should be built from.
None of this requires new software to start. It requires admitting that a retry schedule is a hypothesis about when people have money, and hypotheses should be written down, dated, and checked. The merchants who recover well treat the calendar as an asset — reviewed monthly, adjusted when the data moves. The ones who recover badly are usually running a sequence somebody else chose for a different customer base in a different year, and calling it automation.
The broader recovery picture — how timing, card updates, and honest customer emails fit together — is laid out at Swipe Again, which is where the calendar above lives.
Top comments (0)