Seamless Wallet vs Transfer Wallet: How Casino Game APIs Move Money

In a single wallet (often called a seamless wallet) the operator keeps the player balance and answers every bet and win call, while in a transfer wallet the funds move to the provider, in five points:

1. Single wallet: the game provider calls your servers for each bet, win and rollback, and you change the balance,
2. Transfer wallet: you move funds in and out, and the provider tracks the balance during play,
3. Single wallet puts the failure handling on you: timeouts, duplicate calls and rollbacks,
4. Transfer wallet is simpler to build but splits the money across two systems,
5. The facts here rest on Hub88’s public docs for single wallet and one other provider’s doc for transfer wallet, so other providers will differ

This is a technical guide for operators and their developers. It is not legal or financial advice.

• The two models in one minute
• How a single wallet works in Hub88 docs
• How a transfer wallet works in one provider doc
• Failure modes and how each model handles them
• Reconciliation and record keeping
• Which model suits which operator
• Questions to ask before you sign
• FAQ

The two models in one minute

Every game round moves money. A player stakes an amount, the game decides the result, and a win may be paid. The wallet model decides which system holds the balance while that happens.

In a single wallet, there is one balance and it stays on your platform. The game provider, or the aggregator in front of it, asks your platform to take the stake and to pay the win. Hub88’s developer docs call this a seamless wallet, and its API reference is our main source for it.

In a transfer wallet, you send the player’s funds to the provider. The provider holds them while the player plays. Later the funds go back. One provider’s balance transfer doc describes this, and we use it as our example.

Be careful with the name. A vendor guide from Track360 notes that “transfer wallet” has two meanings: provider-held funds in an API transfer mode, or separate per-product balances inside the operator’s platform, where the player moves money between, say, casino and sportsbook. Ask which one a vendor means.

If you are still choosing a game source, start with our guide to what a game aggregator is.

How a single wallet works in Hub88 docs

According to Hub88’s wallet API reference, the operator builds five endpoints that Hub88 calls: /user/info, /user/balance, /transaction/bet, /transaction/win and /transaction/rollback. So your platform is the one answering. Each call asks you to read a balance or change it.

Who holds the balance: the operator in a single wallet, the provider in a transfer wallet.

Every request carries an X-Hub88-Signature header. Hub88 signs the body with RSA-SHA256, and the operator checks the signature with the public key that belongs to its operator_id. This stops someone else from sending fake bet calls to your server.

Each bet and win carries a unique transaction_uuid. The docs say the operator must check that a bet was not already processed before it changes the balance, and that an action with the same transaction_uuid must not be processed more than once.

Amounts are whole numbers. The docs say Hub88 multiplies the real value by 100000, so USD 3.56 is sent as 356000. The operator must always move the balance by the amount field, never by billable_amount, which only affects GGR reporting.

A rollback names an earlier transaction through reference_transaction_uuid. The operator must find that transaction, reverse its effect and return the new balance.

None of this tells you how another aggregator works. Field names, retry rules and limits differ, and many aggregator pages do not describe their wallet model at all. SOFTSWISS, EveryMatrix and Alea do not describe it on the product pages reviewed for our ranking.

How a transfer wallet works in one provider doc

The transfer example comes from the balance transfer guide in the Scorpio Play casino API docs. That is one provider, so do not read it as the rule for the market.

The doc says all player funds are transferred to the provider’s API, and the provider manages the balances. It says no balance synchronisation or real-time callbacks to the operator are required during gameplay. Deposits and withdrawals use /v1/player/wallet/deposit and /v1/player/wallet/withdraw.

The doc also says a player with a zero balance cannot place bets, so a first deposit is part of onboarding. Transaction history is available through the API for reconciliation and disputes. The full doc compares this with single-wallet mode: in that mode the funds stay in your system and the provider calls your backend for each transaction.

For the operator, the change is clear. You call the provider when money needs to move, and you do not run an endpoint that must answer in real time during play. The cost is that the player’s money now sits with a third party for as long as it is there.

Failure modes and how each model handles them

The failures below are general ideas in payments systems. The specific behaviour is from Hub88’s docs, and applies to Hub88 only.

