How the iGaming supply chain works

This page is for the reader who is building a casino operation and meets this market for the first time. No API details here: the parties, the money flow, and the integration models you are choosing between. The companion page, Launching your first operation, turns this picture into a checklist.

Who is who

Four roles cover most of the market:

• Operator. The casino: the site or app that players visit. The operator holds player accounts and player money, decides which games to offer, and answers to a regulator for all of it. In every flow on this hub the operator owns the player wallet.
• Game provider. The studio: the company that designs games and runs the servers those games execute on, so every result is computed on the provider’s side, not in the player’s browser. A provider ships games; it never holds player money.
• Aggregator. The layer between them. An aggregator integrates many studios once and offers operators the combined catalog behind one contract and one API. Aggregator.gg is this hub’s platform; Operators describes the offer in full.
• Platform. An operator that runs several brands on shared infrastructure: one team, one wallet integration, many storefronts. On this hub the multi-brand case is served by platform accounts and described on Platforms.

How money moves in a round

A game round is one short loop between the game and the operator’s wallet:

1. The player presses spin. The game asks the operator’s wallet to debit the stake. That request is a bet.
2. The game computes the result on the provider’s server.
3. If the round pays out, the game asks the wallet to credit the payout: a win. A losing round credits nothing.

The player’s balance lives in the operator’s wallet through all of it; the aggregator in the middle routes, verifies, and records the calls without ever holding the money. That is the model on this hub too: the operator owns the wallet, and Aggregator.gg never holds player funds. Normalized wallet callback amounts are integers in the currency’s minor units: 10000 is 100.00 EUR.

Three terms describe the economics of the loop:

• GGR, gross gaming revenue. Bets minus wins over a period. This is the operator’s gross result from game content, before bonuses and costs.
• RTP, return to player. The share of stakes a game is designed to pay back over its whole statistical life. RTP is a property of the game’s math, declared by the studio: a certified figure, not a promise about any single session. Operators filter the catalog by RTP, show it in their lobbies, and answer to their regulators for what those lobbies claim, which is why every RTP in the catalog arrives with a named source.
• Volatility. How unevenly that return arrives. A low-volatility game pays small amounts often; a high-volatility game pays rarely but larger. Two games can share the same RTP and play out very differently, so the catalog carries a declared volatility profile next to it.

Over a large volume of rounds GGR tends toward the share of stakes that RTP leaves to the house. On any given day it swings with luck, and volatility sets how wide the swings are.

Direct integrations or an aggregator

An operator gets games one of two ways: connect each studio directly, or connect an aggregator once.

Direct means every studio is its own project. Each one brings its own API and wallet contract, its own test cycle and certification, its own commercial negotiation, and its own support relationship when something breaks at 2 a.m. Ten studios means roughly ten times that work, and the bill is not one-time: every integration has to be maintained as the studio’s API evolves. Large operators run whole teams for exactly this.

An aggregator collapses this into one contract and one integration. New studios then appear as catalog entries the operator enables, not projects it builds. The trade is standardization: the operator implements the aggregator’s contract instead of ten native ones, and content breadth depends on the aggregator’s catalog. On this hub that promise is concrete: Aggregator.gg normalizes every provider protocol into one session API and one callback shape.

The same logic works from the studio’s side: game providers integrate the aggregator once and reach the operators on it.

The wallet-callback model

The models above differ in who talks to whom about money. In the model this platform uses, the answer is: the wallet stays yours, and the platform calls it.

When a bet or win happens in a game, Aggregator.gg sends your backend a signed HTTP request, a wallet callback: debit this stake, or credit this payout. Your endpoint updates the player’s balance in your database and answers with the new balance. The game shows the result only after your wallet has answered, so your ledger stays the source of truth at every moment of the round.

That is the whole model. What it takes to implement it well (signatures, idempotency, error semantics) is exactly what the operator documentation on this hub covers: Callbacks is the contract, How a round works is the lifecycle with payloads.

What an aggregator does not solve

An aggregator supplies and settles game content. A casino is more than that, and these parts stay with you regardless of which supplier you choose:

• Your licence. Operators need a licence for the jurisdiction where they operate. Game supply does not replace it, and no supplier’s paperwork covers your storefront.
• Payments. Deposits and withdrawals between you and your players run on payment providers you contract yourself. Game rounds settle against the wallet those deposits fund; how money enters and leaves that wallet is outside the aggregator’s scope.
• Player KYC and player protection. Knowing who your players are, anti-money-laundering checks, and responsible-gambling duties are operator processes. The API assumes they exist: a session for a self-excluded player must not start, but deciding who is excluded is your system, not ours.

If this division of labour matches what you are building, the next page is the checklist: Launching your first operation.