Game session data
Player, brand, game, currency, country, language, mode, jurisdiction and access expiry.
Documentation / Gaming Flow
Gaming API flow
The complete path from player validation and game launch to bets, winnings, game rounds, operation cancellations and financial reconciliation.
Session
player and game launch
Balance
bets and winnings
Rounds
game session flow
Cancellation
operation recovery
Game lifecycle
From launch to round closure
01
Create a game session
Player, game, currency, language, country, mode and return URL.
02
Launch the game
Temporary access key, launch URL and game availability check.
03
Process financial operations
Balance check, bet, win, combined operation and platform responses.
04
Close and reconcile the round
Final outcome, cancellations, financial ledger and provider report.
Overview
The gaming API links the player, round and movement of funds
Game launch and movement of funds are different parts of one process. The session identifies the player and launch conditions, the round links provider actions, and the platform API confirms every debit, credit and cancellation.
Balance control
The platform checks available funds and applies each bet, payout or cancellation only once.
Game financial ledger
Operation and round identifiers, operation type, amount and balances before and after are retained for control and reconciliation.
Game launch
Typical game launch flow
The platform first validates the player and game availability, then creates a time-limited session and receives a launch URL from the provider.
01
Validate the player and game availability
The platform checks account status, currency, country, restrictions, limits, real-money or demo mode and game availability.
02
Create an internal session
A session identifier is created with the player, game, brand, currency, language, IP and expiry details.
03
Get the game launch URL
The provider receives the session key, notification and return URLs, device type, jurisdiction and interface parameters.
04
Open the game in the browser
The player opens the returned URL, while subsequent financial operations are processed directly between servers.
Balance operations
Core balance operations
Method names differ between providers, but the logic remains the same: balance check, bet debit, win credit and cancellation of a previously confirmed operation.
Balance check
Returns the player's available balance in the active session currency without changing the financial ledger.
Bet debit
Validates the player, session, currency and available funds, then debits the confirmed bet once.
Win credit
Credits winnings using unique operation and round identifiers, including a zero result.
Bet and result in one request
Applies the bet and game result together when the provider supports this model.
Operation cancellation
Creates a separate correcting operation for a previously confirmed bet or payout without deleting the original entry.
Bonuses and free spins
Passes bonus campaign and game-round data while separating real and bonus funds.
Currency and amount precision
Each operation validates the currency, amount units, decimal places and rounding rules.
Platform response
Returns the operation status, internal identifier, current balance and a unified error code.
Round lifecycle
Game round lifecycle
One round may include several bets and results. Its state is determined by game rules, not only by the order of network requests.
Round created
The platform receives the round identifier for the first time and creates an internal record.
Round active
The round may contain additional bets, game actions and intermediate winnings.
Bet accepted
The debit is confirmed by the platform and linked to the provider's unique operation identifier.
Result received
A win or zero result has been received, but the round may remain open under the game rules.
Round closed
The provider has confirmed the end of the round and all expected financial operations have been processed.
Operations cancelled
One or more operations have been corrected while preserving the full original history.
One round may include multiple operations
The round identifier must not be the only idempotency key. Every bet, payout and cancellation should have its own unique identifier.
Reliability and reconciliation
Duplicate protection and financial reconciliation
The gaming API must safely handle repeated requests, response delays, out-of-order operations and provider recovery after a failure.
Safe repeat processing
The provider operation identifier is unique for each type of financial action.
A repeated request returns the original result and current balance without moving funds again.
A retry with a different amount, currency or player is rejected as a data conflict.
A cancellation references a specific original operation and also receives its own unique identifier.
Round ledger and reconciliation
Store session, round, provider operation and platform operation identifiers.
Record the operation type, amount, currency, balances before and after, and processing time.
Do not alter posted entries; create a separate correcting operation.
Reconcile provider reports, game rounds, balance movements, GGR and identified discrepancies.
Testing
What to test in the test environment
Checks should cover game launch, player restrictions, insufficient balance, repeated operations, response delays, cancellations and reconciliation of a closed round.
Launch and game session
Real-money and demo modes, invalid currency, prohibited country, expired access and unavailable game.
Balance and bet rejection
Insufficient funds, blocked player, currency mismatch and exceeded limit.
Delay and unknown outcome
The provider does not receive a response after the debit has actually occurred and resends the operation with the same identifier.
Repeated bets and winnings
The same identifier arrives before or after processing is completed, including with conflicting parameters.
Operation cancellations
Bet cancellation, win cancellation, repeated cancellation and reference to an unknown original operation.
Round reconciliation
Bet, win and cancellation amounts, final status, balance movement and the provider report must match.
Pre-launch checklist
Launch takes place after game sessions, balance operations, duplicate protection, cancellations and reporting have been verified.
Test and production environments use different access credentials, API endpoints and launch settings.
The game session key is time-limited and linked to the player, game, currency and brand.
Every balance operation is protected by a unique provider identifier.
Repeated bets, winnings and cancellations do not change the balance a second time.
Posted entries are not deleted and are corrected through separate adjustment operations.
Event logs, alerts, provider reports and the round-reconciliation process are configured.
Need to configure the gaming API flow?
Send us the provider documentation, balance-operation list, game-round model, currencies and reporting requirements. APIACE will help structure game launch, bets, winnings, cancellations and financial reconciliation.