What Smart Retries actually optimises
Stripe reschedules failed charges using network-wide signals about when a similar card is likely to clear. Within its scope that is genuinely good, and better than a naive fixed schedule.
Its scope is the charge. It has no opinion about the message, because it only has one message to send.
The three hard limits
One channel: Stripe-branded email. One sender: Stripe. One shape of copy: the invoice notice. If your customer never opens billing email from a vendor they do not recognise, the retry schedule is irrelevant.
There is also no per-decline-code messaging. A customer whose 3-D Secure confirmation expired needs a confirmation link in minutes, not an invoice reminder in two days.
Layering without conflict
Subscribe to `invoice.payment_failed` read-only, verify the signature with a constant-time HMAC compare, deduplicate on the Stripe event id, and run your own cadence beside Stripe's retries.
Pause Stripe's own dunning emails when you cut over, or your customer receives two notices for one failure. Keep Smart Retries itself on — it is scheduling charges, not sending your messages.
When Stripe alone is enough
Under roughly $2,000 of at-risk MRR per month, the operational overhead of a second system rarely pays for itself. Turn Smart Retries on and revisit at scale.
Above that, the gap between single-channel Stripe email and a two-channel decline-aware cadence is usually worth 8-15 percentage points of recovery.