Show IH: RetryFix: Get your failed Stripe payments back on autopilot (10% fee)

✅ RetryFix Update — 3 weeks after the Show IH (still building in public)

Hey everyone,
First off — thank you for the incredible engagement on the original Show IH post. 50+ comments, thoughtful feedback, and several of you reaching out about trying it — I really appreciate it.

Since April 19 I’ve been heads-down shipping smaller but meaningful improvements. Nothing flashy on the marketing side yet, but the product itself is noticeably more polished and production-ready.
What shipped recently:

Fully functional Account page — you can now update your payment method directly through Stripe’s Customer Portal, see your current card, manage subscription details, update email, and reset password. Everything feels clean and reliable now.
Better payment method display after using the Stripe portal (no more blank states).
Ongoing work on the Stripe Connect OAuth flow (this is part of a larger series — the last two PRs just landed the config foundation and environment variables). The goal is to make the “Connect your Stripe” step completely seamless and automatic in the near future.

Various stability and reliability tweaks across auth, email delivery, and backend config.

The core product (automatic failed-payment recovery + smart dunning) continues to work solidly in my own testing. I’m still running everything on test data for now, but the foundation is rock-solid and ready for real merchants.

Next up
I’m continuing the OAuth/auto-enrollment series (7 tickets total) while also keeping the current onboarding experience excellent for anyone who wants to jump in today.
Special offer still stands

If you’re an Indie Hacker and want to try RetryFix, reply here or email me — I’m still giving the first month free on the Performance plan (10% of recovered revenue, zero upfront) to the first few people from this community.

Would love any feedback on the Account page or the direction of the OAuth work.
Thanks again for following along — more updates soon as we keep shipping.

— Paul

✅ Day 14 Update – Account page is now fully live
Hey everyone,
The new Account page is live for all users.
You can now:

See your current plan + next billing date
View your saved payment method (brand + last 4 digits)
Update your payment method via Stripe
Change your email address
Reset your password

I’ve added 4 new screenshots of the live Account page + email change flow directly into the main post (see above).
Would love your feedback specifically on the Account page:

Does the payment method display feel clear and trustworthy?
Is the overall layout clean and professional enough?
Any UX tweaks you’d suggest?

Full app: https://retryfix.com
Thanks again for all the earlier feedback!

Day 10 Update – Account page is now live

Hi everyone,

Quick update: the Account page is now fully live in production.

Users can:

• View their current subscription and next billing date
• Update their payment method via Stripe
• Change their email address
• Reset their password

The email change flow took longer than expected to get right. Because Supabase uses a single email template for both confirmation steps, both links land on the same callback path. After trying (and failing) to force two distinct messages, I simplified the approach: both confirmation links now show the same clear message:

✅ Email successfully updated!
To fully complete the change, please also click the confirmation link sent to your new email address. Both confirmations must be completed.

It’s reliable, transparent, and sets the right expectation for users.

Tomorrow I’ll share 4 new screenshots showing the full Account page and the email change flow in action.

Next up is polishing Stripe Connect onboarding and some onboarding improvements.

How’s everyone else’s week going?

Thanks For Sharing Looks very Interesting.

This is a great problem to solve , failed payments are one of those silent revenue leaks most founders underestimate. I like the performance-based pricing, feels aligned with outcomes. One thing I’m curious about like Are you seeing better recovery from smart email timing/content or just repeated retry attempts?

interested

This solves a real pain I actually went through a few days back. I spent time building out a past_due grace period banner and "fix billing" CTA for my own SaaS because I realized how much revenue just quietly disappears when a renewal fails and nobody notices.
The 10% of recovered revenue model is smart pricing, removes all friction from the buying decision. "You only pay when we win" is one of the strongest value props you can have.

Honest question: How do you handle the case where a customer has already cancelled intentionally but their card just happened to fail on the last invoice? Do you have a way to distinguish "card failed, customer still wants the service" from "card failed, customer was already done"? That false positive scenario would be my biggest concern before plugging this into a subscription business.

Overall I could see myself actually using this once I'm generating enough volume for failed payments to be a real problem. Well done on everything you've done so far! Cheers!

Nice angle, and the performance pricing is the strongest part.

A few conversion tweaks I’d test fast:

1. The homepage hero should lead with the money already being lost, not "automatically retries and fixes failed Stripe payments." Something closer to "Recover failed Stripe revenue without adding another ops job" feels more urgent.
2. "Start free trial" is a little mismatched for a founder who still doesn’t know what setup/risk looks like. I’d test a primary CTA like "See recovered revenue estimate" or "Preview my failed invoices" and keep trial/signup as the next step.
3. The calculator is doing real work, but it needs to sit much closer to the hero. Right now the page asks for trust before showing the concrete payoff.
4. The testimonial area reads placeholder-ish because the quotes are generic and unattributed. Even one real mini proof point with business type + amount recovered would likely outperform three broad quotes.
5. Since this touches billing, I’d surface the "we never touch your money" trust language much earlier, probably directly under the hero CTA.

If helpful, I do very short teardown-style homepage audits for founders here, including the exact trust/CTA leaks that suppress first conversions: https://roastmysite.io/go.php?src=external_manual_ih_retryfix_failedpayments_apr20_usd_presell_hv

This is an interesting model — taking a % of recovered revenue instead of a flat subscription fee aligns incentives perfectly. Failed payments are silent revenue killers for SaaS, and Stripe’s native retries only go so far. Two questions: 1) Does RetryFix handle dunning logic beyond simple retries (e.g., smart retry scheduling, card updater integration)? 2) How do you prevent double-charging when we already have some retry logic in place? Love the IH approach — congrats on the launch.

Paul, the pay-per-recovery pricing is an absolute no-brainer. Perfectly aligned with
how indies think about risk. Nice ship.

On the naming note someone raised above: I'd actually keep it. "RetryFix" reads
exactly like what someone would type at 3am when Stripe pings them. Utility beats
clever when your buyer is a stressed founder.

We're aiming at basically the same people (SaaS founders with Stripe accounts). I'm
building StatusPageBuddy, free public status pages for indie devs, 60s setup, no
YAML. If any of your merchants ever ask about a public page, remember I exist.

Rooting for this.

The "pay-per-recovery" model is a total no-brainer for founders, Paul. Losing revenue to failed Stripe payments is a silent killer for SaaS, so offering a 10% performance plan makes it an easy "yes" for anyone looking to plug their churn holes.

I’m currently running a project in Tokyo (Tokyo Lore) that highlights high-utility tools just like RetryFix. Since you're focused on helping businesses win back lost revenue, entering this competition could be a perfect way to demonstrate your recovery logic to a live field of builders.

Oh this has some potential in my books!

Clear problem and pricing model — that part is solid.

One thing I’d watch early though:

in this space, a lot of tools end up competing on the same promise — “recover failed payments.”

When that happens, people don’t choose based on features — they choose what they remember or trust first.

“RetryFix” works functionally, but long-term the question is:
does it feel like a default category name, or just another tool in the list?

Seen products here plateau not because they didn’t work — but because they never stood out in memory.

If this starts scaling, that layer becomes more important than expected.