Gambling payment gateway: what it is, and what changed for it in India in 2026

Operational guidance, not legal advice. The Act, its rules, official interpretations and payment-partner policies change. Confirm the current position and the classification of your own product with qualified advice before you launch.

What a gambling payment gateway actually is

The name describes a layer, and most misunderstandings in this category come from treating the layer as if it were the business. It is not. It moves transaction data. Everything that makes a gambling operation legal, taxable or punishable sits above it, not inside it.

Four components sit between a card in a player's hand and a settled amount in an operator's account, and the same four appear in every market:

1. The cashier

   The interface the player actually touches: the method list, the amount, the pay button, the return path. It is usually part of the operator's own product, and it is the only part of the stack a player ever sees. What it renders — which methods, which limits, which currencies — comes from the gateway, not from the operator's database.

   Most "the payment provider is broken" tickets are cashier problems: a hard-coded method list, a missing limit, a return path that loses the order reference.

2. The payment gateway

   The technology that carries transaction data between the cashier and the acquirer. It selects the route, formats the request, handles the authorisation response, keeps the state, and reports. This is the layer a "gambling payment gateway" refers to. In most modern stacks the gateway is supplied by the acquirer or by a licensed provider sitting between the operator and the bank.

   The gateway does not decide the outcome of a game, does not hold player funds, and does not make a business legal to operate. A compliance decision belongs to the merchant and its legal adviser, not to the technology layer.

3. The acquirer and the network

   The bank that contracts with the merchant and the card or payment network that carries the traffic. This is where approval rates, reserve requirements, chargeback liability and settlement timing are decided — not at the gateway. An operator's approval rate is mostly an acquiring outcome.

   When a merchant says the gateway has a low approval rate, the first question is which acquirer is actually routing the transaction.

4. The aggregator, where one is used

   An entity that receives customer funds before passing them to the merchant, or that routes volume across several acquirers. Under the Reserve Bank of India's framework a payment gateway provides the technology without handling funds, while a payment aggregator handles the money in between. The difference decides who carries the risk when a payment goes wrong or a dispute arrives, and it is one of the first questions an underwriter asks.

   The same transaction can be gateway-led or aggregator-led. The merchant contract and the money flow show which one you are in.

Two consequences follow, and they explain most of the confusion around this keyword. First, a gateway is interchangeable in a way that the licence is not: two operators can use the same technology and face completely different outcomes, because the merchant category, the flow and the licence are what the acquirer underwrites. Second, the search term "gambling payment gateway" usually means one of three different things — a technology to integrate, a merchant account to be approved for, or a regulated service provider. The pages that rank for it are usually about the first, while the buyer usually wants the second, and the supplier is selling the third.

A casino payment gateway, a betting payment gateway and an iGaming payment gateway are the same layer serving different operators. What separates them is the merchant category, the licence and the money flow underneath — not the technology, and not the integration work. Where a return to the customer is a prize rather than a refund of a stake, that difference decides the treatment of the whole flow, which is why the classification question is answered before the technical question.

Types of gambling payment gateway solution

The phrase covers four different products that get sold under one name. Before comparing anything, an operator should know which one is being quoted, because they differ in who holds the money, who carries the risk, and what happens when a payment goes wrong.

Two further axes sit on top of these four. The first is checkout shape: a hosted payment page the player completes on the provider's domain, or an API-led flow where the operator's own interface talks to the provider. The hosted page converts better and integrates faster; the API-led flow keeps the player on the operator's domain and keeps the order reference under the operator's control, which matters more than it sounds when reconciliation is the thing that breaks. The second axis is routing: a single acquiring relationship, or multi-acquirer routing with automatic failover. For this category, where a single issuer can decline an entire merchant category, routing is less an optimisation than a continuity requirement.

The 2026 position in India

This is the part that changed, and it changed at the payment layer before it changed anywhere else.

The Promotion and Regulation of Online Gaming Act, 2025 applies throughout India and was brought into force in April 2026. It prohibits the offering of online money games, and it separately prohibits any bank, financial institution or other person facilitating financial transactions from enabling payment for an online money gaming service.

