Prerequisites
- A verified sending domain and a secret key.
Build it
1
Send payment events
Send Other languages follow the same shape, see the API Reference.
payment_failed when a charge fails, and payment_recovered when it succeeds on retry. The recovery series runs between the two.2
Build the dunning series
Trigger on
payment_failed and send a short sequence, each with a one-click link to fix the card:trigger (payment_failed) → send email (Update your payment) → wait 2 days → send email (Still can't charge your card) → wait 3 days → send email (Last reminder before your account pauses)Branch so anyone who sends payment_recovered exits immediately with a “you’re all set.”3
Hand off if it still fails
If the series completes without recovery, tag the contact Payment failed so your team (or a downgrade flow) can take over.
4
Activate and publish.
Both are required.
Test
Sendpayment_failed with your own email, confirm the series fires on schedule. Send payment_recovered partway through and confirm it stops.
Measure
- Recovery rate of failed payments.
- Revenue saved versus the pre-automation baseline.
- Which email recovers the most (usually the first), so you can tune timing.
Variations
- Branch on reason. An expired card and an insufficient-funds failure may warrant different wording.
- In-app banner. Pair with an in-app prompt for users who log in during the dunning window.

