Seamless wallet vs transfer wallet
The wallet model decides where your money sits during play, how failures behave, and how painful month-end reconciliation is. There are only two options and the trade-offs are concrete.
How each model works
In a transfer wallet, the player's funds are moved from your platform into a provider-side wallet before play starts and pulled back when the session ends. The provider holds the balance while the player is in the game.
In a seamless (single) wallet, the money never leaves your platform. The aggregator calls your wallet endpoint for every balance check, bet, win and rollback, in real time, during the round. Your reply is authoritative.
Why seamless usually wins
The practical argument is stranded money. Transfer wallets leave balances sitting in provider wallets when a session ends badly — a dropped connection, a browser close, a failed pull-back — and your support team spends its week chasing them. A single wallet has nowhere for money to be stranded.
The second argument is bonuses and limits. Responsible-gambling limits, loss caps, bonus wagering and KYC gates all live on your platform. In seamless mode they apply to every round automatically, because every round asks you first. In transfer mode they only apply at transfer time.
- No stranded balances in provider wallets
- Limits, bonuses and RG rules apply per round, not per transfer
- One ledger to reconcile instead of many provider wallets
- Instant, accurate balance display across the whole lobby
What seamless demands from you
Seamless puts your wallet in the critical path, so it has to be quick and correct. Two non-negotiables: idempotency keyed on the provider transaction ID, and an explicit fail response when you decline an operation. A silent or ambiguous refusal is the single most expensive bug in this model — the round can continue against a debit that never happened, and the dispute lands weeks later.
Availability matters too. If your wallet endpoint is down, play stops. That is the correct behaviour, but it means the endpoint deserves the same uptime attention as your payment stack.
- Respond within a couple of seconds, consistently
- Unique index on the transaction ID — duplicates must be no-ops
- Explicit fail status plus current balance when declining
- Log the raw signed body of every callback for dispute evidence
When transfer wallet still makes sense
If your platform cannot expose a reliable low-latency endpoint — a legacy core, a batch-oriented ledger, or a regulatory constraint on real-time external calls — transfer mode is a valid fallback. Accept that you will operate a sweep job for stranded balances and reconcile more than one source of truth.
Frequently asked questions
Is a seamless wallet safer than a transfer wallet?
For money handling, yes in practice: funds never leave your ledger, so there are no stranded provider balances to reconcile. It does require your wallet endpoint to be fast, idempotent and available, since every round depends on it.
What happens if my wallet endpoint times out?
The operation fails and the round does not settle against an unconfirmed debit. A well-built integration retries with the same transaction ID, and your idempotency key ensures the retry moves money exactly once.
Can I switch from transfer to seamless later?
Yes, but plan it as a migration: you need the callback endpoint live, all provider-side balances swept back, and a cutover window. It is far cheaper to start seamless.