The second limb is the one that reshaped this market. A prohibition on offering is a problem for the operator. A prohibition on facilitating payment is a problem for everyone in the chain above it, including the gateway. In practice the Online Gaming Act 2025 reaches the payment layer before it reaches the product: a gateway asked to carry a prohibited flow is being asked to carry it unlawfully, not merely to carry it badly.

Under the Act, an online money game is one where a user pays fees, deposits money or provides another stake in expectation of monetary or equivalent enrichment, and that applies whether the game is described as skill, chance, or a mixture of the two. The statutory description of esports is narrower and more useful: organised competitive play governed by predefined rules and recognised under the applicable sports framework, which may include registration or participation fees used to enter or to cover administrative costs, and performance-based prize money, but cannot involve bets, wagers or other stakes.

That is a deliberate position, and it is also the commercially sensible one. A provider that carries a prohibited product does not gain a customer; it gains a merchant that will be closed, a portfolio that will be reviewed, and a domain that becomes the obvious place a regulator starts looking. The category is not a growth market for anyone in the chain.

The tax position is part of the classification

Money that leaves a gaming platform to a player is not a commercial payment, and Indian tax law treats it separately from one. Net winnings from online games are taxed under Section 115BBJ of the Income-tax Act, 1961 at a flat rate, and the person paying those winnings is required to deduct tax at source under Section 194BA, with no minimum threshold below which the deduction is skipped. Both provisions were introduced by the Finance Act, 2023 and apply whether the game is described as one of skill or one of chance.

That is why a payment rail for this category has to carry a withholding step, and why the operator's ledger has to be able to produce the deduction record per recipient rather than per transaction. It is also why the treatment of a prize and the treatment of a refund cannot be the same code path: one is a payment with a tax deduction attached, the other is the return of a stake.

The GST (goods and services tax) position on online gaming has been revised more than once since 2023, and the applicable slab is not the same for platform fees and for player deposits. Treat any rate you find quoted online as dated, and confirm the current position before it appears in a commercial proposal. The Income Tax Department's own page on winnings from online games is the reference, and the current treatment of a specific product remains a question for a tax adviser rather than a payment provider.

Regional differences: what changes outside India

"Gambling payment gateway" is a global phrase describing four different regulatory problems. An operator serving more than one market is not choosing a payment method; it is choosing a set of licences.

In the United Kingdom, gambling runs on a Gambling Commission licence, and credit cards have not been allowed for online gambling since 2020. The method mix is therefore structurally different from India's, where cards exist but compete against free UPI rails, and a provider quoting a single global price card will be quoting something that cannot be delivered in both. In the European Union the position is the mirror image again: a licensing regime in several member states, the Strong Customer Authentication rules under PSD2, and a set of issuing banks that decline gambling merchant categories outright, which makes the acquirer mix the deciding factor rather than the gateway choice.

Latin America is a different problem again, because the local acquiring relationships and the local regulatory regimes are what decide approval, and split-payment and delayed-settlement structures are common. In South-East Asia, some markets require a local licence for the operator and a locally licensed payment partner, which is why operators in this category frequently end up running one regulated entity per market rather than one gateway everywhere.

Two practical consequences follow for anyone comparing providers. First, a provider licensed in one market is not licensed in another, and "we accept gambling" says nothing about where the licence is. Ask for the licence, the acquiring relationships and the settlement currencies per market, not for a global statement. Second, the player's country drives the compliance obligation while the operator's country drives the tax obligation, and the two are rarely the same place. The provider that can show it has thought about that split is the one worth talking to.

Why gambling merchant accounts get declined

Almost every decline in this category comes down to one of three things, and only the third is usually what the applicant expects to be asked about.

The three documents that decide the outcome

Everything else in an application is supporting material. These three carry the decision, and each has a specific failure mode worth naming.

