I found revenue I'd already 'earned' but never collected in my Stripe dashboard. Here's what I'm building.
Hey IH 👋
A few weeks ago I did something most founders avoid: I actually went through my Stripe payment history line by line. Not the happy "MRR is up" chart — the failed charges tab.
What I found made me a little sick. Payment after payment had silently failed. Expired cards. "Insufficient funds." Banks declining charges for no clear reason. These weren't customers who wanted to leave — they'd already decided to pay me. The money just… never landed. And I never noticed, because nothing screams at you when a renewal quietly fails. It just shows up later as "churn."
The scary part is how normal this is. Roughly 15% of recurring payments fail every month across subscription businesses. Most of us shrug and call it "just how Stripe works." But that's revenue you already sold. You did the hard part — you won the customer — and then lost the money on the last inch.
So instead of accepting it, I started building Revova.
The first thing I made was almost selfish: a Lost Revenue Finder that scans your Stripe history and tells you the exact number you've already lost. I wanted to see my own damage first. (Fair warning: the number surprises everyone.)
Then came the part that actually recovers it — automated dunning that doesn't feel robotic. Instead of the generic "your payment failed" email everyone ignores, it runs a personalized 5-email sequence, in the customer's own language (8 supported), timed to when they're most likely to fix it. It works with Stripe, Paddle, Braintree, Chargebee and Recurly, and setup takes about 3 minutes with no code.
Where I'm honestly at: just launched, still early, and I care more about getting this right than getting it big. I'd rather have 10 founders tell me what's broken than 1,000 signups I can't learn from.
So two real questions for you:
- Have you ever actually checked how much failed payments cost you last year? Or is it a number you'd rather not know? 😅
- How do you handle failed charges today — Stripe's default retries, a tool, or nothing?
If you want to run the Lost Revenue Finder on your own Stripe and see your number, it's here → https://revova.io (use code Bird20 for 25% off if you decide to stick around).
I'll keep posting what I learn as I build this out. 🚀
Full disclosure: I'm Avery Lin (avrlin). I've been packaging a Stripe Dunning Email Pack ($29 — failure-reason matrix + calm retry copy) with AI assistance, so take this as adjacent interest, not neutral advice.
Biggest leak I keep seeing: one generic "update your card" email for every decline. Soft declines (insufficient funds) need a different ladder than expired cards or fraud holds — mapping the failure reason to short, specific retry copy recovers more than a single blast.
Curious — for Stripe/SaaS involuntary churn, do you branch dunning by decline reason, or is it still one template for everything?
Congrats on shipping this, the failed-payment blind spot is real. I've been burned by it more from the "nobody noticed a failed webhook" angle than pure declines. I run more than one business at once so anything that silently fails in a dashboard I only check every few days basically doesn't exist to me until a customer emails asking why access got cut off. That's the reason I built FounderFlow, it surfaces the few things across my businesses that actually need attention that day. 15% stat is wild when you say it out loud. Good luck with Revova.
Exactly — running more than one thing at once means nobody has bandwidth to babysit a leak that quietly bleeds money. Set-and-forget is the only version that survives real founder attention spans. Good luck with yours!
The Lost Revenue Finder is your whole go-to-market: it turns an invisible problem into a dollar figure, and a dollar figure sells itself in a way feature lists never do. I'd also test pricing as a percentage of recovered revenue instead of a flat fee, because it removes the 'is this worth another subscription' objection and aligns you with the outcome. We run subscription billing at SocialPost.ai, and founders only act on this the day they see their own number.
"An invisible problem into a dollar figure" — that's the exact insight the whole product is built around, so it means a lot hearing it from someone running billing at scale. On percentage-of-recovered pricing: I went back and forth on it. It's genuinely appealing — it's outcome-aligned and it kills the "is this worth another subscription" objection like you said. The reason I landed on flat + no-commission is part trust, part honesty: a cut of "recovered" revenue is only fair if you can prove the tool actually caused the recovery, and a good chunk of failed charges land on the processor's own smart retries anyway. Charging a percentage of those feels like billing for dollars that were coming back regardless. I'd rather measure true incremental lift against a holdout and keep pricing simple and predictable — but you're right that commission lowers buying friction, so it stays on my list to test. And since you run subs at SocialPost.ai: the scan is free and read-only if you ever want to see your own number, no strings attached. Really sharp take — thanks for it.
The line that got me was money you already sold and then lost on the last inch. That is basically the same failure mode I obsess over, just in a different spot in the business. Revenue silently slipping through a gap nobody is watching. I see it constantly running multiple ventures at once, it is never the big obvious problems that hurt, it is the quiet ones like this.
"The quiet ones that hurt" — that's exactly it. The loud problems get all the attention; the last-inch revenue leak is invisible until you go looking for it. And running multiple ventures makes it worse, because none of them individually feels big enough to babysit a dunning system — which is the whole reason I wanted this to be set-and-forget. Appreciate you putting it so well.
Exactly — running more than one thing at once means nobody has bandwidth to babysit a leak that quietly bleeds money. Set-and-forget is the only version that survives real founder attention spans. Good luck with yours!
The 'failed charges tab' is the most avoided part of Stripe for most founders, so actually sitting down and going through it line by line takes real nerve. The 15% recurring failure rate is one of those numbers that sounds made up until you see your own. I've looked at mine once and immediately wished I hadn't. The multilingual dunning sequence is a smart differentiator — the generic 'your payment failed' email problem is the reason most recovery tools underperform. The personalization question is whether you can adapt tone and timing beyond language, or if language is the main variable. What's your recovery rate on the 5-email sequence so far on early users?
You nailed a few things here. On the 15% — you're completely right, a generic number reads as made-up; I actually pulled that framing off my own site because of comments like yours, and leaned harder on "here's YOUR number" from the historical scan instead. On personalization: language is the headline, but not the only variable — the emails adapt to the decline reason too (an insufficient-funds email shouldn't read like an expired-card one), and I just shipped tone that adapts to B2B vs B2C customers. On recovery rate: I'm early, and I'd rather not quote a shiny number that's really Stripe's retries doing the work — someone else in this thread made exactly that point, so I'm building the honest version (lift vs a holdout) before I claim a figure.
one metric I'd add: incremental recovered revenue, not total. Stripe's Smart Retries already claw back a decent chunk of these on their own, so counting every eventually-successful charge as a save overstates what the tool actually adds. the honest version is lift measured against a holdout left on plain Smart Retries, otherwise you're paying a cut for dollars that would've landed anyway. good problem to be working on though, involuntary churn is about the most winnable revenue there is.
This is the sharpest note in the thread and you're 100% right — counting every eventually-successful charge as a "save" is misleading because Smart Retries would land a chunk anyway. I'm building it exactly as you describe: an optional holdout left on plain Smart Retries as a control, so the number I report is the incremental lift, not the gross total. I'd rather show a smaller honest number than a big misleading one. Thanks for pushing on it.
To answer your second question: Stripe Smart Retries plus the card account updater do most of the work for me, and email is the last resort rather than the first. One thing worth splitting out though: in the EU a big slice of 'failed' recurring charges aren't insufficient funds, they're SCA/3DS challenges the customer never completes. Those don't need a warmer dunning email, they need a re-authentication link, and if Revova buckets them with expired cards the recovery rate on EU merchants will look worse than it should. Are you separating hard declines from authentication failures in the Lost Revenue Finder? That split is usually where the recoverable money sits.
Really important one, and you're right that lumping SCA failures in with hard declines makes EU recovery look worse than it is — they're a completely different fix. You actually prompted me to ship it: authentication failures are now their own class. They get a "confirm this with your bank" flow with the re-auth link (the hosted confirmation page) instead of a "replace your card" email, and the historical scan surfaces that slice separately so you can see where the easy money sits. The card-account-updater point is well taken too — email should be the last resort, not the first. Appreciate the depth here.
Good. One layer under that, if you want the scan to earn its keep: a high SCA slice on recurring charges usually points upstream, to setup.
Off-session renewals on a properly authenticated mandate fall outside SCA as merchant-initiated transactions, so a challenge there should be the exception. If an EU merchant's renewals are getting challenged in volume, the mandate probably wasn't authenticated up front, or off_session isn't being set. No email fixes that. The next renewal fails the same way.
That would make the Finder diagnostic instead of only remedial: here's your recoverable slice, and here's why it keeps happening. Same move as surfacing the leak in the first place.
This is a genuinely great insight and you're right — a high SCA slice on recurring charges is a symptom, not the disease. Properly authenticated off-session renewals shouldn't be getting challenged; if an EU merchant sees volume there, the mandate wasn't authenticated up front or off_session isn't being set, and no dunning email fixes that — the next renewal fails the exact same way. You've basically described the next thing I want to build: make the Lost Revenue Finder diagnostic, not just remedial — "here's your recoverable slice, and here's why it keeps happening, so you can fix it upstream." Surfacing the root cause is the same move as surfacing the leak in the first place. Really appreciate you going a layer deeper.
If it helps you scope that build, the detection is cheaper than it sounds. On the failed off-session renewals, bucket the ones where Stripe hands back "authentication_required" as the decline code, then check whether that customer's saved payment method has a mandate set up for off-session use. Code present and no valid off-session mandate means "fix the setup upstream", not "send a re-auth email". And it predicts recurrence for free: a genuine one-off step-up won't repeat, but a broken mandate throws the same code next month. It's all sitting in the objects you're already pulling, so the diagnostic column is basically a join, not a new data source. Keen to see where you take it.
One thing I'd keep testing is whether you're selling revenue recovery or operational confidence.
Recovering lost payments saves money once. Giving founders confidence that revenue isn't quietly leaking every month changes how they think about the business. That feels like the stronger position over time.
This reframed how I think about the product, honestly. Recovering a payment saves money once, but the durable value is the founder never having to wonder if revenue is quietly leaking. I just leaned into exactly that — the pitch is shifting from "we recover X" toward "you never have to check; it's watched 24/7." It's also the better answer to "why is this a monthly subscription and not a one-time tool." Most useful strategic note I've gotten — thank you.
I like where that led.
One thing I'd keep watching is whether founders eventually describe the product as helping them recover failed payments or as helping them stop thinking about failed payments altogether.
Those sound similar, but the second means the product has become part of the business's operating infrastructure rather than another revenue optimization tool.
Helping them stop thinking about failed payments altogether — that's the north star, and you put it better than I had. The moment it becomes infrastructure rather than a tool people check, the whole relationship changes: it's not a line item they re-evaluate, it's something they'd feel the absence of. It's also the honest answer to "why monthly and not one-time" — you're not buying a recovery, you're buying never having to think about it again. I'm literally reworking the positioning around this. Thank you.
I'm glad it resonated.
Reading your reply gave me one thought about what changes when a product moves from being a recovery tool to becoming infrastructure. I don't think I could explain that properly in a thread without oversimplifying it.
If you're interested, what's the best email to reach you on?