Seamless wallet vs transfer wallet: how casino game money really moves

By Soft of Games editorial team · Updated 2026-10-07

Every game integration has to answer one question: where does the player's balance live while they play? A seamless wallet keeps it on your server and gets a call for every bet. A transfer wallet moves money into the game provider's system and back. This guide walks through both, with the failure cases that decide which one you should pick.

Two places a balance can live

When a player opens a slot, money has to be somewhere the game can reach. There are two answers.

In a seamless wallet (sometimes called a single wallet), the balance stays on the operator’s server for the whole session. The game provider holds nothing. Each bet arrives at your server as a debit request and each win as a credit request. You reply with the new balance.

In a transfer wallet, the operator moves part of the player’s money into a balance held by the game provider. The player plays against that balance. When they leave, the remaining amount is moved back.

Both models work. They fail in very different ways, and those failures are what you are really choosing between.

How a seamless wallet works, call by call

A typical seamless integration exposes four or five endpoints on your side:

• Balance: return the player’s current balance in the session currency.
• Debit (bet): subtract an amount, keyed by a unique transaction ID.
• Credit (win): add an amount, keyed by its own transaction ID and linked to a round.
• Rollback: reverse a specific earlier debit.
• Some vendors add a combined bet-and-win call for instant games, or an end round message.

The aggregator signs every request, usually with an HMAC hash over the body and a shared secret, so your server can reject anything that did not come from them.

With SoftAggregator, for example, the operator exposes HTTP callbacks for balance, debit and credit, and the same callbacks serve slots, live casino, virtuals and the sportsbook. That is the main convenience of a seamless model: one set of endpoints covers every product. SOFTSWISS, Hub88, St8 and most large studios follow the same pattern, with differences in naming and in how rounds are grouped.

The three rules that matter

1. Idempotency. If the same transaction ID arrives twice, apply it once and return the same answer both times. Retries are normal. Double payouts are not.
2. Atomicity. The balance check and the deduction must happen in one database transaction. Otherwise two fast bets from two tabs can both pass a balance check that only one of them should pass.
3. Rollback tolerance. You will receive rollbacks for debits you processed, and sometimes for debits you never received because the request died on the way. Store the rollback either way, so that if the late debit arrives afterwards you can refuse it.

Developers who get these three right have done most of the hard work.

How a transfer wallet works

The flow is simpler on paper:

1. Player opens a game. You call the provider’s “deposit” or “transfer in” endpoint with an amount.
2. The provider credits its own balance for that player.
3. The player plays. You hear nothing during play.
4. The player leaves, or you call “transfer out”. The provider sends the remaining balance back.

Your server is not in the path of each bet, so its speed and uptime matter less during play. That is the real advantage, and it is why some operators with fragile backends once preferred it.

Where each model breaks

Seamless: your server is part of every spin

If your wallet endpoint slows down, every game slows down. If it goes offline, every bet fails across every studio at once. Players blame the game, not you, but they leave your casino either way.

Mitigations are standard engineering: keep the wallet service small and separate from the rest of your site, put it close to the aggregator’s servers, monitor latency per endpoint, and alert on error rates.

Seamless: the half-finished round

The player bets, the debit succeeds, the game shows a win, and the credit call fails three times. The aggregator will keep retrying, or queue the credit for later, or mark the round for manual settlement. Ask your vendor which. Then make sure your support team can see unsettled rounds, because the player will write in within minutes.

Transfer: money stuck in the middle

A transfer-in succeeds on the provider side but your server never gets the confirmation. The player’s money has left your balance in your mind but you do not know if it arrived. Or the reverse on transfer out. Each case needs a reconciliation job that asks the provider for its view and fixes the difference. Multiply by every provider, and reconciliation becomes a daily chore.

Transfer: the player in two games

With a transfer wallet, a player who opens two games from two providers needs money in two places. Many casinos simply block this, or pull everything back from game A before opening game B. That makes the experience clunky, especially on mobile where players switch quickly.

Transfer: bonus money

If you run bonus balances with wagering rules, a transfer wallet makes it hard to know which money is being wagered, because the provider sees one undifferentiated balance. In a seamless wallet you see every bet and can apply your own rules on each one.

Side-by-side

Where the balance sits during play. Seamless: your server. Transfer: the provider’s server.

Calls per spin. Seamless: one or two to your server. Transfer: none during play, two per session.

What fails when your server is slow. Seamless: every bet. Transfer: only opening and closing sessions.

Reconciliation effort. Seamless: compare your log with the vendor report. Transfer: chase each transfer that did not confirm.

Multi-game sessions. Seamless: natural. Transfer: awkward.

Bonus wagering control. Seamless: per bet. Transfer: per session at best.

Developer effort. Seamless: more up front, mostly in idempotency and rollbacks. Transfer: less up front, more in ongoing reconciliation.

Which one to pick

For a new casino in 2026, pick seamless unless you have a specific reason not to. It is what most aggregators and studios are built around, it gives you full control of bonus logic, and it makes a single balance across every product possible. The work it demands is real but it is one-time work.

A transfer wallet still makes sense in a few cases:

• You are adding a single provider that only offers transfer mode, and you do not want to build a second wallet path for one supplier.
• Your backend cannot guarantee fast responses and you cannot change that soon.
• You are building a game hub that resells to operators with very different technical levels, and you need a lowest-common-denominator option.

What to test before go-live

Ask your developer to run these against the sandbox, not just the happy path:

• Send the same debit twice. Balance should change once.
• Make your debit endpoint sleep past the vendor’s timeout. Confirm a rollback arrives and is applied.
• Send a rollback for a transaction ID you never saw. Your server should accept it and record it.
• Open two games in two tabs and bet quickly in both. Check the final balance by hand.
• Kill the wallet service mid-round, restart it, and see whether the pending credit lands.
• Compare one day of your transaction log with the vendor’s report to the cent.

If all six pass, your wallet is ready for real players. If your vendor will not let you run these in a sandbox, add that to the list of questions in our guide to choosing a game aggregator.

A note on prepaid credit

Wallet model and payment model are separate things, but operators sometimes confuse them. Some aggregators bill you monthly for GGR. Others ask for prepaid credit that is drawn down as players lose. With a prepaid model your seamless wallet works exactly the same way. The only extra job is watching the credit level so games do not stop when it runs out. SoftAggregator uses this prepaid approach, topped up in USDT or USDC, which suits crypto casinos that already hold stablecoins but means someone has to own the top-ups.