Reselling a White-Label Crypto Payment Gateway

Short answer: yes for your own brands, probably not for anyone else's.

Operators can usually extend a white label crypto payment gateway across brands they own under a single group agreement. Reselling to third-party merchants is a different animal. That path drags in PSP-of-record status and licensing obligations that most gaming licenses and provider contracts simply do not cover unless a specific reseller or referral agreement is signed first.

Who this is for: multi-brand casino groups running several skins, turnkey platform providers with downstream licensees, and aggregators who want a payments revenue line without becoming a payments company.

Why are multi-brand operators asking about this at all?

Because crypto deposit volume has stopped being marginal.

Run six skins with 30% of deposit value arriving on-chain and the payment layer stops being a cost centre you tolerate. It becomes a line item with a spread attached, and that spread belongs to someone. If it all sits with your provider, you are leaving basis points on the table. If part of it sits with you, it is group margin.

Platform providers feel this more sharply. A turnkey supplier running 40 downstream operators is already the commercial counterparty for game content, back office and hosting. Payments is the obvious adjacent line. Crypto is the easiest place to start, because the rails cost less and the settlement flow is far more transparent than card acquiring.

The margin exists. The real question is which structure lets you take it without picking up obligations you cannot service.

What is the difference between extending a gateway and reselling one?

This distinction decides everything else, so let's be blunt about it.

Extending means one gateway agreement covering multiple brands under common ownership and control. Your group remains the single contracting party. Each skin gets its own configuration, wallets and reporting. The legal relationship with the provider does not multiply. You are not selling anything to anyone.

Reselling means inserting yourself between the provider and a third-party merchant, an operator you do not own, and taking commercial responsibility for that relationship. You set their pricing. You may hold their funds. You may be the entity they contract with.

The moment you hold or direct someone else's settlement funds, you look like a payment intermediary. That is regulated activity in most jurisdictions, and no Curaçao, Malta, Isle of Man or Anjouan gaming licence covers it. Your gaming licence lets you operate games of chance. It does not let you process payments for other businesses.

Most operators asking "can we resell?" actually want reselling economics with extending obligations. That is achievable. Just not through a true reseller structure. Referral and platform-embedded models get you there.

What models are available for a crypto payment gateway white label across brands?

Everything meaningful about these models lives in the prose below, not the grid.

Multi-brand group account

One agreement, several skins. Each brand receives its own wallet set, its own deposit addresses and its own reporting line. The provider contracts with your group entity.

No resale margin here, because no third party is paying you. What you get is aggregated volume, and aggregated volume is how you negotiate tiering. A group pushing $40m in monthly crypto deposit value across eight brands prices very differently from eight standalone operators pushing $5m each.

This is the default and the cleanest starting point. If your brands sit under genuine common ownership, your provider will offer this without friction. A well-structured multi-brand crypto payment gateway setup should give you per-skin segregation inside a single integration.

Sub-merchant hierarchy

The provider onboards each downstream brand as a distinct sub-merchant. You sit above them in the reporting tree with visibility and some commercial control.

The provider still contracts with each sub-merchant and still runs compliance on them. You are not the PSP of record. But your agreement may let you apply a markup on top of provider pricing for the brands in your tree, or take a share of provider revenue from those brands.

This is the model that looks most like reselling while keeping licensing where it belongs. It only works if the provider genuinely supports hierarchical merchant structures. Many do not. Others support them as a reporting overlay with no independent settlement per node, which is not the same thing at all. Ask specifically.

Referral or introducer

You introduce operators to the provider. The provider contracts with them directly. You take a commission on volume or revenue.

Zero licensing exposure. Zero settlement responsibility. Zero reconciliation burden. Also the least control: you do not set pricing, you do not own the relationship, and if the provider underdelivers you eat the reputational cost with no contractual leverage.

For affiliate networks and smaller platforms this is frequently the right answer. It converts a relationship you already have into recurring revenue without building anything.

Full reseller or psp-of-record

You become merchant of record for downstream operators. You contract with them, you price them, and funds may flow through entities you control.

That is a payments business. Expect registration or licensing in the relevant jurisdictions, an AML programme covering your sub-merchants, capital adequacy in some regimes, and a provider contract that explicitly permits resale.