• The money flow, drawn. Every movement of money: what the player pays, what the platform receives, what leaves, to whom, and under what rule. A missing arrow is as damaging as a wrong one — an undeclared refund path reads as a hidden withdrawal. A paragraph leaves room for interpretation, and interpretation is where a decline is born.
• The player terms. The published terms, not a summary. They are read for what a player can do with money: keep it, convert it, transfer it, get it back. Language that describes a purchase of access and language that describes a stake are separated by a few words, and those words get quoted back to you in a decline letter.
• The refund and withdrawal policy. Specifically: can a player recover a stake, and under what conditions. A published rule that permits a full refund after the event is fixed is the single most common reason a legitimate operator is treated as a wagering business — and it has to match what the flow actually does, because a policy that promises more than the flow supports becomes a dispute in a support inbox.

Two supporting documents do real work alongside them: the description of the product — mechanics, rules, what a player receives — and the evidence of recognition, registration or a legal opinion where the model needs it.

What the acquirer actually checks

Underwriting is not a conversation about your product. It is a list of fields, and the answers are compared against a policy. Knowing which fields exist, and what the right answers look like, saves a declined application.

Merchant category code

The acquirer classifies the merchant before it assesses anything else, and the classification is a number that travels with every transaction. Gambling sits in MCC 7995 — betting, wagering, lottery, gambling tickets or chips. Related codes carry the adjacent businesses: 7996 for non-financial gambling organisations, 7997 for clubs and entertainment venues, and 7994 for video game arcades and establishments. The card networks require gambling transactions in a card-present environment to be presented under 7995 specifically.

One correction is worth making, because the number that circulates most widely in this vertical is wrong: 7993 is video amusement game supplies, not gambling. It appears in a lot of published material on this subject, including in otherwise careful guides. An application filed under the wrong code gets routed to a policy team that was never going to approve it, and the reason for the decline is never explained.

Security and authentication

Three certifications and controls decide whether the technical side is acceptable at all. PCI DSS certification defines who is allowed to touch card data and at what level; the level is a consequence of the architecture, not a choice made afterwards. 3-D Secure 2.0 is the authentication step that protects the issuer, and it doubles as evidence in a dispute — which matters more here than in ordinary e-commerce, because the dispute reasons are less standard. Tokenisation keeps the card number out of the merchant's environment entirely, which removes a whole category of audit obligation and is usually the fastest way to shorten a security review. On top of that sits the fraud layer, and here the vocabulary is specific: velocity rules on how often a card, an account or a device may attempt a payment in a window, allow and deny lists of instruments, merchants and geographies, and the device, IP and behavioural signals that decide whether a transaction is stepped up for review or sent straight to the issuer.

Risk, reserves and settlement

Underwriting also produces the commercial terms, and these are the numbers worth negotiating hardest, because they compound over volume.

• Reserve percentage — the share of processed volume held back as protection. For this category it is a normal term, not an exception, and it is usually negotiable against evidence rather than against optimism.
• Rolling limit — the cap on volume processed before the account is re-reviewed. A limit that is set too low stops the business at exactly the moment it is working.
• Chargeback ratio and refund ratio — the thresholds at which the account is suspended or the reserve is raised. Ask for them as numbers, because they are usually described in prose as "monitoring".
• Settlement cycle — T+1 or T+2 for collection, and the net terms on the other side, commonly net 15 or net 30. In a category where prize money leaves weeks after the stake arrives, the gap between those two clocks is the operator's working capital, and it should be modelled before launch rather than discovered at the first payout run.

The money flow that survives underwriting

The pattern that gets approved is not the one that looks like a wallet. It is two separate rails, each with its own controls, its own reconciliation and its own documentation.

The mistake is treating a wagering operation as one flow with a balance. Once money can sit on a platform and come back out, the platform is holding a stake, and no amount of contract language reverses that. The alternative is to separate the two directions and design each one as a commercial flow in its own right.

The reconciliation principle behind this is simple and worth stating plainly, because it is where the money disappears when it does. The player, the operator and the acquiring bank each keep a record. They agree when the same amount appears in all three, in the same order, referencing the same thing. A flow that satisfies this in one direction only — collections reconciling but payouts not — will hide a missing disbursement for weeks.

There is a third flow whenever in-app currency is involved, sitting between the two rails. Players buy it with real money, and the question that decides its treatment is whether it can be converted back, withdrawn or transferred. If it can, it behaves like a stake. If it cannot, it behaves like a purchased item. The naming is irrelevant; the economic flow decides it.

