The problem, with real numbers
If you run a Stripe-native SaaS between roughly $3k and $30k MRR, somewhere between 5% and 10% of your monthly revenue quietly disappears to failed cards. Expired cards, insufficient funds, the usual. On $10k MRR that's $500-$1,000 a month walking out the door before you even notice.
The fix is known: smarter retries based on the decline code, plus a hosted page where the customer can update their card in 30 seconds. That second piece recovers more than retry timing ever will.
Why the existing options don't fit this band
Churnkey is genuinely good, but the floor is about $3k a year and they take 1-3% of every recovered dollar on top. That math only works once you're past $30k MRR. Stunning is cheaper but the UX feels frozen in 2017 and the config is scattered. ProfitWell Retain killed its free tier. Baremetrics Recover has been coasting for years. If you're below $30k MRR you basically write your own retry cron job and hope.
What I'm building
Nanokept. Flat pricing: $49, $149, or $349 a month by your MRR band. Never a percent of recovered revenue.
What's in the box:
- Stripe Connect OAuth install, read-only, about 90 seconds
- Decline-code-aware retries: soft declines retry on day 1/3/5/7/14, hard declines stop auto-retrying and trigger a branded customer email
- Hosted card-update page per failed invoice
- Idempotency keys on every Invoice.pay call so a network hiccup never double-charges anyone
- Works against the Stripe sandbox from day one, which I was surprised to find most competitors still don't
Rails 8, SolidQueue for the retry jobs, EU-hosted on Hetzner with Cloudflare in front. I'm solo, based in Bosnia, and billing through Lemon Squeezy as merchant of record since I can't take Stripe directly from here. Previous project was AccessGuard (getaccessguard.com).
Status
Landing page and waitlist are live at nanokept.com. Product is mid-build, targeting end of May 2026 for the first paying cohort.
What I'd like from you
Two questions for anyone running a Stripe SaaS in this MRR band:
- What's your actual recovery rate right now, and do you even measure it?
- If you've looked at dunning tools and bounced off them, what was the dealbreaker: the price floor, the revenue share, the setup time, or something else?
Link: https://nanokept.com. Happy to answer anything in the comments.
Top comments (1)
Answering your two questions directly, since they're the right ones to ask:
Most teams in this MRR band don't measure recovery rate at all — and the ones that do usually measure it wrong, as a single blended number. The number that actually drives decisions is recovered revenue per failed-invoice cohort, split by decline reason. A blended 20% can hide that you're recovering most expired cards and zero fraud blocks. If you build the dashboard, build that split first.
The dealbreaker is the percentage-of-recovered-revenue cut, for exactly the reason you name: the vendor taxes the dollars it claims to save you, so the better it works, the more you pay. A flat fee per MRR band aligns incentives — the tool makes the same money whether it recovers 10% or 40%, so its only lever is being genuinely better.
One build note: your day 1/3/5/7/14 soft-decline ladder is sensible, but consider letting the decline reason shift the timing, not just the tier — insufficient_funds near month-end wants a retry after the 1st.
Disclosure: I work with Swipe Again (failed-payment recovery). Flat pricing for this exact reason — the % model never sat right with us either.