Deposit Failed but Money Deducted: Get Your Add-Cash Back

The 30-second answer

You tapped add cash, your bank debited it, and the wallet never moved. A deposit is a merchant payment (P2M), so under RBI’s TAT circular it must auto-reverse by T+5 — not T+1 — after which your bank owes ₹100 a day. Capture the UTR, count your debits, dispute through NPCI UDIR, and pursue a reversal, never a re-deposit.

This page is the deposit-side mirror of the refund cluster. The recovery hub — Refund and dispute recovery — covers the whole map of getting money back from a gaming app: payout reversals, KYC-blocked balances, chargebacks, the Day-0-to-30 ladder. This spoke zooms all the way into one specific event: you added cash, the money left, and the chips never arrived. If your problem is a withdrawal that was debited from the operator and never reached your bank, you’re on the wrong page — that’s the UPI failed, money debited spoke, which is the withdrawal-side twin of this one. If the money flowed out of your account toward a game and vanished, you’re in exactly the right place. We’ll name the rail, name the liable party, decode why a deposit can fail after a clean debit, and walk the exact dispute path.

2026 reality, stated once. After the Promotion and Regulation of Online Gaming Act, 2025 (PROGA) took force (Rules in effect 1 May 2026), depositing real money into an online money game is no longer a grey area — it is part of a criminalised payment chain. That changes the goal of this whole guide. You are not here to “top up” or to “unlock” anything. You are here to recover a failed or erroneous debit — your own money that left your account and produced nothing. The rail protections below apply identically to that recovery. The one rule that hardens: never add a second deposit “to fix” the first. A fresh deposit into a banned money game is illegal, and on the deposit side a re-attempt is also the fastest way to turn one missing ₹500 into two.

What “deposit failed but money deducted” actually means

The phrase describes a symptom, and like most payment symptoms it hides at least three different mechanical causes. The five words “add cash failed, money deducted” tell you almost nothing about which one you have — and since each one has a different liable party and a different clock, guessing wrong wastes the exact days you need for the right fix. So start with the plumbing.

When you tap add cash, you are the sender. Money leaves your bank account or UPI handle and travels toward the game’s wallet. But it does not travel directly to the game. It travels to the game’s payment aggregator — a regulated intermediary like Razorpay or Cashfree that collects the money on the operator’s behalf, holds it briefly in an escrow account, and then settles it to the operator. The game itself almost never touches a raw UPI credit. That single layer — the aggregator sitting between your debit and your chips — is where most deposit failures are born, and it’s the layer every “the app stole my money” rant ignores.

A successful deposit has three legs the user sees as one instant tap:

• A debit leg, where money leaves your account.
• A collection leg, where the payment aggregator receives the money into its escrow.
• A credit/credit-confirmation leg, where the aggregator confirms success back to the operator and the operator’s system bumps your wallet balance by the deposited amount.

When add-cash works, all three complete in under five seconds and you never think about them separately. A deposit failure is what you call it when the debit leg completed but one of the later legs didn’t — the money left you, but the wallet number never moved. And crucially, the system has not yet resolved whether the money will eventually credit, bounce back, or sit stuck. That unresolved gap is the entire problem. Real money is gone from one place and has not arrived at the other.

Here’s the distinction that decides everything downstream: a deposit can fail at three different points, and the recovery differs at each.

• The rail failed. The aggregator never received your money cleanly — a UPI timeout, a downed link, a bank that didn’t confirm. The money is in payment-system limbo, owed back to you under the TAT rules.
• The aggregator received it, but the wallet never updated. The money reached the operator’s escrow, but the credit-confirmation back to the game didn’t land, or the game’s wallet-update job hit a bug. The money is with the operator’s payment chain, and the fix is on their side — credit the wallet or refund the source.
• You actually paid twice. The first tap looked failed, you re-tapped, and now your statement shows two debits for one intended deposit. This is the most common self-inflicted loss on the deposit side, and it’s why rule one is: count your debits before you do anything.

Hold the core idea: a debit with no chips is a payment-system event with hard RBI timelines, not a gaming-app mood. The moment money is debited on a regulated rail, your problem stops being “the app is buggy” and becomes “a regulated entity owes me a reversal.” That shift is your single biggest lever, and the rest of this page is about pulling it correctly. For the broader recovery map across every refund scenario, the hub ties this into the full picture; here we stay zoomed on the add-cash failure.

The number that matters most on Day 0

One figure decides what follows: the UTR/RRN — the 12-digit reference that ties your specific debit to its (missing) credit. Without it, no bank can trace your money and no dispute can be filed. With it, every door below opens. Capture it within the first hour, before the failed transaction ages out of your app’s quick view. The exact menu path per UPI app is later in this guide. The second figure that matters: how many debits hit your account. One missing deposit is a dispute; two debits for one intended deposit is a double-charge recovery, and you handle them differently.

Why a deposit fails after the money is already gone

This is the part almost every explainer skips, because it’s counter-intuitive: how can the money leave your account if the deposit “failed”? The answer is that the debit and the success-confirmation are two separate events on two separate timelines, and the gap between them is where every deposit failure lives. Here are the concrete reasons a deposit fails after a clean debit, in rough order of how often they’re the real cause.

Gateway timeout (the most common cause)

UPI gives each transaction a tight time budget. Your bank debits you, sends the credit instruction toward the aggregator, and waits for a confirmation. If that confirmation doesn’t come back inside the window — the aggregator’s server was slow, the network hiccupped, the operator’s callback endpoint didn’t respond in time — the transaction times out. Your bank has already moved the money; the confirmation never closed the loop. Per the TAT circular, a timeout is explicitly a failure “not attributable to the customer,” which is the clause that puts you inside the compensation framework. A timed-out deposit is, oddly, the cleanest kind to recover, because the system can plainly see it never completed.

The merchant flow: aggregator received it, callback didn’t fire

A deposit is a person-to-merchant (P2M) transaction, and the “merchant” is the operator as represented by its payment aggregator. Under the RBI Payment Aggregator Directions 2025 (issued 15 September 2025), the aggregator collects your money into a bank-held escrow and is obligated to settle it to the operator by T+1. The wallet credit, though, depends on a callback — the aggregator pinging the operator’s server to say “payment succeeded, credit this user.” If that callback fails or is delayed, your money is sitting safely in the aggregator’s escrow, but the game has no idea you paid, so your balance stays flat. This is the case where the money genuinely reached the operator’s chain and the fix is a reconciliation, not a rail reversal.

KYC or deposit-limit block

A deposit can be debited and then rejected at the operator’s risk layer. The aggregator’s merchant due-diligence rules and the operator’s own controls can hold or bounce a payment when the paying account’s name doesn’t match the registered user, when a daily deposit cap is hit, when an account is flagged, or when an unverified user crosses a deposit threshold that triggers a KYC wall. The money may have left your bank an instant before the rejection fired, leaving you debited while the operator declines to credit a payment it won’t accept. The reversal is owed — but the cause is a control, not a crash, and the operator’s support is the faster door for these because they can see the explicit reject reason.

