White Label Crypto Payment Gateway: iGaming Guide

A white label crypto payment gateway is payment infrastructure that runs under your brand while somebody else operates the wallets, the nodes, and the settlement rails.

Your players see your cashier. They never see the provider. Behind the glass, that provider is generating addresses, watching blocks, signing payouts, and settling to you in fiat or stablecoin on a schedule you agreed in a contract.

That's the whole idea. The interesting part is everything the sales deck skips: who holds the keys, who eats the price risk, who gets called at 2am on a Sunday when withdrawals back up after a Champions League final.

What does a white label crypto payment gateway actually do?

Strip the marketing away and it performs five jobs.

One: it creates a way for the player to pay

On most chains that means deriving a fresh receive address per player, per transaction, from a master key using HD wallet derivation. Hierarchical deterministic derivation, if you want the full phrase.

Thousands of addresses from one seed, no address reuse, and every inbound transaction attributable to a specific player account.

On the Bitcoin Lightning Network the mechanism is different: the gateway issues a single-use Lightning invoice that settles off-chain in seconds instead of waiting for a block.

Two: it watches the chain

The gateway runs nodes or connects to them, spots the incoming transaction, and applies a confirmation policy. That policy is a number: how many blocks must sit on top before you credit the player.

One confirmation on fast chains. Two or three on Bitcoin, which is 20 to 30 minutes at normal block times. Stablecoin transfers on high-throughput chains often clear inside a minute.

Three: it credits your platform

An API call into your wallet or PAM (player account management) system with a normalised amount, usually converted to the player's account currency at a quoted rate.

Four: it pays people out

This is where integrations get tested and where cheap ones fall apart. Your platform sends a payout instruction. The gateway applies risk and compliance rules, signs, broadcasts, and reports back the transaction hash. Deposits are a solved problem. Withdrawals are the product.

Five: it settles to you

It either holds crypto on your behalf, converts to stablecoin, or converts to fiat and pays your bank.

Dashboards, reporting, reconciliation exports, AML screening: all of it wraps around those five functions. None of it replaces them.

Where does the gateway sit relative to KYC and your risk engine?

Almost every scoping call I've sat in eventually hits the same confusion. People treat "the gateway" as if it were the whole payments stack. It isn't.

In a properly assembled iGaming setup you're running three distinct systems: an identity/KYC provider, a risk engine, and the gateway itself.

Each one owns a different decision, and the order in which they fire is a compliance control, not an implementation detail.

Here's the deposit path, in sequence:

Player in cashier (your UI, your brand)
        │
        ▼
1. PAM / account layer  ─── holds player status, balance, limits
        │
        ▼
2. KYC provider  ─────────── is this player verified to the tier this deposit requires?
        │                    (gate BEFORE an address is issued, not after)
        ▼
3. Gateway  ──────────────── issue address / Lightning invoice, monitor chain,
        │                    reach confirmation policy
        ▼
4. Risk engine + chain analytics ── screen source address, sanctions,
        │                            high-risk exposure, velocity, dedupe
        ▼
5. Gateway → PAM credit  ── amount + FX rate stamp written to ledger
        │
        ▼
6. Settlement engine  ────── convert, batch, pay out to your bank / treasury wallet

Player in cashier (your UI, your brand)
        │
        ▼
1. PAM / account layer  ─── holds player status, balance, limits
        │
        ▼
2. KYC provider  ─────────── is this player verified to the tier this deposit requires?
        │                    (gate BEFORE an address is issued, not after)
        ▼
3. Gateway  ──────────────── issue address / Lightning invoice, monitor chain,
        │                    reach confirmation policy
        ▼
4. Risk engine + chain analytics ── screen source address, sanctions,
        │                            high-risk exposure, velocity, dedupe
        ▼
5. Gateway → PAM credit  ── amount + FX rate stamp written to ledger
        │
        ▼
6. Settlement engine  ────── convert, batch, pay out to your bank / treasury wallet

Player in cashier (your UI, your brand)
        │
        ▼
1. PAM / account layer  ─── holds player status, balance, limits
        │
        ▼
2. KYC provider  ─────────── is this player verified to the tier this deposit requires?
        │                    (gate BEFORE an address is issued, not after)
        ▼
3. Gateway  ──────────────── issue address / Lightning invoice, monitor chain,
        │                    reach confirmation policy
        ▼
4. Risk engine + chain analytics ── screen source address, sanctions,
        │                            high-risk exposure, velocity, dedupe
        ▼
5. Gateway → PAM credit  ── amount + FX rate stamp written to ledger
        │
        ▼
6. Settlement engine  ────── convert, batch, pay out to your bank / treasury wallet

And the withdrawal path, which runs the same components in a different order:

Payout request from PAM
        │
        ▼