Very few gaming operators should go here. The ones that do usually build a separate, separately-capitalised payments entity rather than bolting it onto the operating company. Treat it as a strategic decision with a legal budget attached. Not a payments configuration choice.

Platform-embedded gateway

The gateway is built into your turnkey platform. Downstream operators activate it as a module. The provider handles their onboarding and settlement. Your platform agreement includes a revenue share on payment volume.

Commercially this is the most attractive structure for B2B suppliers, because payments become a default rather than a decision. Operators launching on your platform get crypto deposits switched on at go-live, and you earn on volume you never had to sell separately.

It works when the provider's white label crypto payment gateway software supports true multi-tenancy: independent wallets, independent reporting, independent settlement per tenant, all under your branding.

How do sub-merchant hierarchies actually work across multiple skins?

Picture a tree rather than a list.

At the top sits a parent account, usually your group entity or platform company. Beneath it, each brand is a child node with its own merchant profile. That profile carries its own wallet set, its own API credentials, its own deposit page configuration and, critically, its own ledger. Skin A's deposits never touch Skin B's balance sheet.

The separate-ledger point is where most implementations fall over. Plenty of gateways offer "multiple accounts" that are really one settlement pool with a brand tag stapled to each transaction. That works fine until a downstream partner asks to see their own reconciliation, or until you need to freeze one brand's payouts without touching the other five. Tags do not survive that test. Separate ledgers do.

A properly built hierarchy gives you:

• A parent view aggregating volume, fees and balances across every child brand.

• Child accounts that operate independently, each with its own deposit addresses, settlement schedule and transaction history.

• Inheritance rules so group-level settings (chain support, risk thresholds, KYC triggers) cascade down while brand-level overrides stay possible.

• Node-level controls so you can suspend, throttle or reprice one brand without a group-wide change.

When you evaluate this, ask to see the parent dashboard and a child dashboard side by side in a live demo. If the child view is really the parent view with a filter applied, you will find out on day one of month-end rather than three months in.

How much can each brand look like its own business?

More than most operators expect, and this is where white-labelling earns its keep.

Separate domains. Each skin should transact on its own domain or subdomain: pay.brandone.com, checkout.brandtwo.io. Players never see a shared payments host, and your brands never look like siblings to anyone poking at DNS.

Separate deposit pages. Logo, colour palette, typography, supported chains, minimum amounts, copy tone. Skin A might push USDT on Tron and lead with a low minimum for a value-conscious market. Skin B might front Bitcoin and Lightning for a high-roller audience. Same gateway, two different front doors.

Email and receipt identity per skin. Deposit confirmations, payout notifications and receipts should send from the brand's own domain with the brand's own sender name and template. Nothing breaks the illusion faster than a confirmation email from noreply@yourplatform.com landing in a player's inbox after they deposited on a completely different brand.

Support-facing artefacts. Transaction reference formats, PDF receipts, chargeback or dispute correspondence. All of it should carry brand identity, not group identity.

For platform providers the stakes are higher again. Your downstream operators are your customers. If your gateway shows your supplier's logo in the operator back office, you have just introduced your customer to the company you buy from. Confirm that branding extends to the operator-facing interface and reports, not just the player-facing checkout.

Who inside each brand should see what?

Role-based access is not a nice-to-have once you pass two or three skins. It is the thing that stops a commercial argument becoming a data breach.

The model that works:

• Brand-level users see only their own skin. Their transactions, their balances, their settlement history, their disputes. Nothing from a sibling brand appears anywhere in their view.

• Group finance sees everything, aggregated and per-brand, plus fee attribution.

• Group technical sees configuration and logs across nodes, but not necessarily balances.

• Downstream operator users (in platform models) see their own account only, with your branding, and no visibility into your cost from the provider.

That last line matters commercially. If a downstream operator can see provider-level pricing inside the interface, your markup is visible and your margin conversation is over. Ask providers directly whether cost and price are separable in the UI, and whether permission sets are configurable per node or fixed by their template.

Also worth checking: audit logs. When a brand team disputes a settlement figure, you want a record of who changed which setting and when. Providers that skip audit trails will cost you a week of email archaeology at some point.

Consolidated group treasury versus per-skin settlement

These two needs pull in opposite directions, and the resolution is not "pick one."

