The failed payment tab is usually where churn hides
Open a Razorpay or Cashfree subscription dashboard at the end of the month.
The cancellation number may look manageable. A few customers left. A few downgraded. The loss feels explainable.
Then open the failed payment events.
A different pattern appears. Some renewals failed after retries. Some customers never completed mandate action. Some UPI Autopay attempts did not go through. Some card transactions needed customer approval. A few mandates were revoked, but nobody treated them as churn signals.
This is where dunning begins.
Dunning is the system that detects a failed subscription payment, understands why it failed, reaches the customer through the right channel, gives them the right action path, and stops when the payment is recovered.
In card-heavy SaaS markets, dunning is often explained as email reminders plus card retries. That definition is useful, but it is too narrow for India.
In India, dunning has to understand rails.
A Razorpay subscription failure, a Cashfree mandate issue, a UPI Autopay approval problem, and an RBI e-mandate authentication requirement should not receive the same recovery flow. Treating them as one generic “payment failed” event is how recoverable revenue becomes silent churn.
Dunning in India is payment-state diagnosis.
The standard definition is only the starting point
A useful base definition is simple: dunning is the process of recovering failed subscription payments. In SaaS, that usually means detecting a payment failure, notifying the customer, retrying the payment, and asking the customer to update their payment method if needed.
That is a good starting point.
But the standard card-first SaaS flow usually assumes three things.
Assumption in a card-heavy SaaS market | Why it breaks in India |
|---|---|
The main issue is a failed card charge | Indian subscriptions may fail because of UPI Autopay action, eNACH state, mandate status, AFA, bank-side rules, or customer revocation. |
Email is the primary recovery channel | Email is useful for records, but WhatsApp often becomes the faster action channel for Indian customers. |
Retries solve most recoverable failures | Retries help only when the failure is retryable. Mandate-state problems often need customer action. |
This is the first mistake many Indian SaaS teams make. They copy dunning flows built for card-heavy markets and expect them to work inside Indian recurring payments.
They do not.
Not because the idea of dunning is wrong. Because the workflow is under-specified for India.
Why Indian recurring payments need rail-aware dunning
Indian subscription payments contain more customer-action points than a simple card retry model assumes.
Razorpay Subscriptions support plan-based recurring payments, dashboard management, webhook events, and payment methods such as cards, UPI AutoPay, and Emandate. Cashfree describes a subscription mandate as an authorization between merchant and customer that allows recurring debit at a fixed frequency or on demand up to a maximum amount. Its subscription rails include cards, eNACH, UPI Autopay, and Physical NACH.
RBI e-mandate rules add another operational layer. E-mandates involve Additional Factor Authentication, transactions above INR 15,000 require AFA, banks must send a pre-debit notification at least 24 hours before debit, and customers can withdraw an e-mandate at any time.
UPI Autopay introduces its own mandate behavior. Users can set up recurring e-mandates through UPI apps, and recurring UPI mandates can be modified, revoked, or paused.
This means an Indian failed payment event is rarely just one thing.
Dashboard label | What may actually be happening | Better recovery path |
|---|---|---|
Payment failed | Temporary bank, balance, network, or processor issue | Retry plus a clear customer notification |
Mandate inactive | Customer action is required before recovery | Send a mandate update path, not a generic reminder |
UPI Autopay pending | Approval, pause, revoke, or UPI-side friction | Send UPI-aware instructions through WhatsApp and email backup |
Card authentication required | AFA or recurring payment approval is needed | Explain the approval step before another attempt |
Mandate revoked | Payment friction or early cancellation intent | Move from payment recovery into retention diagnosis |
Repeated non-response | Customer is busy, unreachable, or leaving | Escalate respectfully, then classify the outcome |
This is why dunning in India cannot begin with “send another email.”
It has to begin with “what type of failure is this?”
Billing automation is not recovery orchestration
Payment gateways are essential infrastructure. They create subscriptions, initiate charges, manage payment events, emit webhooks, and often support retries.
That solves billing automation.
It does not automatically solve revenue recovery.
The distinction is small in wording and large in MRR impact.
Layer | What it does well | What still needs orchestration |
|---|---|---|
Payment gateway | Creates subscriptions and processes scheduled debits | Deciding the right recovery path after failure |
Retry logic | Attempts payment again after failure | Knowing whether the failure is retryable or needs customer action |
Webhooks | Tell your system that an event occurred | Translating the event into the right message and next step |
Dashboard | Shows subscription and payment states | Turning failed events into recovery workflows |
Dunning layer | Coordinates diagnosis, messaging, retry, and resolution | Works on top of the gateway instead of replacing it |
This is where most Indian SaaS teams discover the gap.
The gateway can tell you that a payment failed. It may retry. It may show the status.
But if the customer needs to approve UPI Autopay, update a mandate, understand an AFA step, or respond on WhatsApp before access is interrupted, the gateway event is only the beginning.
A gateway event is an input.
A recovery workflow is the system built after that input.
This is the category SubsShield is built for: Indian subscription businesses that already use Razorpay or Cashfree, but need a recovery layer that understands failed-payment states, WhatsApp action flows, win-back sequences, and revenue analytics in the Indian payment context.
Aggressive recovery is usually lazy recovery
A failed payment message should not sound like debt collection.
It should not shame the customer. It should not create panic. It should not hide the next step behind vague wording.
The job of a dunning message is to reduce uncertainty.
A useful Indian dunning message usually answers four questions.
Message part | Purpose | Example wording |
|---|---|---|
What happened | Removes ambiguity | “Your subscription payment for ₹4,999 did not go through.” |
Why it may have happened | Reduces anxiety | “This can happen when a mandate needs approval or the payment method needs action.” |
What to do next | Creates action | “Please complete payment or update the mandate using this secure link.” |
What happens after payment | Builds trust | “Once payment succeeds, your access continues and reminders stop automatically.” |
The message should also match the failure state.
Failure state | Weak message | Better message |
|---|---|---|
UPI Autopay pending | “Your payment failed. Update card.” | “Your UPI Autopay payment needs action. Please review the approval or use this payment link.” |
Mandate inactive | “We could not charge you.” | “Your recurring mandate is inactive. Please update the mandate to continue your subscription.” |
AFA required | “Retry failed.” | “This payment may require approval because of recurring payment rules. Please complete the approval step here.” |
Temporary failure | “Your subscription will be cancelled.” | “We will retry shortly. If you prefer, you can complete payment now using this link.” |
Mandate revoked | “Payment failed.” | “We noticed your recurring payment mandate was cancelled. Was this intentional, or should we help restore billing?” |
Good dunning is specific, not loud.
A founder should be able to read the recovery message and know whether it matches the actual payment state. If the same message goes to every failed payment, the workflow is probably not diagnosing enough.
The recovery workflow Indian SaaS teams should build
The simplest useful dunning workflow has seven stages.
Stage | What should happen | Indian payment context |
|---|---|---|
Detect | Capture the failed payment event immediately | Razorpay or Cashfree webhook |
Classify | Identify the payment rail and failure state | Card, UPI Autopay, eNACH, Emandate, mandate revoked, AFA required |
Decide | Choose retry, customer action, or retention path | Not every failure deserves the same sequence |
Reach | Use the right message and channel | WhatsApp for action, email for records, human follow-up for key accounts |
Resolve | Provide a direct path to payment or mandate repair | Payment link, mandate update, approval instruction, plan discussion |
Stop | End the workflow when payment succeeds | Prevents unnecessary reminders and trust damage |
Learn | Track recovered, unrecovered, and repeated patterns | Converts failed events into retention intelligence |
The hidden stage is classification.
Most teams jump from failure to reminder. That is where recovery quality drops.
A retryable temporary failure does not need a long explanation. A mandate issue does. A revoked mandate may need a retention conversation. A high-value account may need a human note before automated suspension.
That is the difference between a dunning sequence and a recovery system.
Pre-dunning is part of trust
Dunning usually begins after failure. Pre-dunning begins before failure.
In card-heavy SaaS, pre-dunning often means warning customers before a card expires. In India, pre-dunning should be broader because recurring payments often involve consent, mandate status, approval behavior, and customer comfort with auto-debit.
RBI e-mandate rules include bank-side pre-debit notifications. A SaaS company cannot control every bank notification, but it can reduce customer surprise by making amount, renewal date, invoice context, and action paths easy to understand.
Pre-dunning moment | Why it matters |
|---|---|
Before renewal | Reduces surprise and payment anxiety |
Before annual charge | Gives the customer time to clarify invoice, GST, plan, or approval questions |
Before mandate expiry | Prevents avoidable failed debit |
Before price change | Separates pricing conversation from payment failure |
Before high-value debit | Reduces support load and failed collection risk |
In India, trust around auto-debit is part of retention.
The recovery system should not begin only after trust has already been interrupted.
A one-month dunning audit for founders
If you do not have a verified internal data point yet, do not invent one for the blog.
Instead, run this audit on one month of failed subscription payments. It will give you the real example that should eventually sit inside this article.
Diagnostic question | What it reveals |
|---|---|
How much MRR failed this month? | Revenue at risk |
How much of that was recovered? | Recovery effectiveness |
How long did recovery take? | Cash-flow and access risk |
Which payment rail failed most often? | Card, UPI Autopay, eNACH, or mandate pattern |
Which failures required customer action? | Messaging and education need |
Which messages were actually seen? | Channel effectiveness |
Which accounts eventually cancelled? | Boundary between payment failure and churn |
Which failures repeated across months? | Structural issue in billing setup |
The useful number is not only failed MRR.
The useful number is failed MRR split by reason.
A founder who learns that most failed renewals were temporary bank failures will build a different system from a founder who learns that most failures needed mandate action. A founder who learns that revocations are rising should not treat that as a retry problem at all.
This is how dunning becomes payment intelligence.
Where SubsShield fits
SubsShield is built around the Indian version of dunning.
It does not replace Razorpay or Cashfree. It sits on top of them and turns failed payment events into recovery workflows.
The product layer is simple to describe: automated dunning, WhatsApp alerts, win-back campaigns, and revenue analytics for Indian subscription businesses.
The deeper difference is context.
Generic dunning question | SubsShield-style Indian question |
|---|---|
Did the card fail? | Which Indian payment rail failed, and why? |
Should we send another email? | Which channel will create safe customer action fastest? |
Should we retry tomorrow? | Is this failure retryable, or does the customer need mandate action? |
When should access be cancelled? | Is this unresolved payment friction or true churn intent? |
How much churn happened? | How much MRR was failed, recovered, unrecovered, and truly cancelled? |
A card-first dunning product usually starts with cards and email.
SubsShield starts with Indian rails, INR billing, Razorpay and Cashfree workflows, UPI Autopay behavior, mandate states, WhatsApp action flows, and founder-visible revenue leakage.
That is why the category matters.
If your recovery flow cannot distinguish between a retryable bank failure, an inactive mandate, and churn intent, then your billing stack is leaking revenue silently.
The open question for every Indian SaaS founder is this: how much of last month’s churn was a customer decision, and how much was a failed payment your system did not understand in time?