Deemed success (the hard case)

This is the dangerous one. A deemed-successful (or “deemed approved”) deposit is one the payment system marks as completed even though your chips never appeared. It happens, per NPCI’s deemed-approved process, when your bank successfully sends the money out and settlement moves toward the beneficiary (the aggregator), but the final credit confirmation isn’t received in time. To keep the rail moving, the transaction is deemed to have succeeded and pushed to settlement. So your bank SMS says “success,” the app may even say “completed,” yet your wallet is empty of the credit. As one payments processor explains, the amount sits in a “deemed success” state until the aggregator and NPCI reconcile it to a terminal state — processed, failed, or reversed. The deposit version of this is brutal because the operator can point at the “success” stamp and insist you were credited, while your wallet flatly disagrees.

The double-debit illusion

This isn’t a rail fault at all, but it produces the identical symptom. You tapped add-cash, the screen lagged or showed “failed,” you assumed nothing happened and tapped again — and now your statement carries two debits for one intended deposit. The first one may have actually succeeded (chips credited), or both may be in limbo, or one succeeded and one failed. Every combination looks like “money deducted, deposit failed” until you read the statement line by line. This is why counting debits is rule one: the recovery for one failed deposit and two debits where one worked are completely different claims.

The one-line triage for why it failed: timeout → cleanest, reverses almost mechanically. Callback miss → money’s with the operator’s aggregator, fix is reconciliation. KYC/limit block → a control rejected it, operator support is fastest. Deemed success → the hard one, you must prove the missing credit with the UTR. Double-debit → not a failure, a duplicate, recovered as an extra-debit refund. Sort yours first; the fix follows from the cause.

Failed vs deemed-successful vs pending: the bucket that decides your case

The system does not see “deposit failed, money deducted” as one status. It sorts every stuck deposit into one of three buckets, and which bucket yours lands in decides whether you get an automatic refund or a fight. Read the exact word on your transaction screen and bank SMS — they’re surprisingly consistent.

Bucket 1 — Failed

A failed deposit is one the system has already concluded did not complete. RBI’s TAT circular defines it precisely as “a transaction which has not been fully completed due to any reason not attributable to the customer such as failure in communication links, non-availability of cash in an ATM, time-out of sessions, etc.” That clause — not attributable to the customer — is the gate into the entire compensation framework. A deposit that failed on a timeout or a downed link is the payment system’s problem to fix, on its clock, with its compensation. This is the best bucket. If your add-cash is cleanly marked “failed” and the money left, a reversal is owed almost automatically, and for a P2M failure it’s due by T+5.

Bucket 2 — Pending

A pending deposit is one the system hasn’t decided yet. The debit happened, the credit hasn’t confirmed, and the rail is still waiting to hear back. Pending is a temporary state by design — the holding pen while reconciliation runs. NPCI’s own benchmark is that most failed deposit refunds should land within 60 minutes, and the great majority of pending UPI transactions resolve within minutes to a working day, either completing (chips credited) or failing (money reversed). The mistake is treating Day-0 pending as theft. It usually isn’t; it’s the rail doing what the rail does. Pending has a hard expiry: for a merchant payment that doesn’t resolve, the reversal is due by T+5.

Bucket 3 — Deemed successful (the hard case)

A deemed-successful deposit is marked completed even though no chips arrived. The money reached the aggregator’s escrow, but the final credit-confirmation to the operator wasn’t received in time, so it was deemed to have succeeded to keep the rail moving, per NPCI’s process. The status word says the money arrived; reality says the wallet is empty. To win this, you can’t just point at a “failed” stamp — you have to prove a negative: that the deposit produced no chips and either the money is owed back or the operator must credit it. That’s why the UTR is non-negotiable here, and why you fight on two fronts at once — the rail dispute and the operator’s reconciliation.

The one-line triage for which bucket: Failed → reversal owed, often automatic, T+5 for a deposit. Pending → wait, it has a T+5 expiry, most resolve in under an hour. Deemed successful but no chips → you must prove the missing credit with the UTR and push the operator’s reconciliation. The first two largely fix themselves on the rule-clock; the third is the one you actually have to work.

A practical tell for your bucket: read the exact word. “Transaction failed” / “payment unsuccessful” → Bucket 1. “Pending” / “processing” / “awaiting confirmation” → Bucket 2. “Success” / “completed” / “paid” with a UTR but no chips in your wallet → Bucket 3, the one that needs the operator reconciliation plus the bank trace. The hub’s recovery map places this alongside every other refund scenario; here we stay zoomed on the add-cash row.

The RBI TAT framework, decoded for a deposit

Everything you’re entitled to flows from one document: RBI Circular DPSS.CO.PD No.629/02.01.014/2019-20, dated 20 September 2019 — the “Harmonisation of Turn Around Time (TAT) and customer compensation for failed transactions” circular, effective 15 October 2019. People quote “₹100 a day” without reading the table, and on the deposit side they almost always quote the wrong deadline. The table is short, and the deposit row is the one nobody reads.

The rule that makes compensation automatic

The most under-used sentence in the circular: “Wherever financial compensation is involved, the same shall be effected to the customer’s account suo moto, without waiting for a complaint or claim.” Read that again. The ₹100/day is not a favour you beg for — it is a credit your bank or the liable party is obligated to push to you on its own, the moment it blows past the TAT. In practice many don’t, which is exactly why the claim letter later in this guide cites this clause by name. You are not asking; you are reminding them of an existing duty.

The TAT table, with the deposit row highlighted

The circular sets a turnaround time and a compensation rate per transaction type. These are the rows that matter for a game deposit and the payout it sits next to:

(Source: the TAT circular’s annex table and the Cashfree annexure of the same table. “T” is the calendar date of the transaction.)

Three things in that table change how you fight a deposit, and most people miss all three.

First — your deposit is T+5, not T+1. When you add cash, the payment is to a merchant, and a game-wallet top-up is a textbook P2M payment. So the reversal deadline stretches to T+5, because the merchant’s acquiring bank (the aggregator) needs longer to confirm whether the merchant got the money. This is the single most common deposit-side mistake: a player rages at the bank on Day 2 of a failed deposit, demanding the “T+1 reversal” they read about — and the agent correctly tells them the rule allows the merchant five. A failed deposit can legitimately take up to five days to reverse. A failed payout credit to your bank should bounce in one. Same five symptom-words, different deadline, because the direction of money changed who the law treats as the merchant.

Second — liability sits with the acquirer, not your bank. For a P2M failure, the acquirer — the aggregator’s bank — carries the reversal and the compensation, not your own bank. This matters because when you complain, your own bank may genuinely be telling the truth when it says “the money left us cleanly.” It did. The hold-up is downstream, in the aggregator’s settlement chain. Your bank is still the door you knock on (it lodges the dispute and traces the UTR), but the liable party is the acquirer.

