Guru11 payment gateway: UPI, wallet, withdrawal timing, and TDS
The Guru11 payment gateway is the bridge between the user's bank account and the contest wallet, and the bridge is the place where the most consequential taps of the whole flow happen. This page is the desk's working note on how deposits work on UPI, wallet, net banking and card, the three screenshot rule that protects the user during a dispute, the difference between a failed and a pending transaction, the timing on withdrawals, the basics of TDS at withdrawal, and the point at which a dispute should be escalated through the bank rather than through the operator.
The three-screenshot rule
The three-screenshot rule is the desk's habit for every deposit that lands on the Guru11 payment gateway. The first screenshot is the deposit screen inside the app, captured before the rail is selected. The second screenshot is the UPI confirmation screen, captured the moment the bank app returns the success or failure status. The third screenshot is the in-app success screen, captured after the wallet has been credited. The three screenshots together form the record the operator's support desk reads when a deposit is contested, and the record is the cheapest insurance the user can carry for the forty-eight hour dispute window.
The three-screenshot rule is also the reason the desk recommends the 24 hour pause before every deposit. The pause is the time the user takes to read the coupon sheet, confirm the qualifying deposit, and confirm the rail-side fee, and the pause is the time the user takes to set a reminder for the dispute window. The pause is not a hesitation ritual, it is a reading habit, and the habit is the cheapest way to keep the three screenshots organised when the support desk eventually asks for them. The blog note Guru11 payment pause: the 24 hour rule before every deposit walks through the pause in detail.
The three-screenshot rule is the habit of taking a screenshot before, during, and after every transaction. The before screenshot shows the deposit amount and the payment method. The during screenshot shows the UPI app's confirmation screen. The after screenshot shows the operator's wallet balance update. The three screenshots are the evidence the player needs if the transaction is disputed, and the cost of taking them is 2-3 seconds per transaction. The asymmetry is overwhelming in favour of taking the screenshots.
How a UPI deposit lands
A UPI deposit on Guru11 starts when the user taps the deposit button on the wallet screen and selects the UPI rail. The app opens a UPI intent that the bank app receives, and the bank app asks the user to authorise the payment through a UPI PIN. Once the PIN is entered, the bank app returns a success or failure status to the Guru11 payment gateway, and the gateway forwards the status to the in-app success screen. The full cycle usually takes between five and thirty seconds on a stable 4G connection, and the cycle is the place where most failed deposits originate.
The most common failure mode on the UPI rail is a session timeout at the bank app. The session timeout happens when the user takes more than ninety seconds to enter the UPI PIN, and the timeout is the reason the three-screenshot rule captures the UPI confirmation screen separately from the deposit screen. Beginners who experience a session timeout usually see a failed status on the bank app and a pending status on the in-app success screen, and the dual status is the place where the pending transaction trap sits. The trap is explained in the next section.
A UPI deposit lands in the operator's wallet within 5-30 seconds of the UPI app's confirmation. The wallet balance update is the signal that the deposit has landed, and the operator's transaction history shows the deposit with a timestamp and a UPI reference number. A deposit that doesn't show up in the transaction history after 5 minutes is a pending transaction, not a failed one, and the player should wait for the standard settlement window before assuming a failure.
The pending transaction trap
The pending transaction trap is the case where the bank app returns a success status, the user's bank account is debited, but the Guru11 payment gateway has not yet credited the wallet. The trap usually clears within thirty minutes as the gateway reconciles the UPI ledger, and the reconciliation is automatic. The trap becomes a dispute when the user starts a second deposit before the first one has reconciled, and the second deposit usually fails or queues behind the first. The desk's habit is to wait until the in-app success screen shows a credited balance before starting a second deposit, and the wait is the cheapest way to avoid a stacked pending state.
The pending transaction trap is also the reason the three-screenshot rule captures the in-app success screen as a separate shot. The success screen carries the credited balance and the timestamp, and the timestamp is the single piece of evidence the support desk reads when the user reports a missing deposit. Beginners who skip the success screenshot usually find that the support desk has to escalate to the payment gateway's reconciliation team, and the escalation adds days to the dispute cycle.
The pending transaction trap is the most common source of duplicate-charge disputes. The player initiates a deposit, the UPI app confirms, the wallet balance doesn't update, the player initiates a second deposit, both deposits land, and the player is now over-deposited by the amount of the first deposit. The safe path is to wait the standard settlement window (5-30 minutes for UPI, 1-2 hours for net banking) before initiating a second deposit. The wait is annoying but it eliminates the duplicate-charge scenario.
Wallet, net banking, and card rails
The wallet rail on Guru11 is the path where the user funds the wallet through a third-party wallet such as Paytm, PhonePe, or Amazon Pay. The wallet rail usually carries a higher processing fee than the UPI rail, and the fee is deducted from the deposit amount before the wallet is credited. The net banking rail is the path where the user logs into a bank portal through the gateway's redirect, and the redirect is the place where most net banking failures originate because the bank portal times out if the user takes more than five minutes to authorise the payment.
The card rail is the path where the user enters a debit or credit card number, expiry, and CVV. The card rail usually carries the highest processing fee and the longest settlement time, and the rail is the place where the operator's KYC check is most likely to ask for an additional ID. Beginners who use the card rail should expect a settlement time of one to three working days on the deposit, and the settlement time is the cheapest reason to default to UPI when the deposit qualifies. The coupon code hub explains how the rail-side fee interacts with the qualifying deposit clause.
The three rails - wallet, net banking, and card - have different settlement times and different dispute resolution flows. Wallet rails (Paytm, PhonePe) settle within 5-30 seconds and disputes are handled by the wallet provider. Net banking settles within 1-2 hours and disputes are handled by the bank. Card rails settle within 1-3 days and disputes are handled by the card network (Visa, Mastercard, RuPay). The player should choose the rail based on the urgency of the deposit and the dispute risk.
Withdrawal timing and the settlement window
Withdrawal timing on Guru11 depends on the rail the user selects at the withdrawal screen. UPI withdrawals usually settle within fifteen minutes to four hours, depending on the issuing bank's UPI availability. Bank account withdrawals through IMPS or NEFT usually settle within two to twenty-four hours, depending on the cut-off time at the issuing bank. Card withdrawals are rare on the operator's published withdrawal screen, and the card rail is usually only available as a refund path rather than as a primary withdrawal rail.
The settlement window is the cheapest place to confirm when a withdrawal will land, and the window is stated on the withdrawal screen as an estimated arrival time. The estimated arrival time is not a guarantee, and the time can extend when the issuing bank's UPI rail is under maintenance or when the operator's KYC check is still pending. Beginners who experience a delay beyond the estimated arrival time should check the wallet screen for a pending status before contacting the support desk, because the pending status is the most common cause of a delayed withdrawal.
A withdrawal from the operator's wallet to a UPI ID settles within 2-5 minutes during business hours and 5-30 minutes outside business hours. A withdrawal to a bank account settles within 1-2 hours during business hours and 4-8 hours outside business hours. A withdrawal to a card rail settles within 1-3 days, regardless of the time of day. The settlement windows are published in the operator's help centre, and the player should plan withdrawals around the business hours to avoid the slower settlement.
TDS at withdrawal, in plain language
TDS at withdrawal is the tax the operator deducts at source when the user withdraws net winnings above a threshold published by the Indian government. The current published threshold for fantasy winnings sits at a level the operator's withdrawal screen states explicitly, and the operator deducts TDS at the rate the Income Tax Department publishes for the relevant financial year. The TDS deduction is shown on the withdrawal screen as a separate line before the user confirms the withdrawal, and the deduction is the cheapest place to confirm how much cash will actually land in the bank account.
The TDS deduction is also reflected in the user's Form 26AS and AIS statements, and the deduction can be claimed as a credit at the time of filing the income tax return. Beginners who hit the TDS threshold should download the TDS certificate from the wallet screen, because the certificate is the document the chartered accountant reads at filing time. The desk does not offer tax advice, and the desk recommends that users consult a chartered accountant for the specific TDS treatment that applies to their winnings.
TDS (Tax Deducted at Source) applies to net winnings above Rs 10,000 in a financial year, at a rate of 30%. The operator deducts the TDS before the withdrawal is processed, and the deducted amount is reflected in the player's Form 26AS at the end of the financial year. The TDS is not an additional cost - it's a pre-payment of the player's income tax liability - and the player can claim the TDS as a credit when filing the income tax return. The operator's support team can provide the TDS certificate on request.
Failed versus reversed versus declined
A failed transaction on the Guru11 payment gateway is one where the gateway returned a failure status to the in-app success screen, and the user's bank account was not debited. A reversed transaction is one where the bank debited the user's account but the gateway reversed the debit because of a mismatch in the UPI intent. A declined transaction is one where the issuing bank rejected the UPI intent at the bank app, usually because of a daily limit, a wrong PIN, or a flagged merchant. The three states are different, and the difference is the reason the three-screenshot rule captures each screen separately.
Beginners who experience a reversed transaction should see the debit reversed on the bank statement within three to five working days, and the reversal is automatic. Beginners who experience a declined transaction should check the bank's daily limit and the merchant whitelist before retrying, because the same decline usually repeats until the underlying limit is raised. The desk's habit is to wait for the reversal or to fix the limit before retrying, because a repeated attempt usually produces a second decline rather than a success.
Failed, reversed, and declined are three different outcomes with three different meanings. A failed transaction didn't complete and no money was deducted. A reversed transaction completed and was then reversed by the operator or the bank, usually within 1-3 days. A declined transaction was rejected by the payment rail before the money was deducted. The three outcomes have different dispute paths, and the player should know which outcome they're seeing before contacting support.
When to escalate through the bank
The user should escalate through the bank rather than through the operator when the bank app returned a success status but the Guru11 payment gateway has not credited the wallet within forty-eight hours. The escalation starts with a dispute at the issuing bank's net banking or mobile app, and the dispute references the UPI transaction ID that the three-screenshot rule captured on the UPI confirmation screen. The dispute triggers the bank's reconciliation process, and the process usually takes between five and ten working days to resolve.
The escalation is also the right path when the user's bank account was debited twice for the same deposit. The double debit is a rare but recurring pattern on the UPI rail, and the pattern usually clears within one reconciliation cycle. Beginners who experience a double debit should not start a third deposit, and the desk recommends waiting for the bank's reconciliation before the next attempt. The contact page lists the formats that help the desk read a payment screenshot, including the UPI transaction ID, the bank app name, and the timestamp.
The bank should be contacted when the operator's support team has not resolved the issue within 7 days, or when the operator has explicitly refused to resolve the issue. The bank is the right escalation path because the bank is the regulated entity that holds the funds during the dispute. The operator's support team is the right first contact, but the bank is the right escalation when the support team can't or won't resolve the issue.
How the payment gateway hub fits the wider site
The payment gateway hub is one of two operational hubs on the Guru11 India site. The other is the app download hub, which explains the install path and the permissions list. The payment gateway hub is the deeper dive for users who want to understand the deposit and withdrawal rails, and the app download hub is the deeper dive for users who want to understand the install path and the permissions list. The two hubs cross-link so that users who land on the wrong hub for their situation can find the right hub without consulting the sitemap.
The payment gateway hub also cross-links to the coupon code hub, which explains how the rail-side fee interacts with the qualifying deposit clause, and to the refer code hub, which explains how the qualifying deposit triggers the refer credit. The cross-link set mirrors the cross-link set on the offer-side hubs, because the deposit is the single event that triggers most of the conditions across the site. Users who want a wider view of the operational frame should read the responsible play hub, which explains the deposit cap and the session limit that interact with the payment flow.
How disputed transactions are resolved in India
Disputed transactions in India are resolved through the bank's dispute resolution mechanism, which is a regulatory requirement under the Reserve Bank of India's 2019 circular on customer protection. The mechanism requires the bank to acknowledge the dispute within 3 days, resolve it within 90 days, and provide a provisional refund if the dispute is in the customer's favour. The provisional refund is usually credited within 7-10 days of the dispute being filed, and the resolution is communicated via SMS and email.
The dispute resolution flow starts with the player contacting the bank, not the operator. The bank's customer support team is the right first contact, because the bank is the regulated entity that holds the funds during the dispute. The operator's support team can help with the transaction details - the merchant ID, the transaction reference number, the timestamp - but the dispute itself is filed with the bank. The flow is: bank files the dispute, operator responds with transaction evidence, bank makes a decision based on the evidence.
The success rate of disputed transactions depends on the type of dispute. A duplicate-charge dispute (the player was charged twice for the same transaction) usually resolves in the player's favour within 7-10 days. A fraud dispute (the transaction was not initiated by the player) resolves in the player's favour if the bank confirms the fraud. A service-not-rendered dispute (the player paid for a service that wasn't delivered) resolves in the player's favour only if the operator is unable to demonstrate that the service was delivered.
What the operator's payment terms say about your rights
The operator's payment terms are published on the operator's website, in the terms-of-service or payments section. The terms cover: the deposit flow, the withdrawal flow, the dispute resolution flow, the chargeback policy, and the player's rights under Indian law. The terms are the binding agreement between the player and the operator, and any deviation from the terms by the operator is a breach that the player can dispute through the bank's dispute resolution mechanism.
The player's rights under Indian law are stronger than the operator's terms in some areas and weaker in others. The player has the right to a refund for unauthorised transactions, the right to dispute a transaction within 120 days, and the right to escalate the dispute to the banking ombudsman if the bank doesn't resolve it within 90 days. The player does not have the right to a refund for a transaction that was correctly executed, even if the player regrets the deposit.
The way to use the operator's payment terms is to read them before making the first deposit, not after. The reading takes 5-10 minutes and it establishes the baseline for what the player can expect from the operator. The terms are usually 2-3 pages long and they cover the most common scenarios the player will encounter. The cost of not reading them is the surprise when a scenario comes up that the player didn't anticipate, and the surprise is usually avoidable by a one-time 10-minute read.