Why Western dunning playbooks break inside Indian recurring payments

I used to believe a good dunning sequence was portable. Find what the best US SaaS companies do, adapt the copy, ship it — failed payments recovered. That belief cost me a few months of mediocre recovery numbers before I understood why it was wrong. The emails were fine. The market underneath them was not the one the playbook was written for.

A founder in Pune showed me his version once — a four-email sequence his team had copied almost line-for-line from a US SaaS blog. Polite copy, sensible timing, a genuinely good product behind it. The recovery numbers were still poor. Not because the team executed badly, but because every email rested on assumptions that quietly don't hold in India.

Western dunning playbooks assume three things without ever saying them out loud: the card is the primary rail, the inbox is a reliable recovery channel, and most failures come down to retry timing. In India, all three need re-checking before you send a single message.

Dunning is recovery, not nagging

The useful core idea — from references like Churnkey and Baremetrics — is that failed payments are a recoverable operational problem, not a vague retention mood you wait out. That framing absolutely holds. It is the edges that are different here.

In India a failed recurring debit can sit on a card mandate, a UPI AutoPay mandate, eNACH, or netbanking — each one registered at the customer's bank, each failing for its own reasons. A mandate is a standing authorisation to debit a specific merchant up to a maximum amount; the gateway orchestrates the debit, but the bank authorises every single attempt. "Retry the card three times and send an email" doesn't even describe that world.

The retry engines were built for someone else's rails

The sophisticated Western retry systems are genuinely good — Stripe's Smart Retries uses machine-learning signals to pick retry times and flags hard declines that can't recover until a new method exists. But the most instructive detail is buried in its own documentation: Stripe attempts a payment from an India-issued card exactly once, regardless of your retry settings. Smart Retries simply does not apply to India-issued cards, because Indian recurring debits run on a mandate model the RBI built differently.

That one constraint says more than most dunning articles do. India is not a region where the same flow gets translated into rupees. The rails behave differently, the compliance steps are different, and the customer's attention lives somewhere other than the inbox. A retry engine that fires once and stops is not a recovery strategy — it is the starting line.

There is a timing trap on top of that. Since 1 August 2025, NPCI holds UPI AutoPay executions during peak hours (10:00–13:00 and 17:00–21:30 IST) and releases them in the non-peak windows. A debit that reads "failed" inside a peak window may just be queued. A Western-style flow that fires off an irritated email the instant a debit doesn't clear will, sooner or later, be chasing a payment that had not actually failed yet — and the customer who gets that email remembers it.

Classify before you communicate

A better Indian sequence starts with diagnosis, not with the first email.

If the answer is "wait for the retry," automation handles it and you stay quiet. If it is "the customer has to approve something," the message has to say exactly that. If the method is unusable, ask for a new one. And if the customer is actually leaving, stop chasing the payment and start understanding why — those are two different conversations, and running them as one loses you both.

Why WhatsApp earns its place

Not because it is a louder channel — because it is a closer one. Indian customers already act on bank prompts, UPI requests, and payment links on their phones, and almost every SaaS business collects a phone number at signup anyway. Transactional WhatsApp open rates in India run far ahead of email (commonly cited around 70–90% versus 15–25%). Email still matters as the billing record. But making email the primary recovery channel in India usually says more about where the playbook was copied from than about how the customer actually behaves.

Where SubsShield fits

SubsShield reads the failure from the Razorpay or Cashfree webhook, classifies the rail and the reason, and routes the next action — a timed retry window, a mandate re-auth, a card update, or a WhatsApp message with a working payment path — before it decides what to actually say. Rails first, then channels, then copy. It sits on top of the gateway, never in place of it.

So if your failed-payment flow was lifted from a card-and-email market, here is the uncomfortable question: which part of it still quietly assumes your customer behaves like a US cardholder?