Razorpay retries are useful, but they are not a recovery strategy

A founder in Noida once told me, with some relief, "Razorpay will retry it." The first debit had failed, the system was trying again, the dashboard had updated — something was happening. But not every failure is solved by another attempt.

Retry logic is a component of recovery. It is not the recovery strategy.

What a retry can and can't answer

Razorpay Subscriptions is a strong billing foundation: automated charging across cards, UPI AutoPay and e-mandate, subscription webhooks, and built-in retries. The trouble starts when founders treat retry infrastructure as if it owns the whole outcome.

A retry answers one question: should we attempt the charge again? Recovery answers a larger set: why did it fail, what has to change, who needs to act, which channel reaches them, what payment path do we offer, and when do we stop and either pause or save the subscription?

There's a hard mechanical limit worth knowing. On Razorpay, after four consecutive failed attempts, a subscription moves from pending to halted and retries stop entirely. It won't charge again until the customer takes action and the merchant resumes. So "Razorpay will retry it" has a built-in expiry — four tries — and what happens around and after those four tries is the part retries can't do.

When retrying is the wrong move

If a mandate expired or was revoked, another retry can't fix it — only fresh AFA from the customer can. If the charge needs authentication (≥ ₹15,000), a silent retry isn't enough. If the card is invalid, the customer needs a new path. If they've decided to leave, payment-chasing language reads as tone-deaf.

This isn't a Razorpay flaw — Stripe's retries draw the same line between retryable failures and hard declines that need a new method. And there's an India-specific trap on top: a UPI AutoPay debit that "fails" inside NPCI's peak window (10:00–13:00 or 17:00–21:30 IST) may just be queued. Retrying aggressively or firing messages there can chase a payment that was never actually failed.

The four parts of real recovery

Most teams have the first. Some have the second. Few have all four working together — which is how a founder can say "we have retries enabled" and still lose money every month.

There's also a measurement gap retries create. When a subscription recovers from halted back to active, the unpaid invoices from the halted period are not auto-charged — only future cycles resume. So "subscription saved" and "past MRR recovered" are two different numbers, and for domestic-card subscribers (most of the market) that past invoice needs a fresh payment link, because Razorpay's manual charge is international-card only.

A simple audit

Take last month's failed Razorpay subscription payments and build four columns: retry status, failure reason, customer message, final outcome. Then look for the blanks. Retry filled but message blank means automation without communication. Reason blank means alerts without diagnosis. Outcome blank means activity without recovery measurement. Many marked "unrecovered" with no record of whether the customer ever saw a message isn't a payment problem — it's an observability problem.

Where SubsShield fits

SubsShield sits in the gap after the gateway event. It does not retry on your behalf and it does not replace Razorpay's retry engine — the gateway tells you what happened; SubsShield decides what should happen next. It classifies the failure, suppresses messaging during downtime and peak-window ambiguity, reaches the customer brand-first, hands them a working path, and separates "subscription saved" from "past MRR recovered" on the dashboard.

If your team says "Razorpay will retry it," who is responsible for knowing whether the customer needs to do something before that retry — or the fourth and final one — can ever succeed?