iGaming Payments Infrastructure Map: Who Moves the Money?

An iGaming payment is not a single API call. The player sees a deposit or withdrawal, but the operating licence holder, payment service provider (PSP), gateway or orchestrator, acquirer, issuing bank and account provider may each perform a different part of the transaction. The operator still has to know who owns the player relationship, who holds or settles funds, who checks risk, and what happens when a payment fails or is reversed.

This map is for gambling operators, procurement teams and analysts comparing payment setups. It describes functional roles rather than endorsing a vendor or asserting that one architecture works in every market. The exact regulated perimeter depends on the jurisdiction, product, contract and payment method.

What are the layers in an iGaming payment stack?

Start with the licensed operator. It offers the gambling product to the player, controls the gambling account and is accountable for its own regulatory obligations. Its player-account system maintains a balance and an event history; the PAM explainer describes this operational layer. The player wallet is not automatically the same as a bank account: the ledger may show a stake, win, pending withdrawal or refund before the corresponding external transfer settles.

The gateway handles the technical handoff to payment services. An orchestrator may select among routes, retry within agreed rules and consolidate reporting. A PSP or processor processes a particular payment method; an acquirer enables card acceptance and settlement for the merchant; an issuer is on the player's card side. These terms overlap in commercial packages. The PCI Security Standards Council glossary explicitly notes that “payment processor” is sometimes called a payment gateway or PSP, so a vendor label alone does not identify the contractual or regulated role.

For bank-to-bank methods, the chain differs. Open Banking Limited defines a payment initiation service provider as a service that initiates a payment order at the user's request from an account held with another PSP. The account-servicing provider maintains that account. An operator should therefore map the authorisation, confirmation and reconciliation events rather than treating “open banking” as a synonym for guaranteed receipt.

The deposit flow: authorisation is not settlement

In a typical card deposit, the player selects a method, the operator applies account and risk rules, the technical layer sends a request, and the payment chain returns an authorisation result. Capture, settlement, fees and possible dispute follow on different timelines. The operator's ledger needs an unambiguous transaction ID, status, amount, currency and mapping to the player's account.

The control question is what the operator does when the gateway reports “approved” but a webhook is delayed, duplicated or later reversed. A defensible design makes posting idempotent, separates pending from available balance, and reconciles provider reports against the operator ledger and settlement statement. These are design recommendations, not a claim about any named provider's implementation.

The MCC 7995 and gambling-payments guide explains why a card merchant category code and a legal payment restriction answer different questions. In Britain, licence condition 6.1.2 and the Commission's guidance extend the gambling credit-card ban to credit-funded payments routed through money-service businesses. A wallet or intermediary does not make the underlying funding source irrelevant.

Withdrawals require their own controls

A withdrawal is not merely a deposit in reverse. It can involve account ownership checks, open bets, bonus or fraud rules, source-of-funds review, payout-route restrictions and reconciliation of a new outbound transfer. The UK Gambling Commission's withdrawal guidance warns against accepting deposits from a questionable third-party method and only investigating that method once a player requests a withdrawal. The lesson is to identify a foreseeable problem at the earliest appropriate point, not to manufacture friction at payout.

For every method, document who can place a hold, who resolves an exception, what evidence is retained and how the player is informed. The processor may return a failure reason, but the operator needs a case owner and a ledger correction rule. The transaction-monitoring guide covers how payment events can trigger review without converting every alert into a finding.

Who owns compliance when a PSP is involved?

In Great Britain, LCCP condition 5.1.2 says covered remote licensees must only accept customer payments involving specified payment services where the provider meets the statutory PSP definition. The Commission's third-party guidance says licensees remain responsible for contracted parties carrying out licensed activity. Its October 2025 risk notice specifically says operators must not rely on payment processors to conduct KYC on their behalf or establish source of funds without further scrutiny.

The practical boundary is a documented RACI, not “the PSP handles compliance”. A processor may screen a payment instrument; the operator may still need to decide whether the player's activity is consistent with its risk assessment, safer-gambling duties and account history. Market-specific legal advice is needed before translating this British rule to another jurisdiction.

Procurement map: the questions to put in a contract

Test one successful deposit, one decline, one timeout, one reversal, one successful withdrawal and one returned payout. Record the status at each layer and the player-facing balance after each event. The table is a due-diligence worksheet, not a certification standard.

Frequently asked questions

Is a payment gateway the same as an acquirer?

Not necessarily. A gateway can provide a technical connection or orchestration, while an acquirer has a specific role in card acceptance and settlement. Some suppliers bundle both. Ask which legal entity contracts with the merchant, which entity settles funds and which rules apply to each payment method.

Does a PSP complete the operator's KYC obligations?

No general transfer follows from appointing a PSP. A payment provider may perform its own regulated checks, but the gambling operator must identify the checks and decisions required of its licence. The British regulator expressly warns licensees not to rely on processors to perform their customer checks without further scrutiny.

Is an approved deposit final?

An approval is one state in a longer flow. Capture, settlement, reversals and disputes may follow. The operator should distinguish pending, posted and reversed ledger states and reconcile them to provider and bank records. The exact timing depends on the rail and contract.

Where does open banking fit?

Payment initiation can start an account-to-account transfer with the player's consent through a payment-initiation provider and the account-servicing provider. It does not replace the gambling account ledger, payout rules or reconciliation. Confirm the event that the operator treats as usable funds before crediting play.

Bottom line

The useful iGaming payments infrastructure map is a set of named legal entities, money flows and decision owners. A procurement deck that only lists “cards, wallets and bank transfer” misses the controls that determine whether deposits and withdrawals can be reconciled, supported and governed. Map the contract and event chain for each market and method before comparing approval rates or fees.