Almost every casino game aggregator now integrates with operators through a seamless wallet. The model is simple to describe and easy to get subtly wrong. This guide walks through what happens during a game round and what to test before real money flows.
The principle
The operator owns the ledger. The player’s balance never moves to the aggregator or the studio. Instead, the aggregator asks the operator’s wallet what the balance is, tells it to take a stake, and tells it to pay a win. The operator answers each call with the new balance or an error.
One game round, step by step
- Launch. The operator requests a game URL from the aggregator for a given player, currency and game. The aggregator returns a URL that the operator loads for the player.
- Balance. The game asks for the balance; the aggregator calls the operator’s balance endpoint.
- Debit. The player spins. The aggregator calls the operator’s debit endpoint with a transaction ID, round ID and amount. The operator checks funds, books the stake and returns the new balance.
- Credit. The round resolves. The aggregator calls the credit endpoint with the win amount, which may be zero, and the same round ID.
- Rollback, if needed. If the debit was booked but the round failed, the aggregator sends a rollback for the original transaction.
Five rules that prevent balance disputes
- Idempotency on every call. A repeated transaction ID must return the original result, never a second booking.
- Rollback only what exists. A rollback for an unknown transaction should be acknowledged without moving money.
- Credits after rollbacks. Decide and document what happens when a credit arrives for a round already rolled back.
- Timeouts. Agree how long the aggregator waits and how many times it retries. A slow wallet causes duplicate calls.
- Currency precision. Agree whether amounts are sent in units or minor units, especially for crypto with many decimals.
Tests before launch
Run each scenario in the sandbox: insufficient funds, duplicate debit, duplicate credit, rollback after debit, rollback of an unknown transaction, credit after rollback, and a wallet timeout. Log every request and response with the transaction ID so support can trace a disputed round in minutes.
Seamless or transfer?
Transfer wallets move money into a session and back. They simplify some provider integrations but split the balance across systems. Seamless keeps a single source of truth, which is why most operators prefer it. Hub88 is one of the few aggregators that documents both.
Frequently asked questions
What is a seamless wallet?
An integration model where the player's money stays in the operator's system. The aggregator or game server calls the operator for every balance check, stake and win.
What is the difference between seamless and transfer wallets?
With a transfer wallet, money is moved into the game provider's session and back out at the end. With a seamless wallet, it never leaves the operator's ledger.
What is idempotency in a wallet API?
The guarantee that processing the same request twice has the same effect as processing it once. Every debit and credit carries a unique transaction ID so a retried call is not booked twice.
What happens if a debit succeeds but the game round fails?
The aggregator sends a rollback (sometimes called a refund or cancel) referencing the original transaction, and the operator returns the stake to the player.
Which aggregators use a seamless wallet?
Most do. SoftAggregator, SoftGamings and Hub88 state it publicly; Hub88 also offers a TransferWallet option.