Platform Provider vs Game Aggregator: Who Owns What

An online casino stack has four vendor layers: platform/PAM, game aggregator, payment provider, and treasury/wallet. The platform owns the player ledger and cashier logic.

The payment provider owns deposit and withdrawal rails. The treasury layer owns settlement and FX. The game aggregator owns content and never touches player money.

What are the four iGaming vendor stack layers?

Four layers, in the order money and data move through them.

A platform provider (also called a PAM, or player account management system) is the system of record for player identity, balances, bonuses, bet history and the cashier UI. It decides what a player's balance is, what they are allowed to withdraw, and what the operator's books say at close of day. Every other vendor in the stack either feeds it or reads from it.

A game aggregator is a single integration point that exposes many game studios' content through one API and one game-round wallet protocol. It routes bet and win messages to the platform wallet, normalises game metadata, and handles studio-side certification and reporting. It does not hold player money and does not know what a deposit is.

A payment provider is the layer that moves money in and out of the operator's control — generating deposit addresses or checkout sessions, confirming inbound funds, and executing withdrawals. In crypto-facing casinos this includes chain monitoring, confirmation policy, address reuse rules, failed-payout handling and the webhooks that tell the platform a deposit has landed.

A treasury or wallet layer is where funds sit between the deposit rail and the operator's operating accounts, and where conversion, sweeping and settlement decisions are made. Some operators run this in-house. Some inherit it from their payment provider by default and only discover the custody implications later.

Online casino platform provider vs game aggregator: where does the line actually fall?

The line is the wallet protocol. The aggregator sends bet, win, rollback and balance-query calls; the platform answers them against the player ledger it owns. The aggregator is a message router with content attached.

This matters in an RFP because aggregators often present a "wallet" in their documentation, and buyers read that as custody or balance ownership. It is neither. It is a transactional interface into someone else's ledger.

The confusion gets worse when a platform provider bundles a first-party aggregator, or an aggregator resells a white-label platform. The commercial packaging merges; the technical responsibility does not. Ask both vendors, separately, who answers the balance-query call in production, and you will get your answer in one sentence.

One practical consequence: if you swap aggregators, your player ledger and payment rails are untouched. If you swap platforms, everything re-integrates. That asymmetry should shape how you sequence vendor selection — platform first, aggregator second, payments contracted independently of both.

Who owns the cashier, the player wallet balance and the ledger?

The platform owns all three, and it should stay that way.

The cashier is a platform surface. It renders available methods, minimums, limits and withdrawal eligibility using rules that live in the PAM — bonus wagering state, KYC tier, responsible-gambling flags.

A payment provider supplies method availability and status; it should not be deciding whether a given player may withdraw. If you are scoping this boundary in detail, the breakdown of which vendor actually owns the cashier covers the responsibility split at the UI and rules level.

The player wallet balance is a platform record, not a blockchain balance. Even in a crypto casino where deposits arrive on-chain, the number the player sees is a ledger entry the PAM maintains. The chain holds the operator's funds; the platform holds the claim.

Reconciliation is where this gets expensive. Three sets of numbers exist: on-chain movements, payment-provider transaction records, and platform ledger entries. Someone has to own the daily process that proves they agree, and in most contracts nobody does. Name that owner in the RFP, name the file format, and name the cut-off time.

Casino payment provider vs platform provider: which contract owns deposits and withdrawals?

The payment provider owns execution; the platform owns authorisation and recording.

Concretely, on a deposit: the payment layer generates or assigns the address, monitors the chain, applies a confirmation policy, and fires a webhook. The platform validates the webhook, credits the player ledger, applies any bonus logic, and updates the cashier. Two systems, one event, and a clear handoff point — the webhook.

On a withdrawal it runs the other way. The platform decides eligibility and creates a payout instruction; the payment layer validates the destination, executes the transfer, and reports final state including failures and re-broadcasts. The operator's risk team usually sits between those two steps, and the RFP should say which system houses that approval queue.