Third — “not attributable to the customer” is the eligibility gate. The compensation only covers system/technical failures, not your own mistakes. If you typed the wrong VPA and the money went to a stranger, that’s not a “failed transaction” under this circular — it completed, just to the wrong person, and the recovery path is different (you request a reversal from the recipient, you don’t claim ₹100/day). But a deposit that the rail couldn’t deliver to the merchant is a system path, fully covered. An add-cash timeout is almost always in the covered category.

Worked timeline: a ₹500 deposit that fails on a Saturday

Make it concrete. You add ₹500 to a game wallet at 9:10 p.m. on Saturday (T) by UPI. Your bank SMS confirms ₹500 debited; the wallet still reads its old balance.

• Saturday (T): Capture the UTR from the SMS and the UPI app immediately. Open your bank statement and confirm exactly one debit of ₹500, not two. Do not re-deposit. This is a P2M payment, so the deadline is T+5, not T+1.
• Sunday (T+1): Raise the dispute in your UPI app against the ₹500 debit (the per-app path is below). Also tell the operator’s support, with the UTR, in case the money reached the aggregator but the wallet didn’t update.
• Tuesday (T+3): If the merchant’s bank hasn’t responded, NPCI UDIR auto-converts the complaint to a chargeback at T+3 for a P2M transaction.
• Thursday (T+5): The merchant-payment reversal deadline. If the ₹500 still hasn’t reversed, the ₹100/day clock starts and you lodge the formal bank complaint citing the circular.
• Friday (T+6): One day past T+5 — ₹100 compensation has now accrued on top of the ₹500. By Tuesday (T+10) that’s ₹500 of compensation if it’s still missing.

The deposit case wants a clean failure — then you simply get your ₹500 back. Because it’s the PROGA era, the goal is the reversal of the ₹500, not chips: pursue the refund and stop. The payout-side twin of this exact timeline — a credit that fails on its way to you — runs on T+1 instead, and the UPI failed, money debited spoke walks it in full.

The deposit travels through a payment aggregator — and that changes the dispute

This is the deposit side’s most useful original cut, so it gets its own section. When you add cash, your money does not go straight to “Teen Patti.” It goes to the operator’s payment aggregator (PA) — Razorpay, Cashfree, PayU, or similar — which is a separately regulated entity sitting between you and the game. Understanding that layer tells you who actually holds your money at each second, and therefore who to push.

The escrow model: your money is parked, not spent

Under the RBI Payment Aggregators Directions 2025, every non-bank PA must keep collected merchant funds in an escrow account with a scheduled commercial bank. When your ₹500 deposit succeeds at the rail, it lands first in that escrow — it is not yet the operator’s money, and it is not yet chips in your wallet. It sits in a regulated holding account. The PA is then obligated to settle it to the operator’s account, and the framework caps that at T+1 — money must reach the merchant within a maximum of T+1 banking day. The practical consequence for you: when a deposit “fails” but your bank shows a clean debit, the money is very often sitting in the aggregator’s escrow, fully traceable, owed either back to you (rail reversal) or onward to the operator (settlement) depending on whether the transaction terminated as failed or success.

Why the wallet can stay flat even when the rail succeeded

The PA’s job is two-sided. It collects your money, and it tells the operator “this user paid, credit them.” That second message is a server callback (a webhook), and it is a separate event from the money movement. If the callback fails — the operator’s endpoint was down, slow, or rejected the message — then the rail has succeeded (your money reached escrow) but the operator never learned of it, so your wallet stays flat. This is the maddening case where everyone is half-right: your bank says “paid” (true, to escrow), the rail says “success” (true), and the operator says “we never got a deposit notification” (also true). The money is real and locked in a regulated escrow; the fix is the operator and PA reconciling the missing callback, which they do from the PA’s transaction dashboard using your UTR.

Who’s liable, in one map

The reason this matters: a deposit dispute is really a chain, and your job is to find which link is stuck and aim at it. Aiming the TAT ₹100/day claim at your bank when the money is sitting in the PA’s escrow awaiting a callback fix gets you nowhere — your bank moved the money cleanly. Conversely, waiting on the operator’s “we’ll check” when the money never reached the rail at all wastes your T+5 window. Trace the UTR, find the link, push the holder of the money at that link. The recovery hub frames this within the full dispute architecture; this section is the deposit-specific zoom.

The aggregator takeaway in one line: your deposit is held by a regulated PA in escrow for a beat, not handed straight to the game — so a “failed” add-cash with a clean debit is almost always traceable money in a regulated account, owed back to you (rail reversal) or onward (settlement), and the UTR is the key that finds it.

How to tell if it auto-reverses vs needs a dispute

The most useful question on Day 0 isn’t “where’s my money” — it’s “will this come back on its own, or do I have to chase it?” Getting that right saves you both the panic of disputing a refund that was already coming and the cost of waiting on one that never will. Here’s the decision, in order.

Step 1 — read the status word

• “Failed” / “unsuccessful” → strong auto-reverse candidate. The system already concluded it didn’t complete; for a P2M deposit the reversal is due by T+5, often much sooner. Likely auto-reverses. Watch for it; only dispute if it misses the window.
• “Pending” / “processing” → wait. Most resolve in under an hour, all should resolve by T+5. Likely auto-resolves one way or the other. Don’t dispute on Day 0.
• “Success” / “completed” but no chips → does NOT auto-reverse. The system thinks it paid you, so no reversal will fire on its own. This one you must work — bank trace plus operator reconciliation.

Step 2 — check whether the money is in escrow or in limbo

If you can get the operator or its PA to confirm the deposit reached the aggregator’s escrow (status “success” at the rail), then it will not auto-reverse to you — it’s owed onward to the operator, and your fix is the operator crediting your wallet or refunding the source. If the rail status is failed, the money is owed back to you and an auto-reversal is the expected path.

Step 3 — count the debits

If there are two debits for one intended deposit, the extra one is almost certainly an erroneous duplicate — and a duplicate debit on a P2M is owed back under the same T+5 rule. This will tend to reverse once flagged, but you should dispute the duplicate explicitly because the system may treat both as valid until you raise it.

The auto-reverse vs dispute decision table

The honest summary: a cleanly failed or pending deposit is the kind that fixes itself on the rule-clock, usually within hours and certainly by T+5 — your job there is mostly to not make it worse (don’t re-deposit) and to be ready to dispute if it misses the window. A deemed-successful deposit with no chips is the kind that never self-corrects, because the system believes it already paid — that’s the one you actively chase with the UTR. Sort yours into one of those two before you spend a single minute complaining.

How to read the deposit narration, UTR, and your statement

You can’t dispute what you can’t prove, and on the deposit side the proof lives in two places — your bank statement and your UPI app history — both hinging on one number. Here’s how to read each so no desk can brush you off with “we have no record.”

The UTR/RRN: one number, many names

