A Gurugram founder once walked me through a week of failed-payment alerts in his Cashfree dashboard, scrolling fast. One customer, one invoice, one red mark — and within a minute he was calling all of them "payment failures." That phrase is convenient. It also hides the thing that matters most: different failures need different actions.
Recovery in India starts with classification, not communication. Classify badly and you send the wrong message; send the wrong message and you train customers to ignore recovery; once they ignore it, a recoverable subscription quietly becomes churn.
The decline classes that actually matter
Western dunning content explains soft vs. hard declines well, and Stripe's retry docs sensibly separate retryable failures from hard declines that need a new method. Useful — but India needs its own working set. These are the categories a recovery engine should route on:
Class | What's really happening | Right first action |
|---|---|---|
Hard — card | Card expired or invalid | Card-update message now. No retry will fix it. |
Hard — mandate | e-mandate expired or rejected | Customer must re-authorise (fresh AFA). The merchant can't revive a dead mandate. |
Soft — insufficient funds | Money wasn't there at debit time | Light reminder, retry on a sensible window; consider payday timing |
Voluntary — payer rejected | Customer declined the UPI request | Soft, low-urgency note — intent may have changed |
Infrastructure | Gateway/bank/issuer downtime | Do nothing yet. Queue everything until it resolves. |
Unknown | Unmapped error | Generic "small hiccup" message; tighten the map later |
The mistake is firing one generic line — "Your payment failed, please update your card" — at all six. That works only when the card is genuinely the problem. It's actively wrong for a UPI AutoPay mandate, an eNACH debit, a revoked authorisation, or a customer who needs to authenticate a ₹15,000-plus charge.
The one rule that prevents most false alarms
Before any of this, there's a timing check that's specific to India. 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, with one main attempt and up to three retries. A debit that appears to fail inside a peak window may simply be queued.
So the first question isn't "which message do we send?" It's "is this even a real failure yet?" Starting a recovery sequence on a peak-window UPI event that later clears on its own is how teams annoy paying customers and damage their own WhatsApp sender quality. Confirm the debit is actually failed before you classify it.
A diagnostic to run inside the company first
The recovery workflow should begin with a short internal table, not a customer email.
Question | Why it matters |
|---|---|
Which rail and method was used? | Card, UPI, eNACH change the next step entirely |
Was the mandate active at debit time? | No retry fixes a broken authorisation path |
Was this a peak-window UPI execution? | It may be queued, not failed |
Did the charge need fresh AFA (≥ ₹15,000)? | The next action is customer approval, not a silent retry |
Has this failed before for this customer? | A repeat pattern reads differently from a one-off |
Was payment eventually recovered, and via which touch? | Recovery rate matters more than alert volume |
This looks operational, but it's strategic. A founder who knows the failure class can decide whether to invest in better retries, cleaner mandate setup, pre-debit communication, WhatsApp reminders, pricing clarity, or method collection. A founder who doesn't classify does the same thing every week — sends reminders, waits, calls it churn — and never learns which lever was broken.
Where SubsShield fits
SubsShield treats a failed payment as an event with context. It reads the decline signals from the Razorpay or Cashfree webhook, sorts the failure into the right class, suppresses messaging during downtime and peak-window ambiguity, and only then routes the rail-appropriate next action. The recovery message is written after the system understands what failed — not before.
If you had to tag every failed payment this month by the exact next action required, how many would still fit under one generic recovery sequence?
References
Razorpay Subscriptions / payment failure docs — https://razorpay.com/docs/payments/subscriptions/
Cashfree Subscriptions docs — https://docs.cashfree.com/
Stripe Billing Smart Retries — https://docs.stripe.com/billing/revenue-recovery/smart-retries
NPCI UPI AutoPay execution-window circular UPI-OC-No-215-A-FY-2025-26 (eff. 1 Aug 2025)
RBI, Digital Payments – E-mandate Framework (2026)
