Configuring Wallet Connectivity
Self-hosted operators have the ability to customize certain aspects of how ThrillGate integrates and operates when integrated with one or more operator wallet systems. This section describes the general configuration options available.
Customizing ThrillGate integration behaviour
NOTE: For all the API calls below, you will need to have a valid authenticated token issued by Thrill-ID and attach it as a
Bearertoken on theAuthorizationheader
Each brand must have a wallet definition created in ThrillGate. These wallet configurations are made via the POST thrillgate_server/admin/wallets Admin API.
Example
{
"id": "CasinoWallet",
"operator_id": "thrilltech",
"brand_id": "casino1",
"connection_details": {
"protocol": "https",
"host": "your_wallet_server_host",
"port": 443
},
"endpoints": {
"auth": "/auth",
"balance": "/balance",
"debit": "/debit",
"credit": "/credit",
"cancel_bet": "/cancel"
},
"config": {
"secret_key": "this_is_the_hmac_secret"
}
}
The ThrillGate wallet configuration supports customization of behaviour via the config field which is an object that supports the following properties:
| Property | Definition | Notes |
|---|---|---|
secret_key | HMAC key | If you use HMAC validation on your wallet to validate the messages that ThrillGate sends, this key must match the key that is configured on your wallet |
request_timeout | Base timeout in seconds for a Standard Wallet API call | Default is 10 seconds |
request_retry_limit | Maximum number of time to retry an API call | Default is 3 |
request_retry_backoff | Request retry backoff factor. The factor by which the timeout is increased on each retry | Default is 2 |
retry_backoff_sleep | Should the retry mechanism sleep (timeout * backoff * count) between attempts | Default is false |
error_response_rules | Definition of custom error response rules | More information can be found here |