Group treasury wants one number. How much crypto does the group hold right now, across every chain and every brand, and what is it worth? Without that, hedging decisions and liquidity planning turn into a spreadsheet-merging ritual every Monday morning.

Each skin wants independence. Its own settlement schedule, its own payout wallets, its own bank or exchange relationships, its own ledger that reconciles cleanly to its own accounts.

The right architecture gives you both: per-skin settlement with a consolidated read-only treasury view. Funds settle to brand-controlled wallets on brand-specific schedules. A group dashboard reads across all of them for reporting and risk. Money moves at the brand level. Visibility aggregates at the group level.

What to avoid: a group sweep wallet that pools everything before redistributing. It gives you the consolidated number, sure, and it also creates a commingled float you now have to allocate, plus a serious argument about whether you are holding third-party funds. Convenience at the front, regulatory exposure at the back.

Non-custodial structures and why they close the licensing question

Here is the cleanest structural answer to the funds-handling problem: do not handle the funds.

A non-custodial setup gives each brand its own operator-controlled wallets. Keys, or key shares, sit with that brand. Deposits land directly in the brand's wallet. The gateway generates addresses, monitors chains, credits player accounts and produces reporting, but never takes possession of the money.

Two things follow from that, and both are useful.

Licensing. If funds never sit in an entity you control, the "are you handling third-party money?" question largely resolves itself. You are providing technology and reporting, not payment intermediation. That distinction does most of the heavy lifting in a regulatory conversation.

Counterparty risk. No provider float means no provider insolvency exposure, no freeze risk on someone else's compliance decision, and no waiting on a settlement cycle to access your own liquidity. Anyone who watched a payments provider fail while holding operator balances understands why this matters.

The trade-off is real: your brands own key management, which means hardware security modules or MPC, documented recovery procedures, and someone whose actual job includes signing policy. That is genuine operational work. Weighed against custodial float risk plus the intermediary question, most multi-brand groups take the trade.

How does the economics actually work across brands?

The illustrative figures below are examples for modelling only. They are not LightningPay pricing.

Say your group processes $20m in monthly crypto deposit value across five skins. Negotiated all-in cost sits around 0.6%. You present an internal cost of 0.9% to each brand's P&L. The group captures roughly 0.3%, about $60,000 monthly, $720,000 annualised. A real number, produced entirely by structure.

Platform providers run on revenue share instead. Take 30 downstream operators averaging $800,000 in monthly crypto deposits, so $24m aggregate. A 20 basis point share is roughly $48,000 monthly. Not transformative alone. But it recurs, it grows with your operators, and it costs almost nothing to service once integration is done.

Where the margin actually comes from

"Spread" is a lazy summary. Break it out, because each source carries a different defensibility and a different amount of work.

FX and conversion spread. The gap between the rate at which crypto converts to fiat or stablecoin and the rate you pass through to the brand. On a $20m book, a few basis points here compounds fast. It is also the source downstream partners scrutinise hardest, since they can check spot rates themselves. Price it honestly or price it elsewhere.

Settlement handling. On-chain fees, batching efficiency, chain selection, payout timing. A group that batches payouts intelligently and routes through cheaper chains where the player mix allows genuinely lowers cost per settlement. Keeping part of that saving is defensible margin, because you created it.

The support layer. This is the most underrated line. When a player's deposit does not credit, someone reads the block explorer, identifies the wrong-network transfer, and resolves it. For platform providers, that someone is you rather than the provider. Downstream operators pay for that layer willingly, because the alternative is building a crypto-literate support team themselves. Price it explicitly. Do not bury it in FX.

Integration and onboarding. One-off, but real. Adding a new brand to an existing hierarchy is work you have already paid for once. Charging for it is fair. Charging six weeks of professional services for a config change that takes two hours is not, and downstream partners find out.

Three things constrain all of this in practice.

Volume beats spread. A wide markup on thin volume loses to a thin markup on real volume every single time. Do not price downstream partners off the rails you want them using.

Reconciliation cost is real. Take margin and you take responsibility for explaining it. Monthly arguments about whose deposits generated which fees will consume the margin in staff time faster than you expect. It is a reporting-architecture problem, and it is solvable, but only if you solve it before signing partners.

