During play, that can involve a launch request, session details, wallet messages, and records of the round. The exact sequence depends on the API and wallet model. The following example uses a callback wallet, where the operator's system handles balance requests received during the game.
Before Play: The Catalog Must Be Ready
The process starts before a player clicks a game. The operator needs the provider and game identifiers used by the service, the content enabled for the account, and the settings required to launch it.
The casino uses catalog data to prepare its lobby. Players see names, artwork, categories, and selected placements; the software needs the corresponding game IDs. A title visible in a lobby still needs valid account access and settings to launch successfully.
Your team should check the actual games intended for release, rather than treating a successful connection to one test game as proof that the entire catalog is ready.
The Three Systems Behind a Game Session
Each system has a different job:
The operator platform
Manages the casino-side player session and, in this example, the player wallet.
The aggregator
Connects the operator-facing messages with the relevant provider service.
The game provider
Supplies the game and its gameplay service.
The aggregator routes and records the relevant data. It does not choose a player's winning or losing result simply because the game was accessed through its API.
A Typical Round, Step by Step
The Player Selects a Game
The player chooses a title in the casino lobby. The operator's system identifies the requested game and prepares the session details required by the API.
A browser click alone is not the full launch request. The server needs to supply the correct game and player references and any required language, currency, or other session settings.
The Casino Requests a Launch URL
The operator sends a session request to the aggregator. The aggregator handles the provider-side exchange and returns the information needed to open the game, commonly including a launch URL.
The casino then presents the game to the player. A session reference ties that launch to later messages and records.
The Player Places a Stake
In a callback-wallet setup, the relevant game event leads to a request to the operator's wallet service. The operator checks the request and determines whether the balance action can be accepted under the documented rules.
An accepted stake is recorded against the wallet. Insufficient funds must produce the expected refusal response; they should not be treated as a successful debit or an unexplained server failure.
The Game Supplies the Result
The provider's game service produces the result according to that game's rules. Any resulting wallet message is passed through the agreed connection.
Where a payout is due, the wallet receives the information needed to credit it. A round can involve more than one event, especially where bonus play or other game features are involved. The API documentation defines how those events relate to a round.
The Systems Record the Outcome
The operator and game service need consistent records of the accepted wallet actions. Transaction references help connect the messages to the session and round.
The Round Becomes Available for Review
The records can support game reports and the investigation of player questions. The useful detail is not just that a player opened a game, but which wallet actions were accepted and how they relate to the round.
The end of a browser session is not always the end of transaction processing. Delayed messages and unfinished rounds need to follow the service's documented rules.
A Simplified Balance Example
Consider a player with a balance of 100 units who places a stake of 2 and receives a payout of 5. The accepted stake takes the balance to 98; the payout takes it to 103. These are two balance movements, not a single instruction to “add the profit.”
The amounts in a real message must use the API's specified format. The example describes the balance changes, not a request payload.
What Happens If a Message Is Repeated or Delayed?
A request can reach the wallet even if its response does not reach the sender. When the sender retries, the wallet must recognize the same identified operation and avoid applying the balance change twice.
This is why transaction identity matters. A displayed balance alone cannot establish whether an earlier request succeeded. The system needs a record of the operation and the result it returned.
If a reversal is required, the API defines which original transaction it refers to and how it must be handled. It is not a general instruction to erase a whole game session. Supported reversal types and the treatment of unknown or already reversed transactions vary between services.
How Is a Transfer Wallet Different?
With a callback wallet, the game-facing service requests balance actions from the operator during play. With a transfer wallet, funds are moved into a separate game-side balance and transferred back according to the supported process.
The difference changes what needs testing and how balances are checked across systems. A team planning a transfer-wallet setup should confirm the rules for transfers, remaining funds, and recovery after an interrupted session.
Neither model should be selected from its name alone. It needs to match the operator's platform and the behavior documented by the service.
Why Testing Must Cover More Than a Successful Launch
A game that opens correctly can still have problems later in the session. Before release, test normal play and cases such as:
- A stake that exceeds the available balance.
- A request received more than once.
- A delayed response or unavailable wallet service.
- A supported reversal and a repeated reversal request.
- Different supported currencies and amount formats.
- Closing the game before all round messages have arrived.
- Free spins and jackpot events, where those tools are used.
For every test, confirm both the visible result and the recorded wallet actions. That gives the operations team a basis for investigating the same situation after launch.
What the Operator Manages After Go-Live
The technical connection is only one part of running the catalog. The operator still decides which games to feature, which content to enable, and how to use the available campaign tools.
Our service provides those controls through a back-office and API settings, with access to 20,000+ games from 150+ providers. It supports callback and transfer wallet models, automatic monthly catalog updates, free spins, and cross-game jackpots.
The next step is to review the documented process against your current platform. Request the API documentation and commercial terms to establish what your team needs before testing begins.