White Label Crypto Payment Gateway Providers: 20 Questions

Vet white label crypto payment gateway providers across eight areas: where settlement liquidity actually comes from, settlement latency and payout float, Lightning-specific mechanics, custody, routing evidence, who answers at 02:00 on a Sunday, compliance ownership, multi-brand subaccount structure and exit terms.

Ask for numbers, contract clauses and live dashboard access. Not adjectives. A vendor who stays vague on custody or exit has failed the process.

Why does a provider shortlist tell you almost nothing?

Because on paper, everyone has feature parity.

Pull up four vendor sites side by side. All four support BTC, ETH, USDT and Lightning. All four do multi-brand. All four have dashboards, webhooks, API docs, an AML partner, a compliance page and a logo wall.

The feature grids are near-identical, which is unsurprising, because they're written by people reading each other's feature grids.

None of it predicts what happens at 22:40 on a Saturday when a Champions League cash-out wave and a Brazilian deposit spike land in the same ten minutes, your p99 confirmation time triples, and 400 players are staring at a pending screen.

That's the only test that matters. Deposit load, payout load, at peak, in your corridors. Everything else is a brochure.

So the job in diligence isn't gathering claims. It's converting them.

The three claims nobody checks

Operators interrogate pricing to two decimal places and then accept three things on trust:

Uptime. "99.9%" gets nodded through without anyone asking which endpoint that covers, at what probe interval, or whether a payout API that's up but not paying counts as downtime.

Liquidity. "Deep liquidity" is accepted as a property of the vendor rather than a question about whose money is funding your Sunday-morning withdrawals.

Custody. "Your funds are secure" ends the conversation instead of starting it. Secure where? In whose name? On whose ledger?

Those three are where the real risk lives, and they're the three that never get evidence attached. Start there.

Turning a claim into a measurable question

The method is mechanical. Strip the adjective. Name the metric. Name the window. Name the artefact you want to see on screen.

Run that conversion on every line of every deck you've been sent. You'll find that roughly a third of what you were told isn't a claim at all. It's a vibe.

Is this a gateway, or a reseller wrapper?

Worth settling early, because it changes the meaning of every other answer.

A meaningful share of white label crypto payment gateway providers are commercial layers sitting on top of infrastructure they don't own. Someone else's Lightning nodes.

Someone else's exchange for conversion. Someone else's custodian holding the float. Someone else's compliance stack, licensed to them.

That isn't automatically disqualifying. Plenty of good businesses resell well. But understand what you're buying: two SLAs stacked on top of each other, and visibility into neither.

When the upstream provider has an incident, your vendor is a customer filing a ticket, exactly like you, except you're the one with 900 queued withdrawals and a Trustpilot problem.

The test is short. Ask for an architecture diagram that names every third party in the deposit path and the payout path. Then ask one follow-up: can you change routing logic yourselves, today, or do you have to request it?

A vendor that controls its own routing and settlement can reroute a failing corridor in an afternoon. A wrapper opens a ticket and waits. Ask which they are, and get the answer in writing, because the sales team will say "our platform" about infrastructure they rent by the month.

Liquidity, settlement and payout float

Deposits are the easy half. Payout performance under load is where operators get hurt: Saturday night in a live sportsbook, or a big-win withdrawal cluster at 01:00 when your float is thin and nobody senior is awake.

1. Where does settlement liquidity actually come from: your own float, a market maker, or a third party?

Pass: a straight answer with the plumbing attached. "We hold our own float, currently seven figures, with a named market maker as a secondary source above X per hour, and here's the ceiling." Or: "It's a third party, here's who, here's the contract length, here's our fallback if they pull the line."

Disqualify: "we have deep liquidity relationships." That's a claim about someone else's balance sheet, and if it's a third party you've never heard of, your payout capacity depends on a commercial relationship you can't inspect, renegotiate or replace. Ask what happens to your withdrawals if that relationship ends on 30 days' notice.

2. What are your median, 95th-percentile and 99th-percentile deposit settlement latencies over the last 30 days?

