Why Your Razorpay Dashboard Shows Healthy Churn While Collection Revenue Leaks
A Mumbai-based B2B SaaS founder pulled up their Razorpay Subscriptions dashboard last quarter and saw the number that mattered: cancellations were low, active subscriptions were climbing, and new signups were arriving on schedule.
MRR should have been growing. Instead it had been flat for two months.
The answer wasn't in the cancellation report. It was in the failed payment log — ₹2.8L in subscription attempts that had not cleared, sitting across expired mandates, gateway failures, and retry exhaustion. The subscriptions were active. The customers were still using the product. The money was not in the bank.
What Razorpay shows you vs what it doesn't
Razorpay Subscriptions tracks two things in parallel: subscription state and payment state. The dashboard prioritises 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.
This separation matters because the failure modes in India are specific to the payment rail — and each rail creates a different recovery problem.
Payment rail | How it fails | What the Razorpay dashboard shows |
|---|---|---|
UPI Autopay | Insufficient funds, revoked mandate, pre-debit notification not sent | Subscription still "Active" until retry window exhausts |
eNACH / card mandate | Bank-side decline, tokenization failure, card expired |
|
Card recurring (tokenized) | Soft decline vs hard decline — require different responses | Failure code ( |
The failure code is the routing input for recovery. Most founders never look at it.
Why UPI Autopay creates a specific blind spot
When a UPI Autopay debit fails, the pre-debit notification was already sent 24 hours earlier — that's an RBI requirement. The customer may have seen the notification. They may not have. The debit failed regardless.
Razorpay has no built-in obligation to notify the customer after failure. The subscription.pending webhook fires. The subscription stays visible as recoverable. Without an action — retry, WhatsApp message, or payment update link — the subscription waits.
For transactions above ₹15,000, RBI's AFA requirement means the customer must authenticate again even if the mandate was previously confirmed. Retrying without asking the customer to act will fail again.
This is the part most founders discover after three or four identical retry failures on the same invoice.
The six questions that measure actual collection health
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 anyone counted it as lost.
For every billing cycle, the right diagnostic is:
Question | Why it matters |
|---|---|
How much MRR was scheduled for collection? | Establishes the real collection base — not expected MRR from plan pricing |
How much cleared on first attempt? | Shows baseline payment health across your mandate mix |
How much failed? | Identifies the recovery pool — this is the number that should sit next to cancellation MRR |
Which failures were retryable without customer action? | Prevents exhausting retry attempts on hard declines or revoked mandates |
Which failures needed customer action? | Separates gateway retry from WhatsApp message from payment update link |
How much was recovered before the billing cycle closed? | Shows whether your current recovery flow is working or just logging |
Running this reconciliation monthly — even in a spreadsheet pulling from Razorpay's export and webhook logs — shows the collection gap directly. Most founders who do this for the first time find 8–15% of attempted MRR sitting unrecovered, uncounted, and never separated from their active subscription count.
Collection churn vs cancellation churn
Western dunning writing separates voluntary churn (customer cancelled) from involuntary churn (payment failed). That distinction is useful but incomplete for India.
In India, involuntary churn has sub-categories that require different responses:
Mandate churn: UPI Autopay mandate revoked or expired after a bank account change — the customer may still want the product
Payment-state churn: Subscription is
activein Razorpay but no payment has cleared in the current cycle — a "zombie active" subscriptionDelinquent churn: The retry window has exhausted and the customer was never reached — involuntary at the start, voluntary by the end
Each of these requires a different next action. Mandate churn needs a re-registration link. Payment-state churn needs a payment update or WhatsApp nudge before the retry window closes. Delinquent churn needs a re-engagement sequence before the customer is counted as lost.
A single "failed payments" number does not distinguish them. The Razorpay dashboard does not distinguish them by default. Without reading the failure code and the mandate state together, the correct action for each customer is invisible.
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 failed payment log for the last 30 days and separated mandate failures from gateway declines from retry exhaustion — how many of those failure states have a distinct recovery action in your current stack, and how many are being retried the same way regardless of failure type?
