Verified against d96759dMarkdown

For game providers

PlayerPal lets the rounds your games already settle earn Points for linked players, and gives your studio analytics on how those players play, without handling personal data or sitting in the game loop. You report facts about settled rounds; PlayerPal does the loyalty calculation.

The labels mean: Available (built and tested in the platform), In development (being built; behaviour may change) and Planned (designed, not built yet).

What you get

Capability	What it means for you	Status
Activity from game rounds	Settled rounds sent in batches earn Points for linked players	Available
Studio analytics	Rounds, bets, wins and share of turnover for the players reached through your integrations	Available
Cohort analytics	Distinct-Account counts across all your integrations, with small groups suppressed	Available
KPI API and comparisons	Own KPIs, anonymous comparison with the network, and peer benchmarks among providers	Available
PlayerPal widget	A PlayerPal panel you can show inside your game experience	In development
Provider launch sessions	A pattern for receiving launch context from the operator safely	In development · demo
Provider portal	Browser workspace for your studio analytics	In development · demo

Aliases scoped to one casino

Available

A provider works with many operators, so PlayerPal gives you a separate Alias (pp_plr_prv_…) for each provider-operator integration. The same player at two casinos reaches you as two unrelated Aliases. You cannot join a player across casinos through PlayerPal, and no other party can join your Aliases with theirs.

Aliases are random and contain no personal data, account IDs or timestamps.
Your integration, not a field in the payload, decides which casino an event belongs to.
An Alias issued to someone else gets the same response as one that does not exist.

Off the game path

Available

PlayerPal is never called at launch, bet or settlement. The operator places your provider Alias in its existing launch payload. Your backend writes eligible rounds to its own outbox and sends them to PlayerPal in batches after settlement, retrying until they are accepted. If PlayerPal is unavailable, games keep running and winnings are paid as normal.

The operator creates a short-lived launch session through your own backend; PlayerPal is not involved. Launch context is passed in a single-use request body, never in the game URL. Your page receives only your integration's Alias and a coarse connection status. Points balances, the ledger and the player's private PlayerPal ID stay on PlayerPal surfaces.

You load the PlayerPal widget as an exact, versioned build from PlayerPal, checked with Subresource Integrity. You do not rebuild or redistribute it, and a widget failure never blocks play.

Part	Status
Versioned widget builds served with integrity hashes	Available
Launch session pattern	In development · demo
Provider-led linking from inside your experience	Available

Studio and cohort analytics

Available

Studio analytics count distinct Accounts across all of your integrations, so a player who plays your games at two casinos is counted once. Windows with fewer Accounts than the minimum are suppressed. You can also look up figures for a single Alias that was issued to you; the response contains numbers only, such as rounds and turnover with you and elsewhere.

The KPI API adds your own KPIs, a comparison with the rest of the network and benchmarks against other providers, all behind the same anonymity rules. See Privacy thresholds.

Integration status

Part	Status
Activity batches and large uploads, idempotent	Available
Per-partner credentials for activity batches	In development
Daily game and catalogue facts through fact ingest	Available
Studio analytics and KPI API with OAuth or signed requests	Available