A Pune founder once showed me a four-email dunning sequence his team had copied almost line-for-line from a US SaaS blog. Polite copy, reasonable timing, useful product. The recovery numbers were still poor.
The emails weren't the problem. The assumptions behind them were.
Western dunning playbooks quietly assume three things: the card is the primary rail, the inbox is a reliable recovery channel, and most failures are a question of retry timing. Each one needs rechecking in India.
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. That framing holds. The edges are different here.
In India a failed recurring debit can sit on a card mandate, a UPI AutoPay mandate, eNACH, or netbanking — each 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 attempt. "Retry the card three times and send an email" doesn't describe that world.
Western dunning assumption | Indian recurring-payment reality |
|---|---|
Card failed — retry later | Could be card, UPI AutoPay, eNACH, or a broken mandate |
Email reaches the payer | The paying user often acts faster on WhatsApp |
Retry timing solves most failures | Many failures need a mandate update, fresh AFA, or a new method |
Billing contact is obvious | Founder, finance, and the product user may be three people |
Decline = card problem | Failure may be bank-side, consent-side, mandate-side, or queued |
The retry engines were built for someone else's rails
Sophisticated Western retry systems are genuinely good — Stripe's Smart Retries uses signals to choose retry times and flags hard declines that can't recover until a new method exists. The instructive detail is in its constraints: Stripe has documented that its retry logic does not extend to India-issued cards, because Indian recurring debits run on a mandate model RBI built differently. (Worth confirming against Stripe's current docs, but the principle stands.)
That single line says more than most dunning articles. India isn't 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.
There's a timing trap too. 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 non-peak windows. A debit that reads "failed" inside a peak window may just be queued. A Western-style flow that fires an angry email the instant a debit doesn't clear will sometimes be chasing a payment that hadn't actually failed yet.
Classify before you communicate
A better Indian sequence starts with diagnosis, not the first email.
Failure class | What it usually needs | Bad habit to drop |
|---|---|---|
Temporary / soft (insufficient funds) | Timed retry + a light reminder | A generic "your card failed" email |
Mandate broken (expired, revoked) | Customer re-authorises | Retrying the same dead mandate |
AFA-required (≥ ₹15,000) | A clear instruction before the next attempt | Treating it like a soft decline |
UPI AutoPay issue | UPI-aware message + alternate path | Card-style copy |
Intent unclear | A conversation, not pressure | Offering a discount too early |
If the answer is "wait for retry," automation handles it. If it's "the customer must approve something," the message has to spell that out. If the method is unusable, ask for a new one. If the customer is leaving, switch from payment-chasing to understanding why.
Why WhatsApp earns its place
Not as a louder channel — as a closer one. Indian customers already act on bank prompts, UPI requests, and payment links on mobile, and most SaaS businesses collect a phone number at signup. Transactional WhatsApp open rates in India run far ahead of email (commonly cited at 70–90% vs 15–25%). Email still matters as the billing record. Making email the primary recovery channel in India usually reflects where the playbook came from, not how the customer behaves.
Where SubsShield fits
SubsShield reads the failure from the Razorpay or Cashfree webhook, classifies the rail and 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 deciding what to actually say. Rails first, then channels, then copy. It sits on top of the gateway, not in place of it.
If your failed-payment flow was lifted from a card-and-email market, which part of it still assumes your customer behaves like a US cardholder?
References
Stripe Billing, Smart Retries documentation — https://docs.stripe.com/billing/revenue-recovery/smart-retries
Razorpay Subscriptions docs — https://razorpay.com/docs/payments/subscriptions/
Cashfree Subscriptions docs — https://docs.cashfree.com/
RBI, Digital Payments – E-mandate Framework (2026)
NPCI UPI AutoPay execution-window circular UPI-OC-No-215-A-FY-2025-26 (eff. 1 Aug 2025)