For a UPI deposit, the UTR (Unique Transaction Reference) and the RRN (Retrieval Reference Number) are, for practical purposes, the same 12-digit number. The RRN is the 12-digit reference used for inter-bank tracking; the UTR is the broader term. For your deposit debit, when the bank asks for “the RRN” and the app shows “UPI Reference No.,” they point at the same 12 digits. This is the number your bank traces. Without it, the failed-transaction desk literally cannot look up your money.

Each app labels it differently, which is why people think they “don’t have a UTR” while staring right at it:

• PhonePe: “UPI Reference No.” (or “UPI Transaction ID”)
• Google Pay: “Bank Reference ID” / “UPI transaction ID”
• Paytm: “UPI Ref No.”
• BHIM: “Transaction ID”

All four are the same 12-digit thread. (The exact menu path to each is in the dispute section below.)

Reading the deposit narration on your statement

Open your account statement or passbook for the deposit date. A UPI deposit debit appears as a single line that contains, in some order:

• The debit amount (with a “Dr” marker or in the withdrawal column).
• A UPI narration that typically reads something like UPI/[12-digit RRN]/[merchant or aggregator VPA]/[bank]. The 12-digit block in that narration is your RRN/UTR — read it off there if the app won’t show it.
• The value date and time.

Here’s the deposit-specific tell most people miss: the beneficiary VPA in the narration is usually the aggregator, not the game. You’ll see something like razorpay, cashfree, payu, or a cryptic merchant handle ending in @axisbank / @hdfcbank / @ybl — not “TeenPatti.” That’s normal and correct: your money went to the operator’s payment aggregator, which is exactly why a deposit is a P2M transaction with a T+5 clock. Don’t read the unfamiliar merchant name as fraud; read it as confirmation you’re in the merchant-payment lane. If the VPA is a recognizable aggregator, that’s a strong sign the money is sitting in a regulated escrow and is traceable.

What you prove with the statement is simple and powerful: the debit happened, on this date, for this amount, with this RRN, to this merchant/aggregator. For a deposit failure, the matching question is whether your game wallet rose by that amount (it didn’t — that’s your dispute). The absence of the matching wallet credit, against a named RRN paid to a named aggregator, is the entire evidentiary core of a failed-deposit claim.

Reading the UPI app history

In the app, open the transaction’s detail screen (not just the list). Capture, in one screenshot:

• The amount and date/time.
• The status word — “Failed,” “Pending,” or “Success/Completed” — which tells you your bucket.
• The UTR/RRN under its app-specific label.
• The beneficiary (the aggregator VPA the money was heading to).

Build the one-page evidence file on Day 0

Pull all of it into a single place within the first hour, because a failed transaction can drop out of an app’s quick view and a bank’s quick-trace window after a few days:

1. Screenshot of the app’s transaction detail (status + UTR + aggregator VPA).
2. Screenshot or PDF line of the bank statement debit showing the same RRN.
3. The bank SMS for the debit (it independently carries the RRN and timestamp).
4. Screenshot of the game wallet balance showing it did not rise (ideally with the in-app “add cash” history showing the failed/missing entry).
5. The support ticket ID once you raise one.

Five artifacts, one number tying them together. With that file, no desk can tell you “we have no record” — you hand them the record. The wallet screenshot is the deposit-specific addition the withdrawal side doesn’t need: it’s how you prove the credit (chips) never happened, which is the whole claim. Without it, you’re arguing from memory, and memory loses every payment dispute.

The exact dispute path: bank → payment aggregator → operator → NPCI UDIR → RBI

A deposit dispute has one more door than a payout dispute — the aggregator/operator link — because the money may be sitting in escrow rather than lost on the rail. Climb in sequence; skip a rung and the next authority bounces you back. Here is each door, what it’s for, and the gate that opens it.

Step 1 — Confirm the debit count and capture the UTR (Day 0)

Before any complaint, open your bank statement and answer one question: how many times were you actually debited for this deposit? One debit → a single failed-deposit claim. Two debits → a duplicate-debit claim where one may have worked. Capture the UTR for each debit. This five-minute check prevents the single most common deposit loss: chasing “a failed deposit” when in fact you paid twice and one succeeded.

Step 2 — Raise the in-app UPI dispute (feeds NPCI UDIR)

Every major UPI app has a per-transaction complaint button that routes into NPCI’s Unified Dispute and Issue Resolution (UDIR) system. The menu path per app:

• PhonePe: History → tap the transaction → Help / Contact Support → “money debited but not received” / “payment failed” → submit. PhonePe’s own failed-transaction guide confirms this path.
• Google Pay: tap the transaction in activity → support/question option → select the failed/not-received issue → raise dispute.
• Paytm: Balance & History → UPI & Bank Transfer → open the transaction → Help & Support → pick the dispute reason → submit. Paytm’s own recovery guide walks the deducted-not-received path.
• BHIM: Transaction History → open the transaction → Raise Concern → file.

For a merchant (P2M) payment — your deposit — the auto-conversion to chargeback happens at T+3 if the merchant or its bank doesn’t respond, and NPCI’s system keeps polling for the final status for up to 5 days before settling to a terminal state. NPCI’s stated overall window for a UPI complaint is 3–5 working days. So the in-app dispute isn’t a black hole — it has a built-in deadline that forces a resolution.

If the app won’t let you raise the dispute, go straight to the NPCI UPI Help portal “Dispute Redressal” page and file with the UPI transaction ID (UTR/RRN), bank, amount, date, registered mobile, and email. The same engine processes it. The NPCI UPI complaint line is 1800-120-1740 and the help email is [email protected].

Step 3 — Tell the operator (and, through it, the aggregator)

This step is more important on the deposit side than the withdrawal side, because the money may have reached the operator’s aggregator and only the wallet credit is missing. Open the game’s support and report the failed deposit with the UTR. You’re forcing the operator to do one of two things from its PA dashboard:

• Confirm it received the funds — in which case the rail succeeded, the money is in its chain, and the fix is the operator crediting your wallet or (the correct PROGA-era outcome) refunding the source. Do not accept chips into a banned game; insist on a source refund.
• Confirm it did not receive the funds — in which case the rail failed, the reversal is owed to you, and your UDIR/bank dispute is the right track.

Either answer narrows your case. Get it in writing with a ticket ID. The customer-care escalation guide covers exactly how to reach an operator’s grievance channel and force a written answer rather than a chat-bot loop.

Step 4 — Lodge the bank’s failed-transaction complaint (claim the ₹100/day here)

Run this in parallel, especially once you’re near or past T+5. Call your bank’s helpline or use its app’s complaint flow and lodge a failed-transaction dispute with the UTR/RRN. Then say the sentence most callers never say:

“This is a merchant payment (P2M) that was debited but not credited, under RBI circular DPSS.CO.PD No.629/02.01.014/2019-20. It should have auto-reversed by T+5. We are past that, so I’m claiming the ₹100-per-day compensation, which the circular says is to be credited suo moto.”

Get a complaint reference number in writing. The bank’s grievance flow is the formal record that later feeds the RBI Ombudsman, and the 30-day clock that unlocks the Ombudsman starts from this complaint, so dating it matters.

