How to Choose a White Label Crypto Payment Gateway (Checklist)

Choosing a white label crypto payment gateway comes down to eight decision axes: settlement speed and custody model, payout success rate, rail coverage including Lightning and stablecoins, failover routing between providers, compliance hooks for your licence, branding control in the cashier, API depth for reconciliation, and contractual SLAs matched to your jurisdictions.

Score each, weight against your churn drivers, then demand evidence.

Why does a scorecard beat a feature comparison?

Vendor decks converge. Every white label crypto payment gateway will tell you it supports major chains, settles fast, has an API, and is compliance-ready. The differences that matter only surface when you ask for evidence: a 90-day payout success log, a routing diagram, a signed SLA with credits attached, a sandbox key.

The scorecard below is deliberately vendor-agnostic. Twelve criteria, grouped under four questions, each with a single question to ask and a single artefact to demand. Score each criterion 1-5, apply your own weights, and you have an RFP tab you can defend to your board and your compliance lead.

Before the criteria, it helps to be honest about which structural model you are actually buying.

Those ranges assume you already have a cashier and a KYC provider in place. The in-house row is the one operators underestimate: the build is not the hard part, the on-call rota and rail maintenance are. The reseller plugin row is where most operators replacing a basic BTC integration are starting from, and its weakness is almost always the same — you cannot see why a payout failed, so you cannot fix it.

Which crypto rails and settlement mechanics must the gateway support?

This bucket carries the most weight for nearly every operator model, because it determines both the cost per transaction and the withdrawal SLA you can credibly promise.

1. Rail coverage and depth per rail

Breadth of chains matters less than depth on the rails your players actually use. A gateway supporting 40 chains but with thin Lightning capacity or no native USDT on Tron is worse than one supporting six rails properly. Ask specifically about Lightning for low-value high-frequency traffic and stablecoins on low-fee chains for larger balances.

What to ask the vendor: For each rail you support, what share of our expected volume can you handle without manual intervention, and what is your liquidity or channel capacity ceiling per rail?

Proof to demand: A per-rail volume and capacity sheet from an existing iGaming client of comparable size, with the client anonymised but the numbers real.

2. Settlement speed and confirmation policy

Deposit crediting policy is a commercial decision disguised as a technical one. Some gateways credit on first confirmation, some on three, some on zero-conf with a risk score. Each choice trades support tickets against exposure. On the payout side, the question is whether withdrawals leave automatically or queue for approval.

This is where the difference between rails becomes a player-experience difference. On-chain settlement means waiting for block confirmations; Lightning settlement clears in seconds. It is worth understanding how a crypto payment gateway built for iGaming handles instant payouts before you accept a vendor's claim that "instant" and "fast" mean the same thing.

What to ask the vendor: What is your median and 95th-percentile time from player withdrawal request to funds spendable, broken out by rail?

Proof to demand: Timing distributions from production logs over 30 days, not a marketing figure, with the 95th percentile visible.

3. Custody model and float ownership

Custodial, non-custodial, or hybrid changes your risk register, your audit scope, and possibly your licence conditions. If the gateway holds funds, you need to know where, under what regulatory permission, and what happens on their insolvency. If you hold funds, you need to know how the gateway triggers payouts from your wallets and who holds the keys.

For sweepstakes and social models operating outside a gambling licence, custody flexibility often matters less than for a licensed sportsbook whose regulator will ask exactly this question at the next audit.

What to ask the vendor: Who holds legal and operational control of player funds at each stage, and under which entity and permission?

Proof to demand: A custody flow diagram plus the licence or registration reference of the entity holding funds, and their most recent proof-of-reserves or audit letter.

4. Payout success rate and failure taxonomy

This is the single most under-asked question on crypto payment gateway comparison criteria. A gateway with a 96% payout success rate and one with 99.4% look identical in a demo and completely different in your support inbox.

What matters more than the headline number is whether the vendor can classify failures — insufficient liquidity, invalid address, network congestion, internal timeout, sanctions hold — because a vendor who cannot classify failures cannot reduce them.

What to ask the vendor: What is your payout success rate on first attempt by rail, and what is the breakdown of failure reasons for the last 90 days?

Proof to demand: A failure-reason table with percentages, plus the retry policy and how many attempts happen before a player sees an error.

How should risk and compliance criteria be scored?

Your compliance lead signs off on this bucket, so score it with them in the room. The failure mode here is not a gateway that lacks controls — it is a gateway whose controls cannot be evidenced to your regulator in the format your regulator wants.

5. On-chain analytics and sanctions screening

Screening should happen on deposit addresses and withdrawal destinations, against a named provider, with configurable risk thresholds you control rather than the vendor. Ask what happens to a flagged deposit: rejected, quarantined, or credited with a flag raised.

What to ask the vendor: Which analytics provider do you screen with, at which points in the flow, and can we set our own risk thresholds per brand?

Proof to demand: The provider contract or integration confirmation, plus a redacted sample of an alert as it appears in your operations console.

6. KYC and AML orchestration hooks

The gateway rarely does your KYC, but it must respect it. You need the ability to block payouts to unverified accounts, enforce source-of-funds thresholds, and pass identity state between your platform and the gateway without a nightly batch file.

What to ask the vendor: How does the gateway receive and act on our KYC status, and can it enforce different payout limits by verification tier?

