Connect your game to Playmos.
Keep the storefront, game runtime and payment service connected through explicit contracts.
Three services. Clear responsibilities.#
| Surface | Responsibility |
|---|---|
| Playmos storefront / publishing API | Sessions, studio roles, catalog, releases, review and player reports. SQLite in this iteration. |
| SDK service | Payment and contest primitives, chain verification, signed events and receipt records. Separate API and MongoDB store. |
| Your game backend | Verified admission, score validation, fulfillment and game-specific history. |
The iframe stage#
The current stage launches an allowlisted practice client. It does not transfer the storefront login into the game, collect gameplay events or issue paid entry tokens. The first-party game kit owns its own UI and SDK provider inside that frame.
A production bridge needs a versioned message contract, exact origin checks, scoped launch/session tokens and server-verified admission. Never forward a secret key or accept money facts from postMessage.
Publishing readiness#
Prepare your draft, submit for review, then prove the frozen release: isolated build, malware/security scan, approved SDK integration and a machine-verifiable publication receipt. A saved or approved draft is not a public listing.
Open your publisher workspaceWhat your console should measure#
| Metric | Source / readiness |
|---|---|
| Release and review status | Publisher API — available for drafts today. |
| Verified entries, volume, studio revenue and fees | Reconciled SDK receipts and actual contract splits — not wired into the console yet. |
| Round/epoch settlement and overdue age | SDK and game backend — aggregate per studio/game. |
| Views → game ready → practice → entry | Storefront + authenticated iframe events — collection needed. |
| Rejected scores and validation reasons | Trusted game backend; no browser-authoritative scores. |
| Webhook attempts and verification errors | SDK records; detailed delivery telemetry still needs instrumentation. |
Filter by game, release, time range and test/live environment. Every monetary chart needs a verification source and freshness timestamp; unavailable data must not render as zero.