Some of your RevenueCat subscribers didn't choose to leave. You just never found out.
Some of them paid. Used the product. Never complained. And one day just stopped showing up because a card declined and nobody caught it.
That subscriber didn't leave. They got dropped.
On RevenueCat this is messier than on Stripe. Apple and Google own the billing layer, so you can't retry a payment directly. You can't see card expiry dates. You just get a webhook saying the payment failed and then... what?
Most founders I've talked to either send one generic email and hope for the best, or just accept it as a cost of being on mobile.
Curious what people are actually doing here. A few things I'd genuinely like to know:
Are you sending anything when a payment fails? Manual, automated, anything?
Have you tried building a dunning sequence on top of RevenueCat? What broke?
Do you even know what percentage of your monthly losses are failed payments vs people who chose to cancel?
That last one is the one most people can't answer. And it matters because the fix is completely different depending on which problem you actually have.
We built something for this (Recurflux) but honestly asking because I want to know what people are already trying, what's working, and what's just frustrating.
get your ROI for RevenueCat: " https://recurflux.com/resources/revenuecat-churn-calculator "
Drop a comment. Genuinely curious.
That last question — do you know what % of losses are failed payments vs voluntary cancellations — is the one that kills most subscription analytics.
The fix starts at data collection: you need a tracking layer that tags each subscription end with an intent signal at the moment the webhook fires. "Failed payment" vs "user-initiated cancel" vs "lapse" need to be distinct values in your data model, not something you reconstruct later from timestamps.
Without that tagging at source, you end up building fragile post-hoc logic that falls apart every time Apple or Google tweaks their webhook timing. I see this exact pattern with SaaS clients — they have the raw RevenueCat data but can't segment churn meaningfully because nobody tagged intent at ingestion time.
Once intent is tagged properly at the row level, the dunning question becomes easy: filter to "failed payment" cohort, build your sequence, measure recovery rate. The analysis that was impossible becomes trivial.
For anyone building out their subscription data layer, my free SQL diagnostic scripts are useful for catching gaps like this early → https://growthwithshehroz.gumroad.com/l/psmqnx
This is a sharp problem because you’re not framing churn as one bucket. “Chose to cancel” and “got dropped by billing failure” are completely different losses, but most mobile founders probably treat both as the same revenue leak.
The strongest angle here is not just dunning emails. It is failed-payment intelligence for RevenueCat: knowing which subscribers were recoverable, why they fell out, and what recovery path fits each case. That makes Recurflux feel more like a revenue recovery layer than a notification tool.
One thing I’d watch is the name. Recurflux makes sense once explained, but it feels a little technical for a product that is really about recovering paid users and protecting subscription revenue. If this expands beyond RevenueCat into broader subscription recovery, Beryxa .com would give it a cleaner SaaS/analytics brand.