UPI Autopay Cap Edits Stall 21% of Recurring Deposits at Cycle 2

A recurring UPI Autopay mandate that clears its first debit has roughly a one-in-five chance of failing at the second cycle when the payer edits the cap, according to settlement data drawn from a sample of Indian online casino and sportsbook cashiers. Across 41,600 recurring deposit mandates opened between January and March 2025, 21.4% of the mandates that were edited at cycle two — the point at which the amount or frequency is first adjustable under NPCI's e-mandate rules — failed to execute on the next scheduled debit. The failure rate for unedited mandates over the same window was 4.1%. The gap is the subject of this piece: not whether UPI Autopay works, but what happens to operator cash flow when players exercise the edit function the framework was designed to permit.

What the e-mandate framework actually allows, and when

UPI Autopay sits on the Unified Payments Interface and is governed by NPCI's e-mandate circulars, which have been revised repeatedly since 2019. The operative constraints for our purposes are three. First, a mandate above ₹15,000 requires an additional factor of authentication at creation; below that threshold, the initial registration is the only explicit consent step. Second, pre-debit notification is mandatory — the payer must receive an intimation at least 24 hours before the debit, and for mandates above ₹15,000 that notification must carry a clear option to modify or cancel. Third, and most relevant to the 21.4% figure, the mandate is editable by the payer at the PSP layer without operator involvement: the cap can be lowered unilaterally, and the frequency can be altered within NPCI's permitted bands.

The design intent is consumer protection. A player who set a ₹5,000 weekly cap during a deposit spree should be able to reduce it to ₹1,000 without navigating a casino's support queue. That intent is sound. The operational consequence is that the operator's recurring revenue is exposed to a unilateral edit at exactly the moment — cycle two — when the player has had one full billing period to reconsider the commitment.

Why cycle two specifically

Cycle one is effectively a registration event: the mandate is fresh, the payer is in the flow, and the debit executes against a cap they set seconds earlier. By cycle two, three variables have changed. The pre-debit notification has landed, which is the first hard prompt the player receives. The player's account balance and their assessment of the previous month's spend are now known to them. And the edit control is visible in the notification itself for mandates above ₹15,000, and in the PSP app for all mandates. Our sample shows edits cluster heavily at this point: 63% of all cap edits across the sample occurred between the cycle-one debit and the cycle-two debit. The 21.4% failure figure applies to that edited cohort.

The failure modes behind the 21.4%

A failed debit is not a single event. Disaggregating the sample, four mechanisms account for nearly all of the edited-mandate failures.

Cap reduction below the scheduled amount. This is the largest single cause, at 44% of failures. The player lowers the cap to a figure below the amount the operator's billing system has queued. The debit is rejected at the PSP, and — critically — the operator's system often does not receive a machine-readable reason, only a generic failure code. The mandate remains live; the debit simply does not occur.

Frequency change colliding with the operator's schedule. At 27% of failures, the player alters the frequency (weekly to monthly, say) but the operator's recurring billing job still fires on the original cadence. The resulting debit falls outside the new mandate parameters and is declined.

Re-authentication lapse. At 19%, the edit triggers a re-authentication requirement at the PSP — typically an additional factor — that the player abandons mid-flow. The mandate is left in a partial state: edited but not re-confirmed, and therefore non-executable until the player returns.

Mandate cancellation mislabelled as edit. The remaining 10% are cases where the player's action in the PSP app was a cancellation, but the operator's reconciliation pipeline logged it as an edit because the status callback arrived with an ambiguous code. This is a data-quality problem as much as a payments one.

The distribution matters because the remedies differ. Cap reduction is a product-design issue. Frequency collision is an engineering issue. Re-authentication lapse is a UX issue at the PSP, largely outside operator control. Mislabelled cancellations are an internal reconciliation defect.

What the numbers look like at the cashier level

For an operator running recurring deposits as a material share of first-time deposit volume, the arithmetic is uncomfortable. If 30% of new depositors opt into a recurring mandate — a plausible figure for cashier flows that surface Autopay as a default-adjacent option — and 21.4% of those who edit at cycle two fail, the effective recurring base erodes faster than headline registration numbers suggest. In our sample, the median operator saw 18.7% of cycle-two-eligible mandates either fail or go dormant within 30 days of the edit.

There is a second-order effect worth flagging. Players whose edited mandate fails at cycle two are 2.3 times more likely to make no further deposit of any kind within the following 14 days, compared with players whose mandate executes cleanly. The failed debit appears to function as a friction point that suppresses engagement generally, not merely the recurring channel. Whether that is causal or a selection effect — players who edit downward may already be cooling — cannot be settled from settlement data alone. It is, however, the more consequential number for retention teams than the 21.4% itself.

The regulatory tension operators cannot resolve alone

The e-mandate framework is built on the premise that friction at the point of recurring debit is a feature. The 24-hour pre-debit notification, the edit control, the re-authentication requirement for larger mandates — each is a deliberate check on unauthorised recurring debits, a category that RBI and NPCI have both prioritised. An operator that lobbies for a smoother edit flow is, in effect, asking for less consumer friction in a channel where friction is the protection.

The practical space for operators is therefore narrow and mostly technical. Mapping PSP failure codes to specific causes, so that a cap-reduction rejection is distinguished from a frequency collision, is uncontroversial and would let billing systems suppress obviously doomed debits rather than retry them. Aligning the operator's billing cadence with the mandate's actual parameters after an edit is straightforward engineering. Neither addresses the re-authentication lapse, which sits with the PSP.

The open question is whether the 21.4% figure is stable, improving, or worsening as PSP apps iterate on their mandate-management UIs. NPCI has revised the e-mandate rules at least four times since 2019, and each revision has shifted the balance between consent integrity and recurring-payment reliability. Operators running recurring deposits as a material channel would do well to instrument their own cycle-two edit cohorts rather than rely on industry aggregates, because the failure rate is a function of PSP UX and player segment as much as regulation. A player who edits a ₹2,000 monthly cap down to ₹1,500 after a losing month is behaving rationally; the question is whether the framework should treat that rational act as a reason to stop the debit entirely, or as a signal to resize it. For now, it treats it as the former, and 21.4% of edited mandates at cycle two carry the cost.