> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zerodash.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Account ID

> The identifier that ties a player to every bet, transaction and report — for life.

You return `accountId` from [Player authorization](/api-reference/callbacks/player). From that moment it is the identity Zero-Dash uses for everything about that player.

<Card title="Zero-Dash keys the following on accountId" icon="link" horizontal>
  All bets · all transactions · reporting, telemetry and audits
</Card>

## The four requirements

<CardGroup cols={2}>
  <Card title="Unique per player" icon="fingerprint">
    No two players may ever share an account ID.
  </Card>

  <Card title="Permanent" icon="infinity">
    Stable for the player's entire lifetime. It is never re-issued and never reused.
  </Card>

  <Card title="No personal data" icon="user-shield">
    No email, no name, no username, no document number. Nothing that identifies a human.
  </Card>

  <Card title="One currency each" icon="coins">
    An account ID maps to exactly one currency, permanently.
  </Card>
</CardGroup>

<Warning>
  Changing a player's account ID orphans their entire history. Bets, transactions, reports and audit trails all key on it, and there is no migration path. Choose the scheme once and never revisit it.
</Warning>

## Choosing an identifier

<Tabs>
  <Tab title="Good">
    ```json theme={null}
    { "accountId": "acct_8f2c19a4b7" }
    { "accountId": "9c1f0d2e-6b5a-4c8f-9e21-3a7b5d4f0c11" }
    { "accountId": "usr-104857-usd" }
    ```

    Opaque, stable, carries no personal data. The third form encodes the currency, which makes multi-wallet players easy to reason about.
  </Tab>

  <Tab title="Bad">
    ```json theme={null}
    { "accountId": "matthew.smith@example.com" }   // personal data
    { "accountId": "MatthewS" }                    // personal data, and renameable
    { "accountId": "AB1234567" }                   // document number
    { "accountId": "session-7f3a91c" }             // not permanent
    ```

    Each of these either exposes a person or changes over time.
  </Tab>
</Tabs>

<Tip>
  Your existing internal player ID is usually the right answer, as long as it is not personal data and not renameable. Prefix it if you want to keep it opaque — `acct_` plus the ID is fine.
</Tip>

## One currency per account

This is the requirement most likely to bite a multi-currency platform. An account ID may only ever be associated with **one** currency.

A player who holds a USD wallet and a BTC wallet is **two account IDs**:

```json theme={null}
// USD session
{ "accountId": "usr-104857-usd", "balance": { "amount": 12.45, "currency": "USD", … } }

// BTC session
{ "accountId": "usr-104857-btc", "balance": { "amount": 0.00031200, "currency": "BTC", … } }
```

Each session launches with its own currency and its own token, and each account ID accumulates its own history.

<Warning>
  Returning a different currency for an account ID we have already seen is a hard failure. The ledger is denominated per account; there is no conversion path mid-stream.
</Warning>

## Where it appears

| Context                                                                                                                                    | Field         |
| ------------------------------------------------------------------------------------------------------------------------------------------ | ------------- |
| [Player authorization](/api-reference/callbacks/player) response                                                                           | `accountId`   |
| [Debit](/api-reference/callbacks/debit), [credit](/api-reference/callbacks/credit), [rollback](/api-reference/callbacks/rollback) requests | `playerId`    |
| [Transaction lookup](/api-reference/callbacks/get-transaction) path                                                                        | `{accountId}` |
| [Free rounds bonus code](/api-reference/customer/create-bonus-code) request                                                                | `userId`      |

<Note>
  Four field names, one identifier. `playerId` in the money callbacks is the same value you returned as `accountId` — resolve it the same way everywhere.
</Note>

## Display name

Alongside the account ID you return `displayName`, shown to **other players** in shared surfaces such as multiplayer chat and live bet lists.

<Columns cols={2}>
  <Card title="Do" icon="check">
    `Matthew S.` · `Player_4821` · `LuckyDuck77`

    Abbreviated, pseudonymous, safe to show publicly.
  </Card>

  <Card title="Do not" icon="xmark">
    `matthew.smith@example.com` · `Matthew Smith`

    Full names and contact details are visible to strangers.
  </Card>
</Columns>

<Warning>
  `displayName` is broadcast to other players in the same game session. Treat it as public.
</Warning>

## Sub-operators

Several brands behind a single integration? Return `subOperatorId` and the games use it to keep shared surfaces separate — for example, one chat room per brand rather than one for everyone.

```json theme={null}
{
  "accountId": "acct_8f2c19",
  "displayName": "Matthew S.",
  "balance": { "amount": 12.45, "currency": "USD", "updatedAt": "2026-01-29T14:05:29.678Z" },
  "subOperatorId": "9"
}
```

Optional. Omit it entirely if you run one brand.