DEV Community

Swipe Again
Swipe Again

Posted on Edited on

Dunning Management Is an Operations Job, Not an Email Setting

Most subscription businesses meet dunning as a settings page: a toggle, a retry count, a template somebody wrote in 2021. That framing quietly decides the outcome. A failed payment is not a message problem. It is a small operations problem that arrives with a diagnosis attached, the decline code, and asks to be sorted before anyone writes a word to the customer.

Sorted properly, the queue splits into jobs that look nothing alike. Hard declines are finished: stop attempting, send one clean card-update request, and close the file. Soft declines are timing problems: re-read the invoice, confirm nothing has settled in the meantime, and space the next attempt so the issuer sees patience instead of pressure. Insufficient funds is a calendar entry that belongs after payday, which is why a serious ladder stretches toward day 25 instead of burning its attempts in the first week.

Read the invoice again before you touch it

That re-read is not a ritual. It is the difference between acting on the world as it is and acting on a snapshot taken at the moment of failure. Before every attempt, the invoice is read fresh: has it already been paid through another route, has the card already been updated, has the amount changed, has a native retry already run or is one already scheduled? A retry fired from stale information can charge a customer who has already fixed the problem, chase an invoice that no longer exists in its old form, or duplicate work the platform has already done. The fresh read also decides whether an attempt should happen at all. If the invoice settled overnight, the correct action is silence. If the card was updated after the first email, the correct action is one prompt attempt on the new credential, recorded properly. Operations is mostly this: checking before acting, and being willing not to act when the facts have moved.

Weave into the native schedule, do not stack on top of it

Every billing platform already runs some native retry schedule, and an outside recovery tool that ignores it creates a second, competing rhythm on the same card. The disciplined alternative is to weave additional attempts into the gaps of that native schedule, under a combined cap of 15 attempts in total, with Swipe Again's own ceiling set at 8. Treat the cap as a design constraint, not a target to reach. A single shared ledger of attempts, whoever made them, keeps the issuer from seeing a burst of pressure and keeps the customer from receiving a retry and a message that contradict each other. Spacing is a form of respect for the cardholder, the issuer, and the merchant's own processing costs, and it forces each attempt to earn its place in the sequence.

The email cadence sits on top of that sorting, not underneath it: day 1, day 3, and 7, written in the merchant's own brand, every message pointing at a card-update page instead of a support thread. When the sorting is the product, dunning management software stops being a nicer template and becomes what it should have been all along: a small, disciplined operations desk that reads first and acts second.

Close the file honestly

An operations desk also has to say, afterward, what actually recovered the money, and to say it once. Recovery attribution is stamped at a single choke point, in a fixed order: first the retry, then the card update, then the save offer, then honest external causes that the tooling did not produce. That ordering prevents the same renewal being claimed twice by two parts of the system, and it keeps reporting credible when finance asks hard questions. The save offer itself is a separate, deliberate moment: one branded offer shown at the cancel click, with exit one click away, never a maze. And when a merchant connects, a 90-day backfill of past failures gives the desk its starting queue, so the work begins with the failures that already happened, handled with the same fresh read and the same sorting, not only with tomorrow's.

There is also a boundary worth naming. Recovery tooling does not fix a product people want to cancel. It fixes the payments of people who never decided to leave. Keeping those two groups separate, in the tooling and in the reporting, is most of the job.


Published by Swipe Again - failed-payment recovery for subscription businesses.

Top comments (0)