Pass: three numbers and a measurement definition. "Median 4 seconds, p95 11 seconds, p99 48 seconds, measured from broadcast to credited in your ledger."

Insist on the p99. The median flatters everyone. Your support tickets don't come from the median, they come from the tail, and the tail is where a 4-second average quietly hides a 3-minute worst case on a busy Saturday. A vendor who tracks p99 has a monitoring culture. A vendor who has to go and calculate it doesn't.

Disqualify: "instant" or "near-instant." Also disqualify any latency figure that excludes on-chain confirmation. That measures their API, not your player's experience.

3. What's the largest single payout you've processed in the last 90 days?

Pass: a figure, an asset, a date, and how long it took end to end. "€184,000 in USDT on 12 March, cleared in under a minute, no manual intervention." Bonus points if they volunteer what broke and what they changed afterwards.

This question does more work than it looks like it should. It tells you whether their float has ever been genuinely stressed, whether large payouts trigger a manual review queue nobody mentioned, and whether their biggest customer is a scale above you or a scale below. If their record payout is €9,000 and your VIP desk clears €80,000 tickets, you're their experiment.

Disqualify: "we don't have limits" with no example. Everyone has limits. The ones nobody will name are usually the ones set by whoever funds the float.

4. Who funds payout liquidity, and what happens when my float runs dry mid-weekend?

Pass: a clear model. Either you pre-fund a payout wallet you monitor, with alerting you control, or they extend a defined credit line with a stated ceiling, a top-up latency and interest terms. Numbers, not intentions.

Disqualify: "we handle liquidity." Push harder: it's 23:00 on a Saturday, your float is exhausted, their treasury desk went home at 18:00 Friday.

Who authorises the top-up? What's their ceiling? How long does it take? If nobody has a written answer, your withdrawals queue, your VIP manager starts apologising, and your players find a competitor who paid out in four seconds.

Follow-up: how do you price conversion, and where is the spread?

Pass: a stated spread in basis points against a named reference rate, plus a separate, transparent processing fee. You can reconcile it per transaction against a public rate.

Disqualify: "market rates" alongside a zero-fee headline. The spread is where the margin hides, and an unpriced spread is an unforecastable cost line that your finance team will discover in month four.

Follow-up: can I settle in crypto, fiat, or both, and who carries volatility between deposit and settlement?

Pass: explicit settlement currency options, an explicit volatility window measured in seconds or minutes, and a named party carrying the risk. If they carry it, that risk is priced somewhere. Find out where.

Disqualify: an answer that assumes you want fiat. Multi-jurisdiction operators often need mixed settlement, and rigid vendors push you into treasury workarounds you'll be maintaining by hand in spreadsheets a year later.

This is also the block where you learn whether a vendor understands iGaming or has simply added it to a dropdown.

Generic processors optimise for e-commerce settlement cycles, and T+2 is perfectly fine when nobody expects a payout in four minutes. A crypto payment gateway built for iGaming settlement is architected around payout velocity and float visibility, because those two variables decide whether your cashier holds up on a peak weekend or becomes a support incident.

Lightning specifics: the questions that separate operators from resellers

If Lightning is part of the pitch, this block is where wrappers fall apart. Lightning isn't a checkbox next to BTC. It's a liquidity management discipline, and running it well takes people watching channels at 2am.

5. What is your Lightning payment success rate, and precisely how do you measure it?

Pass: a definition with a denominator. "Settled payments divided by invoices generated, last 30 days, including expired invoices and route failures, broken out by hour of day." A vendor doing this properly will also tell you their worst hour, and it'll be Saturday evening.

Disqualify: "Lightning is basically 100%." It isn't, not under load, not with large amounts, not across every wallet your players use. Also disqualify any figure that counts only payments that found a route, which is a bit like measuring flight punctuality using only the planes that took off.

6. How do you manage inbound and outbound channel liquidity at peak, and who is watching it at 2am?

Pass: specifics. Monitored inbound capacity per channel with thresholds and alerting, automated rebalancing, submarine swaps to on-chain when a channel drains, and pre-funded inbound liquidity ahead of known peaks.

