In brief
- Draw the money and identity flows before discussing screens or SDK calls.
- Separate the player wallet from card processing, casino ledger, TITO and compliance records.
- Name one owner for reconciliation, outages and every cross-system exception.
A cashless casino project is not one API. It is a chain of systems that must agree about a person, a balance and a transaction. The safest first deliverable is therefore a boundary map, not a polished wallet screen.
Start with four flows
Draw four diagrams: enrolment and identity verification; funding; wagering and redemption; and reconciliation. For each step, label the system that creates the record, the system of record, the identifier passed downstream and the team responsible for failure recovery.
Keep card data out of the game client wherever possible. The PCI Security Standards Council says payment terminals are part of an entity's cardholder data environment and are in scope for PCI DSS. It also explains that the controls vary with the device and its configuration. That means a terminal, kiosk and mobile acceptance flow cannot automatically share the same security assumptions.
Define the ledgers and identifiers
List the wallet ledger, casino-management ledger, TITO record, player-account record and payment-processor record separately. For each one, document its transaction ID, timestamps, status model and reversal rules. Do not treat a successful HTTP response as proof that every ledger settled.
Decide how duplicate requests are detected and make funding, withdrawal and transfer requests idempotent. Record which identifier links a cage adjustment or TITO event back to the wallet. Define what the player sees while a downstream service is unavailable and who can release a held transaction.
Keep compliance data usable
For US operations, FinCEN's casino guidance says programs for casinos with automated data processing systems must use those systems to aid in assuring BSA compliance. It also says a casino or card club is responsible for risk-based internal controls for detecting, analysing and reporting potentially suspicious activity.
Translate that into technical questions: Can compliance staff connect wallet, kiosk, cage and TITO activity to the same verified customer? Are corrections auditable? Can records be exported without manual re-entry? Requirements differ by jurisdiction, so local counsel and compliance teams must define the actual rules; this checklist is architecture guidance, not a legal conclusion.
Test failures, not only happy paths
Before launch, test duplicate messages, delayed callbacks, partial reversals, offline terminals, expired sessions and mismatched balances. Verify that retrying never creates money or loses the original audit trail.
Run a daily reconciliation with known totals and an exception queue that assigns each mismatch to a human owner. Finally, rehearse how the system returns to service after an outage. A cashless experience feels simple only when the operational boundaries underneath it are explicit.
Sources
Would you like to discuss this further?
Share your details so Slotgen can respond with the context of this article and campaign source.
Request a consultation →