Your provider's contract sets the ceiling. Some agreements flatly prohibit onward markup. Some permit it only within owned brands. Read the resale and assignment clauses before building a commercial model on top of them.

If you are sizing a multi-skin or platform structure, model it against a provider's actual capabilities rather than in the abstract. Discuss a multi-skin structure with LightningPay before you commit to pricing downstream.

Which model fits you: 6-skin casino group or 30-licensee turnkey platform?

The economics look similar on a spreadsheet. The right structure is not the same.

A six-skin casino group under common ownership should run a multi-brand group account with sub-merchant hierarchy underneath. Every brand belongs to you, so there is no third-party funds question and no resale clause to negotiate around.

Your priorities are aggregated volume for tiering, separate ledgers per skin so brand P&Ls stand up, consolidated treasury visibility for group finance, and internal transfer pricing that survives an audit.

Do not overbuild. You do not need a reseller agreement, a payments licence or a separate entity. You need one contract, six clean nodes and defensible internal cost allocation.

The trap for this group is the opposite of over-engineering: treating six skins as one merchant because it is faster to launch. Eighteen months later, one brand gets sold or moves to a different licence, and you are unpicking a shared wallet history transaction by transaction.

A turnkey platform with 30 licensees is in a genuinely different position. Those operators are not yours. Funds must not flow through you.

Your structure is platform-embedded, with the provider onboarding and contracting each licensee directly, and your revenue arriving as a share on payment volume plus explicit fees for the support layer you actually deliver.

Priorities: true multi-tenancy, full white-label branding down to the operator back office, role-based access so licensee A never glimpses licensee B, and per-tenant reporting your licensees can audit without your help.

The trap here is drifting into PSP-of-record by accident. It usually happens gradually. You start holding a small float "for convenience." You net fees before passing settlement through.

You become the entity a licensee chases when a payout is late. None of those steps feels like a licensing decision at the time. Together they are one. Draw the line at the contract stage and hold it.

If you are both — a group that owns some brands and licenses its platform to others — run two structures side by side. Owned brands go in the group hierarchy.

Third-party licensees go through platform-embedded terms with the provider contracting directly. Mixing them into one commercial arrangement is how operators end up with a reseller obligation they never intended to accept.

What licensing and settlement constraints decide which model you can use?

Three questions determine your options.

Do you own and control the brands? If yes, extending is straightforward. If no, you are dealing with third parties and everything tightens.

Do funds pass through an entity you control? If settlement flows from player to provider to each brand directly, you are a facilitator. If it flows through you first, you are handling third-party funds, and that is where licensing obligations start.

What does your gaming licence say about ancillary activity? Most gaming licences are narrow. Payment intermediation is rarely in scope, and some regulators treat unauthorised adjacent activity as a licence condition breach rather than a separate offence. The downside is asymmetric.

Then there is the jurisdictional layer. A structure that raises no eyebrows in one licensing regime may require registration in another, and crypto-specific rules keep moving. VASP registration in particular is shifting across most major frameworks right now.

This varies enough that no article should hand you a definitive answer. Take advice on your specific entity structure and target markets.

Practical takeaway: keep settlement direct from provider to brand wherever you can. It preserves your margin models while keeping the funds-handling question shut.

How does month-end settlement and reconciliation actually run?

This is the section operators skip and then regret. Margin you cannot explain is margin you will renegotiate away.

The month-end process

A workable cycle looks like this:

1. Cut-off. Fix a timestamp, in a named timezone, applied identically across every brand. On-chain deposits do not respect calendar months, so decide explicitly whether a transaction belongs to the period by broadcast time or by confirmation time. Write it into the contract. Then never change it.

2. Per-brand extraction. Pull the transaction ledger for each node: deposits, payouts, on-chain fees, conversion rates applied, timestamps, transaction hashes.

3. On-chain verification. Spot-check a sample against block explorers. Every line should tie to a hash. If a figure in the gateway report has no on-chain counterpart, find out why before it becomes a dispute.

4. Fee attribution. Apply provider cost, then your markup, per brand. Keep the two figures separate in your own records even if the downstream invoice shows one blended rate.

5. Group consolidation. Roll up brand ledgers into the treasury view. Reconcile totals against wallet balances at cut-off. Any variance gets chased now, not in March.

6. Invoice generation. Issue downstream, with the supporting detail attached.

