Build proper dunning
Card retries, an updater for expired cards and a short email sequence. Stripe’s own billing page says it recovered $8.2B in failed payments in 2025; read any recovery figure as the vendor’s own.
Time: 4h
Done when
Open the payment provider settings and give the retry schedule and the subject of each dunning email. Retries are on, and the sequence has at least three messages. (Proof: a list of the items.)
If this is a change to your product
- What must become true
- A failed payment triggers scheduled card retries and a short email sequence that links straight to the page where the card is updated, and the sequence stops when the payment succeeds.
- Where it usually lives
- The payment provider’s retry and email settings, plus a handler for failed and recovered payments.
- The trap
- Emails that keep arriving after the card is fixed. Stop the sequence on the recovery event, and test with a test card that fails and then succeeds.
Evidence
Removed from this step
These statements were here until a source did not support them.
It said: Card retries plus four emails recover 30 to 50% of involuntary churn.
We found: No primary source. Stripe’s page gives totals ($8.2B recovered in 2025, $14 per $1 spent), not a share of involuntary churn; a 55% figure two readers reported was not on the page when checked directly.
Now: Stripe’s own totals, labelled as the vendor’s.