Home / Integration guide
Engineering and operations guide

Draw the system boundary
before the first round.

This guide makes no speed or performance guarantee. It turns the responsibilities between an operator and a games supplier into testable questions, so technical evaluation does not depend on marketing shorthand.

Integration boundary

Build one shared event trail for every round.

Document the identifiers used from session opening to the final wallet result. Player, game, round, request and money movement should remain connected in a form that support can inspect. The written contract must name the balance authority and define the outcome for every failure response.

01 / SESSION

Identity and lifetime

Test expiry, reopening and parallel sessions. Decide how authentication failure appears to a player without creating an ambiguous or partially recorded round.

02 / WALLET

One financial result

Verify currency precision, insufficient balance and request replay. Repeating the same request must never create a second money movement.

03 / RECORD

Shared evidence

Both teams should locate the same round, active configuration, request outcome and wallet response through stable identifiers.

Test gate

The happy path is a starting point, not acceptance.

Run one simple round end to end. Then force a timeout, lost connection, duplicate request, balance rejection and reconnection. The player interface, supplier record and operator wallet must reach the same final state in each case.

Review round evidence separately. Take the supplied inputs, reproduce the result outside the game interface and connect it to the stored round. Cryptographic verification does not by itself establish incident ownership, active configuration or the support process.

  • Write the test data and expected result before execution.
  • Require financial idempotency during replay and recovery.
  • Connect the active game configuration to the round record.
  • Keep evidence for failed scenarios, not only successful ones.
Commercial and operational decision

The technical and commercial contracts should describe the same service.

Align the pricing unit, included games, environments, support coverage, change process and incident escalation before signing. A sentence on a marketing page is not a substitute for the executed agreement or the integration evidence your team collects.

Supplier comparison

Compare suppliers with the same game, failure scenarios and evidence list. Score responsibilities that can be demonstrated instead of relying on catalogue volume or unsupported performance language.

Production readiness

Do not treat test access as production readiness. Permissions, observability, recovery, release ownership and support escalation all need named owners and an agreed acceptance record.