Proof to demand: API documentation access for the identity and limits endpoints, plus one reference client using tiered payout limits in production.

7. Reporting, reconciliation and audit trail

Your finance team needs a ledger that reconciles to the satoshi, exportable in a format your accounting stack accepts, with immutable transaction history. Your regulator may need transaction-level reporting on demand. Ask how long history is retained and whether you can export it after contract termination.

What to ask the vendor: What reports are available at transaction level, in what formats, and what is the data retention and post-termination export policy?

Proof to demand: Sample export files from a sandbox account and the retention clause from the standard contract.

8. Jurisdiction fit and licence alignment

Some gateways cannot service certain markets, some will not touch specific licences, and some have geographic restrictions inherited from their own banking or custody partners. Establish this early — it eliminates vendors faster than any other criterion.

What to ask the vendor: Which of our licensed markets can you service today, which require additional review, and which are excluded?

Proof to demand: A written market-by-market matrix signed by the vendor, referencing your specific licences.

What control and integration depth do you actually need?

9. Branding control across the cashier

White label means different things at different depths. Check whether the payment page can carry your domain, your CSS, your language set, and your support contact — or whether players see a third-party brand mid-flow. Multi-brand groups should test whether each brand can have distinct styling from one integration.

What to ask the vendor: At which points in the deposit and withdrawal flow does any vendor branding, domain, or email sender appear?

Proof to demand: Live access to two existing client cashiers on different brands, plus a copy of a system email as a player receives it.

10. API depth, webhooks and sandbox quality

Judge the API by its webhook reliability and its sandbox, not its endpoint count. You want idempotency keys, signed webhooks, replay capability for missed events, and a sandbox that simulates failure states — congested network, invalid address, partial payment — because those are the states your integration will actually break on.

What to ask the vendor: Does the sandbox let us simulate payout failure, network congestion and webhook replay, and how many engineering hours does a typical integration take?

Proof to demand: Sandbox credentials within 48 hours of request, plus a named integration reference your CTO can call.

11. Failover and routing logic

Single-provider dependency is the risk most operators discover during an incident rather than during procurement. Ask whether the gateway routes across multiple liquidity or processing sources, whether routing rules are yours to configure, and what happens automatically when one rail degrades. For a multi-brand group, this is often the highest-weighted criterion on the board.

What to ask the vendor: If your primary route for a rail degrades at peak, what happens in the next 60 seconds, and is that automatic or manual?

Proof to demand: A routing architecture diagram plus a post-incident report from a real degradation event in the last 12 months.

12. SLAs, support model and incident process

The contract is where claims become obligations. You need uptime commitments with credits, a defined severity matrix, response times per severity, a named escalation path, and a status page. Ask who is on the incident bridge at 02:00 on a Sunday during a Champions League weekend equivalent.

What to ask the vendor: What are your contractual uptime and response-time commitments per severity, and what service credits attach to a breach?

Proof to demand: The unredacted SLA schedule, the severity matrix, and 12 months of status-page history.

If you want a working reference point while you score these twelve, you can walk your shortlist through LightningPay's infrastructure and use it as a baseline for what evidence vendors should be able to produce on request.

How should you weight the scorecard?

Equal weighting produces a defensible-looking number and a bad decision. Weight against your own churn drivers.

A sportsbook with meaningful live in-play volume should weight payout speed and payout success rate heaviest — often 30-35% of the total between them. Bettors reload from winnings, and a withdrawal sitting in a queue for 40 minutes is a bettor who is not staking on the second half. Rail coverage matters mainly insofar as it supports fast settlement.

A multi-brand casino group inverts this. Failover, branding control and API depth carry the top weights, because one integration must serve several cashiers with distinct player bases, and a single-provider outage takes down the whole portfolio at once. Payout speed still matters, but casino session economics tolerate slightly more latency than in-play betting does.

A sweepstakes or social operator can usually de-weight jurisdiction fit and custody complexity, and put weight on reconciliation quality and cost per transaction instead. Whatever the model, publish the weights before you see the scores. Weights chosen after scoring are just a justification for a decision already made.

Where LightningPay scores on this checklist

LightningPay's specific contribution is on criteria 2 and 4: instant Lightning Network settlement with automated payouts. Withdrawals are executed programmatically over Lightning rather than being batched into a manual approval queue that waits on on-chain confirmations, so funds are spendable in seconds from the player's request.

The mechanism matters because payout speed and payout success rate are the two criteria that generate support volume. Slow withdrawals produce "where are my funds" tickets at a rate roughly proportional to queue time, and each ticket costs agent minutes plus a retention risk. Removing the confirmation wait and the manual approval step removes the cause rather than staffing around it.

Final thoughts

Most crypto gateway shortlists are won and lost on payout mechanics and failover, not on deposit features — yet deposit features are what vendor demos are built to showcase, because they are the easiest thing to make look good in twenty minutes.

The real function of this scorecard is procedural: it forces vendors to replace claims with artefacts, and a vendor who cannot produce a failure-reason table, a routing diagram, or an unredacted SLA schedule has told you something useful regardless of how they score elsewhere.

Weight the twelve criteria against the reasons your own players actually leave, not against the criteria a vendor is strongest on. When you are ready to test the evidence standard against a live implementation, book a technical review with the LightningPay team and bring the scorecard with you.