Integration Checklist

Exchange integration details

Phoenix sets up your operator and its two environments, sandbox and prod. See What to Send Phoenix for the full list. In short:

• Once, for your operator: display name, currencies, languages (default first), formatting country, and a business and a technical contact.
• For each environment: your Ed25519 public key, your public https wallet base URL, the exact origins of the pages that will frame the embed, a test player for the wallet test, and each currency's minimum and maximum order size.

You keep the private keys. Phoenix gives you your operator code and back-office access for your Admin, who can then review and change most of these values under Manage > Your operator.

Mint launch tokens

Your backend mints EdDSA JWTs signed with the environment's private key (see Launch Tokens):

• Visitor tokens (no sub) let anyone browse.
• Player tokens (sub set to your player id) let a signed-in user trade, see their portfolio and save events.

Every token needs iss, env (sandbox or prod), exp and a currency your operator offers. Never mint tokens in browser code.

Phoenix issues no session token of its own: the embed uses your token for every reconnect. Choose the lifetime with Sessions and Token Refresh in mind.

Embed the iframe

Use the Host SDK:

import { PmmEmbed } from '@phoenix-games-io/pmm-embed'

const embed = PmmEmbed.mount({
  container: '#market',
  url: 'https://embed.prediction.phoenixverse.io/o/acme',
  token: launchToken,
})

Or build the iframe yourself (see Iframe Launch). Either way the page must be served over https; list its origin on the environment.

Connect the events

The iframe hands operator-owned actions back to your page:

• auth.requested: sign the user in, mint a player token, call setToken.
• deposit.requested and profile.requested: open your cashier or account page.
• token.expiring and session.expired: mint a fresh token for the same session and call setToken.

After any balance change outside the embed, push the new balance with balanceUpdate. Bridge events coordinate the UI; money truth stays in your backend and the wallet calls.

Implement the wallet

Phoenix calls your wallet when prediction cash moves (see Wallet Model and Wallet Operations):

• reserve_cash before a buy order opens. This is the only call your wallet may decline.
• capture_cash when a buy fills, release_cash for unused reserved cash.
• credit_cash for sell proceeds, rebates, payouts and refunds.
• balance to show the player's balance when the embed connects.
• Optionally transaction_status, to report a move's stored outcome by its idempotency key, for your own reconciliation. Phoenix never calls it.

Verify Phoenix's signature on every call and make every idempotency key safe to repeat.

Choose languages and look

• Decide who owns the player's language: your site (send language in tokens and call setLanguage) or the embed's picker. See Languages.
• Set your look (logo, font, colors, corners, spacing, mode, layout, chart style), your betting settings (quick amounts, starting amount, price formats) and your player protection (safer-gambling message, links, refusal reasons) once in the back office, and pass per page only what should differ, such as a different price format among the ones you allow. See Customization.
• Hide the deposit or profile button per player with the token's cfg claim if you need to. See Player Buttons.

Test, then go live

Run the wallet test against sandbox until it clears, try the flows by hand, then repeat in production. The Go-Live Checklist lists everything to confirm.