Games Integration
This document describes the integration between the Merchant and the HPGames platform.
Integration Overview
HPGames is a B2B platform that enables merchants to offer casino games to their players.
The integration consists of the following components:
1. Game Launch (REQUIRED)
- The Merchant launches games by redirecting the Player to the HPGames game launcher URL
- The game can be opened in a new window or embedded via iframe
2. Wallet APIs (REQUIRED)
- HPGames calls Merchant APIs to manage Player authentication, balance, and transactions:
validateTokengetPlayerBalancedebitcreditbulkCreditcancelDebitbulkCancelDebit
3. Simulatta (ADDITIONAL)
- Simulatta extends the Casino integration with bet slip functionality
- It uses the same Wallet APIs, with one additional endpoint:
betSlip
4. Rewards (ADDITIONAL)
- The Merchant uses HPGames APIs to create and assign rewards (e.g. free bets), which are later consumed during gameplay through wallet transactions.
5. Game List (ADDITIONAL)
- The Merchant retrieves the list of available games via the HPGames API (
gameList)
Communication Flow
- The Merchant launches the game by redirecting the Player to HPGames
- During gameplay, HPGames calls Merchant Wallet APIs to manage player balance and transactions
- The Merchant calls HPGames APIs to retrieve game data and manage rewards
Communication Protocol
- All communication is performed over HTTPS
- APIs use:
- POST requests with JSON bodies (Wallet, Game List, Rewards)
- GET requests for game launch (URL redirect)
- All requests must include the header:
Content-Type: application/json
- All responses are returned in JSON format
- All API request parameters are case-sensitive
- All timestamps must be provided in epoch milliseconds
Security
All requests are secured using an HMAC SHA256 signature.
Each request must include a valid hash parameter. The fields used for hash calculation depend on the specific API endpoint.
In addition, each request must include a timestamp parameter (in milliseconds). The timestamp is used to prevent replay attacks.
Requests must be sent within 60 seconds of the provided timestamp. Older requests will be rejected.
For details on how the hash is generated, see Request Signing.