Seamless Wallet

Allows integration between the Game Provider and the Licensee wallet system, enabling the Game Provider to directly send transaction requests to the Licensee wallet.

In the Seamless Wallet model, the player’s balance is held and managed by the Licensee. The Game Provider does not store or maintain player balances.

All fund-related operations (such as bets or payouts) must be processed through the Licensee wallet.

Implementation Scope

In the Seamless Wallet model, the Wallet API is provided by the Licensee, and the Game Provider initiates wallet transaction requests based on the player’s game state.

Notes for Licensee

For all requests sent to the Licensee, the Game Provider will include an API_KEY. This API_KEY is issued by the Licensee to the Game Provider.

The Game Provider follows the specifications below:

Uses RESTful APIs
Expected response time under 300 ms
Requests and responses use JSON format (content-type: application/json)
Persistent connections are expected: Response Header includes connection: keep-alive
HTTPS only
Authentication methods:
1. Add authorization: ECDSA-SHA256 <API_KEY> in Request Header ¹
2. Add authorization: HMAC-SHA256 <API_KEY> in Request Header ¹
3. Add authorization: bearer <API_KEY> in Request Header
4. Add api-key: <API_KEY> in Request Header ²
5. Add api_key=<API_KEY> in Query String (Not Recommended)
API_KEY specification:
Provided by the Licensee
Recommended length: 8–22 characters
Allowed characters: A-Z, a-z, 0-9, ., - ³
API endpoint requirements:
Must have a valid HTTPS certificate
Use a fixed public IP or stable DNS record
Temporary tunneling services or short URLs are not accepted

Additional Recommendations

To improve request efficiency between the Game Provider and the Licensee, enabling connection: keep-alive is strongly recommended for persistent HTTP connections.
If the Licensee supports HTTP/2, the Game Provider can also utilize an HTTP/2 client to send requests.

Settlement Types

Two settlement modes are supported: Mixed and Gamewise.

Mixed Settlement Mode

Each Debit Request corresponds to either a Credit Request or a Cancel Request.

If 3 Debit requests are made, the Licensee will ideally receive 3 Credit Requests, or possibly Cancel Requests.

For the Game Provider, each transaction can have the following states:

COMMIT: A Debit Request has been sent, but no Credit or Cancel has been issued yet
COMPLETE: A Debit Request and a Credit Request have been sent and successfully acknowledged
CANCELED: A Debit Request and a Cancel Request have been sent and successfully acknowledged
PENDING: A Debit Request has been sent, and a Credit or Cancel was issued, but no successful response was received
Failed or timed-out requests fall into PENDING
Credit or Cancel will be retried via a retry queue

Combined Submission

In this mode, combined submission is possible based on Licensee requirements: sending Debit and Credit in a single request.
This is commonly used in slot machines or fast RNG games, where the outcome is known immediately upon betting. The Game Provider may internally combine the two requests.

If needed, please contact the Game Provider for support.

Gamewise Settlement Mode

Within a single game round, the Player may issue multiple Debit Requests, followed by a single Credit Request to settle the total amount into the player’s wallet.

Typical use cases include multi-bet or poker-style games:

Baccarat: multiple bets on Player, Banker, Tie
Roulette: bets across different numbers or areas
Live games: continuous betting before betting closes

Each Debit Request can be interpreted as "placing" or "adding" chips within the game logic.

Settlement Failure

In both Gamewise mode and Mixed mode (when split into separate requests), once a Debit Request is accepted, the game will assume the bet is valid.
Even if the Licensee later responds with a failure to the Credit Request, the result will still be delivered to the Player.
From the game’s perspective, a valid bet entitles the player to a corresponding Credit.

If there is a possibility that a Debit succeeds but a Credit is rejected, the Licensee must inform the Game Provider of the handling strategy.