I built a tool that takes 25% of the money it recovers — and $0 if it recovers nothing
Failed payments quietly kill 5–10% of SaaS MRR. Most founders either ignore it or pay $500+/mo for enterprise dunning tools (Churnkey, Baremetrics Recover) that don't make sense under $50k MRR.
So I built RecoverFlow: connect your Stripe account via OAuth (read-only-ish, 2 minutes, no card), and it classifies every decline, schedules payday-aware retries, and sends dunning emails. Attribution is built in — if a payment comes back on its own, you're never charged for it.
Pricing is the part I'm most curious for feedback on: 25% of what we recover, nothing up front, $29/mo floor after your first 30 days. It only wins when you do.
Happy to answer anything about the decline-classification logic — some of the Stripe decline codes are wild.
Trending on Indie Hackers
The free 90-day backtest is the smartest thing on the page — I'd lean on it even harder than the pricing. Everyone here (rightly) likes the "only pay on what we recover" model, but the thing that actually gets a nervous founder to connect Stripe is seeing the real dollars you'd have recovered from their own history before they risk anything. That flips "trust a new tool with my billing" into "look what I'm already leaving on the table." It's in your hero already, but I'd make it the single loudest promise on the whole page.
I actually like the pricing model because it aligns your incentives with the customer's. If you recover nothing, they lose nothing. I imagine the biggest challenge will be earning enough trust for someone to connect their accounts in the first place. Curious how you've been approaching that.
The "you only pay on what I actually recover" framing is the right hook for this, failed-payment churn is exactly the kind of silent leak founders underprice. The thing I'd want nailed before the 25%: can you cleanly attribute a recovered payment to your retry and dunning versus one that would have gone through on the card's own next attempt anyway, so the take rate is provably earned?
Yeah thats a completely valid question and one that I spent a lot of time making sure I had a real answer for. Someone else here also had that question so heres what i told them:
On attribution: it's webhook-driven, not polling. We listen for "invoice.paid" on invoices we're already tracking as failed, and if that event lands before we've fired our own retry/dunning attempt, we mark it as a self-recovery and just don't charge our fee on it. The race condition that actually bit me isn't Stripe's webhook timing so much as our own idempotency, making sure we don't retry a charge that Stripe already recovered a few seconds earlier via its own Smart Retries. Ended up needing a short "grace check" against the invoice status right before we act, not just trusting our last-seen webhook state, that way we let it see if it would've/will come back on it's own during that grace period, and even if recoverflow could've gone and recovered it, we don't stake a claim to any payments that could've easily come back on their own.
So even though it might hurt the potential profits of recoverflow, I feel like the trust gained by setting a high bar for what qualifies as a payment we truly recovered, is more important to have.
That invoice.paid gate is a clean line, honest attribution baked into the pricing is exactly what makes the 25% defensible. The edge I would worry about: a card's own retry and yours firing within the same short window, where it is genuinely ambiguous who recovered it. Do you see much of that gray zone in practice, or is the timing usually clean enough that it stays obvious which side got there first?
Failed payments are such a perfect example of exactly the thing I built FounderFlow around, revenue quietly leaking out without ever showing up as a complaint or a conversation (I'm the founder, mentioning since it's directly relevant here). Nobody emails you angry that their card got declined, they just churn silently and you find out weeks later staring at a spreadsheet. The pricing model is smart too, only getting paid on real recoveries means you're never tempted to inflate what you're "catching." Curious what percentage of declines you're seeing are genuinely unrecoverable, expired card, closed account, versus just needing better retry timing.
Appreciate that, the silent part is exactly what got me too. Nobody complains about a decline, it just shows up as a smaller MRR number three weeks later.
Honest answer on the split: my sample is still small (early days), so take this as industry pattern more than my own production stats: roughly 20-30% of declines are true hard declines (closed account, stolen card, blocked) that we never retry at all. The majority of what's left is insufficient funds, which is mostly a timing problem, retrying near payday instead of on a blind fixed schedule is where most of the recoverable money actually is. Expired cards sit in the middle: unrecoverable by retry alone, but pretty recoverable when a dunning email catches the customer before they even notice.
FounderFlow looks interesting btw, same family of problem, leaks that never make a sound.
Appreciate you saying that, and thanks for the detailed breakdown above too, that hard decline vs insufficient funds vs expired card split is going to stick with me. Yeah, exactly the same family, ours is more about surfacing which of those quiet leaks across a business actually need a decision today instead of just showing up as a lagging metric later. Good luck with RecoverFlow, the fee-only-on-recovery model is a smart way to remove the trust question upfront.
This is the other half of churn most people don't segment for — you're catching involuntary (card failures), which is a different failure mode from voluntary cancels where the customer is actively choosing to leave. I've been heads-down on the voluntary side with CancelKit (exit-survey + save offer right on the cancel button), and most founders I talk to have zero visibility into either bucket until the MRR is already gone. Curious how you handle attribution when a payment recovers on its own late — is that a Stripe webhook race you had to design around, or straightforward interval polling?
Yeah, totally different failure mode: one's the customer ghosting the product, the other's the product ghosting the customer. Glad someone's covering the voluntary side, feels like most tools pick one and ignore the other exists.
On attribution: it's webhook-driven, not polling. We listen for "invoice.paid" on invoices we're already tracking as failed, and if that event lands before we've fired our own retry/dunning attempt, we mark it as a self-recovery and just don't charge our fee on it. The race condition that actually bit me isn't Stripe's webhook timing so much as our own idempotency, making sure we don't retry a charge that Stripe already recovered a few seconds earlier via its own Smart Retries. Ended up needing a short "grace check" against the invoice status right before we act, not just trusting our last-seen webhook state.
CancelKit is a smart wedge, by the way, exit-survey + save-offer right on the cancel button is exactly the kind of thing that should exist by default and doesn't.
I like that you've aligned pricing with the uncertainty founders feel around failed-payment recovery.
Most early SaaS teams know failed payments matter—they just don't know whether the recovery is worth paying for. Charging based on recovered revenue makes evaluating the product a much simpler decision than asking founders to bet on an upfront subscription.
Yeah, totally different failure mode: one's the customer ghosting the product, the other's the product ghosting the customer. Glad someone's covering the voluntary side, feels like most tools pick one and ignore the other exists.
On attribution: it's webhook-driven, not polling. We listen for "invoice.paid" on invoices we're already tracking as failed, and if that event lands before we've fired our own retry/dunning attempt, we mark it as a self-recovery and just don't charge our fee on it. The race condition that actually bit me isn't Stripe's webhook timing so much as our own idempotency, making sure we don't retry a charge that Stripe already recovered a few seconds earlier via its own Smart Retries. Ended up needing a short "grace check" against the invoice status right before we act, not just trusting our last-seen webhook state.
CancelKit is a smart wedge, by the way, exit-survey + save-offer right on the cancel button is exactly the kind of thing that should exist by default and doesn't.
I'm glad it resonated.
Reading your reply gave me one thought about what happens once recovered revenue becomes the product's primary proof of value. I'd rather explain it in the context of what you're building than try to condense it into a few comments.
If you're interested, what's the best email to reach you on?
Yeah of course, [email protected] works best to reach me! Also I realized the reply i left to your comment was meant for a different one lmao, so we can def go into more depth about anything over email or here if you want.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.