The good ones plan around the fixture list: a Saturday 15:00 kick-off block, a title fight, a Grand National. They'll tell you what capacity they add and when.

Disqualify: "channels are managed automatically." Ask the direct version. A run of large withdrawals drains outbound liquidity at 23:00 on Saturday. What rebalances it, how long does it take, and does a human have to be awake?

7. What happens when a Lightning payment fails: automatic retry, on-chain fallback, or does my player eat the friction?

Pass: a documented sequence. Retry across alternate routes for a fixed number of attempts, then a fresh invoice, then a clearly presented on-chain fallback with the fee and timing shown before the player commits. All of it inside the cashier, none of it via support.

Disqualify: the player sees "payment failed" and is invited to contact support. That's not a payment flow, that's a churn mechanism. Ask what percentage of Lightning attempts end in on-chain fallback. If they don't know, they aren't measuring the thing that costs you deposits.

8. Do you run your own nodes, or rent capacity?

Pass: a clear answer with detail. Their own nodes, the implementation (LND, Core Lightning), who holds the keys, their channel policy, peer selection, and, if they lease inbound capacity from a liquidity provider, who that provider is and what happens if that provider deprioritises them during congestion.

Disqualify: "we work with a Lightning partner" and an inability to say whose nodes hold the channels your deposits route through. That's a wrapper, and every Lightning number they've quoted you belongs to somebody else.

Routing failure on Lightning has a nasty property, which brings us to the next block.

Custody and treasury control: who actually holds your money?

This block matters more than every feature discussion combined. A crypto payment gateway white label deal that gets custody wrong hands you counterparty risk you cannot hedge, cannot insure and cannot exit quickly.

9. Where do player deposits sit between confirmation and my settlement?

Pass: a named, specific answer. Deposits land in a wallet you control, or in a segregated account with a named regulated custodian, with a settlement instruction you trigger. They can show you the address or account structure on screen, on the call, without preparation.

Disqualify: "in our secure infrastructure." That's an omnibus wallet. Your float is commingled with other merchants' balances, and in an insolvency it's a claim, not an asset. You'd be queueing behind an administrator with other people's gambling revenue mixed into the same pot.

Follow-up: are you custodial, non-custodial or hybrid, and which parts are which?

Pass: an unambiguous split, leg by leg. For example: deposits non-custodial and swept to your treasury, payout float in a wallet you co-control, fiat conversion routed to a third-party regulated venue.

Disqualify: the word "hybrid" with no breakdown. In practice, hybrid usually means custodial with a non-custodial marketing line.

10. What's your sweep policy, and can I set it?

Pass: configurable sweeps. By threshold, by schedule, or instant per transaction, with a destination address you set and can change yourself without a support ticket.

Disqualify: sweeps on the vendor's schedule, to an address only they can change. That's a liquidity chokepoint dressed up as a feature.

Follow-up: if you entered administration on a Friday, what happens to my balance over the weekend?

Pass: a mechanical answer. Keys you hold. A bankruptcy-remote custodian structure. A documented recovery process. Ideally a clause number in the MSA that their lawyer can point to.

Disqualify: reassurance about how well-funded they are. You asked a mechanical question and got a sentiment. Note which one you were given, because it tends to predict the rest of the relationship.

Uptime, slas and what actually happens at 02:00 on a sunday

Every vendor has a support page. Few are ready when things break.

11. Who is reachable within 15 minutes at 02:00 on a Sunday, and what is their name?

Pass: named humans, an on-call rota you're shown, mobile numbers or a paging channel, and an engineer on call who has authority over treasury, not just over dashboards. A 15-minute acknowledgement window written into the contract with credits attached if it's missed.

Then test it. Ring the number at 02:00 on a Sunday during diligence. Genuinely. It's the cheapest piece of due diligence available to you and it's astonishingly informative.

Disqualify: "24/7 support" that turns out to mean a shared inbox and a Telegram group monitored between 09:00 and 18:00 CET. Ask who was on call last Sunday. If nobody can name a person, nobody was.

