The Number in Your Razorpay Dashboard That Makes Churn Look Smaller Than It Is

Two weeks ago, a founder pinged me about flat MRR. We pulled up his Razorpay dashboard together. Cancellations were low. Active subscriptions were climbing. Signups were still coming in. On the surface, nothing looked broken — and yet MRR had barely moved in eight weeks. ₹3.1L of expected subscription revenue was sitting in retry logs, expired mandates, and unrecovered payment attempts. The subscriptions were active. The customers were still in the product. The money was not in the bank.

He had been looking at cancellations. I asked him to look at payment attempts. That is where the real leak was.

The separation Razorpay tracks but doesn't surface

Razorpay Subscriptions tracks two things in parallel: subscription state and payment state. The default dashboard view surfaces subscription state.

A subscription marked "Active" means the mandate exists and the billing schedule is running. It does not mean the last invoice cleared. A mandate with confirmed status means the customer agreed to recurring debit at setup. It does not mean the next debit will succeed.

A cancellation is explicit. A failed payment is often invisible — until enough failed invoices collect behind it. The customer may still want the product. The mandate may still exist. The subscription may still appear recoverable. But the money has not reached the bank.

This is the gap most Razorpay dashboards don't close on their own. And in India, the gap is wider than it looks — because the payment rail itself introduces failure modes that Western card-first billing doesn't have.

Why India's payment rails add layers to this problem

A card mandate in India has to be set up against RBI's tokenization requirement. Any transaction at or above ₹15,000 requires a fresh Additional Factor of Authentication — which means retrying a ₹20,000 annual plan charge without customer action will fail again, every time. The customer's bank must send a pre-debit notification at least 24 hours before each UPI Autopay debit. Customers can revoke e-mandates from their bank app without warning the merchant.

The rail itself is under stress. Per NPCI data, between 55% and 90% of UPI Autopay debit attempts failed across major banks in August 2025 — a debit-attempt rate, not a churn rate, but a clear signal that "recurring payment" in India still means "fails first, recovers later" for a sizeable share of attempts.

Each payment rail creates a different failure mode — and a different recovery path:

The failure code is the routing input for recovery. Most founders never look at it — not because they don't care, but because nothing in the standard dashboard asks them to.

What a healthy collection view actually measures

A cancellation report tells you who chose to leave. It cannot tell you how much committed MRR was attempted, how much failed, which failures were retryable, and how much was recovered before it was counted as lost.

Most founders I talk to look at cancellation MRR every month. They cannot tell me what failed-payment MRR looked like in the same period — not because the data isn't there, but because their dashboard isn't structured around it. The number that matters most for retention sits in webhook logs, not in the gateway's headline view.

For every billing cycle, six questions tell the real story:

A retry is not just a retry

When a payment fails inside Razorpay, the next action is not always to retry.

It may be a bank-side failure that clears on retry. It may be an expired mandate that needs re-registration. It may be a pre-debit notification issue specific to UPI Autopay. It may be a customer who never saw the email but would have responded to a WhatsApp message. It may be a ₹20,000 annual charge where the customer needs to authenticate again because of AFA threshold rules. It may be a UPI Autopay attempt that was queued by NPCI's peak-window rule and isn't actually failed yet.

India's involuntary churn has sub-categories that each require a different recovery response:

Treating all three the same way — another retry, another email — is why recovery rates stay low even when the infrastructure is in place.

Where SubsShield fits

SubsShield sits between the Razorpay webhook and the customer communication layer. When payment.failed fires, SubsShield reads the failure code and mandate state, routes the event to the right recovery path — retry, WhatsApp action, email, or mandate re-registration — and tracks whether the payment cleared.

It is not a replacement for Razorpay. It is the layer that handles what happens after the gateway reports a failure, because the gateway's job ends there.

If you pulled your Razorpay webhook log for the last 30 days and grouped failures by failure code — not by subscription ID — how many distinct recovery paths are actually running in your stack, and how many of those failures are going through the same retry loop regardless of why they failed?