Request signing

All Games API requests have to be signed by Operator.
All Wallet API requests have to be signed by Vegangster.
All Freegames API requests must be signed by the Operator.
Before the integration, the Operator generates a private/public key pair and sends the public key to Vegangster. Vegangster sends its public key to the Operator. The body of all requests will be signed with RSA-SHA256 using the respective private key and encoded to BASE64. The signature will be placed in the X-API-Signature header. The Operator needs to verify all Wallet API requests using the public key provided by Vegangster. Vegangster verifies all Games and Freegames API requests using the public key provided by the Operator.

Request consistency

Wallet API requests have to be idempotent. All transactions contain a transaction_id field. Operator has to ensure that requests with the same transaction_id are not processed twice while the response has to be same for all duplicate requests.

Gameplay

Once you meet the prerequisites, the process is as follows:

1. Obtain a game URL from Vegangster.
2. Direct the customer to the URL provided by Vegangster.
3. Respond to in-game events sent by Vegangster and update the customer's balance

Note that the process is different for DEMO and REAL gameplay modes. In DEMO mode, user can open the game, check the rules/graphics/paytable, and play with fun mode money. Not all game providers allow DEMO gameplay (none of Live Dealers allow it).

Below is an example of interaction flow to open the game in DEMO mode:

1. Operator makes a Game API call to /operator/v1/game/demo/url to obtain game launch URL.
2. When the game URL is returned, the Operator uses it to direct the player to the game (for example, launch it in iframe or redirect player to the URL).
3. In DEMO mode, no calls to Operator's API are made because providers handle the balance themselves. If player liked the game and wants to switch to REAL mode, Operator should proceed with the next steps.

Below is an example of interaction flow between the customer, operator, Vegangster, and game provider in REAL mode:

1. Operator generates and stores a unique game session token.
2. Operator makes a Game API call /operator/v1/game/url and passes the generated token along with the other request parameters. NOTE: Operator needs to be ready to respond to /player/info Wallet API call even before getting the game URL back.
3. When the game URL is returned, the Operator uses it to direct the player to the game (for example, launch it in iframe or redirect player to the URL).
4. When the game URL is loaded in the browser, Vegangster server makes a Wallet API call /player/info (or /player/balance depends on provider) to the Operator's server.
5. Operator verifies the token against the stored token and returns the user's balance. The user can then place a bet.
6. When the user attempts to place a bet, a Wallet API call /transaction/bet is triggered on the Operator's server.
7. The Operator verifies the token, ensures that the user has enough money for this bet, decreases the user's balance by the bet amount, and returns the updated user's balance.
8. If the user wins, the Wallet API triggers a call /transaction/win on the Operator's server.
9. Operator verifies the token, increases the user's balance by the win amount, and returns the updated user's balance.

Wallet API Response statuses