1. KYC / SoW status check  ─ verification tier, expired documents, open RG flags
        │
        ▼
2. Risk engine  ──────────── destination address screening, bonus abuse rules,
        │                    limit checks, manual-review triggers
        ▼
3. Gateway policy layer  ── whitelist, velocity cap, dual approval threshold
        │
        ▼
4. Signing + broadcast  ─── hot wallet or MPC quorum
        │
        ▼
5. Ledger write-back  ───── tx hash, fee, FX rate stamp, batch ID

Payout request from PAM
        │
        ▼
1. KYC / SoW status check  ─ verification tier, expired documents, open RG flags
        │
        ▼
2. Risk engine  ──────────── destination address screening, bonus abuse rules,
        │                    limit checks, manual-review triggers
        ▼
3. Gateway policy layer  ── whitelist, velocity cap, dual approval threshold
        │
        ▼
4. Signing + broadcast  ─── hot wallet or MPC quorum
        │
        ▼
5. Ledger write-back  ───── tx hash, fee, FX rate stamp, batch ID

Payout request from PAM
        │
        ▼
1. KYC / SoW status check  ─ verification tier, expired documents, open RG flags
        │
        ▼
2. Risk engine  ──────────── destination address screening, bonus abuse rules,
        │                    limit checks, manual-review triggers
        ▼
3. Gateway policy layer  ── whitelist, velocity cap, dual approval threshold
        │
        ▼
4. Signing + broadcast  ─── hot wallet or MPC quorum
        │
        ▼
5. Ledger write-back  ───── tx hash, fee, FX rate stamp, batch ID

Two things fall out of that diagram.

First: the KYC gate belongs upstream of address issuance. Plenty of platforms issue a deposit address the moment a player lands in the cashier, then discover at withdrawal that the account never cleared verification.

Now you're holding funds you can't return to source easily and can't pay out without a document chase.

Second: the risk engine screens before the credit, not after. If a deposit arrives from an address with sanctions exposure and you've already credited it, your options narrow to freezing a player balance and writing an incident report.

Screen first, credit second.

Ask any prospective provider whether their webhook fires pre-screen or post-screen, and whether the screening verdict is returned in the same payload as the credit instruction.

Some providers only screen asynchronously and reconcile later. That's a very different control.

Some gateways bundle a light KYC module and basic rules. Useful for a launch, rarely sufficient at scale, and it makes vendor swap-outs painful.

Most serious operators keep KYC and risk as independent contracts and treat the gateway as the money-movement layer.

What does "white label" actually control?

White label is a branding and control boundary, not a technical one. Get precise about where the line sits, because vendors move it around depending on who's asking.

Branding surface vs. underlying infrastructure ownership

The practical test is short. Ask whether the provider's name shows up anywhere a player can see it: a hosted page URL, a redirect, a transaction memo, an email footer. Ask whether they can change the cashier UI without your sign-off. Ask whether you can embed the cashier inside your existing account area instead of bouncing players out to a hosted page.

Three answers. They tell you how white the label really is.

How do custody models differ, and why does it matter most?

Custody decides who legally holds player funds, who can move them, and what your recovery looks like if the provider is compromised or simply stops answering email. First question on every serious vendor call. If it takes twenty minutes to get a straight answer, that's information.

MPC gets namedropped constantly and explained rarely, so: multi-party computation splits a private key into mathematical shares held by different parties. A transaction signs only when a threshold of shares participates. Two of three, say.

No party ever reconstructs the full key, and compromising one machine doesn't move a single satoshi. Unlike an on-chain multisig wallet, MPC outputs an ordinary single-signature transaction, so fees and chain compatibility stay normal.

No model is universally right. A sportsbook with a real treasury function and a licence that permits holding virtual assets will often prefer MPC or self-custody.

An operator launching in three new markets this year who wants crypto live in six weeks takes segregated provider custody and gets on with it.

Choose deliberately, write down why, and keep the memo. Your regulator will ask, and so will your auditor.

How does settlement work, and where does price risk sit?

Two variables. Currency and window.

Currency

Settle in the same crypto the player deposited and you hold that asset, volatility included, until you sell. Settle in stablecoin, a token designed to hold a fixed value against a fiat currency (usually the dollar), and you strip out most price risk but pick up issuer risk and chain risk instead.

Settle in fiat to a bank account and the provider or its liquidity partner takes the conversion while you receive a familiar credit. That last option leans hardest on banking relationships, which is exactly why fiat settlement availability swings by jurisdiction and by how your risk profile reads to a compliance officer at a bank you've never met.

Window

Instant conversion at deposit locks the rate at confirmation and kills volatility exposure almost entirely. Daily or T+1 is the common middle, and cheaper. Weekly settlement flatters the provider's netting efficiency and leaves you sitting on a fatter crypto balance for longer. Read that sentence again if someone is pitching you weekly as a feature.

