Revenue Recovery Ops
Cashfree, Razorpay, and the difference between billing automation and revenue recovery
Razorpay and Cashfree automate billing. Indian SaaS still needs post-failure recovery across mandates, UPI AutoPay, and WhatsApp.
Here is a question worth sitting with before you read any further: when a debit fails tonight, does your company actually do anything about it — or does it just log the failure and wait for the gateway to try again? If you can't answer that cleanly, you don't have a recovery problem yet. You have a visibility problem, and it is quietly costing you MRR.
A founder in Jaipur put the counter-question to me on a call last month, and it was a fair one: "We already use a payment gateway. Why do we need a recovery layer?" The gateway creates subscriptions, stores mandates, attempts charges, fires webhooks, retries on its own. So where does another layer even fit?
The answer starts with a distinction most founders make far too late. Billing automation is the system that tries to collect your revenue. Revenue recovery is the system that takes over when collection doesn't happen. Same money, completely different job — and the gateway only does the first one.
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, bounded by an expiry and a debit count. Both are good at what they do. Neither one removes the need to actually work the post-failure path.
A recurring-payment system answers: when do we charge, on which method, and what happened to the attempt? A recovery system answers an entirely different set of questions — why did it fail, can it be recovered at all, what does the customer need to do, which channel will actually reach them, and at what point does this account stop being a recovery case and become churn?
| 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"
Here is the example that settles the argument. When a Razorpay subscription recovers from halted back 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 — which are the bulk of most SaaS customer bases. So even with billing fully automated, collecting a specific past invoice from a domestic-card subscriber needs a fresh payment link or the customer re-initiating payment themselves. That is recovery work the gateway structurally does not do, no matter how well you configure it.
Cashfree breaks differently. There is no clean equivalent of Razorpay's explicit halted state — its ON_HOLD has to be read together with the last failure event to understand why it is on hold. Cashfree has no Offers API, so discount-based save flows aren't available there at all, 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 these differences so that you, the founder, never have to keep two mental models of two state machines in your head.
The 72-hour audit
Stop asking "do we have subscriptions enabled?" That is the wrong question. The real one is: what actually happens in the first 72 hours after a debit fails?
| 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 |
Almost every founder I have talked to discovers this gap in the same place: reconciliation. Invoices were created, debits were attempted, some retries fired — and then nobody can say how much failed MRR came back because of a message, how much because of a retry, and how much was simply gone. You have a record of payment activity, but no record of which lever actually moved the money. Those are not the same thing, and only one of them helps you make a decision.
The Western comparisons of recovery tools — Churnkey, Baremetrics — are useful mainly for one thing: they prove recovery is its own category, not a gateway feature. But an Indian founder still has to ask the harder question — does this recovery system actually understand Razorpay's state machine, Cashfree's webhooks, UPI AutoPay behaviour, the RBI framework, and WhatsApp delivery? A tool that nails the concept but not the rails recovers nothing here.
Where SubsShield fits
SubsShield doesn't ask you to replace Cashfree or Razorpay. It asks what should happen the moment either one says "this payment didn't complete." It reads the webhook, classifies the failure across both gateways' different vocabularies, runs the recovery the rail actually calls for, and reports saved and recovered MRR as two separate numbers instead of one blurred total.
So back to where we started. 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?
Samir Gupta, Co-founder & CEO
Samir co-founded SubsShield to build the recovery and retention layer for Indian SaaS. He writes the dashboard-level pieces — what Razorpay and Cashfree tell you, what they quietly don't, and why a healthy churn number can hide a leak the size of a runway.