Skip to main content
The integration has three actors and two API surfaces. Once you can name them, every page on this site falls into place.

Actors

Your platform

Owns the player, the wallet and the session token. Implements the wallet callbacks.

Zero-Dash

Owns the games, the round outcomes and the transaction ledger. Serves the Customer API.

Game client

Runs in the player’s browser. Talks only to Zero-Dash, never to you.
The game client never touches your systems. It authenticates through Zero-Dash, which relays to you over the signed server-to-server callbacks. Your wallet is never exposed to a browser.

The two API surfaces

Both use the same signature algorithm. Write it once, use it in both directions — one to sign, one to verify. See Request signature.

A game round, end to end

Three invariants hold for every round:

One debit

A round starts with exactly one /debit, identified by transactionId.

One settlement

Followed by exactly one /credit or one /rollback. Never both, never neither.

One round ID

Both carry the same gameRoundId. That is your join key for reporting and reconciliation.

Session resumption

Zero-Dash persists game sessions. If a player loses connectivity mid-round, closes the tab, or switches device, reopening the game resumes the round exactly where it stopped. The practical consequence for you: a settlement can arrive much later than the bet, sometimes days later after retries. Your /credit and /rollback handlers must not assume the player is still online. See Errors and retries.

What you build

A signed HTTP client

Calls the Customer API with the three auth headers.

Five HTTPS endpoints

/player, /debit, /credit, /rollback and the transaction lookup. Signature-verified, IP-restricted, idempotent.

A launch handler

Turns a player clicking a game tile into a launch URL and a new tab.

A catalogue sync

Caches List games and renders the artwork.