Casino payment gateway: what the rail has to carry

A casino is where the expectation of a player wallet is strongest, and where that expectation is most likely to be mistaken for a stake. The rail has to carry three different things at once, and the difference between them is the whole design problem.

The deposit is small and frequent. The withdrawal is larger and rarer. The session balance sits between them: a real accounting position that lets a player leave and come back, that must never be withdrawable, and that is not money in the player's hands at any point. It is the third element that turns a collection flow into something a reviewer reads as a stake, because a balance that can be paid out is a balance, and a balance is a stake with a name.

Two further items break the category up, and a gateway that cannot tell them apart will see the whole flow as one thing. A jackpot contribution is not a wager; a tip is not a wager. If they arrive on the same reference as a stake, the acquirer cannot tell which is which — and a bonus with a cash-out option is functionally a withdrawal, whatever the product calls it. That wording is visible in the product copy, not just in the terms, and it is what a reviewer reads first.

Multi-currency and multi-wallet models add a settlement problem rather than a payment problem: the player funds in one currency, the operator settles in another, and the conversion sits somewhere that has to be reconciled on both sides of the rail. That is a treasury decision, and it belongs in the design conversation before the first transaction, not after the first reconciliation break.

Betting payment gateway: what the rail has to carry

Betting splits the rail across two times that do not line up. The stake is captured at the moment of placement. The money leaves days or weeks later, after the event settles, after any void window closes, and usually in a different settlement cycle entirely.

That gap is where betting payments are actually won or lost. A stake can be captured and then refunded, and the refund has to come back clean — same reference, same amount, same currency — even though it lands in a later cycle and may cross a provider's reporting boundary. A gateway that treats refund as a new transaction rather than the reversal of an old one produces a ledger that cannot be tied out, and an operator whose books do not tie cannot answer a regulator, an acquirer or a court.

1. The void window

   A stake captured and then voided is a normal event, not an exception. It has to be a defined path in the payment flow with a defined effect on the balance, and it has to be visible in the reconciliation as a reversal rather than as an unmatched second movement.

2. In-play acceptance and the abandoned bet

   When the price moves between acceptance and capture, and when a player clicks a bet that the page then fails to place, the rail has to be able to refund a captured stake cleanly. If that path is manual, every occurrence becomes a support ticket and a delay, and the delay is what regulators notice.

3. Combined and multi-leg positions

   A parlay settles as one payment against several legs. The gateway carries only the combined result, so the operator's own ledger has to carry the legs, and the two have to be reconcilable to each other. This is the usual source of a betting ledger that is internally consistent and externally unexplainable.

4. Early payout and cash-out

   A feature that lets a customer take money out mid-session is a refund of a stake in substance. If it exists, it has to be modelled, disclosed and explained, because it is the first thing a reviewer looks for. Removing the word from the interface while keeping the function is not a position any partner will accept.

One more detail, and it is a wording problem rather than a technical one. Sportsbook interfaces call the wallet top-up a "deposit". In a market where the legal distinction between a deposit of funds for wagering and a stake is the distinction that decides whether the product is permitted, that word is evidence. A flow that is otherwise carefully structured will be read against a single term in the product copy.

Payment methods that work for this category in India

Availability is set per merchant category and per method, and it is never assumed. A method menu copied from another market is a promise the operator cannot keep.

What the collection side usually runs on, and what each shape costs you operationally:

Chargebacks and disputes: a different problem in India

Most commentary on gambling payments treats the chargeback as the central operational risk. That framing comes from markets where cards dominate. In India it is wrong, and a page that repeats it will sound informed to a reader who does not know the difference — and be wrong to one who does.

The exposure is a function of the method mix, and the mix is not uniform. A card rail carries the formal scheme chargeback with its deadlines, its evidence requirements and its liability rules. UPI, app handoffs and account transfers do not carry a scheme chargeback at all: a dispute there is raised with the bank or the provider under a different framework, with different timescales and a materially different chance of a reversal. Two operators with the same total volume can have entirely different dispute exposure purely because of how that volume is routed.