Step 5 — Escalate to the RBI Integrated Ombudsman (after 30 days)

If the regulated entity — your bank, or the payment aggregator as a Payment System Participant — doesn’t resolve it, the RBI Integrated Ombudsman Scheme 2021 (RB-IOS) is the free, binding escalation. You can file if the entity doesn’t respond within 30 days, rejects the complaint, or you’re unsatisfied. The scheme covers banks, NBFCs, and Payment System Participants — which is why a UPI deposit failure, sitting in a PA’s escrow, is squarely in scope. File at cms.rbi.org.in. Note the outer limit: the complaint must reach the Ombudsman within one year of the entity’s reply (or one year and 30 days of your original complaint if you got no reply), so don’t let it drift.

The timeline gates as one clock

Read it as a staircase. Don’t run to the Ombudsman on Day 2 (it’ll bounce you to the bank), and don’t let a “failed” deposit sit untouched for two weeks (you’ll miss the easy UDIR window and the auto-reversal you were owed). Each rung opens on a specific day.

The copy-paste claim letter that invokes the ₹100/day for a failed deposit

Here is the letter that does the work for a deposit specifically — it names the merchant/P2M classification and the T+5 deadline, so the desk can’t redirect you to the wrong rule. Fill the brackets, keep it factual, and send it to your bank’s grievance channel with a copy to the operator’s support.

Subject: Failed UPI deposit (P2M) — UTR [RRN] — debited not credited —
reversal + TAT compensation under RBI DPSS.CO.PD No.629

