Smart retries (decline recovery)
Re-attempting a failed charge when it is most likely to work, keyed on the decline reason and payday timing, instead of hammering it daily.
See it
What it is
Naive retry logic charges the same card at the same hour three days in a row and calls it a day. Smart retries pick the timing from evidence: the decline reason, the customer's local time of day, the day of the month relative to typical payroll dates, and how similar declines have recovered before. Insufficient funds waits for money to land. Issuer unavailable retries in minutes. A hard decline is never retried at all, it goes straight to 'give us a new card'.
Providers ship this as a feature (Stripe calls it Smart Retries, Recurly and Chargebee have equivalents, and recovery specialists like Churn Buster and Gravy sell it as a service) because the models are trained on billions of attempts, which is data you will never have in-house. If you do roll your own, the highest-value rule is simply 'branch on the decline code', which gets you most of the lift before any machine learning enters the picture.
Gotchas: card networks cap how many times you may retry a declined transaction and charge fees for abusing it, and a merchant account with a poor approval ratio starts eating declines on perfectly good charges. Retries also have to share state with dunning email, or you send 'payment failed' minutes after the money actually cleared. And every retry needs an idempotency key, otherwise a timeout that actually succeeded turns into a double charge.
Ask AI for it
Replace our fixed retry schedule with decline-aware smart retries. On a failed recurring charge, classify the decline first: hard declines are never retried and immediately trigger the 'update your payment method' flow; issuer-unavailable and processing errors retry after 15 minutes and then 2 hours; insufficient funds schedules retries on days 3, 5, and 8, snapped to the 1st or 15th if one falls within two days of either, at roughly 9am in the customer's local timezone. Cap total attempts at 4 per invoice and 15 per card in a rolling 30 days. Send every attempt with an idempotency key derived from the invoice id plus attempt number, cancel all pending retries the instant a payment succeeds or the card changes, and publish an event on each attempt so the dunning email scheduler stays in sync.