Certification and go-live
No operator sees your games until both teams have proven them. Certification is a joint run on a sandbox operator with a test player: real sessions, real signed money legs, and the same path production traffic will take, with no real players anywhere near it. This page is what that run contains and what happens after it goes green.
How certification works
Section titled “How certification works”We set up a sandbox operator account and a test player, and drive the integration the way production will: sessions launch through your connector, your games play, and your server sends signed bet and win legs that settle against the sandbox wallet. Our team drives the scenarios; your team runs your side and watches your logs. Every finding lands in the shared channel with enough context to fix it, whichever side owns it.
The run is not a demo. It is deliberately hostile in the second half, because the failure modes it rehearses are the ones that otherwise debut on real players.
What we check together
Section titled “What we check together”The happy path comes first: launch a session, play, settle a bet and a win, close the round, reconcile. Then the failure scenarios, each proving one property that production will eventually test for real:
| Scenario | What it proves |
|---|---|
| Invalid auth | Calls with wrong or missing credentials are refused and fail safely |
| Schema mismatch | A payload that does not match the agreed contract is rejected, never half-processed |
| Duplicate delivery | A repeated scoped integration/provider/transaction identity does not settle twice |
| Idempotency | A replayed transaction identifier returns the original outcome, not an error and not a second movement |
| Timeout and retry | A transient failure recovers within bounded retries, carrying the same identifier |
| Callback failure | Ambiguous or partially settled outcomes are identified and reconciled before recovery |
| Out-of-order events | Legs landing out of sequence are handled deterministically |
| Reconciliation | At the end of the run, the transaction record matches on both sides, leg by leg |
Agree the required scenarios and provider-specific trigger/recovery rules while building the connector; add free-round, refund and late-settlement cases that apply to your protocol.
When the integration is ready
Section titled “When the integration is ready”The bar is binary: every scenario green in one run, and the closing reconciliation clean. Clean means every bet and win in GET /v1/transactions matches the run’s script and your own records, accounting for internally completed zero cash legs, delivered zero free wins, grant-funded bets and reversals. Record both delivery and actual wallet effects.
Findings do not fail the process; they pause it. A fix on either side reruns the scenarios it touches, and the certification closes on the first run where nothing is open. Nothing about the schedule is promised, because the honest answer is that the date depends on what the run finds.
Opening traffic
Section titled “Opening traffic”When certification closes, we open your provider on the network. Operators’ live keys only see providers that have completed go-live, so this is the moment your catalog appears to them: operators find the games, enable what fits their storefront, and traffic arrives operator by operator rather than in one wave. That shape is deliberate; the first operators are the second half of your certification.
The first hours
Section titled “The first hours”Both teams watch the first live sessions, each from their own side:
- Your side: launch answers and money legs from your server, their latency, and any error your logs show that the run never produced.
- Our side: the platform path of the same sessions, error rates by code, and a first reconciliation of live transactions once there is enough traffic to mean something.
Anything found is triaged in the shared channel, the same way certification findings were. After the first hours, the relationship settles into routine: catalog updates flow as described in Catalog requirements, and the runtime contract on Runtime expectations is the thing both monitoring setups quietly verify from then on. If you are reading this page before you are in the process, start at Provider onboarding.