Follow-up: what's your incident history for the last 12 months, and what does the SLA actually credit?

Pass: an incident log with dates, durations, root causes and remediation, plus service credits that bite. Credits banded against uptime targets, applied automatically, not on request.

Disqualify: "no incidents." Everyone has incidents. A vendor claiming a clean 12 months either has no monitoring or isn't being straight with you, and both are worse than a bad month they can explain.

12. When withdrawals start queueing, what exactly is the escalation path?

This is the specific failure that ends operator relationships, so ask it specifically. Not "how do you handle incidents." How do you handle queued withdrawals.

Pass: a written path with names against each step. Who declares the incident. Who authorises an out-of-hours float top-up and up to what ceiling without waking a director. How you're notified and how often. A target time to clear the backlog, and what happens to it if that target slips.

Disqualify: "we'd look into it straight away." That sentence has never cleared a payout queue. Also treat as a red flag any vendor whose escalation path routes through your account manager, because account managers cannot move money at 3am.

Follow-up: what happens when your compliance team blocks a withdrawal my compliance team has already approved?

Pass: a documented conflict-resolution path with named contacts and a time-bound SLA.

Disqualify: silence, or "that doesn't happen." It happens constantly, and the resolution latency lands squarely on your player experience while your team explains a hold they didn't place.

Vague SLA answer vs verifiable SLA answer

Keep this next to you on the call. When you hear the left column, ask for the right.

If a vendor won't put the right-hand column in the MSA, the left-hand column is the product.

Routing, reliability and success-rate evidence

Every vendor quotes a success rate. Almost none define it. Your job is to find the denominator.

13. How do you define routing success rate, and what's excluded from the calculation?

Pass: a definition you can audit. Completed deposits divided by initiated deposit sessions, including abandoned sessions, underpayments and wrong-network sends, segmented per corridor.

Disqualify: anything above 99% with no definition attached. Those figures almost always exclude user-abandoned sessions, wrong-network sends and underpayments, which are precisely the failures your support team absorbs at 30 minutes a ticket.

Here's the part operators miss. Routing failure rarely shows up in error logs, because from the gateway's perspective nothing failed. An invoice was generated. No payment arrived. Session expired. Clean logs, no alert, no incident.

What actually happened is that a player in São Paulo tried three times, watched a spinner, and went to a competitor. That's deposit abandonment, and it lives in your funnel analytics, not the vendor's error dashboard.

Which is why the only honest measure starts at initiated session, not at invoice paid. Ask for the abandonment curve by corridor. If they can't produce one, they cannot see the failure mode that costs you the most money.

14. Show me success rate by corridor and by asset for my top three markets, last 90 days.

Pass: segmented data, even where it looks bad. Honest segmentation is one of the strongest buy signals in this entire process. A vendor who says "Brazil PIX-to-crypto sits at 91% and here's what we're doing about it" is worth more than one quoting a flawless blended figure.

Disqualify: a global blended number and nothing else. A blended 98% can conceal a 76% LatAm corridor that will dominate your ticket volume by Q2.

Follow-up: do you have automatic failover across nodes and networks, and has it ever actually fired?

Pass: yes, with a date and a description of the last real failover event, including what players experienced during it.

Disqualify: "we have redundancy." Untested redundancy is architecture, not resilience. Ask when they last ran a deliberate failover drill. "Never" is an answer.

Compliance, licensing and AML ownership

Don't let this turn into a philosophy seminar. You're establishing one thing: who is contractually answerable when a regulator or an acquiring bank asks a hard question.

15. Which jurisdictions do you restrict or block, and how would I find out before my players do?

The quiet killer. Vendors apply geo rules, sanctions screening, IP filtering and asset-level restrictions that silently drop traffic from markets you're properly licensed in. Nobody tells you. Deposit volume from one country just... tapers. Your data team spends three weeks blaming the cashier redesign.

