Start with the owner of the balance
In the callback wallet model planned for WGC, the casino platform holds the player wallet. WGC asks that platform for a balance or for the result of a gaming transaction. The player reference identifies an account in the casino’s system; it is not the commercial account used to access WGC. Agree on this ownership boundary first so that both teams know which system is authoritative when a request fails or an amount is disputed.
Follow a transaction through the systems
A typical integration needs a balance check and a way to record a stake and its result. WGC’s callback contract names these getBalance and writeBet; writeBet carries bet and win in one request. Keep the player, currency, game, round and transaction references together. A launch URL is only the entry point to a game. It does not confirm that a balance check, settlement or reconciliation has completed.
Treat a retry as the same transaction
A network timeout can happen after an operation was accepted but before the response reached the caller. Repeating that operation blindly can debit a player twice. An idempotent handler recognises the same transaction identifier and returns the recorded result instead of applying the amounts again. Include concurrent duplicates, delayed responses and a retry after a timeout in the acceptance tests. Session-opening retries are a separate contract and should not be assumed to have the same behaviour.
Make currency and amounts explicit
A player wallet may use a different currency from the operator’s commercial account. Every transaction must identify its currency and follow the agreed precision rules. The WGC commercial account balance is in USD and is not the player’s spendable balance. Do not derive one from the other or assume that a currency displayed in a backoffice is already supported by every provider and game. Confirm the intended combinations before testing.
Test failures as well as successful play
Prepare checks for insufficient funds, an unknown player, an unsupported currency, an invalid signature, a delayed response and duplicate delivery. Preserve the transaction reference and a support request identifier in your own operational records. Compare the accepted transactions on both sides, not just the final balances. A successful dry run can validate a message shape, but it cannot prove that a real supplier and your wallet settle correctly together.
Confirm the readiness of each connection
WGC provides a callback contract and a tester for preparing this work. Supplier wallet callbacks remain under development, so a production-ready seamless wallet is not implied by the public site. Discuss the current supported flow, failure policy and acceptance criteria with the integration team. Access details are provided directly by your manager.