Payment Rail Deep Dives
What Stripe's Smart Retries get right — and where India stops it
Stripe's retry engine is genuinely good, and the fastest way to understand why Indian recovery has to be built differently is the one line where Stripe admits it doesn't apply here.
Stripe's Smart Retries is genuinely good, and reading its documentation is the fastest way to understand why Indian payment recovery has to be built differently. Not because Stripe got anything wrong — because of one honest line buried in its constraints.
That line says more about Indian recurring payments than most dunning guides manage in a thousand words.
What Stripe gets right
Stripe's retry logic uses machine-learning signals drawn from millions of businesses to choose when to re-attempt a failed charge, lets you configure how long retries run, and — importantly — distinguishes retryable failures from hard declines where collection cannot continue until a new payment method is in place. That is a mature way to think about retries: not "try again on a fixed schedule," but "try again when it is most likely to work, and stop when trying is pointless."
The line that matters for India
The most useful sentence in Stripe's retry docs is the one where it admits it does not apply to India.
Stripe's own Smart Retries documentation states that it does not retry payments when the card is India-issued. That is not a gap in Stripe — it is an accurate read of the rail. Under RBI tokenisation and the e-mandate regime, you cannot simply re-hit a stored Indian card the way you can a US one; the consent, the authentication, and the token all work differently.
When the most sophisticated Western retry engine deliberately steps back at the Indian border, that is the signal: India is not a region you localise into, it is a different rail you build for.
Why translation fails
India is not just another market where the same recovery flow gets converted into local currency. The rails behave differently, the compliance is different, and the attention channel is different.
| Stripe Smart Retries assumption | Indian reality |
|---|---|
| Re-attempt the stored card on smart timing | UPI AutoPay queues in peak windows; mandates need re-auth; tokens can't just be re-hit |
| Hard decline → ask for a new method | True — but the "ask" has to reach the customer on WhatsApp, not only email |
| Retry timing solves most involuntary churn | Many Indian failures are consent- and authentication-shaped, not timing-shaped |
What an India-native split looks like
The cleaner model separates two jobs. The gateway — Razorpay or Cashfree — does the retrying, within RBI rules, on Indian cards and UPI AutoPay. The recovery layer does the reason, the reach, and the resolution: classify what failed, reach the customer on the right channel, and offer the right action. And it does one more thing a retry engine can't — it decides when not to retry or message at all, because the debit is a peak-window queue or a soft decline that will clear on its own.
Where SubsShield fits
SubsShield does not try to out-retry Stripe; it does the India-shaped work that begins after the gateway's retry — classify, reach on WhatsApp, resolve. It diagnoses and communicates; it does not move money.
So if even the best Western retry engine steps back at the Indian border, what in your stack is doing the part it won't?
Aditi Mehta, Founder, Pune SaaS · guest writer · Co-founder & CEO
Aditi is the founder of a Pune-based B2B SaaS company. She writes peer essays — the things she learned about Indian recurring payments the expensive way, after copying a US dunning playbook and watching it underperform on her own customers.