UPI Collect Requests Fail 18% at First Deposit Above ₹5,000

First-deposit UPI Collect requests above ₹5,000 fail at the authorisation stage roughly 18% of the time, according to failure logs shared by three Indian payment aggregators that process for online gaming merchants. The figure covers the first six months of 2024 and refers specifically to the collect flow — the pull request a merchant raises against a customer's VPA — rather than intent-based UPI, where failure rates sit materially lower. The gap matters because collect is still the default rail for most casino and sportsbook cashier integrations in India.

What the 18% actually measures

The number needs unpacking before it travels. It is a first-attempt failure rate, not a permanent one. Of the 18% that fail, a majority succeed on retry — either immediately or within a 30-minute window — which pushes the eventual first-deposit success rate to around 91%. The residual 9% is where the money is lost: users who abandon after one or two declines and never return to complete the deposit.

The denominator is also narrower than it looks. The 18% applies to transactions where the requested amount exceeds ₹5,000. Below that threshold, the same aggregator logs show first-attempt failures clustering between 9% and 11%. The failure rate is not linear across amount bands, which suggests the causes are not purely technical.

Three mechanisms account for most of the gap.

Bank-side risk rules. Several large public-sector and private banks apply velocity and value checks to collect requests from merchants in the gaming MCC (merchant category code, currently 7995 in most acquirer setups). A ₹5,000+ pull from an unfamiliar VPA on a gaming merchant is more likely to be queued for manual review or auto-declined than a ₹1,000 pull. The threshold is not standardised across banks, but ₹5,000 appears repeatedly in the decline-reason data as a soft cut-off.

Customer-side abandonment. UPI Collect requires the payer to open their app, find the pending request, and approve it with a PIN. Above ₹5,000, users are more likely to pause, check their balance, or second-guess the deposit. Aggregators report that pending collect requests above ₹5,000 have a median approval time roughly 40 seconds longer than sub-₹5,000 requests — and time-to-approval correlates negatively with completion.

VPA and device mismatch. New accounts depositing for the first time often use a VPA that has no transaction history with the merchant. Risk engines weight first-time merchant-VPA pairs more heavily, and the weighting scales with amount. A first deposit of ₹10,000 from a VPA the merchant has never seen is the highest-friction case in the dataset.

Why the first deposit is the exposed point

Repeat deposits fail less often — around 11% at the same amount bands — because the merchant-VPA pair has history and the bank's risk engine has seen the pattern before. The first deposit carries the full weight of unfamiliarity on both sides.

This is structurally awkward for operators because the first deposit is the conversion event. Acquisition spend is sunk by the time the user reaches the cashier. A failed collect request at that moment does not just lose the deposit; it loses the registration, the KYC effort, and the attribution cost. Operators who model cost-per-first-deposit rather than cost-per-registration will recognise the 18% as an acquisition tax rather than a payments annoyance.

There is a second-order effect that rarely appears in operator dashboards. Users who hit a failure on their first deposit attempt are measurably less likely to attempt a second deposit later, even if the first eventually succeeds on retry. The aggregator logs show a 22% drop in 30-day repeat-deposit rate for users who experienced at least one collect failure on their first attempt, compared with matched users who did not. The mechanism is plausibly trust — a declined payment on a gambling site reads as a signal, however incorrectly — but the data cannot separate that from simple friction fatigue.

The workarounds and what they cost

The obvious response is to shift first deposits onto intent-based UPI, where the customer initiates the payment from their own app rather than approving a pull. Intent flows show first-attempt failure rates closer to 7% at the same amount bands, largely because the customer has already committed to the payment before the request reaches the bank.

The trade-off is operational. Intent flows require the merchant to generate a dynamic QR or deep link and reconcile the incoming credit against the pending deposit — a matching problem that collect avoids by design, since collect carries the order reference through the rail. Reconciliation errors on intent flows run higher, and for operators running bonus or free-bet logic tied to deposit confirmation, the delay between payment and credit is a support-ticket generator.

A second workaround is amount-splitting: capping the first collect request below the friction threshold and prompting for a top-up. This works on paper and fails on conversion, because it converts one decision into two. Operators who have tried it report first-deposit completion rates that are worse than the retry-based approach.

The third option is routing. Aggregators with multiple bank partnerships can retry a failed collect against a different acquiring bank, which recovers a meaningful share of the 18% within the same session. The recovery rate depends on how many bank rails the aggregator holds and whether the merchant's integration surfaces the retry to the user without requiring re-entry. Merchants on single-bank integrations recover almost none of it.

What the number implies for onboarding design

If 18% of first collect attempts above ₹5,000 fail, and the median Indian casino first deposit sits somewhere between ₹2,000 and ₹6,000 depending on the operator's acquisition mix, then a substantial share of the customer base sits right at the friction boundary. The design implication is not to lower minimum deposits — that suppresses revenue per user — but to treat the first deposit as a multi-rail problem from the outset: collect as the default, intent as the fallback, and a retry path that does not require the user to re-enter anything.

The open question is whether the 18% is stable or moving. Bank risk rules on gaming MCCs have tightened over the past 18 months, and the aggregator data covers a period before the most recent round of acquirer policy changes took effect. If the rate is drifting upward, the first-deposit conversion problem is compounding quietly, and operators modelling acquisition costs on last year's payment assumptions are understating what a registered user is actually worth.