Timeouts. A bet call times out. Did your system take the money or not? In a single wallet this is your problem. Hub88 retries a bet 3 times on network failure (HTTP 502, timeout, nxdomain) with a 1 second timeout. If it does not get HTTP 200, it counts the bet as failed and generates a rollback. Hub88 retries that rollback up to 500 times with exponential back off.

That detail matters. If your server took the stake but answered too slowly, a rollback can arrive for money you did take. Your rollback code must handle it.

Duplicate requests. Retries mean the same bet can reach you twice. The rule in the docs is to check the transaction_uuid before changing the balance. In practice you store each ID and return the same result for a repeat. Hub88 also lists a duplicate-transaction status among its response codes.

Delayed wins. For a win, Hub88 applies the same 3 retries. After that, the docs say the retries may continue indefinitely or the bet may be rolled back, as decided by the game provider’s remote game server. So a failed win call can end in either outcome, and you cannot assume which.

Transfer wallet failures. The money moves less often, so there are fewer live calls to fail. The risk shifts to the deposit and withdraw steps. If a withdraw call fails after the player cashes out, the player’s money may sit at the provider while your system shows the wrong balance. The doc says history is available through the API, so a check is possible. It does not describe retry rules for these calls, so ask.

Reconciliation and record keeping

Both models need a way to prove who holds what. The two systems must agree on every bet, win and rollback.

Hub88’s docs say operators should keep transaction IDs for at least 4 months for reconciliation. A daily or hourly job should compare your ledger with the provider’s reports and flag any gap. A stuck rollback, an unmatched win or a bet with no result is how small losses start.

In a transfer wallet, you reconcile the transfers and the provider’s reported balance. Because the provider holds the balance during play, you depend more on its reports. Scorpio Play’s doc points to transaction history for this.

Consider the bonus engine too. In a single wallet, your platform sees every bet and can apply wagering rules in real time. Vantegris lists the wallet model as a term to settle in the supply contract, and says it affects your bonus engine. In a transfer wallet, bonus money inside the provider’s balance can be harder to track, so ask how your bonus rules work there.

Bring your accounting team in early. Which system is the book of record is a legal and tax question as well as a technical one. We cannot answer it for you.

Which model suits which operator

A single wallet takes more engineering, but it keeps the player’s money and rules in one place. A transfer wallet is lighter, but you give up some control and visibility during play.

Neither model suits an operator that cannot staff basic monitoring. A single wallet needs fast servers and on-call support. A transfer wallet needs a clear process for moving funds back. If you are on a white label platform, the vendor usually handles this layer for you. See our guide to how to choose an iGaming platform provider and our overview of startup-friendly casino API providers.

Questions to ask before you sign

1. Which wallet model is offered: single, transfer, or both?
2. What are the retry and timeout rules for bets, wins and rollbacks?
3. How do you detect and report a duplicate request?
4. How long must I keep transaction records, and what report can I pull?
5. Where does bonus money sit, and how do wagering rules apply?
6. What happens to a player’s balance if the provider has an outage?

Write the answers into the contract. Our guide to aggregator versus direct integration shows how these terms change by route. Pricing is a separate topic; see how aggregators charge. You can compare aggregators in our ranking.

FAQ

What is a seamless wallet in iGaming?

A seamless wallet, also called a single wallet, keeps the player balance on the operator’s platform. The game provider or aggregator calls the operator for each bet, win and rollback, and the operator changes the balance. Hub88’s public docs describe this model with five operator endpoints.

What is a transfer wallet?

It has two meanings. In one provider’s doc, funds move to the provider’s API and the provider manages the balance during play. In other vendor guides it means separate balances per product inside the operator’s platform. Ask which meaning a vendor uses.

What happens if a bet request times out?

In Hub88’s docs, it retries a bet 3 times with a 1 second timeout. If it does not get HTTP 200, it counts the bet as failed and generates a rollback, retried up to 500 times. Your system must handle rollbacks for stakes it may have taken.

Why does the transaction ID matter?

Retries can deliver the same bet twice. Hub88’s docs say each bet and win has a unique transaction_uuid, and an action with the same ID must not be processed more than once. Check it before changing any balance, and store IDs for at least 4 months.

Which wallet model is better for a new operator?

It depends on your team. A single wallet gives you control and one balance but needs fast servers and careful error handling. A transfer wallet is lighter to build but splits the money. See our ranking of game aggregators and ask each one which models it offers.