7. Sign-off. One named person per brand approves. One named person at group approves the consolidation. Unapproved months are how small variances turn into unfixable ones.

Give yourself five business days. Groups running per-brand wallets with clean reporting often close in two. Groups running a shared pool with tag-based allocation routinely take three weeks and finish with an argument.

Invoicing downstream brands

For owned brands this is an intercompany journal, not a real invoice, but it still needs documentation that stands up to a tax inspector.

For third-party licensees, an invoice needs to show:

• Gross crypto deposit value in the period, by chain.

• Transaction count.

• Fee rate applied and the basis for it (percentage of deposit value, per-transaction, tiered).

• Any separately-priced services: support layer, integration work, priority settlement.

• Total due, with the reference period and cut-off timestamps stated.

• A pointer to the underlying transaction detail the licensee can pull themselves.

That last item is the one that saves you. If the licensee can log in and reproduce your number from their own dashboard, most disputes never get raised. If your invoice is a total they cannot verify, expect a query every month forever.

Dispute handling workflow

Disputes will happen. Build the path before you need it.

Tier 1: self-service. The licensee checks their own per-brand report and their own on-chain history. A material share of "your invoice is wrong" queries dissolve here, usually because a transaction landed either side of cut-off.

Tier 2: joint review. Both sides compare ledgers on the specific transactions in question. Agree a response window in the contract, five business days is reasonable, and stick to it. Nothing sours a partnership faster than a fee query sitting unanswered for a month.

Tier 3: escalation to the provider. If the discrepancy sits in the gateway's own data, such as a conversion rate applied at a timestamp neither party can reproduce, raise it with the provider. Confirm in advance that your contract entitles you to that support in a defined window. If it does not, you are the one absorbing the delay while your licensee waits.

Tier 4: contractual remedy. Set out in the agreement what happens if a discrepancy cannot be resolved: credit note, adjustment in the following period, withheld payment thresholds, and any dispute resolution forum. Boring to draft. Invaluable once.

Log everything. A dispute register showing what was raised, when it was resolved and what the root cause was will reveal a systemic reporting flaw far earlier than any individual complaint does.

What should you flag to your finance and tax team?

Not tax advice. This is a list of things your CFO will want to know about before, not after, you sign.

Transfer pricing. Charging your own skins above your negotiated cost creates an intercompany transaction.

Where those entities sit in different jurisdictions, tax authorities expect the pricing to be defensible, meaning documented, benchmarked and arm's length. "We picked 0.9% because it looked reasonable" is not a transfer pricing policy.

A short memo explaining the rate build-up (provider cost plus support layer plus treasury function plus integration amortisation) is.

VAT and indirect tax on the fee. The payments margin may be a taxable supply of services depending on the jurisdictions on both sides. Cross-border B2B services often reverse-charge, but not always, and gaming-specific exemptions muddy it further.

Get the treatment confirmed before you issue the first invoice, because unwinding a year of incorrectly-treated intercompany fees is genuinely painful.

Crypto asset accounting. How does each brand carry crypto balances between deposit and conversion? Intangible asset, financial instrument, inventory?

Treatment drives whether unrealised gains hit P&L or reserves, and it varies by reporting framework. Where you also run a group treasury function, you need a policy for gains and losses arising in the window between brand receipt and group-level hedging.

Withholding tax on revenue share. Some jurisdictions apply withholding on service fees or royalties paid cross-border. If you are collecting a revenue share from licensees in multiple countries, check whether treaty relief applies and what documentation you need to claim it.

Permanent establishment risk. Running a payments-adjacent function for downstream operators in a jurisdiction where you have no presence can, in some regimes, create a taxable nexus. Low probability, high consequence. Ask.

Audit trail requirements. Your auditors will want to trace group revenue to on-chain transactions. Confirm your gateway retains transaction-level data for the full statutory retention period in every relevant jurisdiction, and that you can export it in a form the auditors accept.

Some providers purge detail after 12 or 24 months. That is a problem you want to discover now.

What makes lightningpay's per-brand architecture suited to multi-brand and reseller structures?

LightningPay is multi-chain with per-brand wallet architecture. Each skin gets its own operator-controlled wallets and its own reporting, all under a single integration.

For multi-brand and platform structures, three things matter concretely.