To: [Your bank's grievance officer / failed-transaction desk]

A UPI merchant payment (an add-cash deposit) was debited from my account
but the funds were never credited to the merchant's wallet on my behalf,
and no goods/credit were received. Details:

- UTR / RRN (12-digit): [RRN]
- Amount: ₹[AMOUNT]
- Date and time of transaction (T): [DATE, TIME]
- My account number / UPI ID: [A/C or HANDLE]
- Beneficiary VPA shown (aggregator/merchant): [VPA from narration]
- Transaction type: merchant payment (P2M)
- App status shown: [failed / pending / success-but-no-credit]
- Number of debits for this deposit: [ONE / TWO — state duplicates]

This is a "debited but not credited" failure NOT attributable to me.
Under RBI circular DPSS.CO.PD No.629/02.01.014/2019-20 (20 Sep 2019),
a merchant (P2M) payment debited but not confirmed must be auto-reversed
by T+5. It has now been [N] days since T, past that deadline. The same
circular states that where compensation is involved it "shall be effected
to the customer's account suo moto, without waiting for a complaint or
claim," at ₹100 per day of delay beyond the deadline.

I therefore request, within your grievance timeline:
  1. Reversal/credit of ₹[AMOUNT] against the above UTR; and
  2. The ₹100/day compensation accrued from T+5 to the date of credit; and
  3. A written complaint reference number for this grievance.

If unresolved within 30 days of this complaint, I will escalate to the
RBI Integrated Ombudsman (RB-IOS 2021) at cms.rbi.org.in, citing this
reference and the circular above.

[Name] · [Registered mobile] · [Date]

Two notes on using it well. State “merchant payment (P2M)” explicitly — that pins the T+5 deadline and stops an agent from telling you “you’re early for a T+1 reversal” (which is the payout rule, not yours). And keep the tone flat. The letter works because every line is a fact a regulated entity must answer, not because it’s angry. A UTR and a circular number move money; adjectives don’t. For the operator-facing version of this complaint — the one you send to the game’s grievance officer rather than your bank — the customer-care escalation page has the template tuned to an unresponsive operator, and the broader refund hub carries the full template library.

The double-debit case: when “deposit failed” really means “I paid twice”

This deserves its own section because it’s the deposit side’s signature trap, and the recovery is different from a single failed deposit. The pattern is universal: you tap add-cash, the screen lags or flashes “failed,” you assume nothing happened, you tap again — and your bank statement now carries two debits for one intended ₹500 deposit. The maddening part is that any of four things may have happened, and they look identical from the outside.

The four combinations

1. Both failed. Neither reached the wallet; both ₹500 debits are owed back. You’re owed ₹1,000 in reversals.
2. First succeeded, second failed. Your wallet rose by ₹500 once; the second ₹500 is owed back. You’re owed ₹500, and you should not dispute the successful one.
3. First failed, second succeeded. Same net as above — one credit, one reversal owed.
4. Both succeeded. Your wallet rose by ₹1,000 when you meant to add ₹500. No reversal is owed by the rail — the money credited as chips. In the PROGA era this is the worst outcome, because you now have ₹1,000 of balance in a game you can’t legally play, and your only clean exit is the operator’s source refund, not play.

How to tell which one you’re in

Read three things together:

• Your bank statement — confirms exactly how many debits hit and their UTRs.
• Your game wallet’s add-cash history — confirms how many credits the wallet received and the amounts.
• The match — line up debit UTRs against wallet credits. Each debit with no matching wallet credit is owed back; each debit with a matching credit is a real, completed deposit.

How to recover a duplicate

A duplicate debit on a P2M is owed back under the same T+5 rule as any failed deposit, but you must dispute the specific duplicate, not “the deposit,” or the desk may treat both debits as valid completed payments. In your UDIR/bank complaint, state it precisely: “Two debits, UTR [X] and UTR [Y], for one intended ₹500 deposit; my wallet shows [one credit / no credit]; I am disputing the un-credited debit UTR [Z] as an erroneous duplicate.” If both succeeded and you’re stuck with double the chips you wanted in a banned game, that’s not a rail dispute at all — it’s an operator refund-of-erroneous-credit request, and the refund hub covers how to push a source refund when the operator would rather leave the money as locked balance.

The double-debit rule in one line: count the debits, match them to wallet credits, and dispute only the debits with no matching credit. Disputing a deposit that actually worked flags your account and can freeze the rest; disputing only the orphan debit gets your money back clean.

When the deposit rides IMPS, a card, or a wallet load instead of UPI

Not every add-cash is a UPI push. When you fund a deposit with a card, a net-banking / IMPS transfer, or a prepaid wallet (Paytm Wallet, an operator’s own PPI), the “debited but not credited” protection still applies — but the deadline, the liable party, and the return mechanism shift. Knowing which rail carried your deposit changes which clock you quote.

Card deposits (the other T+5 rail)

If you added cash with a debit or credit card, you used a card-not-present (CNP) e-commerce transaction, and the TAT circular puts it on the same T+5 deadline as a UPI P2M, with the acquirer liable. The reference you trace is the card transaction’s ARN/RRN, found in your card statement and the gateway’s confirmation. A failed card deposit reverses to your card, not your bank account, and the issuing bank’s card-dispute desk is the door. Because cards add an authorization-then-capture step, a failed card deposit sometimes shows as a hold (a pre-authorization) that auto-releases in a few working days without a formal reversal — check whether the debit is “posted” or merely “on hold” before you dispute.

IMPS / net-banking deposits

If the deposit went out as an IMPS transfer or a net-banking payment to the aggregator’s account, it sits under the same NPCI/RBI TAT circular. The wrinkle: a plain account-to-account IMPS transfer (your account → the aggregator’s account) is technically an account-to-account failure with a T+1 deadline and the beneficiary (aggregator’s) bank liable — faster than the UPI-P2M T+5. But if it’s routed and labelled as a merchant collection, the merchant T+5 may apply. The trace reference is the 12-digit RRN, same shape as a UPI RRN, and IMPS auto-reversals are often the fastest on any rail, frequently within minutes.

Wallet / PPI loads

If you first loaded a prepaid wallet (a PPI) and the load failed mid-way — money left your bank, the wallet didn’t fill — that’s a PPI load failure, which the TAT circular puts on a T+1 deadline with the PPI issuer liable. This is a two-step deposit (bank → wallet → game), and a failure can strand the money at either hop, so identify which leg failed: bank-to-wallet (PPI issuer’s problem, T+1) or wallet-to-game (a P2M from the wallet, T+5).

The deposit-rail table

Read the table as a fork in your evidence file: identify the funding method before you write a complaint, because quoting the UPI-P2M T+5 at a failed PPI load (which is T+1) just gets you corrected, and quoting T+1 at a UPI deposit gets you told “you’re early.” The narration and the reference format tell you which rail you used — a UPI/ narration with a 12-digit RRN to an aggregator VPA is the P2M-T+5 lane; a card statement ARN is the CNP-T+5 lane; a wallet “load failed” entry is the PPI-T+1 lane.

Proving a deemed-successful deposit that never credited chips

The deemed-successful deposit is where most genuinely stuck add-cash money sits, and it’s the one where you must prove a negative: that despite a “success” stamp and a UTR, the wallet never rose. This is the evidence chain that does it.

Why “success” doesn’t mean “credited to your wallet”

When your bank pushes the money out and settlement moves toward the aggregator, the transaction can be marked deemed approved to keep the rail moving — the money reached the beneficiary (the aggregator) but the final wallet credit isn’t yet confirmed, per NPCI’s deemed-approved process. The status word and the wallet balance disagree, and the status word is the one everyone trusts by default. Your whole job is to replace the word “success” with a fact: there is no chip credit in my wallet against this UTR, and either the money never reached the operator (rail owes me) or it did and the operator owes me a refund.

The evidence chain, in order

Each link proves one thing the next one needs:

1. The UTR/RRN itself. Without the 12-digit reference there’s nothing to trace; it’s the index every party searches on. Read it off the app, the bank SMS, or the statement narration.
2. The debit proof. Your bank statement line showing the money left on date T for amount ₹X, carrying that UTR and the aggregator’s VPA in the narration. This is the deposit-specific anchor — it shows the money went to a payment merchant, confirming the P2M lane.
3. The non-credit proof. Your game wallet screenshot and the wallet’s add-cash history showing the balance did not rise by ₹X. This is the deposit equivalent of “no credit found” — the chips that the deposit was supposed to buy never appeared.
4. The operator’s answer. A written reply (chat or email, with a ticket ID) where the operator either confirms it received the funds (rail succeeded → operator owes a wallet credit or source refund) or confirms it didn’t (rail failed → reversal owed to you). This single answer routes the rest of your claim.

Those four together convert “the bank says it paid” into “a regulated chain can confirm the money produced no chips, and here is who holds it.” That’s the case.

Forcing the operator and the rail to agree

The lever that breaks a deemed-successful deposit stall is making the two sides reconcile against the same UTR. The rail dispute (UDIR) forces the aggregator/beneficiary bank to file its answer — a chargeback that auto-handles on the TCC/RET the bank files in the next settlement cycle. Simultaneously, the operator ticket forces the operator to look up the same UTR in its PA dashboard. One of two clean outcomes results: the rail confirms the money never reached the merchant (it returns to you) or the operator confirms it did (it credits or refunds you). The case only stays stuck while nobody is forced to look — and raising both disputes against one UTR is exactly what forces them. The withdrawal-side mechanics of this same TCC/RET reconciliation are walked step-by-step in the UPI failed, money debited spoke; the logic is identical, only the direction of money differs.

The post-PROGA reality: you are recovering a debit, not buying chips

This frame governs everything on this page, so it gets stated plainly. After PROGA and its Rules took force on 1 May 2026, an online money game — any game where you pay to play for a monetary return, skill or chance — is flatly prohibited. There is no licence and no skill exception. Critically for deposits, PROGA makes offering, advertising, and facilitating payments for these games cognisable, non-bailable offences, and it requires payment intermediaries to block transactions for prohibited games. Depositing into one is no longer a grey area; it’s part of a criminalised payment chain.

What that means for a failed deposit, in practice:

• Your recovery goal is a reversal of the debit, not chips. If your add-cash failed and the money is owed back, take the money back — never let an operator “fix” it by crediting chips into a game you can’t legally play. If the operator confirms it received the funds, the correct ask is a source refund, not a wallet credit.
• Never re-deposit “to unlock” or “to retry.” A fresh deposit into a banned money game is illegal and it’s the deposit side’s fastest way to double your loss. If anyone — support, a “helper,” a forum comment — tells you to deposit again to release stuck money, that’s both bad advice and a scam pattern.
• A failed deposit’s rail rights survive the ban. The TAT reversal, the ₹100/day, the UDIR dispute, the Ombudsman — all of these protect the payment, and they apply identically whether the deposit was a live top-up or an erroneous transfer into a now-banned app. You’re invoking payment-system law, which doesn’t care whether the merchant turned out to be a prohibited game.

The honest bottom line: PROGA doesn’t weaken your right to get a failed deposit back — that’s a payment-rail claim, fully intact. It changes what a successful deposit means (now an unwanted, possibly unlawful credit you should get refunded to source) and it hardens the one rule you most need on the deposit side: the fix is never another deposit. The refund hub and the withdrawal hub both carry the full PROGA context; here it’s the lens for one thing — get the debit reversed, stop, and don’t pay again.

Common mistakes that lose a failed-deposit claim

The rules are on your side, which is exactly why the losses are almost always self-inflicted. The seven that cost people their refund:

1. Re-depositing “because the first one failed.” This is the deposit-side mistake. It gives you two debits — and now you’re untangling which one worked instead of recovering a clean single failure. Confirm in your bank statement how many debits happened before you do anything at all. One missing deposit is a simple claim; two debits is a mess you created.
2. Not capturing the UTR on Day 0. A failed transaction can drop out of an app’s quick view within days, and a bank cannot trace money you can’t name. No UTR, no case. Capture it in the first hour, off the SMS if the app hides it.
3. Quoting the wrong deadline. Demanding a T+1 reversal on a failed deposit (a merchant payment, which is T+5) just gets you told “you’re early.” State “merchant payment (P2M)” and quote T+5. This is the single most common reason a correct deposit complaint gets brushed off.
4. Reading the aggregator’s VPA as fraud. Your deposit narration shows razorpay / cashfree / a cryptic merchant handle, not “TeenPatti” — and people panic that the money “went to a stranger.” It didn’t; it went to the operator’s regulated payment aggregator, which is exactly why it’s a P2M with T+5 protection. Don’t dispute it as a wrong-beneficiary transfer (that strips your ₹100/day eligibility); dispute it as a failed merchant payment.
5. Accepting chips as the “fix.” If an operator offers to resolve a failed deposit by crediting your wallet, that’s not a fix in the PROGA era — it’s locking your money in a game you can’t legally play. Insist on a source refund or a rail reversal.
6. Treating Day-0 pending as theft and skipping to RBI. The Ombudsman requires the entity to have had your complaint for 30 days first. Jump the queue and you’re bounced back, having wasted time. Climb the rungs in order, and remember a pending deposit usually resolves in under an hour.
7. Sharing an OTP or UPI PIN with anyone who “calls to help.” The most common way a deposit victim loses more money is a fake “customer care” caller who promises to “reverse the failed deposit” and asks for an OTP or PIN. No legitimate bank, app, or NPCI process ever needs your PIN or OTP to refund you — a refund flows to you and never requires your PIN. Hang up and report the number to cybercrime 1930 / cybercrime.gov.in.

On that last point: if you reached a “help number” from a Google search, a YouTube comment, or an SMS rather than the app’s official listing, treat it as a scam by default. The customer-care escalation page goes deep on why most posted “care numbers” are phishing traps. A genuine failed-deposit refund never starts with you reading out a code.

How long should each stage actually take?

A realistic clock for a deposit, so you know when “wait” turns into “escalate.” Rule-backed rows are marked; the rest are typical processing behaviour.

The honest read: a cleanly failed deposit is usually back in your account within minutes to five days without you lifting a finger, because the auto-reversal is mandated and a UPI refund often lands inside an hour. The cases that drag to Day 30 are nearly always deemed-successful ones where the system thinks the merchant got paid — and even those resolve once you force the operator and the rail to reconcile against the same UTR.

When the money is genuinely gone: the limits of this framework

Honesty about where the leverage ends. The RBI/NPCI/PA machinery is overwhelmingly strong against a deposit-rail failure — money that left your account toward a regulated aggregator and didn’t produce chips — because every party in that chain (your bank, the aggregator, the acquirer, NPCI) is RBI-regulated and bound by the TAT circular and the PA Directions 2025. That’s the recoverable kind, and it’s the kind this whole page is built for.

It’s weaker in two situations, and pretending otherwise wastes your time:

• The deposit went to an unlicensed, offshore, or clone payment endpoint. If your add-cash money reached a “merchant” that turns out to be a scam collection account rather than a regulated aggregator, the rail dispute and a cybercrime 1930 report are still worth filing — but recovery of funds that landed inside an entity outside Indian regulatory reach is not guaranteed. The tell is in the narration: a recognizable aggregator VPA (razorpay, cashfree, payu, a bank-suffixed merchant handle) is regulated and traceable; a random personal-looking VPA or a foreign endpoint is a red flag.
• The deposit succeeded and you simply regret it. If the money credited as chips and you just want it back because the game is banned or you changed your mind, that’s not a “failed transaction” — it completed. Your route there is an operator source refund of an unwanted balance, which the refund hub covers, not a rail reversal you have no grounds for.

The bright line: if there’s a debit on a regulated rail to a regulated aggregator, a UTR, and no chips, you have a strong, rule-backed claim, and the steps above usually win it. If the destination is lawless or the deposit actually completed, the rules bend, and you fall back on fraud-reporting or operator-refund routes. Know which side of that line your money is on before you decide how hard to fight — and on which door to knock.

FAQ

1. My deposit failed but money was deducted — will I get it back automatically? For a cleanly failed merchant (P2M) deposit, yes — under RBI’s TAT circular it must auto-reverse by T+5, and a UPI refund often lands inside 60 minutes. The circular says compensation is credited “suo moto, without waiting for a complaint.” The catch is the deemed-successful case, where the system thinks the merchant got paid — that one you have to prove with the UTR before a reversal triggers.

2. How many days before the bank owes me compensation on a failed deposit? T+5 for a merchant payment (your add-cash), where T is the transaction date — not T+1, which is the rule for a failed payout credit. Beyond T+5, the liable party owes ₹100 per day of delay, per the TAT circular. So a deposit still missing 4 days after T+5 has accrued ₹400 on top of the principal.

3. Why is a deposit T+5 when a withdrawal is T+1? Because the direction of money decides who counts as the merchant. A deposit is a person-to-merchant (P2M) payment, and the circular gives the merchant’s acquirer 5 days to confirm receipt. A payout credit is an account-to-account transfer to your bank, which reconciles faster, so it’s T+1. Same symptom-words, different deadline.

4. My bank says “the money left us cleanly” — who actually has it? Often your bank is telling the truth. On a P2M deposit, the money flows to the operator’s payment aggregator (Razorpay, Cashfree, etc.), which holds it in a regulated escrow before settling to the operator by T+1. So your money is usually sitting in the aggregator’s chain, traceable by the UTR — owed back to you (rail failed) or onward to the operator (rail succeeded, wallet not updated).

5. The bank SMS says “success” but no chips appeared. What now? Get the UTR, then push two doors at once: ask your bank to trace the UTR, and open an operator ticket asking whether it received the funds. If the operator confirms receipt, demand a source refund (not chips). If it confirms non-receipt, the rail failed and the reversal is owed to you. NPCI’s stated resolution window is 3–5 working days.

6. I tapped add-cash twice and got debited twice — how do I fix it? Count the debits in your bank statement and match each UTR against your wallet’s add-cash history. Each debit with no matching wallet credit is owed back under the T+5 rule. Dispute the specific un-credited duplicate UTR — don’t dispute “the deposit,” or the desk may treat both debits as valid completed payments.

7. The deposit went to “razorpay” / “cashfree,” not the game — is that fraud? No. That’s the operator’s payment aggregator, and it’s exactly why your deposit is a P2M with T+5 protection. A recognizable aggregator VPA means your money is in a regulated escrow and is traceable. Don’t dispute it as a wrong-beneficiary send — that’s the customer-attributable bucket and it strips your ₹100/day eligibility. Dispute it as a failed merchant payment.

8. What is a UTR/RRN and where do I find it for a deposit? For UPI it’s the same 12-digit reference, labelled “UPI Reference No.” (PhonePe), “Bank Reference ID” (Google Pay), “UPI Ref No.” (Paytm), or “Transaction ID” (BHIM). If the app hides it, read it off your bank statement — the deposit line reads roughly UPI/[12-digit RRN]/[aggregator VPA]/[bank], and that 12-digit block is your UTR. Your bank SMS carries it too.

9. Do I have to ask for the ₹100/day, or is it automatic? The circular says it should be credited suo moto — automatically. In practice many banks don’t, so you claim it in writing, quoting the “suo moto, without waiting for a complaint or claim” clause by name, and specifying merchant payment / T+5. You’re reminding them of an existing duty, not requesting a favour.

10. Does the ₹100/day apply if I sent the deposit to the wrong UPI handle? No. The compensation only covers failures “not attributable to the customer.” A wrong-handle transfer completed — to the wrong person — so it isn’t a “failed transaction” under the circular. You request a reversal from the recipient through your bank; you don’t claim ₹100/day. A timeout or rail failure on a deposit to the correct merchant is covered.

11. The operator says it never received my deposit, but my bank debited me. Who’s right? Both can be. The money may be parked in the aggregator’s escrow for up to T+1 (the PA’s settlement deadline to the merchant), so the rail succeeded to the PA but the operator genuinely hasn’t “received” a usable deposit yet. Hand the UTR to both: raise the UDIR dispute so the aggregator’s bank must answer, and make the operator look up the same UTR. The reconciliation resolves it.

12. My deposit is still “pending” hours later — should I worry? Usually not yet. Most pending UPI deposits resolve within minutes to a working day, and NPCI’s benchmark for failed-deposit refunds is 60 minutes. A merchant deposit has a hard T+5 expiry, so it must terminate (credit or reverse) by then. Raise the in-app dispute on Day 1 if it’s still pending, but don’t escalate to RBI on Day 0 — the rail is likely mid-reconciliation.

13. The app offered to “credit my wallet” to fix a failed deposit — should I accept? Not in the PROGA era. A wallet credit locks your money in a game you can’t legally play. If the operator confirms it received the funds, the correct resolution is a refund to your source account, not chips. Insist on the source refund and decline the wallet credit.

14. Should I just deposit again to retry? Never. A fresh deposit into a banned money game is illegal, and even setting that aside, re-depositing is the deposit side’s fastest way to turn one missing ₹500 into two debits you then have to untangle. The fix for a failed deposit is always a reversal or a refund — never another payment.

15. My deposit was by card, not UPI — is the rule different? The deadline is the same. A card add-cash is a card-not-present (CNP) e-commerce payment, which the TAT circular also puts at T+5 with the acquirer liable; the reversal goes back to your card. Check first whether the debit is “posted” or merely an authorization hold — a held pre-auth often auto-releases in a few working days without a formal dispute. Trace it by the card ARN/RRN.

16. My deposit failed during a wallet (PPI) load — what deadline applies? A failed PPI / wallet load (bank → wallet) is on a T+1 deadline with the PPI issuer liable, per the TAT circular. Identify which leg failed: if the bank-to-wallet load failed, that’s the T+1 PPI case; if the wallet-to-game step failed, that’s a P2M from the wallet on T+5. The two legs have different clocks.

17. How do I raise the NPCI UDIR complaint without the app? Use the NPCI UPI Help portal “Dispute Redressal” page and file with the UTR/RRN, bank, amount, date, registered mobile and email, or call 1800-120-1740. This routes to the same UDIR engine the app would use — the fix when the app won’t let you raise a dispute on the failed deposit.

18. When does a P2M deposit dispute auto-convert to a chargeback? At T+3 for a merchant (P2M) payment, if the merchant or its bank doesn’t respond, per NPCI’s UDIR timelines. NPCI’s system keeps polling for the final status for up to 5 days before settling the transaction to a terminal state. So the in-app dispute has a built-in deadline that forces a resolution rather than vanishing.

19. When can I go to the RBI Ombudsman over a deposit, and does it cost anything? After 30 days without resolution from the bank or the payment aggregator (a Payment System Participant), or if it rejects your complaint — file free at cms.rbi.org.in under RB-IOS 2021, which covers Payment System Participants. There’s an outer limit of one year from the entity’s reply, so don’t let it drift.

20. Someone called offering to “reverse my failed deposit” and asked for an OTP — is that real? No — it’s a scam, and it’s the most common way deposit victims lose more money. A genuine refund flows to you and never needs your OTP or UPI PIN. No bank, app, or NPCI process asks for your PIN to refund you. Hang up and report the number to cybercrime 1930 / cybercrime.gov.in. If you found the “help number” via a search or a comment rather than the official listing, treat it as a scam by default — see the customer-care escalation page.

21. My deposit was rejected for a “KYC” or “limit” reason — is the money still owed back? Yes. If the debit happened and the operator then rejected the payment for a name-mismatch, a deposit-cap, or an unverified-KYC threshold, the money is owed back as a reversal — the rejection means the merchant won’t accept it, so it can’t keep it. Get the operator’s written reject reason, then pursue the reversal on the T+5 P2M clock. The reject reason is also your fix list: match the paying account’s name to your registered profile, complete KYC, or stay under the cap.

22. How long before a failed deposit is normally back in my account? A cleanly failed deposit is usually reversed within minutes to five days with no action from you, because the T+5 auto-reversal is mandated and UPI refunds often land in under an hour. The cases that reach Day 30 are nearly always deemed-successful ones where the system believes the merchant was paid — and even those resolve once you force the operator and the rail to reconcile against one UTR.

23. This is a withdrawal that failed, not a deposit — am I on the right page? No. This page is the deposit side — you added cash, the money left your account, and the chips never arrived. If the operator sent a payout that was debited from it and never reached your bank, that’s the withdrawal side: read the UPI failed, money debited spoke, or start at the withdrawal hub. The two share a rulebook but differ on direction, deadline (T+5 deposit vs T+1 payout), and liable party.

Sources & method. The reversal deadlines, the compensation rule, the merchant-vs-account-to-account liability split, the “not attributable to the customer” definition, and the payment-aggregator escrow/settlement framework on this page come from primary regulatory and payment-system sources — not personal deposit tests. Key references: RBI failed-transaction TAT circular DPSS.CO.PD No.629/02.01.014/2019-20 (20 Sep 2019) and the annexed TAT table (P2M = T+5); the RBI Payment Aggregators Directions 2025 (15 Sep 2025) on escrow holding and T+1 merchant settlement, summarised in AuthBridge’s guide; the NPCI deemed-approved process circular; NPCI UPI Help / UDIR and the UDIR auto-chargeback timelines (P2M T+3, 5-day poll); the “deemed success” reconciliation explainer; the RBI Integrated Ombudsman Scheme 2021 FAQ and cms.rbi.org.in; UTR vs RRN reference formats and the RRN as 12-digit inter-bank reference; the deducted-not-credited resolution guides from PhonePe and Paytm; the NPCI Feb-2025 TCC/RET auto-chargeback rules; the Promotion and Regulation of Online Gaming Act, 2025 with the payment-facilitation offence framing from GaganLegal and the Mondaq reset analysis; and cybercrime reporting at cybercrime.gov.in / helpline 1930. This is information, not legal or financial advice — verify each step against your bank’s current UPI dispute policy, your payment aggregator’s terms, and the operator’s terms.