A founder once showed me a four-email dunning sequence copied almost line-for-line from a US SaaS blog.
The writing was polite. The timing was reasonable. The product was useful. Nothing looked obviously wrong. But the recovery numbers were still poor.
"The problem was not the emails. The problem was the assumption behind them."
Western dunning playbooks usually assume three things: the card is the primary rail, the inbox is a reliable recovery channel, and retries are mostly a question of timing. In India, each assumption needs to be rechecked.
Dunning is still the work of recovering failed payments. Most Western dunning literature treats failed payments as a retry and reminder problem — which is useful framing, because it makes recovery operational rather than vague. But the Indian version of the problem has different edges.
A failed payment may involve a card mandate, UPI Autopay mandate, eNACH, a bank notification, a customer approval step, or a gateway retry. A private billing reference describes a mandate as a contract between merchant and customer that authorises recurring debits up to a maximum amount, and supports cards, eNACH, UPI Autopay, and Physical NACH.
That is not the same as "send three emails and retry the card."
The core mismatch
Western assumption | Indian recurring payment reality |
|---|---|
Card failed — retry later | Card, UPI Autopay, eNACH, or mandate state may each be involved |
Email reaches the buyer | The paying user may respond faster on WhatsApp than email |
Retry timing solves most failures | Some failures need mandate update, AFA, or a new payment method |
A card-first payment processor says it does not retry payments when the payment card is India-issued. That one line says more than most generic dunning articles. India is not just another region where the same recovery flow can be translated into local currency. The rails behave differently. The compliance requirements are different. The customer attention channel is different.
~40% of failed renewals in Indian SaaS require direct customer action — not passive retry. They involve mandate reauthorisation, AFA approval, or a new payment method.
Classification Before Communication
A better Indian dunning flow starts with classification before communication. The question is not "when should we send the next email?" The question is: what action must happen next?
Temporary payment failure: Insufficient funds, transient bank error, network timeout. The method is still valid. → Timed retry + status reminder
Mandate issue: Mandate is expired, paused, or breached its maximum amount. → Ask customer to update or reapprove mandate
AFA-required payment: RBI's Additional Factor of Authentication requires explicit customer action. → Clear instruction, not a retry
UPI Autopay issue: UPI-specific mandate state issue. → UPI-aware message + alternate payment path
If the answer is "wait for retry," automation can do that. If the answer is "customer needs to approve something," the message must explain the action clearly. If the answer is "payment method is no longer usable," the recovery flow must request an updated method.
Where WhatsApp Fits
This is where WhatsApp matters — not as a magic channel. Just as a channel closer to how Indian customers respond to urgent payment and account messages. Many Indian SaaS businesses collect phone numbers during signup. Many buyers are already comfortable acting on payment links and reminders from mobile.
Email still has a role. But making email the main recovery channel in India often reflects the source of the playbook, not the behavior of the customer.
The Right Order: Rails, Then Channels, Then Copy
SubsShield's view is that Indian SaaS recovery should be built around rails first, then channels, then copy. Razorpay and Cashfree can initiate and manage recurring billing. The recovery layer has to decide what to say, where to say it, and what payment action to request after something fails.
A recovery system designed around US card behaviour will misdiagnose Indian payment failures by default. The rails are different, the compliance layer is different, and the customer is responding from a different device, on a different channel, inside a different payment context.
If your recovery logic assumes retries solve most failures, you may be automating the wrong problem entirely.