The abuse patterns specific to this category are also not the ordinary kind of friendly fraud. They include multiple-account abuse, bonus hunting with a matched set of accounts created for the purpose, withdrawal to an account held in someone else's name, and the pattern where a card dispute is filed and the money leaves on a second rail before the first dispute is decided. None of these are visible as fraud at the point of authorisation, which is why the evidence trail matters more here than the fraud filter does.

What to keep is specific and it is worth agreeing it in advance: the payment reference, the game or bet reference, the balance state at the moment of the transaction, the terms the player accepted at that moment, and the verification status of the account. A session record with IP, device and event history is what wins a representation. A settlement report on its own is not.

What breaks in production

Six failures account for most of the support tickets in this category. None of them are exotic, and all of them are design decisions made in the first fortnight.

1. The same payment event, delivered twice

   Providers retry. A webhook that credits a balance on every delivery credits it twice. Every state change has to be idempotent, keyed on the provider's event identifier, and a duplicate has to be recognisable as a duplicate rather than as new information.

2. Order state and payment state are different things

   A bet is placed when the funds clear, and the funds are captured at a moment the customer has already left the page. Modelling one as the other produces a balance that says "paid" for someone who never completed the flow, or a paid customer with no position on the game.

3. Timeout is not decline

   A request that times out may still succeed a moment later. Treating a timeout as a hard failure and letting the customer retry is how one person ends up paying twice for one attempt.

4. The refund after the event is fixed

   Withdrawal from a live competition is a different operation from a cancellation. It has to be a defined path in the payment flow, with a defined effect on the position, and a published rule that says which one applies.

5. No dispute mechanism means no safety net

   On rails without a formal dispute process, your own team is the resolution path. That makes the refund window and the failed-payout retry policy part of the product, not part of operations. Write them down and publish them.

6. Two settlement clocks

   Collection settles on the provider's cycle, disbursement leaves on yours, and the reconciliation window between them is where a mismatch hides. A daily reconciliation across both rails, with an exception queue, is the cheapest control in this list.

Choosing a provider: what to check

Nobody publishes a rate card for this category, and any rate card you find will be wrong by the time you read it. What is useful before you sign is the list of what you are actually buying, and the questions that separate a gateway from a reseller.

Beyond the commercials, four questions separate a genuine licensed provider from a reseller, and it is worth asking all four before the contract rather than after the first decline.

• Who contracts with the acquirer? A provider that routes through someone else's merchant account is taking risk it does not control, and the approval rate you see may not be the one you get.
• Who is liable for a chargeback? The name on the statement, the name in the contract and the name that carries the dispute risk should be the same entity.
• Which legal entity holds the funds? If money sits in an account somewhere before it reaches you, ask who that entity is regulated by. This is the difference between a gateway and an aggregator, and it decides your risk.
• Who classifies the product? If the answer is "we do not, the bank does", you are carrying the risk of a classification decision you never saw. A provider that asks for the flow, the terms and the refund policy before quoting is doing that work with you.

And nine features that decide whether a provider is usable in this category at all, rather than merely acceptable on paper:

• Both directions on separate rails — collection and disbursement are not the same integration.
• A documented route for the session balance that is never withdrawable.
• Idempotent webhooks with duplicate delivery handled as a duplicate.
• Named methods with published minimum and maximum amounts, read from the platform rather than hard-coded.
• A stated settlement cycle and net terms for both directions.
• Chargeback and refund thresholds given as numbers, with a stated reserve percentage.
• A refund policy that matches what the flow actually does, including after an event is under way.
• Tax withholding handled in the disbursement path, with a per-recipient record.
• A reconciliation export that ties the settlement report to the operator's own ledger line by line.

Frequently asked

Where to read further

Use the current official text and qualified advice for a final decision:

• MeitY: Promotion and Regulation of Online Gaming Act, 2025, rules and notifications
• Gazette text: Promotion and Regulation of Online Gaming Act, 2025
• RBI: Guidelines on Regulation of Payment Aggregators and Payment Gateways
• RBI: current Payment and Settlement Systems notifications
• On this site: India eligibility guide for online gaming payments