UPI Autopay Revokes 20 Million Mandates a Month. Your Card Dunning Playbook Has Nothing for That.

Every dunning guide we've published, including our own breakdowns of ACH bank transfer failures and SEPA Direct Debit reversals, treats a failed recurring payment as a retryable event: the charge didn't go through, try again on a better day, or fall back to asking for a new payment method. UPI Autopay, India's e-mandate rail for recurring UPI payments, breaks that model in a way neither of those rails does. A meaningful share of its failures don't leave you with a declined charge to retry — they leave you with a cancelled mandate, and a subscriber who has to re-authenticate from scratch before you can bill them again.

If you don't sell into India, this is a rail you can skip. If you do — or if UPI shows up as a payment method option anywhere your checkout accepts international cards and wallets side by side — this is the gap in your involuntary churn model that a card-and-ACH playbook was never built to catch.

How a UPI Autopay mandate actually works

UPI Autopay is NPCI's e-mandate framework for recurring debits over the UPI rail. Mechanically, it looks like a subscription token at first glance: a customer authorizes a mandate once, inside whatever UPI app they use — Google Pay, PhonePe, Paytm, dozens of others share the same rail — using their UPI PIN as Additional Factor Authentication, and the merchant can then debit the linked bank account on a recurring schedule without asking again each time. That's the same basic shape as a stored card token or an ACH authorization.

Where it diverges is what happens when a scheduled debit doesn't clear. A card decline against a stored token is just that: one failed attempt, the token is still valid, retry it later. On UPI Autopay, a debit failing at execution time frequently takes the mandate down with it. The bank or the UPI app treats repeated execution failures as grounds to cancel the standing authorization, not just the individual transaction. That's a fundamentally different failure shape from anything a card-first or ACH-first dunning stack is built to expect.

Compiled from Nacha operating rules, the SEPA Core Direct Debit Rulebook, and RBI/NPCI e-mandate framework documentation.

The growth number and the leak number are both real

UPI Autopay adoption is genuinely large and still accelerating. NPCI-sourced reporting via Business Standard put new mandate registrations at over 50 million in July 2025 alone, roughly double the prior year's pace. That's not a niche payment method — it's become the default recurring rail for a large share of Indian consumer subscriptions, OTT services, SIPs, and loan EMIs, alongside cards and eNACH.

The same growth that makes UPI Autopay worth supporting is also why its failure rate matters more than it would for a smaller rail. Execution-stage failure rates on UPI Autopay mandates run consistently higher than card-based e-mandates in India — Razorpay's own comparison of UPI Autopay against eNACH and card mandates puts UPI Autopay failures in the 8–15% range against roughly 2–3% for card e-mandates processed under the same RBI framework. That comparison matters specifically because both rails sit under identical regulatory rules in India — same AFA requirements, same notification rules — so the gap isn't regulatory friction. It's the underlying mechanics of debiting a UPI-linked bank account versus authorizing a stored card token.

Why the gap? Most UPI-linked accounts are also the customer's primary transactional account — the one they're paying rent, groceries, and other subscriptions out of — rather than a dedicated payment account with a maintained buffer. When a recurring debit competes with same-day spending for whatever balance is sitting there, insufficient-funds failures happen more often than they would against, say, a corporate card with a credit line behind it. Business Standard's reporting is explicit on this point: low customer balance at the moment of execution is the leading driver of the 20 million monthly revocations, not fraud, not disputed authorization, not a technical outage.

The regulatory scaffolding you're building dunning logic inside

UPI Autopay doesn't operate in a permissive gray zone the way some newer payment rails do — it sits inside one of the more prescriptive recurring-payment regulatory frameworks in the world, and the rules shape what your dunning logic is even allowed to do.

