Player experience

Use this guide to train support staff and rehearse the Mini App journey in staging. OpenPoly provides the screens described here; operators do not need to build a separate Polyflight UI or Wallet Adapter.

Polyflight shares its board, purchase presentation, strategy calculator, flight history, and proof replay with the Polynion web experience. Funding stays separate: Mini App players use their operator's IDR wallet, not Polynion Credits.

Where players go

These paths belong to the Mini App Client, not the Operator Dashboard or Operator API.

Tickets appear on the live-board page; there is no separate client /polyflight/tickets page. The Operator Dashboard's Polyflight → Tickets is a different, staff-only reporting screen.

Launch players through the returned launch_url, not by sending an unauthenticated player directly to one of these paths. See Overview and launch.

Read the live board

The Departures / Arrivals board shows each flight's code, eight-digit board, status, countdown, and weather. Flight-board times are UTC. They are not the operator's monthly settlement timezone.

• Scheduled: wait for the flight to open.
• In flight: a compatible IDR flight can accept tickets until its purchase gate closes. Select Buy ticket when available.
• Landing: wait for the published result; a countdown is not confirmation that settlement or wallet delivery has finished.
• Landed: use Flight history to inspect the result and proof.

The moving board is not the final result. Before landing, option activity is shown as heat levels, not exact ticket counts or money totals. Do not present a popular option, weather condition, or moving digit as a guaranteed winner.

A missing Buy ticket action does not necessarily mean the operator wallet is broken. The flight may not be open, may not support native IDR, or the live connection may be stale. A visible New purchases are paused notice means new entry is suspended; existing tickets and owed payments remain available.

Buy an IDR ticket

1. Open an eligible flight from the live board.
2. Select ABCD or EFGH, then one of that group's displayed four-digit options. ABCD covers the first four result digits; EFGH covers the last four. One ticket selects one group and one option, not the entire eight-digit result.
3. Enter the stake in whole IDR. The minimum and step are both 1,000 IDR. The +1K, +5K, and +10K controls add to the stake; MAX uses the available wallet balance rounded down to a valid step, subject to the technical ticket limit.
4. Review the server quote: fee, net stake, potential payout, net profit if won, and estimated balance after purchase.
5. Move Slide to buy fully to the end to submit.
6. Follow the purchase state on the live board. Acceptance pending is not an admitted ticket. Accepted means the ticket was admitted.

The Mini App disables purchase when the wallet is unavailable, the balance is insufficient, the quote no longer matches the stake or flight, the live board is stale, or the purchase gate has closed. Changing the amount requires a fresh matching quote. Displaying a quote does not reserve admission before the gate.

The wallet header shows the operator's IDR balance and includes a refresh control. Refresh it when investigating a stale display; do not create another purchase to test whether a previous debit worked.

Example: one 10,000 IDR ticket

Assume the player starts with 100,000 IDR and buys one available ABCD option for 10,000 IDR. No other wallet activity occurs.

If that ABCD option wins, the wallet receives 38,000 IDR, bringing the balance to 128,000 IDR. It does not receive another 10,000 IDR on top. If the ticket loses, the operator wallet receives a zero-amount losing-result notification to acknowledge, not a payout, and the balance remains 90,000 IDR. If the flight is cancelled and the refund completes, the full 10,000 IDR returns, bringing the balance back to 100,000 IDR.

No IDR-to-Credits conversion occurs in any of these wallet movements. See Native wallet contract for exact reasons, keys, and payloads.

Use the strategy calculator

Open Strategy calculator on a flight row or from the purchase dialog. It shows:

• the current or frozen board, weather, landing countdown, and board-freeze countdown;
• the moving columns and their estimated steps;
• option rankings and the counted favorite;
• the flight's published counted-favorite chance;
• Copy AI prompt, which copies the flight's calculation context for use outside the Mini App.

Before the checkpoint, the calculation is provisional. The calculator identifies when it uses the official frozen board. A counted favorite is not a promised result, and copying an AI prompt neither places a ticket nor changes the flight. Players still select an option and confirm a purchase separately.

Track tickets and payments

The live-board ticket panel has Active tickets and Recent results tabs. It shows committed IDR, a next-result countdown, and 24-hour net results. It is a recent-activity view, not an account statement. The panel can be absent for a player with no recent tickets or purchases; that alone is not a loading failure.

Recent failed or compensated purchase attempts remain visible so a player can distinguish an unsuccessful purchase from an admitted ticket. An unsuccessful attempt does not increase the accepted-ticket count.

The displayed net result is calculated from ticket outcomes. It is not proof of cash received: a won ticket can show a positive net result while its payment is still owed. For investigation steps, use Operations and reconciliation.

The zero-amount loss credit is a wallet-facing result notification, not money returned to the player. Its delivery lifecycle may say owed, in_flight, paid, or manual_review; for a loss, those states mean acknowledgement outstanding, in progress, confirmed, or needing investigation. They never mean a delayed payout, and must not turn a Lost result into “payout pending.” The existing ticket.resolved callback remains authoritative; there is no loss payout pending/processed callback. Historical losses are not backfilled.

Inspect history and the Black Box

1. Select Flight history from the live board or navigation.
2. Open a landed flight. Other flight states lead to flight details instead.
3. Check the published eight-digit result and Machine proof verified status.
4. Inspect the ABCD and EFGH rankings, anonymous ticket count, participating currencies, and disclosed valuation evidence.
5. If the player bought tickets for this flight, inspect Your tickets on this flight. Each ticket has a payment/outcome badge and a separate proof-classification badge.
6. Use the proof replay and Machine proof download when investigating the result.

A verified global proof does not confirm that an individual wallet credit arrived. Likewise, Proof mapping pending, Ticket absent from proof, a mismatch, or an unverified global proof is not a successful per-ticket check. Capture the flight code and ticket ID and escalate the discrepancy rather than promising a payout based only on the screen.

Public proof contains anonymous flight evidence. The player's private ticket and wallet status remain session-scoped. See API, events, and proof for the verification contract.

Staging walkthrough

Use a dedicated simulator user and the real single-use launch flow. Keep the operator-wide REST v1 adapter configuration unchanged.

1. Launch product: "polyflight" and confirm the IDR wallet and live board load.
2. Open the calculator, switch between ABCD and EFGH in the purchase dialog, and review a 10,000 IDR quote.
3. Submit one ticket and follow pending admission through to its terminal purchase state. Reload and confirm the existing purchase or ticket remains visible.
4. Follow the flight to a result. Check the ticket's result separately from its payment state.
5. Open Flight history, inspect the flight's Black Box, and download its machine proof.
6. In the Operator Dashboard, correlate the same purchase/ticket with its balance operation and webhook evidence.

This walkthrough covers the player journey. It does not replace the separate real-adapter failure and idempotency drills in Operations and reconciliation.