Chase The Card Within The Hour

A failed-payment email sent inside the first hour recovers revenue a monthly dunning batch never will.

Most billing setups still treat a declined card like a chore to batch up and clear once a week. Stripe knows the charge failed at 2:14pm on a Tuesday. The customer does not find out until your dunning job runs Friday night, if it runs at all that week. By then the moment that made them likely to act, the surprise, the "wait, did my card expire," is gone, and you are chasing a cold trail instead of a warm one. Fire the email the second the decline happens and you are chasing the same customer while they still care.

What to do: Trigger the first recovery email off the payment-failed webhook itself, the instant the charge declines, not on a nightly or weekly batch job. Then weight the whole sequence toward the first 72 hours instead of spreading it evenly across 30 days. Send more, and send closer together, right after the decline, and taper off as the days pass.

Why it works: Payment intent peaks in the first hour after a card fails and decays fast after that, so a same-day email is catching attention a Day-15 email can only hope to find still there.

Example: Baremetrics ran the numbers on over 1 million dunning emails sent through its own Recover product and published the breakdown. The email sent the same day as the failed charge pulls a 41.29% open rate and accounts for 13.25% of all recovered revenue. By Day 15 that same email design is down to a 28.17% open rate and just 4.22% of recovered revenue. Same copy, same company, same product, and the only thing that changed is the day it went out. Snappa, a graphic design tool, runs this exact same-day trigger in production, firing an "Uh-oh! Your payment for Snappa failed" email the day the card declines.

Walk it through

I pulled this straight from Baremetrics' own published dunning data in July 2026. Here is exactly what it shows.

1. Look at what happens to the same email as it ages.

Read down the columns. Open rate falls from 41.29% on day 0 to 34.1% by day 3, 32.7% by day 7, and 28.17% by day 15. Recovery rate falls even harder, from 13.25% down to 4.22% over the same stretch. This is not a different email working worse. It is the identical dunning email, sent later, to a customer whose attention has already moved on.

2. See what a same-day email actually looks like in production.

Nothing complicated. A subject line that names the problem in plain language, a one-line explanation, and a billing link. Snappa sends this the day the card fails, then a second, firmer notice at day 3, then a final warning at day 7. The tone climbs with the day count. Day 0 is a nudge. Day 7 says the account gets cancelled if this one bounces too.

3. Build the cadence around the decay curve, not the calendar.

Wire your payment processor's decline event, Stripe calls it invoice.payment_failed, directly to your email trigger so the first message goes out in minutes, not at the next batch run. Then front-load the rest of the sequence into the first week and a half. Something close to day 0, day 3, day 7, and day 10 to 13 covers the window where the data above shows recovery still above 11%. Anything you send past day 15 is mopping up, not fishing where the fish are.

The read

• The first touch is the whole game. A 13.25% recovery rate on day 0 beats every other single day in Baremetrics' table outright, and it is more than three times what the day-15 email pulls.
• Open rate decay predicts recovery decay. The two curves move together almost exactly, from 41.29%/13.25% on day 0 down to 28.17%/4.22% by day 15. Recovery is not falling because the copy got worse. It is falling because fewer people are opening.
• The trigger matters more than the template. Snappa's email is plain, almost bare. It works because of when it fires, not because of clever copywriting.

Steal it

Find the decline event in your billing provider and wire it straight to your email trigger, no batch job in between. If you are on Stripe, that is the invoice.payment_failed webhook. If you are on Chargebee, Recurly, or a processor with a built-in dunning tool, check whether its default cadence is spread evenly over 30 days, because most out-of-the-box tools are, and that is exactly the mistake the data above argues against. Rewrite the schedule so more of your emails land in the first ten days, and let the tail beyond day 15 shrink to one or two last notices instead of a steady drip.

Defend the other side too. If a competitor is watching your own churn rate, a fast, well-tuned dunning sequence is not something they can see from outside, so this is a quiet advantage, not one you need to hide harder than you already do. The real risk is internal: whoever owns billing infrastructure needs to actually build the webhook path, since a marketing team asking for "one more email" without the engineering trigger behind it just adds a slower message to a slow sequence.

Gotchas

• A same-day trigger is an engineering task, not a marketing setting. You need a real-time webhook wired to your billing event, not a scheduled export, and that is a bigger lift than editing an email template.
• Watch for double-fires against your processor's own retry logic. Some processors auto-retry a failed card on their own schedule. If your email and their silent retry land at the same time, the customer gets confused about which fixed it.
• Recovery rate is easy to measure dishonestly. Baremetrics itself flags this: counting recovered charges against every failed charge, including ones you never attempted to email, inflates or deflates the number. Measure against attempted recoveries only, or your day-0-versus-day-15 comparison will not mean what you think it means.