• The AFA threshold is ₹15,000. Recurring debits under that amount, once the mandate is registered, don't require a fresh Additional Factor Authentication step at execution time. Cross it, and the customer has to actively authenticate that specific transaction — insurance premiums, SIPs, and credit card bill payments get a separate, higher ₹1 lakh threshold.
• Every debit needs a 24-hour pre-debit notification. Merchant name, exact amount, and date, with an opt-out the customer can act on before the money moves. This isn't a best practice — it's an RBI requirement, and it's also your highest-leverage lever for reducing "I didn't recognize this charge" disputes that push a failed collection toward mandate revocation instead of a clean retry.
• Zero-liability protection now extends to e-mandate transactions. A customer who reports an unauthorized debit promptly isn't on the hook for it, which raises the bar on making sure your pre-debit notifications are unambiguous — a vague or generically-branded alert is exactly what produces a report that didn't need to happen.
• Mandates became portable across UPI apps as of December 31, 2025. Per an NPCI circular issued October 7, 2025, users can now view, manage, and transfer active Autopay mandates between apps — Google Pay to PhonePe, for instance — instead of being locked into whichever app they originally registered in. NPCI framed this explicitly as a response to dark-pattern complaints around users feeling stuck with recurring mandates they couldn't easily find or cancel.

That last change cuts both ways for a SaaS business. It's good news if your billing relationship is legitimate and your notifications are clear — a customer who wants to keep paying you doesn't lose that ability just because they switched their primary UPI app. It's also a new, low-friction cancellation surface: a subscriber who previously would have let a mandate quietly lapse or called support can now find and kill it in a completely different app than the one they set it up in, without ever touching your product or your cancellation flow.

What this actually means for your dunning stack

The instinct carried over from card and ACH dunning — treat every failure as retryable until proven otherwise — actively works against you here. A UPI Autopay failure needs to be diagnosed before you decide what to do with it:

1. Distinguish a failed execution from a revoked mandate at the webhook level. If your processor's failure payload for a UPI recurring charge doesn't tell you whether the mandate itself is still active, you're guessing. A failed execution against a live mandate can reasonably be retried after a few days, the same logic you'd apply to an ACH R01. A revoked mandate can't — there's nothing left to retry against.
2. Route revoked-mandate subscribers into a re-registration flow, not a retry queue. This is closer to how you'd handle a card that's been fully closed than a card that's simply expired — the customer needs to go through AFA authorization again, in their UPI app, before anything can be billed. A silent retry attempt against a dead mandate just produces another failure and burns time you could spend prompting re-registration.
3. Make your pre-debit notification do double duty. The RBI already requires you to send it 24 hours ahead — use that mandatory touchpoint to make the charge unmistakably recognizable (your actual product name, not a payment processor's generic descriptor) rather than treating it as regulatory boilerplate. Every notification that gets read and understood is one less "I didn't authorize this" dispute pushing a live mandate toward revocation.
4. Capture a backup payment method where the ACV justifies it. The same principle we've laid out for wallet-based Southeast Asian payment methods applies here: a rail with a materially higher structural failure rate is worth offering for the conversion it unlocks, but pairing it with a card as backup at signup gives you somewhere to fall back to instead of a dead end.
5. Track mandate revocation as its own metric, not folded into a generic "payment failed" bucket. A blended involuntary-churn number that mixes card declines, ACH returns, and UPI mandate revocations will understate how much attention the UPI segment specifically needs, the same trap we've flagged for lumping ACH returns in with card declines.

None of this is a reason to avoid UPI Autopay if you're selling into India — a rail used by hundreds of millions of people isn't optional coverage, it's table stakes, the same argument we've made about meeting customers on the payment rail they actually use. It's a reason to stop assuming your card dunning logic, or even your ACH logic, transfers to it unmodified. If you're trying to size how much of your involuntary churn is coming from a specific rail before you decide where to invest, running your UPI, card, and ACH failure segments separately through our churn calculator will show you which one is actually worth building custom logic for. And when a mandate does get revoked and a subscriber genuinely decides to move on rather than re-authenticate, that's exactly the moment CancelFlow is built to catch — routing them to a real save attempt instead of one more silent account you find out about from a support ticket weeks later.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.