Last month a founder in Bangalore shared her Razorpay dashboard with me and asked for a second opinion on her churn. Her subscription count had barely moved, cancellations looked manageable, and new signups were still landing every week. On that screen, nothing looked broken.
So we stopped looking at cancellations and looked at payment attempts instead. That is where the leak was.
Your churn number answers the wrong question
Your churn report tells you who cancelled. It does not tell you who quietly stopped paying. In Indian SaaS those are two different problems, and only one of them shows up in the number most founders quote.
A cancellation is a decision. A failed payment is a silence. Only one of them shows up in your churn number.
A failed payment stays silent until enough failed invoices stack up behind it. The customer may still want the product. The mandate may still be alive. The subscription may still be fully recoverable. The money just has not reached the bank.
Razorpay Subscriptions is good billing infrastructure: define a plan, attach a customer, and it charges on schedule across cards, UPI AutoPay, and e-mandate, with webhooks and built-in retries. That plumbing works. But billing infrastructure is not churn visibility. The dashboard question is not how many customers cancelled? It is how much committed MRR was scheduled, how much was collected, how much failed, and how much of the failed amount came back?
The rail itself manufactures silence
The reason this matters more here than in the Stripe-based playbooks is that the Indian rail produces more failure — and more silence — by design. Two numbers make the point. UPI AutoPay mandates crossed 1.27 billion in November 2025, roughly ten times where they sat at the start of 2024 (Razorpay's own figures). And in August 2025, depending on the bank, between 55% and 90% of UPI AutoPay debit attempts failed on first execution (NPCI data, reported by Mint and Business Standard). That second figure is a debit-attempt rate for a single execution, not a churn rate — most of it is soft, insufficient-funds declines that clear on a later try, and around 20 million mandates are revoked every month, largely on low balances.
There is a quieter complication too. Since 1 August 2025, NPCI holds UPI AutoPay executions during peak hours — 10am to 1pm, and 5pm to 9:30pm IST — and releases them in the non-peak windows. A debit that looks failed inside a peak window may simply have been queued, not declined. Treat that as a failure and fire a message at the customer, and you have created a problem that did not exist yet.
Reconcile the two lifecycles, every cycle
The fix is not to stare harder at the churn percentage. It is to reconcile the subscription lifecycle against the payment lifecycle every cycle.
One recovery is really two numbers
Razorpay makes one part of this concrete. After four consecutive failed charge attempts a subscription moves from pending to halted and stops retrying. Halted is the moment most worth watching. But here is the detail that quietly distorts recovery reporting: when a halted subscription comes back to active, the unpaid invoices from the halted period are not charged automatically. Only future cycles resume. That splits one recovery into two numbers that should never be reported as one:
Subscription saved — the customer is active again, and future MRR is protected.
Past MRR recovered — those specific halted invoices were actually collected.
You can save the subscription and still never recover the rupees that failed while it was halted — especially on domestic cards, where Razorpay does not permit a programmatic manual charge and you have to send a fresh payment link. If your dashboard shows one blended recovered figure, you are almost certainly overstating one of these.
The Stripe-based writing on all this is worth reading — Churnkey's retention benchmarks, Recurly's dunning data — but it grew up on card-first billing, where a retry and a customer message are nearly the same motion. In India they are not. A retry is the gateway asking the bank again. Dunning is you explaining to the customer what broke and what to do about it.
Where SubsShield fits
This is the gap SubsShield sits in — not to replace Razorpay or Cashfree, but to read the failure after the gateway reports it, classify what actually broke, and decide what the customer needs to do next. Often that decision is to stay quiet while the gateway's own retry runs, rather than message too early. It diagnoses and communicates; it does not move money.
So here is the question worth taking back to your own dashboard: when did you last compare cancelled MRR against failed-and-unrecovered MRR in the same billing period — and could you split that unrecovered number into subscription saved and rupees actually collected?
