# ADR 0015. PlayerPal Is an Async Loyalty Sidecar

## Status
Accepted.

Together with [ADR 0016](0016-bff-cookies-and-machine-oauth.md), supersedes
[ADR 0003](0003-session-jwt-at-boundary.md) for gameplay. Strengthens
[ADR 0004](0004-async-first-ingestion.md).

## Context
If PlayerPal sits in game launch, wager or payout, an identity outage becomes
a casino outage. Partners will not accept that. Loyalty can be delayed;
settlement cannot.

## Decision
If every PlayerPal service is unavailable, the operator and provider must
still authenticate the player, launch the game, accept bets, settle rounds
and pay winnings.

- No PlayerPal call before or during game launch.
- No PlayerPal call per wager or round.
- The provider receives `pp_plr_prv_...` in the operator's existing launch
  metadata (provisioned at link time).
- Activity is written to a local outbox and submitted in asynchronous batches.
- Overlay/status reads are optional and must fail open with respect to play.

Interactive linking may fail; the game remains usable.

## Consequences
- Token refresh is per integration worker (minutes), not per player.
- IAM outages must not invalidate already accepted batches.
- Interactive/core and ingestion scale independently (spec §41).
- See [docs/ingestion-and-availability.md](../ingestion-and-availability.md)
  and spec §34.