There's one screen in Stripe I quietly avoided for months: the failed charges tab.
I'd check MRR. I'd check new signups. I'd refresh those out of nervous habit. But the failed payments? I always told myself I'd "get to it later."
Looking back, I avoided it because it felt like a scoreboard for things I couldn't control. New signups feel like a win I earned. Failed charges feel like money slipping out a hole in the boat, and staring at the hole doesn't feel productive.
Then one evening I actually sat down and went through it line by line. And the rows were more specific, and more human, than I expected:
None of those three people decided to leave. But in my head I'd already filed them under "churned."
That's the part that got me. I'd been grieving them as lost customers, when most were closer to a delivery that failed at the door than a customer walking away. And each type needs a totally different response: the expired card needs a heads-up, the insufficient-funds one needs a smarter retry, the auth one needs a "confirm this was you" nudge, not a "replace your card" email.
I'm early and I won't throw out stats I can't back. But the general industry ranges (failed payments quietly costing something like 5-10% of revenue) stopped being abstract the moment I saw my own rows.
Going through it line by line is literally what made me start building Revova (https://revova.io) around this problem. The first thing I made was almost selfish: a scan that just shows you your own number, because I wanted to see my own damage first.
So I'll go first on the vulnerability: have you actually opened your failed charges tab recently and read it line by line? Or is it the screen you keep meaning to get to?
This is the flip side of what I see building CancelKit — the involuntary churn you're describing (expired card, insufficient funds, auth required) needs a completely different playbook than someone who deliberately clicks cancel. The person with the expired card never made a decision to leave; the canceller did. Conflating both into one "churned" bucket is how teams end up sending win-back emails to people who were never gone. Curious — does Revova segment retry timing by decline code (e.g. wait a few days for insufficient funds vs. an immediate nudge for auth required)?
The line-by-line pass is useful once, but the product test is whether the scan turns rows into ranked recoverable revenue. I'd show count and value by failure reason, then one next action per bucket. Otherwise the failed-charges tab has just been rebuilt with nicer copy.