A Jaipur founder asked me a fair question on a call last month: "We already use a payment gateway. Why do we need a recovery layer?" If the gateway creates subscriptions, stores mandates, attempts charges, sends webhooks, and retries, where does another layer fit?
The answer starts with a distinction most founders make too late. Billing automation is the system that tries to collect revenue. Revenue recovery is the system that responds when collection doesn't happen.
Two different jobs
Razorpay Subscriptions creates plan-based subscriptions and charges them across cards, UPI AutoPay, and e-mandate, with webhooks and retries. Cashfree Subscriptions sets up recurring debits via mandates across cards, eNACH, UPI AutoPay, and physical NACH, where a mandate authorises debits up to a maximum amount with validity bounded by expiry and debit count. Both are good at what they do. Neither removes the need to inspect the post-failure workflow.
A recurring-payment system answers: when do we charge, on which method, and what happened to the attempt? A recovery system answers: why did it fail, can it be recovered, what should the customer do, which channel reaches them, and when does this account move from recovery to churn handling?
Capability | Billing automation | Revenue recovery |
|---|---|---|
Create subscription | Yes | No |
Store / manage mandate | Yes | No |
Attempt scheduled debit | Yes | No |
Emit failure event | Yes | Uses the event as input |
Classify the recovery path | Limited / custom | Core function |
Send a rail-aware message | Needs setup | Core function |
Coordinate WhatsApp + email + link | Usually external | Core function |
Separate failed payment from cancellation intent | Usually not enough | Core function |
Measure recovered vs. saved MRR | Sometimes | Core outcome |
The cleanest proof that "automated" ≠ "recovered"
When a Razorpay subscription recovers from halted to active, the unpaid invoices from the halted window are not automatically charged. And Razorpay's manual invoice charge works for international cards but not domestic Indian cards — the bulk of most SaaS customer bases. So even with billing fully automated, recovering a specific past invoice for a domestic-card subscriber requires a fresh payment link or the customer re-initiating payment. That is recovery work the gateway structurally does not do.
Cashfree differs in its own ways. There's no clean equivalent of Razorpay's explicit halted state — ON_HOLD has to be read together with the last failure event to know why it's on hold. Cashfree has no Offers API, so discount-based save flows aren't available there, and it doesn't document an equivalent manual-charge path. None of this makes either gateway worse; it means the recovery layer has to absorb the differences so the founder doesn't have to.
The 72-hour audit
Don't ask "do we have subscriptions enabled?" Ask "what happens in the first 72 hours after a failed debit?"
Post-failure question | Why it matters |
|---|---|
Was the failure captured immediately? | Delayed detection lowers recovery odds |
Was the reason classified? | Wrong class → wrong action |
Was a peak-window UPI event confirmed failed before messaging? | Avoids chasing a queued debit |
Was the customer contacted in the right channel? | Email alone often doesn't produce action |
Did the message name the correct method and action? | Card, UPI, and mandate issues need different language |
Was a working payment path included? | Awareness without action recovers nothing |
Was the outcome measured — saved, recovered, or churned? | Teams need all three states, not one |
Founders usually discover the gap at reconciliation. Invoices were created, debits attempted, some retries happened — and no one can say how much failed MRR came back because of a message, how much because of a retry, and how much was true churn. That's the difference between payment activity and recovery intelligence.
Western comparisons of recovery tools — Churnkey, Baremetrics — are useful for understanding that recovery is its own category. But an Indian founder still has to ask whether the recovery system actually understands Razorpay's state machine, Cashfree's webhooks, UPI AutoPay behaviour, the RBI framework, and WhatsApp delivery.
Where SubsShield fits
SubsShield doesn't ask you to replace Cashfree or Razorpay. It asks what should happen after either one says "this payment didn't complete." It reads the webhook, classifies the failure across both gateways' vocabularies, runs the rail-appropriate recovery, and reports saved and recovered MRR separately.
If your subscription system can tell you a debit failed but can't tell you which recovery path each customer entered next, are you running billing automation or revenue recovery?
References
Razorpay Subscriptions docs — https://razorpay.com/docs/payments/subscriptions/
Cashfree Subscriptions docs — https://docs.cashfree.com/
Churnkey / Baremetrics (recovery-tooling category reference)
RBI, Digital Payments – E-mandate Framework (2026)