Pass: a written list of blocked and restricted jurisdictions, plus asset-level restrictions, plus a contractual commitment to give you 30 days' notice before adding to it. Ideally a dashboard view showing rejected attempts by country and reason code, so a policy change surfaces as data rather than as a mystery.

Disqualify: "we're global." Nobody is global. Ask them to name the last three countries they added to the list and why. The answer tells you whether they made the decision or their upstream provider made it for them.

16. Which entity is the regulated party here, and under which licence or registration?

Pass: a named legal entity, its jurisdiction, a licence or VASP registration number, and a certificate in your inbox the same day.

Disqualify: a group brand name with no legal entity behind it, or a licence in a jurisdiction with no bearing on the flows you're processing. A Lithuanian registration does not cover a Curaçao-facing payout corridor just because both words appear in the same deck.

17. Who performs transaction screening, and who owns the SAR and escalation decision?

Pass: a clear allocation. They screen using a named analytics provider, you retain the player-level decision, escalation paths written into the MSA with response windows.

Disqualify: any answer implying they take care of all of it. Nobody has ever successfully outsourced their own AML liability, and a vendor suggesting otherwise has not been through a serious examination.

Nail down who actually owns compliance, licensing and AML in the deal before you countersign, because that's the clause that resurfaces during your next licence renewal, usually at the worst possible moment.

Multi-brand architecture and subaccount hierarchy

Any group running more than one brand, or planning to inside 18 months, needs this settled before integration scope is fixed. Retrofitting brand separation is a six-month project nobody budgets for.

18. How deep is the subaccount hierarchy, and can each brand have isolated ledgers, limits and reporting?

Pass: a structural answer. Parent group, brand, sub-brand, with per-node fee schedules, limits, wallets and exportable reporting at every level. Ask them to draw it.

Disqualify: one merchant account plus a tagging system. Tags don't survive an audit, and they certainly don't survive a brand divestment where a buyer's due diligence team wants 24 months of isolated transaction history.

Follow-up: can I onboard new brands or sub-merchants myself, and how long until they're taking live traffic?

Pass: self-serve provisioning through the PSP API with a stated time to live traffic measured in hours.

Disqualify: every new brand needs a vendor ticket and a fresh commercial negotiation. That's a growth tax, and it compounds. If your model involves reselling the gateway to your own brands or sub-merchants, get the commercial and technical permissions in writing now, not in the renewal.

Follow-up: does your PAM/PSP API support per-brand webhooks, idempotency keys and reconciliation exports?

Pass: yes, with documentation you can hand to your platform CTO before the call ends.

Disqualify: a single global webhook endpoint. Your finance team will be reverse-engineering brand attribution out of raw transaction logs by month three, and they will not forget who signed that contract.

Commercial terms and exit

The questions vendors least enjoy. Also the ones that decide your position after go-live.

19. What's the notice period, and what exactly do I take with me?

Pass: a defined notice window, a full transaction-history export in a documented format, and, critically, the ability to migrate or retain deposit wallet addresses so returning players' saved addresses keep working.

Disqualify: 12-month lock-ins, exit fees indexed to volume, or "historical data remains our property." Address portability is the sleeper issue in this entire article. Lose it and every returning player has to re-onboard, which means a support spike, a deposit dip and a churn cohort you'll be explaining in a board deck.

20. Is there a volume commitment, exclusivity, an auto-renewal, or a restriction on running a second gateway in parallel?

Pass: no exclusivity, explicit permission to route a defined percentage of volume elsewhere, and a renewal that requires an active decision from you.

Disqualify: exclusivity clauses. A gateway that forbids a backup is protecting its revenue, not your uptime.

And strike the auto-renewal. Everyone redlines lock-in and volume covenants, then leaves in a clause that silently rolls the contract for another 12 months unless you cancel 90 days before the anniversary.

Diarise it and someone still misses it, because the person who diarised it left in March. Either replace it with a rolling monthly term after the initial period, or cut the notice window to 30 days.

This is the single cheapest amendment in the whole MSA and the one most often skipped.

What should instantly disqualify a provider?

