ADR 0030. Unlink and Delete Account live on the PlayerPal Account

Status

Accepted (as listed in the decisions index).

The APIs exist (DELETE /v1/me/connections/:audienceId, DELETE /v1/me). Players will look for the verbs on Bucks Connected services. Hosting them there makes Unlink look like a casino setting. The widget may grow the same verbs later; v1 does not.

Decision

The Player Unlinks one Audience and Deletes the Account only on the PlayerPal Account screen. Each Connected partners row is one Audience, labelled with Party display_name (not PII). Operator-led Unlink of that operator Party cascades provider connections for that operator; provider-led Unlink is that integration only.

Reauth reuses the recovery-code step-up. Unlink confirms consequences (play continues, Points stay, later Activity does not earn, relink mints a new alias). Delete Account is a danger zone on the same screen: reauth plus a checkbox that Bucks/Google stay. After Unlink, stay on Account. After Delete Account, sign out to the player landing with a one-shot flash.

Bucks Connected services deep-links to that Account. It does not gain an Unlink control. Linked copy names the PlayerPal verbs. On show/focus it re-queries operator link status so Connect returns when Bucks knows. Demo Bucks applies an async PlayerPal notice and may reconcile the stored alias (ADR 0032). If the notice has not landed and PlayerPal is unreachable, stale-linked plus Open portal is still allowed.

Consequences

• GET /v1/me connections include a config label from Party display_name.
• Widget Unlink is a later slice, not a missing v1 control.
• Casino Log out remains a presenter reset; it is not the Unlink path.