People imagine failed-payment recovery as an email sequence. A charge fails, a polite note goes out, maybe a second one with more urgency. The emails exist, but they are the visible tenth of the work. The rest is scheduling, restraint, and record-keeping.
The day starts with reading. Every failed charge arrives with a decline code, and the code is a diagnosis: a closed account is a ending, an empty one is a calendar problem, a temporary issuer refusal is a request for space. A system that treats these the same — same retries, same messages, same timing — is not recovering payments so much as re-attempting them and hoping.
Then comes the part nobody brags about: waiting on purpose. The highest-value retry is often the one fired the morning after a payday, which means the correct action today is no action. Schedules stretch as far as roughly day 25 for insufficient funds, widen for soft declines, and stop entirely for hard ones, because attempts spent on a stolen card are worse than wasted — they train issuers to distrust the merchant.
Underneath, the bookkeeping has to be exact. Before any attempt, the invoice gets re-read: customers pay on their own, update cards on other pages, cancel, dispute. A retry fired against a settled invoice is how double charges happen, so the fresh read is not a nicety. It is the job.
That daily discipline — read, wait, re-check, attempt, record — is what dunning software is actually for. The emails are just the part the customer can see.