Ask most SaaS founders what their churn rate is and they'll give you a number. Ask them how much of that churn is involuntary, caused by failed payments rather than customers actively quitting, and you usually get a blank stare.
That gap matters, because involuntary churn is often the single most recoverable revenue in your entire business. The customer still wants your product. Their card just failed. Nobody made a decision to leave.
What "failed payment" actually means
When a recurring charge fails, it's rarely a rejection of your product. The common causes are mundane:
- Expired cards. The customer signed up two years ago and the card on file expired last month.
- Insufficient funds. A temporary blip that clears in a day or two.
- Issuer declines. The bank flags a recurring charge as suspicious and blocks it, even though the customer would happily approve it.
- Hard declines. A genuinely dead card that needs replacing.
The first three are almost always recoverable. The trick is retrying at the right time and prompting the customer when needed, without annoying them.
Why default handling leaves money on the table
If you're on Stripe, you already get some retry logic. By default it retries a failed charge a handful of times on a fixed schedule and can send a basic email. That's better than nothing, but it's blunt:
- Retries happen on a generic cadence, not timed to when a card is statistically more likely to clear (for example, shortly after a payday or once an insufficient-funds hold lifts).
- The dunning email is generic and easy to ignore.
- After the retry window closes, the subscription is simply cancelled, and that recovered-or-not outcome is invisible unless you go digging.
You can build smarter logic yourself with webhooks. Here's the shape of it:
// Listen for failed charges
app.post('/webhooks/stripe', (req, res) => {
const event = stripe.webhooks.constructEvent(
req.body, req.headers['stripe-signature'], endpointSecret
);
if (event.type === 'invoice.payment_failed') {
const invoice = event.data.object;
enqueueRetry(invoice, {
// not "every 3 days" — schedule around likely-clear windows
schedule: smartRetrySchedule(invoice.attempt_count),
notify: true, // trigger a recovery email
});
}
res.sendStatus(200);
});
Then you'd need a job runner to fire those retries, an email system for the recovery sequence, logic to stop on success or hard decline, and a dashboard to actually see what you recovered. It's all doable. It's also a project you'll keep deprioritizing because there's always something more urgent than plumbing.
A simpler path
This is the exact problem PaymentRescue solves, so you don't have to build and maintain that pipeline yourself.
You connect it to Stripe in a few minutes. From there it:
- Detects every failed charge automatically.
- Retries on a schedule designed around when cards are more likely to clear, instead of a fixed "every N days" rule.
- Emails the customer with a clear, well-timed prompt to update their payment method when a retry alone won't fix it.
- Reports exactly how much revenue it recovered, so the impact isn't a guess.
It's deliberately a leaner alternative to the heavier recovery suites. No multi-day onboarding, no dashboards you'll never open, just the recovery layer. There's a free tier, so you can connect it, watch a single billing cycle, and see real recovered charges before you decide anything.
The takeaway
Before you spend another dollar on acquisition, look at the revenue you've already earned and are quietly losing. Pull your failed-payment and past-due numbers. If a meaningful slice of your churn is involuntary, recovering it is the highest-leverage revenue work you can do this quarter, and it's a fraction of the cost of replacing those customers.
You can wire it up yourself with the snippet above, or let PaymentRescue handle the whole loop at paymentrescue.dev.
Full disclosure: I build PaymentRescue, a failed-payment recovery and dunning tool that wins back revenue from declined subscription cards. It is free to try at https://paymentrescue.dev.
Top comments (0)