Some answers end the conversation. Keep this table beside you on vendor calls.

Worth naming the pattern: the disqualifiers cluster in custody, routing ownership and exit. Not features.

Feature gaps are negotiable and often genuinely get built. Custody structure and contractual lock-in are baked in at signature, and you live with both for the full term, through a volume ramp nobody modelled correctly. Trade a missing feature. Never trade custody.

That "we'll build that for you" line deserves particular suspicion. When a vendor commits to building your requirement, ask for three things: a delivery date in the contract, an acceptance test you define, and a termination right if the date slips by 60 days. If all three are refused, the feature does not exist and never will.

If you want a working benchmark for how these answers should sound, see how LightningPay answers these questions and use it to calibrate the rest of your shortlist.

How does instant Lightning settlement change the custody question?

Two of the questions above generate the vaguest answers in the entire script: where does my payout float sit, and how quickly can I move it.

That isn't coincidence. In a pooled-custody model those questions genuinely have no precise answer.

Your balance is a ledger entry inside a vendor-controlled omnibus wallet, and your withdrawal speed depends on their treasury operations rather than your instruction. The vendor isn't necessarily dodging. They may simply not be able to answer.

LightningPay's architecture removes the ambiguity instead of reassuring you about it. Deposits settle over the Lightning Network in seconds, and operator funds are never pooled into a vendor-held omnibus wallet. Treasury control stays non-custodial, on your side.

For a Head of Payments the practical consequence is that both questions stop being trust exercises. You observe settlement latency yourself rather than accepting a quoted median.

You confirm where float sits by looking at a wallet you control, and you move it without raising a ticket and waiting for European business hours.

Which matters most at the exact moment vagueness costs money. The vendors who can't answer custody and latency questions precisely on a Tuesday sales call are the same vendors who strand payout float on a peak Saturday. The imprecision in the pitch reflects real imprecision in the plumbing.

How should you run this question set across a shortlist?

Send all 20 questions in writing to every vendor before the call. Then run the call live and score the gap between what they wrote and what they say out loud. That gap is diagnostic on its own, and it's usually widest on liquidity sourcing and custody.

Score each answer three ways: specific number, vague directional claim, or non-answer. More than two non-answers in the custody, liquidity or exit blocks and the vendor comes off the list regardless of pricing.

Especially regardless of pricing. Cheap gateways with pooled custody are the most expensive product in this market and the invoice arrives all at once.

Demand one live artefact per block. A dashboard screen-share for latency including p99. A corridor-level success-rate export. A sample subaccount tree. The on-call rota.

A redlined MSA clause on exit. Vendors who produce artefacts inside 48 hours have functioning operations behind the deck. Vendors who send a follow-up PDF instead have a marketing department.

And don't build the shortlist off a published white label crypto payment gateway providers list without running this script over it. Those directories rank marketing spend. They do not measure settlement latency, custody structure or whose nodes your Lightning deposits actually route through.

Once you've scored everyone, talk to the LightningPay team and put the same 20 questions to us, with the same scoring, in the same order.

Final thoughts

Vetting has very little to do with the technology on day one.

It's about month 18. Volume has tripled. Your original account manager left for a competitor. There's a payout backlog building on a Sunday morning and you need someone senior with treasury authority to pick up the phone. That's the scenario every one of these 20 questions is really probing.

It's also why the disqualifiers sit around custody, routing ownership and exit rather than features. Features get built. Structural counterparty risk and contractual lock-in only get heavier as you scale, and the moment you most need to leave is the moment leaving is hardest.

The most useful by-product of running this script is that the answers become your operating SLA. Latency percentiles including p99. Corridor success rates. Lightning fallback rates. Float location.

Escalation windows and the names attached to them. Everything you extract in diligence is exactly what you should be measuring monthly afterwards, in a report your payments lead reviews and your CFO occasionally reads.

Operators who never write those numbers down have nothing to renegotiate with and no evidence when they finally need it. They walk into the renewal with a feeling and walk out with the same contract.

Treat the question set as page one of the contract. Not the last step before it.