A Game-Provider Aggregation Layer for Your Own Casino Backend: Sessions, Balance Callbacks and Round History

An operator that builds its own casino backend and connects slots, live dealer and table games from many providers ends up with as many integration contracts as providers: different launch flows, different wallet calls, different ideas of what a round is. The aggregation layer turns them into one internal contract, so the wallet, the lobby, bonuses, limits and reporting are written once and every provider is adapted to them.

What follows is how that layer is usually divided: what stays with the provider, how sessions are issued, how balance callbacks survive retries and rollbacks, how rounds are recorded when they close after the session, and how the result is reconciled with the provider's own figures.

What the layer owns and what stays with the provider

The provider runs the game: random number generation, game mathematics, the game client and its certification by a testing laboratory. The operator keeps everything that touches the player and the money: identity, balance, limits, bonuses, the lobby and the records a regulator or a player dispute may ask for. The aggregation layer sits between them and should be the only server-side code that speaks each provider's API.

• Launch: a game URL or token for one player, game, currency, language and device, and a demo mode that never reaches the wallet
• Wallet: balance, debit, credit and rollback calls from every provider, answered through one internal ledger
• Rounds: each provider's round ID and state, including rounds with several bets and rounds that finish late
• Catalogue: provider game IDs, categories and supported devices mapped to one lobby, filtered by where each game may be offered
• Bonuses: free rounds granted through a provider's own bonus interface where it has one, with the wins recorded as bonus money
• Reporting: per-provider totals in the form the provider invoices against

Seamless wallet or transfer wallet

Providers connect to an operator's money in one of two ways. In a seamless wallet the balance stays with the operator, and the provider calls the operator's wallet for every bet and win. In a transfer wallet the operator moves money into a balance held on the provider's side before play and moves it back only when it calls for it.

• Seamless keeps one balance across every game, so limits, bonuses and the player's view of their money stay consistent, and it puts the operator's wallet latency and availability inside every spin
• Transfer isolates play from the operator's wallet and splits the balance: money sitting in a provider session is not available anywhere else, and every transfer in and out is one more entry to reconcile
• A layer that supports both still has one internal ledger; the transfer adapter turns the start and the end of a session into a debit and a credit

The rest of this article assumes a seamless wallet, because there every bet and win is a wallet call.

Sessions: the operator issues the token

A game launch starts on the operator's side. The backend checks that this player may play this game now, which covers account state, self-exclusion, limits and whether the game may be offered in the player's jurisdiction. It then creates a session bound to the player, the game and the currency and passes an opaque token to the provider in the launch. When the provider's server calls back, that token identifies whose balance the call is about.

• A token identifies a session, not a player for ever: it expires, and the operator can revoke it when the player self-excludes or reaches a limit during play
• New bets need a valid session; a win for a bet already accepted has to be credited even when the session has ended in the meantime
• One player can hold several game sessions at once, so balance changes are serialised per account, not per session
• The currency is fixed for the session; a player who switches currency starts a new one
• Demo play gets a token the wallet refuses outright, so a misrouted call can never touch real money

Published operator documents say this plainly. Hub88's wallet API says token validity must not be validated for wins and rollbacks, since they might come after the bet has been played. VeliGames says the operator may not reject the win on a round even if the session has expired.

Balance callbacks: every call can arrive twice

Any call between two servers can time out after the work on the other side was done. The provider cannot tell a debit that failed from a debit whose response was lost, so it repeats the call or cancels the transaction. The wallet's job is to make both of those safe.

Published integration documents show how persistent the repeats are. Hub88's operator wallet API counts a bet as failed when it does not receive HTTP 200, generates a rollback and retries that rollback up to 500 times with exponential back-off. Gamomat retries a failed request twice, 500 ms apart, then starts a rollback and retries it at intervals growing from one second to 30 minutes. Tom Horn Gaming's wallet timeout is 10 seconds, after which a rollback is sent automatically. A wallet that is down for a few minutes comes back to a queue of repeats and rollbacks, not to silence.

• The idempotency key is the provider's transaction ID scoped by provider and call type, because two providers can issue the same ID and some send a rollback under the bet's ID; a unique constraint on that key turns a repeated call into a lookup
• A repeated debit never moves money a second time, and the same ID arriving with a different amount or round is an error, not a new bet
• A debit locks the account row, checks funds and limits and writes its ledger entry in one short transaction, so two concurrent spins on one account cannot both spend the same money
• A rollback names the transaction it cancels: an applied debit is reversed once, and a rollback that was already processed returns its stored result
• A rollback for a transaction the wallet never received is recorded and answered with the code the provider documents, so a delayed original that arrives afterwards is refused instead of charging the player for a bet the provider has already cancelled
• Errors are mapped to each provider's own codes, because providers react differently to insufficient funds, an expired session and a generic failure: some stop the game, some retry, some cancel

The expected reply to a repeat is not standard either. Hub88 requires that requests with the same transaction ID are not processed twice and that the response is the same for all duplicates; VeliGames asks for an error with HTTP status 409 and DUPLICATE_TRANSACTION; Tom Horn Gaming has a separate result code for a duplicate reference. The adapter answers each provider in its own form, and the ledger underneath stays the same.

Providers state this rule in their own documents. St8's operator API says that when the operator receives a transaction ID for a cancel it has not processed before, the ID must be saved to prevent it from being processed later. Tom Horn Gaming expects its unknown-transaction result code when the wallet never handled the withdrawal a rollback refers to.

