Casino aggregator wallet models
A buyer's technical model for seamless or remote wallets, transfer and shadow balances, authoritative ledgers, debit, credit, rollback, idempotency, interrupted rounds, and daily reconciliation between the PAM, aggregator, RGS, and game provider.
Three independent architecture decisions
Balance experience, ledger ownership, and transaction protocol
Wallet detail status
Current wallet fields in aggregator profiles
The table shows wallet-related product fields. An empty cell means the wallet model is unconfirmed; it does not establish that wallet integration is absent.
| Provider / product | Wallet detail | Wallet model | Ledger authority | Debit / credit / rollback semantics | Status |
|---|---|---|---|---|---|
| Aristocrat Interactive Fusion (Pariplay) | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| BetConstruct Casino Platform | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| Bragg Gaming Group Bragg Hub | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| Digitain Casino Engine | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| EveryMatrix CasinoEngine | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| EveryMatrix SlotMatrix | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| GR8 Tech Infinite Casino Aggregation | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| Light & Wonder (iGaming) OpenGaming (OGS) | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| NuxGame Casino API | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| Pariplay Fusion | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| Slotegrator APIgrator | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
| SOFTSWISS SOFTSWISS Game Aggregator | Wallet detail not confirmed | Not confirmed | Not confirmed | Not confirmed | Wallet architecture not confirmed |
Transaction state model to demand from every supplier
Failure acceptance matrix
Run these against the exact PAM, aggregator, RGS, wallet, environment, currency, and game configuration. Retain requests, responses, logs, ledger entries, round state, reconciliation, and defect disposition.
| Failure | Test | Acceptance condition |
|---|---|---|
| Debit posted, response lost | Retry the same transaction ID after a network timeout. | Exactly one debit; replay returns the original outcome or a deterministic duplicate acknowledgement. |
| Concurrent duplicate debit | Submit the same debit in parallel through separate workers. | Ledger-boundary idempotency allows one posting only; logs retain both requests and the decision. |
| Credit before debit | Send a win or refund before an accepted wager exists. | Reject, queue, or hold under documented ordering rules; later replay cannot create an unmatched or duplicate credit. |
| Rollback after settlement | Attempt a late rollback after credit or completed settlement. | Apply the defined resettlement path or reject; never rewrite history or silently corrupt GGR and balance totals. |
| Late game result | Settle an open round after timeout, restart, or failover. | One documented final state, player-visible history, wallet posting, ageing record, and exception owner. |
| Aggregator, PAM, or RGS outage | Interrupt each dependency before debit, after debit, and before credit. | Durable transaction state, bounded retries, no orphan movements, recoverable rounds, and component-level reconciliation. |
| Currency precision mismatch | Submit boundary and unsupported decimal values for every enabled currency. | Deterministic validation or rounding defined once; request, response, game amount, and ledger amount reconcile. |
| Free spin or jackpot interruption | Drop acknowledgements around award consumption, contribution, or payout. | Award, liability, contribution, payout, round, and wallet state post exactly once and reconcile across systems. |
Minimum daily reconciliation pack
The operator needs raw, stable identifiers and control totals—not only a dashboard total or a supplier assurance that balances match.
- Legal entity, brand, market, wallet, balance bucket, currency, product, provider, game, and business date
- Opening and closing balance with count and value of debit, credit, rollback, void, adjustment, reservation, and release
- Unique transaction, idempotency, game-transaction, round, jackpot, free-spin, wallet-entry, and source-system identifiers
- Unmatched records by direction, duplicate IDs, orphan rounds, stale reservations, open rounds, late settlements, and ageing
- Event time, posting time, source and target watermark, retry count, response code, error, owner, action, and closure evidence
- Signed daily control totals, variance threshold, escalation, correction entry, replay approval, and retained audit output
Technical baselines to map into the protocol
Use the applicable jurisdiction's current rules and test-house scope. The following public baselines help frame accounts, transaction display, interrupted play, audit, and recovery, but do not replace the proposed API specification or contract.
Wallet integration questions
What is a seamless wallet integration?
In a seamless or remote-wallet model, game transactions call the platform wallet instead of maintaining a separately funded game balance. The label does not define ledger ownership, synchronous or asynchronous behaviour, idempotency, ordering, rollback, timeout, or reconciliation rules; those require the exact protocol.
What is a transfer wallet?
A transfer-wallet model moves value between the platform wallet and a separate game or shadow balance. The transfer, available and pending balances, return of residual funds, failed transfer handling, and reconciliation must be explicit.
Does 'single wallet' prove a seamless remote-wallet API?
No. It can describe the player experience or a shared product balance without documenting the transaction protocol. The wallet model remains unconfirmed until protocol-level detail covers ledger authority, transaction states, failure handling, and reconciliation.
Which system should be the authoritative ledger?
The architecture must name exactly one authority for each balance and lifecycle stage. A PAM is often the cash-ledger authority, but a product can use reservations or shadow balances. The buyer must verify the proposed design, legal entity, reconciliation, and failure behaviour.
What evidence should the supplier provide?
Versioned API specifications, sequence diagrams, error and retry tables, idempotency retention, ordering rules, sample logs, certification scope, open-round and replay procedures, daily reconciliation exports, incident tests, and the matching contract and SLA schedules.