Protocol diligence · not a feature-label comparison

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.

Inspect recorded provider wording Download acceptance tests

12 aggregator product cards reviewed3 cards with wallet wording recorded0 normalized protocol models inferred from those labelsDataset snapshot August 2, 2026

“Single wallet” describes too little to pass technical diligence

A product card can describe one player balance while saying nothing about the authoritative ledger, debit acceptance, transaction ordering, retries, rollback, open rounds, or reconciliation. Until versioned API and operational evidence is reviewed, every normalized protocol field below remains “not assessed”—not “unsupported” and not “unavailable.”

Three independent architecture decisions

Balance experience, ledger ownership, and transaction protocol

Dimension 1

Balance model

Seamless/remote calls, transfer or shadow wallet, hybrid reservation, or another documented design. This is how value moves or appears during play.

Dimension 2

Authoritative ledger

The system and legal entity that own cash, bonus, locked, pending, reserved, jackpot, and product balances plus the immutable posting history.

Dimension 3

Protocol semantics

Synchronous or asynchronous requests, accepted-wager point, IDs, idempotency lifetime, ordering, timeouts, retries, rollback, replay, and finality.

Evidence gap table · no protocol inference

What the normalized aggregator product records contain

These are stored editorial product descriptions, highlights, or features that contain the word “wallet.” Claim-level evidence is not normalized for those text fields. An empty cell means the current record does not contain such wording; it does not prove the supplier has no wallet integration.

Recorded wallet wording and unassessed protocol fields for game aggregator product cards
Provider / product	Recorded wallet wording	Normalized model	Ledger authority	Debit / credit / rollback semantics	Evidence boundary
Aristocrat Interactive Fusion (Pariplay)	No wallet wording stored in the current product card	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Field not recorded in the normalized product cardRelated product page
BetConstruct Casino Platform	No wallet wording stored in the current product card	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Field not recorded in the normalized product cardRelated product page
Bragg Gaming Group Bragg Hub	No wallet wording stored in the current product card	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Field not recorded in the normalized product cardRelated product page
Digitain Casino Engine	Digitain's Casino Engine aggregates third-party content behind a unified integration, covering slots, jackpots, RNG tables, live casino, crash, and bingo. The current catalogue and provider figures are retained once in structured evidence rather than presented as a guaranteed customer entitlement. Content ties into the platform's bonus engine, loyalty tools, and shared wallet. Cross-vertical wallet and bonusing Single-wallet integration	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Recorded editorial product text · source status not normalizedRelated product page
EveryMatrix CasinoEngine	No wallet wording stored in the current product card	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Field not recorded in the normalized product cardRelated product page
EveryMatrix SlotMatrix	No wallet wording stored in the current product card	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Field not recorded in the normalized product cardRelated product page
GR8 Tech Infinite Casino Aggregation	No wallet wording stored in the current product card	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Field not recorded in the normalized product cardRelated product page
Light & Wonder (iGaming) OpenGaming (OGS)	No wallet wording stored in the current product card	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Field not recorded in the normalized product cardRelated product page
NuxGame Casino API	A single-wallet aggregation API that connects operators to thousands of slots, table games, and live casino titles plus engagement tools. It consolidates per-provider connections behind a unified integration layer; implementation work still depends on the existing platform and target market. Single-wallet integration Single-wallet API	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Recorded editorial product text · source status not normalizedRelated product page
Pariplay Fusion	No wallet wording stored in the current product card	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Field not recorded in the normalized product card
Slotegrator APIgrator	No wallet wording stored in the current product card	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Field not recorded in the normalized product cardRelated product page
SOFTSWISS SOFTSWISS Game Aggregator	A unified API that gives operators access to a multi-studio catalogue managed from a shared back office and wallet. It is available standalone for third-party platforms. The current Games List back-office tool adds title, provider, feature, licence, and market-availability views; the June launch release describes export as planned rather than currently available. Unified wallet Unified wallet and back office	Not assessed	Not assessed in the normalized dataset	Not assessed in the normalized dataset	Recorded editorial product text · source status not normalizedRelated product page

Transaction state model to demand from every supplier

Available

The authoritative spendable cash or bonus balance before the wager. The system of record and bucket priority must be explicit.

Evidence: Opening balance, wallet ID, currency, brand, jurisdiction, bucket, and ledger watermark.

Reserved or pending

An optional durable hold while acceptance or a multi-step game outcome is unresolved. It cannot be an invisible duplicate balance.

Evidence: Reservation ID, amount, expiry, round, transaction, release rule, and player-visible treatment.

Debited

The accepted wager has one immutable debit linked to the accepted game transaction and round.

Evidence: Idempotency key, debit ID, game transaction ID, round ID, event time, posting time, and response.

Credited

A win, refund, or other credit is posted once and linked to the debit, result, round, and correct balance bucket.

Evidence: Credit ID, result, amount, source transaction, game version, bucket, and settlement status.

Rolled back or voided

A compensating entry neutralizes an accepted posting according to documented rules; history is retained rather than overwritten.

Evidence: Original and compensating IDs, reason, actor/system, time, amount, round state, and replay outcome.

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.

Download the test matrix CSV

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. This page keeps the supplier wording visible but leaves the normalized model unassessed until protocol-level evidence is reviewed.

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.

Aggregator shortlist Migration checklist RFP checklist