What Is Seamless Wallet Integration? Core Model Explained

Learn how GitSlotPark’s seamless wallet model connects directly to your wallet system in real time, with no separate balance store required.

The seamless wallet model means GitSlotPark holds no internal player balance. Instead, every balance query and transaction is sent directly to your system the moment it happens in the game. Your wallet remains the single source of truth for every player’s funds.

Seamless vs. transfer wallet

In a transfer wallet model, a player’s funds are moved to a separate gaming wallet before play begins and moved back when the session ends. The seamless model eliminates this step entirely — there is no separate balance, no transfer in, and no transfer out. GitSlotPark reads and updates your wallet in real time on every bet and win.

The two sides of the integration

Your integration has two distinct directions of communication.

Platform APIs (you → GitSlotPark)

You call GitSlotPark’s endpoints to retrieve the game catalog and generate authenticated game launch URLs for your players. These calls originate from your server.

Callback Service (GitSlotPark → you)

You implement an HTTPS endpoint that GitSlotPark calls for all wallet operations. When a player bets, wins, or a round is cancelled, GitSlotPark sends a POST request to your callback URL and expects a JSON response in return. This is the core of the seamless wallet integration.

Transaction flow

The following steps describe a standard bet-and-win game round.

1. Player places a bet

   The game client sends a wager. GitSlotPark calls your Withdraw callback with the bet amount and a unique transactionID. Your system debits the player’s balance and returns the updated balance.

2. Game round resolves

   The game engine determines the outcome. If there is a win, GitSlotPark calls your Deposit or BetWin callback with the win amount and a new transactionID. Your system credits the player’s balance and returns the updated balance.

3. Round is complete

   GitSlotPark records the final state of the round. No further callbacks are sent unless the transaction needs to be reversed.

4. Rollback (if needed)

   If a round cannot be completed — for example due to a technical fault — GitSlotPark calls your RollbackTransaction callback referencing the original transactionID. Your system reverses the debit and restores the player’s balance.

Idempotency

GitSlotPark’s callbacks are designed to be idempotent. If your server returns a non-200 HTTP status or times out, GitSlotPark may retry the same callback. Each retry carries the same transactionID.

If you receive a callback with a transactionID you have already successfully processed, do not apply the transaction again. Return a success response with the player’s current balance as if the original request succeeded. Applying the same transaction twice will corrupt the player’s balance.

Use transactionID as a unique key in your transaction log. Before processing any debit or credit, check whether that ID already exists. If it does, return the stored result immediately.

HTTP 200 is the only success

GitSlotPark treats any HTTP response other than 200 OK as a failure, regardless of the response body.

Network errors, timeouts, and non-200 status codes all cause GitSlotPark to retry or mark the operation as failed. Always return HTTP 200 — even when reporting a business error such as insufficient funds. Use the result field in the JSON body to communicate the outcome.

Your callback service must return HTTP 200 with a JSON body containing at minimum a result integer code and a message string. See API Result Codes and Error Handling for the full list of codes.