Settlement segregation per brand. Each skin's deposits land in wallets attributed to that skin. No shared pool to divide after the fact. Brand-level treasury stays brand-level from the moment funds arrive.

No commingled float to unwind. If deposits from eight skins land in one wallet, month-end becomes forensic accounting, and every downstream partner has to trust your arithmetic. Per-brand wallets remove the problem instead of reporting around it.

Per-skin reconciliation your partners can audit. Apply a markup or run a revenue share and your downstream operators will eventually ask to see the underlying volume.

Per-skin transaction reporting lets you show them their own numbers directly, rather than handing over a derived spreadsheet they have to accept on faith. That is the difference between a payments margin line that survives contract renewal and one that becomes a recurring argument.

One integration. Independent wallets and reporting per brand. Precisely the shape a multi-brand group or platform provider needs.

Adding a new skin without a new integration

Worth spelling out, because it is the operational payoff of getting the architecture right.

A group runs four live skins. Commercial signs a deal for a fifth, targeting a Latin American market, launching in three weeks. Under a single-merchant setup, that means a fresh gateway application, fresh compliance review, fresh API credentials, fresh integration work by a dev team already booked solid, and a go-live date that slips past the marketing campaign.

Under a proper hierarchy it looks like this instead. Group finance requests a new child node under the existing parent account. The provider runs its brand-level checks against documentation already on file for the group.

The new node is provisioned with its own wallet set and its own ledger, inheriting group-level chain configuration and risk thresholds. The brand team configures its own deposit page: logo, colours, USDT on Tron and Polygon first given the target market, minimums set in local terms. Email templates point at the new brand domain.

Access permissions are set so the new brand's three-person finance team sees that node and nothing else. Existing API integration is untouched, since the platform already speaks to the gateway and the new brand is a parameter in existing calls, not a new endpoint.

Elapsed time: days, not weeks. Developer hours: close to zero. That difference is why platform providers can promise crypto deposits at go-live rather than "in the second phase."

How should you shortlist providers that support sub-merchant structures?

Start by narrowing any white label crypto payment gateway providers list to those that genuinely support hierarchy, not just multiple accounts.

Ask these directly:

• Can each brand have independent wallets and independent settlement, or is it one pool with tagging?

• Does reporting break down by brand natively, or does your team build it from raw transaction exports?

• Are ledgers genuinely separate per skin, with balances that reconcile independently?

• Does the contract permit onward markup or revenue share, and in which models?

• Who performs onboarding and compliance on downstream brands, you or the provider?

• Can permissions be scoped per node so brand teams see only their own data?

• Is your cost from the provider hidden from downstream operators in the interface?

• Does branding extend to separate domains, deposit pages and email or receipt identity per skin?

• How are new skins added, and how long does it take?

• Can the interface carry your branding for downstream operators?

• Is the structure custodial or non-custodial, and where do keys sit?

• How long is transaction-level data retained, and in what export formats?

The last few matter more than they sound. If adding a skin takes six weeks, your platform cannot promise crypto at go-live. If the gateway shows the provider's brand to your downstream operators, you have just introduced them to your supplier.

Next step: before you shortlist anyone, work through a structured set of vendor due-diligence questions covering settlement architecture, contract terms, compliance ownership and technical integration. Take those answers in writing. Verbal assurances about multi-tenancy have a habit of becoming "on the roadmap" once implementation starts.

Final thoughts

Extending a crypto gateway across brands you own is largely an infrastructure and reporting decision. The constraints are technical and contractual. The upside is negotiated volume plus a defensible internal margin.

Reselling to third parties is a regulatory decision. Treat it with the seriousness that implies, not as a configuration setting.

The models that survive several years are the ones where settlement and licensing lines stay unambiguous per brand. Nobody has to reconstruct who owed what. No regulator has to interpret whose activity was whose. And when a brand gets sold, or moves licence, or a licensee walks, you unwind one node instead of untangling a shared history.

Judge providers on the depth of their sub-merchant reporting as hard as you judge them on rails and chain coverage. Reporting is what makes the commercial model auditable, and an unauditable margin is a margin you will renegotiate away.

See what LightningPay supports for platform providers if you are structuring a multi-brand or downstream offering around a white label crypto payment gateway.