Seamless wallet integration
Why the operator stays wallet of record, how seamless differs from a transfer wallet, and what the difference means once Gold Coins and Sweeps Coins are both in play.
Two models, one of which fits dual currency#
There are two ways to connect a game supplier to a balance, and the choice decides most of what follows.
Seamless, or single wallet
One balance, held by the operator. The game side holds nothing and asks the operator’s ledger in real time, round by round. Nothing is ever moved anywhere.
Transfer wallet
Funds are moved to the game side at the start of a session and moved back at the end. For the length of that session, two systems each hold part of the answer.
This integration is seamless only. There is no transfer mode, no session float and no reconciliation job at the end of the night, because there is never a second copy of the balance to reconcile.
Why the ledger has to be yours#
A transfer wallet puts a second balance in play. With one currency that is an accounting nuisance. With Gold Coins and Sweeps Coins it is a compliance problem: the distinction between a coin with no cash value and a coin that can be redeemed is the entire legal basis of the model, and it cannot be allowed to live in two systems that reconcile eventually.
Keeping the ledger authoritative on your side collapses that risk. A regulator, an auditor or a player-support agent all ask the same system the same question and get the same answer, at the moment they ask it.
Where the currency context lives#
A callback URL is registered per currency. The currency is therefore fixed at the boundary, before any command reaches your handler, rather than being carried through the round and interpreted later.
That has a practical consequence worth designing around: the endpoint that receives a Sweeps Coins command can be a different URL, on a different route, with different authorisation, from the one that receives Gold Coins. Teams that split them early find the separation easy to evidence afterwards. Teams that funnel both through one handler and branch on a field inside spend the audit explaining themselves.
What this costs you in engineering time#
Less than most teams expect. The wallet side is one endpoint, a signature check, three handlers and a set of idempotency rules — a few days of work for an engineer who already knows the platform’s ledger.
The long pole is production readiness rather than the wallet: allowlists, monitoring on an endpoint that now sits in the path of every spin, and deciding what your platform does when its own ledger is slow. Budget for that, not for the protocol.
Reference#
The commands themselves, their fields, the idempotency rules and the status codes are in the wallet callback reference. This page argues the model; that page specifies it.
Last reviewed . Something wrong or missing on this page? Tell us.