3
9 Comments

I'm building a tool that recovers failed Stripe payments. The hardest part isn't the tech — it's trust.

I'm building Lirova — a tool that recovers the revenue SaaS quietly loses
to failed Stripe payments (expired cards, declines, bank hiccups).
Pre-launch, sharing the journey here because I keep hitting one wall I
didn't expect.

First, why this problem is bigger than most founders think:

  • 20-40% of all churn is involuntary — the customer never chose to leave,
    their payment just failed
  • Expired cards alone cause ~42% of failed payments
  • Stripe's default retries recover around 35%. The rest lapses silently
  • For most subscription SaaS that's 5-9% of MRR walking out the door every
    month, unnoticed

The tech was the easy part. Decline-code classification (each failure
reason gets its own retry strategy), smart retry timing, a recovery email
sequence, and money-safety logic that stops on hard declines so you don't
burn card-network limits.

Here's the wall: trust.

I'm asking founders to connect their Stripe — their actual money and
billing. Even with read-only access first (it can't charge cards or move
money until they explicitly turn automation on), the hesitation is real and
100% rational. Why would anyone give a brand-new, no-reviews tool access to
the most sensitive part of their business?

I'd hesitate too.

So my question to the community — especially anyone who's sold
infrastructure, fintech, or anything touching payments or sensitive data:

How did you get your first few customers to trust you with sensitive access
when you had zero track record? Free pilots? Hand-holding? A specific
guarantee? Open-source? Something else entirely?

Genuinely trying to learn, not pitch. If anyone runs a subscription
business on Stripe and wants to poke at the demo (sample data, no signup),
it's at lirova.app/demo — would value brutal feedback on whether the
value/trust balance lands.

Thanks 🙏

(For context — my profile here still shows Pillwise, an earlier project.
Lirova's the new thing I'm heads-down on now.)

on June 23, 2026
  1. 1

    The thing I'm not sure about is whether trust is actually the obstacle you're running into, or whether it's becoming the explanation because it's the most visible one.

    Reading this, I could imagine a founder hesitating for several very different reasons and expressing all of them in roughly the same way.

    The reason that stood out to me is that the next few company decisions probably look very different depending on which of those reasons is actually driving the hesitation.

    1. 1

      That's a fair reframe. I've been lumping a few different things under "trust" when they're actually separate problems with different fixes.
      From conversations so far, the hesitation seems to come from at least three distinct places: (1) "I don't know you" — solved by transparency and early pilots; (2) "I don't understand what you actually do to my Stripe" — solved by read-only access and showing the exact API calls; (3) "what if you break something during a retry" — solved by money-safety logic and a clear rollback.
      You're right that conflating them leads to wrong solutions. Someone worried about #2 doesn't need a SOC 2, they need to see the code. Someone worried about #1 doesn't care about the code at all.
      Still figuring out which one shows up most often at first contact.

      1. 1

        That’s a useful breakdown.

        I might be looking at something slightly different though — less about splitting trust into categories and more about how those categories influence what decision gets made next.

        If you’re open to it, happy to continue this over email since it’s getting a bit long for thread.

        What’s the best email to reach you on?

        1. 1

          ivan@lirova.app — happy to continue there.
          Quick context so the conversation has ground: I'm pre-launch, no paying customers yet, so my current thinking on trust is still hypothesis more than pattern. Would be curious what angle you're actually looking at — the category framing or something more specific to how early-stage B2B tools earn access to sensitive infrastructure.

          1. 1

            Hey — the email bounced (says address doesn’t exist).

            Can you double-check it or share an alternate one?

            1. 1

              ohh, sorry, its older
              here new ivan.balias@lirova.app

              1. 1

                Just sent you a note.

  2. 1

    The trust angle is the real moat here. Have you considered SOC 2 compliance early on, or live demo walkthroughs where you show the audit trail real-time? The 42% of failed payments from expired cards is a huge TAM. Good problem to solve.

    1. 1

      The audit-trail-in-real-time idea is sharp — showing exactly what the tool sees and does, live, turns the "black box touching my money" fear into something you can watch. Hadn't framed the demo that way; adding it.

      SOC 2 I've gone back and forth on. It's clearly the right signal for mid-market and up, but at pre-launch with zero customers it feels like spending months on a certificate before I've proven anyone wants the core thing. My current bet is: earn the first few founders with radical transparency (read-only, Stripe OAuth, open about being early), then pursue SOC 2 once there's revenue to justify it and customers who actually require it. Curious whether you think that ordering is a mistake — did SOC 2 early ever unlock deals you couldn't have closed otherwise?

      And yeah, the expired-card TAM is what hooked me too — it's such a mechanical, unglamorous leak that almost everyone just eats.