Game Transaction Flow

Most of the transactions that alter the player's wallet balance comes from game transactions. There are two kinds of provider integration, transfer wallet and seamless wallet. In transfer wallet integration, player balance in the operator system must be transferred to the player account in the provider, while in the latter the game provider directly request player balance deduction and settlement to the operator system.

Since this project is a seamless whitelabel, all integrations to game provider are done with seamless intergration. Player's balance is never transferred to the provider system. Wallet deduction and settlement are directly done in the whitelabel system. And as all transactions are handled in the whitelabel system, it also handles the detailed game transaction report for all game rounds.

Player can launch a game from the player portal provider by the operator. Once a player is in a game session provided by the game provider, any action initiated by the player that triggers balance deduction will be sent to the game provider, where shortly after the game provider will send a request for balance deduction to the provider API provided by the whitelabel system.

game transaction chart

game transaction process flow

Provider APIs are a collection of provider integration API. In the current infrastructure, all provider APIs are created using FaaS model deployed in Google Cloud Functions. A function is responsible for handling a single integration endpoint required by the provider. It processes the request sent by the game provider and map the request into another request to be sent to the Wallet Service. Some functions may have different processing requirements and may not send any request to the Wallet Service at all. Most game provider requires at least three integration endpoint that handles wallet/balance check, wallet deduction, and wallet settlement.

All processes from the game provider to the wallet service is a synchronous request response process, which means if a request requires the provider API to call to the wallet service, it will wait for the response from the wallet service before sending response message to the game provider.

Wallet service is only available through gRPC service which means that only internal services are allowed to communicate to the wallet service. Detailed information on the wallet service can be found in the wallet service documentation. In the flow of game transaction, incoming requests from provider APIs are processed by the wallet service by altering the value in Redis. A successful process will send a transaction and round message to Kafka and will be processed further by the report service.