One of the first architectural decisions when integrating a casino aggregator is choosing between a seamless (single) wallet and a transfer wallet. It sounds boring — until you're 6 months in with reconciliation nightmares and unhappy players.

Seamless (single) wallet

Player balance stays on your server. Every bet and win is a real-time HTTP callback from the provider to your wallet endpoint. Player sees one balance across every game — no transfers.

Pros: One source of truth, instant balance, works perfectly with crypto/USDT wallets, no "stuck funds"
Cons: Your endpoint must be fast (<200ms) and always up — every game round depends on it
Best for: Crypto casinos, modern operators, anyone who wants full control

Transfer wallet

Player has a main wallet on your platform and a separate balance on the provider. Before playing, they transfer funds in; after playing, they transfer out.

Pros: No real-time dependency — provider outages don't kill your whole casino
Cons: Terrible UX, players forget funds on providers, constant support tickets, harder reconciliation
Best for: Legacy platforms, providers that don't support seamless

2026 verdict

Seamless wins in almost every case. Every modern provider supports it, latency is a solved problem with a good aggregator, and players expect a Netflix-style "one balance, everything works" experience.

The only reason to still use transfer wallet in 2026 is if you're on a legacy PAM that can't handle real-time callbacks — in which case, that's your real problem.

What we recommend

GamingAPI is seamless-first with sub-50ms wallet callbacks, HMAC-SHA256 signature verification and idempotency keys built in. Transfer wallet is available for the handful of providers that still require it, but 95% of our operators run pure seamless.

Want the full callback spec and a reference wallet implementation? Read the docs or talk to our integration team.