Payment Rail Deep Dives
Your 'failed' UPI AutoPay debit might not have failed at all
Since 1 August 2025, NPCI holds UPI AutoPay debits during peak hours and releases them later. A debit that looks failed may simply be queued — and recovery logic that can't tell will manufacture problems.
A founder in Chennai messaged me at 11:40 on a Tuesday morning, mildly panicked. His recovery tool had just fired failed-payment WhatsApps at forty-odd subscribers in one batch. By 2pm, more than half of those debits had gone through on their own — no customer action, no card update, nothing. He had apologised to forty paying customers for a problem that, for most of them, did not exist.
The tool was not broken. It just did not know what time it was.
A "failed" debit and a queued debit now look the same
Since 1 August 2025, a UPI AutoPay debit that looks failed during certain hours may not be failed at all. It may be queued. Facing record load — UPI crossed 20 billion transactions in August 2025 — NPCI moved recurring executions out of the busiest hours. AutoPay debits (subscriptions, SIPs, EMIs, bill payments) now process only in the non-peak windows: before 10am, between 1pm and 5pm, and after 9:30pm IST. The peak windows — 10am to 1pm and 5pm to 9:30pm — are reserved for real-time payments.
Read that from a recovery standpoint: a mandate execution attempted in a peak window is not necessarily declined by the bank. It can be held and released in the next non-peak window. The "failure" your system sees may be a timing artefact of the rail, not a problem with the customer's account.
"Failed" now means three different things
Most dunning logic runs on a single trigger: payment event says failed, start the sequence. On UPI AutoPay in 2025, the same event can mean three very different things.
| What the event says | What it may actually be | The right response |
|---|---|---|
| Failed (in a peak window) | Queued, not declined — executes in the next non-peak window | Say nothing; re-check via the gateway later |
| Failed (soft / insufficient funds) | The most common case; the gateway will retry | Let the retry run; time the nudge near payday |
| Failed (hard — re-auth or dead card) | A genuine stop; no retry fixes it without the customer | Message now — the only one that earns an immediate touch |
On UPI AutoPay, "failed on first attempt" is the normal state of a healthy subscription — not a crisis.
This is the normal state, not an edge case
In August 2025, depending on the bank, between 55% and 90% of AutoPay debit attempts failed on first execution (NPCI data via Mint and Business Standard). Most of that is soft — insufficient balance — and clears on a later try; roughly 20 million mandates are revoked every month, largely on low balances. The headline percentage is not the point. The point is that on this rail, a first-attempt failure is the routine condition of a large share of perfectly healthy subscriptions, and much of it is timing and balance, not intent.
If your trigger treats every first-attempt failure as a reason to message, you are not running recovery — you are running a daily false-alarm system on a channel where false alarms are the default.
The first job is to wait and classify, not to message
So the first job of an Indian recovery layer is not to send anything. It is to wait and classify. If the execution landed in a peak window, hold and confirm it actually failed in the next non-peak window before you say a word. If it is a soft, insufficient-funds decline, let the gateway retry — Indian salaried customers are mostly paid on the 1st or the last working day, so a failure on the 27th is a different situation from one on the 6th. Only when the failure is genuinely hard does an immediate message earn its place.
There is even a version that runs before the failure: the customer's bank must send a pre-debit notification at least 24 hours ahead under the RBI 2026 framework, so for a high-value renewal a friendly heads-up before that SMS can make the debit succeed in the first place.
Where SubsShield fits
SubsShield treats the time of day, the failure code, and the gateway's own retry state as inputs before it sends anything — which on UPI AutoPay means staying quiet through a peak-window queue and a soft retry, and speaking up only when the customer is genuinely the blocker. It diagnoses first; the message is the last step, not the first.
So pull your last month of UPI AutoPay "failures" and tag each one by the hour it was attempted. How many of the ones you chased were simply sitting in a peak-window queue that would have cleared on its own?
Meghna Iyer, Recovery Operations Lead · Co-founder & CEO
Meghna leads recovery operations at SubsShield. She writes the ops-level pieces — turning raw gateway webhooks into classified failure states, separating soft declines from hard ones, and building the playbook a founder runs across their first 50 failed payments.