Recovering failed payments without annoying your customers
Blind retry schedules recover less money and burn more goodwill than a diagnosis-first approach.
Most dunning systems retry a failed charge on a fixed schedule—day one, day three, and day seven—regardless of why it failed. That schedule treats an expired card the same as a temporary bank block, and neither gets recovered as often as it could.
Start with the decline reason
Card networks return a reason code with every decline. Insufficient funds recovers best with a short delay and a retry near a plausible payday. An expired card never recovers on retry at all—it needs an update-payment-method email immediately, not a week of silent retries.
decline_reason: 'insufficient_funds' → retry in 3 days, then 7 decline_reason: 'expired_card' → skip retries, send update-method email now
Message tone compounds
The first dunning email a customer gets sets the tone for all the ones after it. Calmer, more specific copy — naming the actual reason instead of a generic 'payment failed' — tends to cut support tickets and lift update-method completion, because a customer can act on a specific problem faster than a vague one.
“A dunning email is a support interaction you get to have before the customer opens a ticket.”
Where it lands
Diagnosis-first recovery, paired with the agent's autopilot mode, is built to recover meaningfully more than a fixed retry schedule — because it targets the actual reason a payment failed instead of guessing.