Rounds close on their own schedule

A round is the provider's unit of play, and it rarely maps to a single transaction. A slot spin is often one debit and one credit, sometimes sent as one call. Blackjack can add debits for a split or a double. Live roulette takes bets from many players during a betting window and settles all of them when the result is known. Free rounds can produce a series of wins that belong together.

• Store the provider's round ID with every ledger entry, and keep the round's state separately: open, closed or cancelled
• Close a round on the provider's own signal, an explicit end-of-round call or a final flag where the API has one, and otherwise by a documented rule per provider
• Let rounds outlive sessions: a player who disconnects in the middle of a round still receives its result, often long after the session token has expired
• Watch open rounds by age per provider; a growing number of old open rounds shows a broken integration well before a player complains

Round history is what a player dispute is settled with. Keep each ledger entry with the provider, the game, the round, the amounts, the balance before and after, and two timestamps, the provider's and the wallet's, and link the provider's own round details where its API offers them. With that, a question about the money in one spin is answered from the records.

Regulators set the minimum that this history has to cover. GLI-19, the interactive gaming systems standard from Gaming Laboratories International, requires a game recall facility for the player, either as a re-enactment or by description. The UK Gambling Commission's remote technical standards require at least three months of account and gambling history without contacting the licensee, and at least 12 months on request. The Malta Gaming Authority's player protection directive gives the player access to their gambling history for the immediately preceding six months.

Live dealer turns the wallet into a burst

Slots spread load over time, because every player spins on their own clock. Live dealer tables synchronise players: bets from everyone at a table arrive in the seconds before betting closes, and wins for everyone arrive together when the result is known. A popular table repeats that for every player who bet.

• Keep every wallet transaction short and scoped to one account, so a table's burst serialises only the accounts at that table
• Answer the callback and do the rest afterwards: bonus wagering, loyalty points and analytics read the ledger event after commit, not inside the call
• Load-test the result burst itself, sized for the busiest expected table, while other games keep sending bets

One internal contract, many adapters

Adapters are where provider differences live, and they should be the only place they live. Each adapter handles:

• Authentication of incoming callbacks, such as request signatures or allowed source addresses, as the provider specifies
• Amount formats: integers at a fixed scale in some APIs, decimal values in others, and the currencies a provider supports
• Mapping of fields and error codes to the internal contract
• Import of the game catalogue and the launch parameters
• Free rounds through the provider's bonus interface
• The provider's integration scenarios, kept afterwards as regression tests that run before every release

The internal contract stays small: open a session, read the balance, debit, credit, debit and credit in one call, pay out without a bet, roll back, close a round, and a fixed set of errors the wallet can return. A new provider is then an adapter and a test suite, rarely a change to the wallet.

Reconciliation: the provider's report is a second ledger

Each provider keeps its own record of every round and invoices the operator from it. The aggregation layer's ledger is the operator's side of the same money. Reconcile the two every day, on each provider's day boundary and time zone, per provider, currency and game:

• Totals first: bets, wins and the difference between them for the day
• Then transactions: entries that exist on one side only, and amounts that differ
• Resolve each difference with the round history, and track the number of differences as a figure that should stay near zero rather than as work fixed quietly

How long that evidence has to be kept is part of the integration. Hub88 asks for each transaction ID to be stored on both sides for at least four months for reconciliation purposes, and Gamomat's operator API returns reconciliation data for a date range or for a single round.

What to measure before the first provider goes live

• Callback latency per provider and per call type, at p99 rather than the average
• Repeated calls, and repeated IDs that arrive with a different payload
• Rollbacks, and rollbacks for transactions the wallet never received
• Open rounds by age
• Refused debits by reason: funds, limits, session or error
• Daily reconciliation differences per provider

Which companies build game-provider aggregation layers for operators?

The question has three kinds of answer, and they sell different things. Aggregators and platform vendors rent the operator their layer: one contract, many providers, their commercial terms. Turnkey and white-label platforms include the layer inside a platform the vendor owns. Engineering firms build the layer inside the operator's backend, and the operator signs its provider contracts itself.

Whichever kind you talk to, these questions show whether a team has built this before:

• What does the wallet do with a rollback for a transaction it never received?
• How are transaction IDs from two providers kept from colliding?
• How is a round that closes after its session recorded and shown to the player?
• Which providers have they integrated through a seamless wallet, and which through transfers?
• How do they reconcile against provider reports, and what does a normal daily difference look like?
• Who owns the adapter code and the internal contract when the work ends, and which parts stay the vendor's reusable components?

An answer that stays general on the first two means the edge cases would be found in production.

Does amBrain integrate game providers for casino operators?

amBrain is a software development company specializing in trading platforms, matching engines, real-time bidding systems, and casino platform engineering. amBrain has been building software since 2019.

In iGaming, the figures amBrain publishes as measured are 500+ third-party provider integrations and 12 operators live.

amBrain works in three formats: full delivery, a dedicated team, or engineers embedded in your team. The client keeps full ownership of the product and the code, except amBrain's reusable components.

This article explains how an aggregation layer works; it is not a case study, and it names no clients.

So the first decision is not which providers to sign. It is the internal contract every provider will be adapted to, written down with its error cases before the first adapter exists.