There is no “best wallet model” outside the platform architecture. Whether to choose a single wallet or a transfer wallet depends on the existing balance system, exception handling, reconciliation processes and the acceptable scope of changes.
This article explains procurement and architecture decisions. It does not include interface endpoints, callback protocols, signing, credentials or production configuration.
What is a single wallet?
A single wallet is often called a seamless wallet. Put simply, the platform continues to manage the player’s main balance, while collaboration related to game balances, debits, payouts or cancellations is completed through processes agreed by both sides.
Procurement should focus on confirming:
- Whether the platform wallet interface can meet real-time collaboration requirements;
- How duplicate and failed requests are handled;
- How balances, transactions and game records are reconciled;
- Who determines and escalates issues when the platform or supplier side has an exception.
A single wallet does not automatically mean “zero risk” or “no changes.” It places clearer requirements on interface stability, duplicate handling and exception responsibilities.
What is a transfer wallet?
A transfer wallet usually transfers a balance from the platform side to the game supplier side first, then transfers it back or handles the remaining balance according to the process agreed by both sides when the player leaves the game.
Procurement should focus on confirming:
- How deposits, withdrawals and balance status are recorded;
- How interruptions or failures are recovered;
- How the platform balance and supplier-side balance are reconciled;
- Whether the player journey and the platform’s existing experience can accommodate additional steps.
A transfer wallet does not automatically mean “simpler” either. It moves some complexity into balance transfers, status and reconciliation processes.
What should be compared between the two models?
| Comparison item | Single-wallet focus | Transfer-wallet focus |
|---|---|---|
| Existing architecture | Whether the platform wallet can collaborate reliably | Whether mature transfer and status management already exist |
| Exception handling | Duplicates, timeouts, failures and balance consistency | Transfer interruptions, uncertain status and recovery |
| Reconciliation | Transaction, round and balance records | Platform and supplier-side balances and transaction records |
| Player journey | Real-time collaboration during gameplay | Whether deposits and withdrawals affect the experience |
| Technical scope | Callback and idempotency requirements | Balance transfer and state-machine requirements |
The table is used to organize technical discussions. It does not represent an AG commitment concerning any specific implementation, performance or automation capability.
What should the testing phase cover?
Whichever model is chosen, the success path alone should not be verified. At minimum, it is advisable to confirm:
- Normal launch and normal transaction paths;
- Insufficient balance, failed requests or session exceptions;
- Duplicate requests or repeated delivery of the same status;
- How records, rounds or balance differences are reconciled;
- Issue materials, responsible people and escalation methods.
Which questions cannot be decided by a public article?
Complete interface protocols, environment domains, signing, callback fields, credentials, allowlists, latency, capacity, stability, market conditions and commercial terms must all be confirmed in a controlled project process.
What AG can currently confirm is that existing business materials cover two integration topics: single wallet and transfer wallet. The specific compatibility approach, test environment and delivery scope still depend on the platform architecture and the result of project confirmation.
Need to turn this guidance into a project plan?
This article supports project evaluation and does not replace technical, contractual, certification or local-law confirmation.