A crypto payment provider for casinos is doing something a card acquirer never had to: managing irreversibility. There is no chargeback to reverse a mis-addressed payout, so address validation, memo handling and network selection are payment-layer responsibilities with real financial consequences. Platform providers rarely want that liability, and they should not have it.

The scope overlap to watch for is transaction status. Both layers will maintain a state machine for every deposit and withdrawal, and both will claim theirs is authoritative. Decide up front: the payment layer is authoritative on rail state, the platform is authoritative on ledger state, and the reconciliation job exists to prove the mapping.

Before you write the requirements matrix, it helps to see how LightningPay sits in the stack relative to the platform and aggregator layers — the boundaries are easier to specify once you can see where each contract stops.

Which layer owns FX and stablecoin conversion?

FX is the most commonly unowned line item in the whole stack, because it appears in three places.

At the rail, the payment layer may convert an inbound asset at the moment of receipt. In treasury, conversion happens again when funds are swept or settled into the operator's preferred holding currency. And in the platform, there is a display conversion — the rate used to express a crypto deposit as a fiat-denominated ledger balance, or vice versa.

Those are three different rates, potentially at three different timestamps, and the spread between them is a real cost that shows up in nobody's invoice. Operators discover it as unexplained variance in monthly reconciliation.

The fix is contractual, not technical. Specify which layer sets the rate that credits the player ledger, specify the rate source, and specify who bears movement between credit time and settlement time. Stablecoin flows reduce the volatility exposure but do not remove the question — a USDT deposit credited to a EUR-denominated ledger is still an FX event.

What does the treasury layer own that nobody else does?

Custody, and the operator's ability to change vendors without moving funds.

The treasury layer answers three questions: where do player-attributable funds sit, who has signing authority over them, and what happens to those funds if a vendor relationship ends. Platform providers and payment providers both routinely end up holding balances by default, simply because no one specified otherwise during integration.

That default is the origin of most platform-versus-payments scope disputes. If the platform provider holds funds, it is implicitly performing a treasury function it did not price and may not be licensed for. If the payment provider holds funds, switching providers becomes a migration of live balances rather than a configuration change.

Treat treasury as a named layer in the RFP even if you intend to outsource it. The worst outcome is that it is nobody's stated responsibility and everybody's actual one.

How does non-custodial treasury with operator-held settlement wallets change the vendor split?

LightningPay operates non-custodially: settlement wallets are held by the operator, and the payment layer orchestrates movement into and out of them without taking possession of funds.

The reason this matters at the scoping level is narrow and specific. When the operator holds the settlement wallets, the platform provider never needs to hold player funds to make the cashier work, and the payment provider never becomes a custodian by accident. The single biggest source of overlap between the platform contract and the payments contract simply stops existing.

It also makes the payments layer swappable. You can add a second provider for redundancy or coverage, or replace one, without migrating balances out of a platform provider's wallet or renegotiating custody terms mid-integration. The platform keeps owning the ledger; the payment layer keeps owning the rails; the funds stay where they were.

Final thoughts

Unowned scope does not show up at signature — it shows up ninety days in, as a reconciliation variance nobody will claim, or as a stalled payout queue where two vendors each point at the other. The cost is measured in operational headcount and delayed launches, not in line items.

Contract the payments layer separately from the platform. It has a different risk profile, a different failure mode and a different replacement cycle, and bundling it into a platform agreement removes your ability to fix it independently when it underperforms.

In the RFP, ask for four things in writing: the named owner of the player balance of record, the exact handoff event for deposits and for withdrawals, the reconciliation owner with format and cut-off, and the custody position on settlement wallets.

If a vendor cannot answer those in a paragraph each, the ambiguity is not in your document — it is in their product. Worth a conversation: talk to the LightningPay team about your vendor split before the requirements matrix is locked.