Ask directly. What rate is used. Who quotes it. What spread sits inside it. What happens if the market moves between the player's payment request and confirmation.

A gateway that quotes a rate, holds it for a defined window, and absorbs the difference is doing real work and should charge for it. A gateway that credits at whatever the rate happens to be when the transaction lands has handed you the risk and called it a feature.

Withdrawal settlement is the mirror image, and it's the half people forget. If you're converting deposits to fiat daily, you need crypto liquidity standing by to pay withdrawals.

Somebody funds that float: the provider on your behalf, or you from a working balance, or nobody, in which case your players wait while conversion happens. Model peak withdrawal hours before you sign anything. Sunday evening after a big fixture settles is a different animal from Tuesday at 10am.

This is the clearest structural gap between a retail e-commerce processor and a crypto payment gateway built for iGaming deposit and withdrawal volumes, where withdrawals can approach deposit volume and payout speed is a competitive weapon rather than a back-office chore.

Batched or instant payouts? pick on purpose

Most providers support both. Very few operators choose deliberately, and the choice affects fees, player experience, and your hot wallet exposure at the same time.

Practical guidance: on Bitcoin, batching is close to a no-brainer during high-fee periods, and Lightning removes most of the reason to batch small payouts at all. On low-fee high-throughput chains, batching buys you almost nothing on cost and costs you player goodwill.

Whatever you choose, insist the batching interval is a config value you control, not a hardcoded provider default. And ask what happens to a batch that gets stuck at a low fee rate. Fee bumping via RBF or CPFP should be automatic, not a support ticket.

Reconciliation exports: the fields finance will demand

Finance doesn't care about your dashboard. They care whether every on-chain movement ties to a player, a platform transaction, and a settlement batch, in a file their system ingests. Ask for a sample export before you sign, and check it contains at minimum:

• Platform transaction ID and player ID

• On-chain transaction hash, plus output index where relevant

• Chain, asset, and contract address for tokens

• Gross amount in the asset, at full decimal precision

• Block height and confirmation timestamp in UTC

• FX rate stamp: the exact rate applied, the rate source or venue, the quote timestamp, the quote or lock ID, and the spread charged as a separate field from the mid-market rate

• Fiat or account-currency equivalent, calculated from that stamped rate

• Network fee paid, and who bore it (operator, player, or provider)

• Provider fee, itemised

• Settlement batch ID and settlement value date

• Screening verdict, risk score, and analytics vendor reference

• Wallet address, direction, and status transition history with timestamps

That FX rate stamp is the field operators discover they need six months in, during their first audit or their first player dispute.

Without a stamped rate, a source, and a timestamp on every single transaction, you cannot prove why a €100 deposit credited as €99.40, and you cannot rebuild the month when the ledger and the bank disagree.

Push back hard if a provider offers only "converted amount" with no rate lineage. It's a cheap field to emit and an expensive one to reconstruct.

How do licence conditions treat crypto deposits and conversions?

Here's the part vendors handle badly, usually by saying "our clients do it all the time." Fine. Your licence conditions are yours.

Broad patterns, as a starting point for a conversation with counsel rather than a substitute for one:

Three practical takeaways.

Almost nobody wants your ledger denominated in Bitcoin. Even where crypto deposits are welcome, regulators want player balances, bonus liabilities, and reporting in a stable unit of account. Design for that.

Privacy coins and mixers are a separate conversation, and usually a short one. If a provider lists an anonymity-enhanced asset among its supported coins as a selling point, ask how that squares with your licence conditions. Then watch the answer.

Your AML policy has to cover crypto explicitly. Not "payment methods" in general. Crypto: address screening, source-of-funds triggers for crypto deposits, how you handle a hit, retention periods for on-chain evidence.

How should an operator evaluate a crypto payment gateway white label provider?

Seven criteria, ordered by how often they decide the outcome. Score every shortlisted vendor on the same sheet, and make somebody from finance sit in on at least one call.

Two failure patterns worth naming.

Buying on coin coverage: a long asset list is trivial to produce and tells you almost nothing about operational quality.

And buying on integration speed alone: a two-week integration that leaves you with manual withdrawals and unreconcilable reporting costs more across a year than a six-week integration that ships automated payouts and a clean export.

Diligence questions most operators forget to ask

Before signing, ask five questions:

1. Who controls the keys, and who can move funds?

2. What happens when withdrawals spike?

3. Is every transaction traceable from player ID to settlement?

4. When exactly does risk screening happen?

5. How fast can you exit and recover your funds?

These answers separate a payment gateway from real payments infrastructure.

LigtningPay is built for iGaming deposits, payouts, settlement, and real-time risk monitoring, giving operators the infrastructure to move faster without adding operational drag.