A Hyderabad founder once described RBI e-mandates to me as "that compliance thing the gateway handles." Understandable — payment rules feel like background infrastructure until they interrupt revenue. Then they get very visible.
The framing worth adopting is this: the e-mandate rules are part of your retention system, not a layer beneath it. When a recurring payment depends on authorisation, notification, and customer control, collection stops being a silent background event.
Use the 2026 framework, not the 2021 one
A lot of SaaS content still quotes the 2021 circular (RBI/2021-22/174). That circular was consolidated and superseded by the Digital Payments – E-mandate Framework, 2026, notified in April 2026. If your understanding is built on 2021-era blog posts, some of it is now historical. Four rules from the current framework decide whether a SaaS subscription actually collects.
Rule | What it means | Why it's a revenue moment |
|---|---|---|
AFA at mandate setup | Every recurring authorisation needs Additional Factor Authentication once, at setup (OTP or UPI approval) | Signup can convert while the collection path stays fragile if setup is rushed |
The ₹15,000 threshold | Debits below ₹15,000 run silently; at or above, the customer must re-authenticate before each debit | A ₹14,999 plan auto-debits; a ₹15,001 plan needs approval every cycle |
24-hour pre-debit notice | The bank must alert the customer ≥ 24h before each debit | Trust and timing around that SMS shape whether the debit succeeds |
Customer opt-out / revoke | Customers can skip a single debit or revoke the whole mandate, via bank or merchant | Cancellation intent can appear entirely outside your product |
Two things are genuinely new in 2026 and matter for recovery. Banks must now send a post-debit notification with grievance-redressal details after each successful debit — which raises the value of a clean "payment recovered" confirmation from the merchant. And banks must auto-migrate mandates when a card is reissued, closing what used to be a common silent-failure mode (though real-world implementation may lag at some banks, so monitor it rather than assume it's solved).
The ₹2 line is a pricing decision, not a footnote
The single most under-discussed fact in Indian SaaS pricing: a plan at ₹14,999/month auto-debits without the customer lifting a finger, while a plan at ₹15,001/month requires fresh customer approval before every debit. SaaS is not in the ₹1,00,000 exempt category (that's reserved for insurance premiums, mutual-fund subscriptions, and credit-card bills). If your largest plans cross ₹15,000, you've quietly chosen a pricing tier that adds a re-authentication step to every renewal — and that step is where larger accounts silently lapse.
Three states that look like one
"Subscription created" does not mean "future revenue secured." A subscription is a commercial promise. A mandate is a payment-authorisation path. A successful debit is collected revenue. Measure them separately, plus the customer's awareness, and the picture sharpens.
State | Question | Owner |
|---|---|---|
Subscription | Active, paused, cancelled, or expired? | Product / billing |
Mandate | Valid, revoked, paused, expired, or limit-exceeded? | Gateway + recovery layer |
Debit | Attempted, queued, failed, or recovered? | Payment operations |
Customer | Do they know what action is needed? | Success / support / automated recovery |
A customer can be active in subscription state and broken in mandate state. A debit can fail while intent is strong. A mandate can be revoked at the bank before your product ever sees a cancellation reason — so your internal cancel flow never fires, and the account gets marked "churned" weeks after the real signal happened elsewhere. This is precisely why Indian retention thinking can't be copied wholesale from a card-first market: some of your earliest churn signals live around authorisation, pre-debit awareness, and mandate state, not inside your product.
Where SubsShield fits
SubsShield watches the mandate and debit layers the gateway exposes, classifies a mandate break versus a soft decline versus a revocation, and — because it can explain why a payment failed in the language of the RBI framework — reduces the blame the customer aims at the merchant. The recovery message says "your authorisation needs re-approval," not "your card failed," because those need different customer actions.
The question isn't "are we RBI-compliant?" Your gateway handles compliance. It's: where inside the e-mandate flow do your customers stop paying you — and if your largest renewals cross the ₹15,000 line, have you mapped the customer action required before that debit ever fails?
References
RBI, Digital Payments – E-mandate Framework (2026), superseding RBI/2021-22/174
Chargebee, RBI e-mandate guide (historical/context) — https://www.chargebee.com/blog/rbi-mandate-india/
Razorpay e-mandate / Subscriptions docs — https://razorpay.com/docs/payments/subscriptions/
NPCI UPI AutoPay product overview — https://www.npci.org.in/what-we-do/upi/product-overview
