The integration decision is therefore broader than choosing attractive games. It includes account eligibility, wallet boundaries, game versions, player history, reporting and support. This guide turns those boundaries into practical questions and acceptance tests.
Instant-win, digital scratch cards and physical inventory
An eInstant resolves a game round according to its agreed game rules and outcome mechanism. A digital scratch interface can provide an interactive reveal, but the rules must explain what the player buys and when the result is fixed. Do not infer that scratching faster, replaying an animation or reconnecting creates a new chance.
This differs from a draw-based ticket that participates in a later identified draw. It also differs from retail software that tracks physical scratch-card packs, stock transfers or activated tickets. Clarify which category is being purchased before comparing suppliers.
Compare commercial scope through the custom-game economics guide, including content rights, operating responsibilities and change costs. A reusable integration does not make every title’s rules or approval requirements identical.
Define the round lifecycle and outcome boundary
Agree a documented sequence: eligible account, selected game and stake, purchase authorization, accepted round, authoritative outcome, reveal and settlement. Some systems combine steps; the contract must still identify the commitment point and evidence for each state. Distinguish “the browser displayed success” from “the server accepted the round”.
Give each round a stable identifier and associate it with player reference, game/version, currency, stake and outcome reference. Define whether the outcome comes from an RNG-based mechanism or an allocated result under the documented model. Ask which component generates, stores and verifies it; do not accept the frontend animation as evidence.
OWASP’s transaction-authorization guidance supports server-side enforcement and controlled state transitions. Apply those principles when defining which requests can commit or change a round.
Assign responsibilities before choosing an integration
A hosted game interface, embedded delivery or direct API integration may place different responsibilities on the operator. Identify the account system, game service, wallet ledger and reporting owner in the platform responsibility map. Agree how session expiry and restrictions reach the purchase decision.
The game service should return the authoritative round status and references required for recovery. The wallet should own financial postings. The account history should show understandable purchase and settlement information without inventing a second financial truth. Support needs a lookup path across all three.
Use the lottery API requirements guide to document versioning, access, failure handling and adapter ownership. Require the actual supplier contract and sandbox; a general integration diagram is not an implemented interface.
Recover interrupted play without a second charge
Separate connection loss from round failure. If the round was accepted and the outcome fixed, reconnecting should retrieve that round’s state under the agreed model, not purchase another round. A repeated reveal must not trigger another stake debit or prize credit.
If acceptance is uncertain, resolve the original reference before retrying a purchase. Define timeout handling, duplicate-request protection, retry ownership and a visible pending state. An automatic refund can be wrong if the original round was actually committed; an automatic second debit can be wrong for the same reason.
Use the wallet reconciliation checklist to match stakes, prizes, reversals and unresolved entries. Keep funding the wallet separate from purchasing the round; the payment integration guide covers external-payment uncertainty.
Keep demo, promotional and real-money play distinct
Identify the mode before a round starts. Demo play, promotional entitlement and a real-money purchase can have different rules, balances and reporting. Show the player which mode applies and prevent a demo result from appearing as a cash entitlement.
Document the funding source, eligibility, expiry, permitted games and payout treatment for each promotional entitlement. Decide whether it may cover a whole stake or only a portion. Test the transition when the entitlement runs out; do not silently switch the next round to cash.
Store the applicable rule and game version with the round reference. A later promotion or content change must not rewrite the conditions of a previously accepted round. Confirm who can configure these changes and who approves their release.
Make round history and audit records usable
Record acceptance, outcome reference, ledger references, settlement status, error category and relevant timestamps. Reconcile by currency, game version and operating period. Show pending and corrected records separately so completed activity is not inflated by retries.
OWASP’s logging guidance distinguishes useful event detail from sensitive data that should not be logged. Avoid secrets and unnecessary personal data in operational traces.
Ask support to demonstrate a single round from purchase to final balance using synthetic data. The RNG and audit-trail checklist adds questions about game configuration, evidence and independent testing scope. A certificate for a different version or component does not answer those questions.
Operator checklist and acceptance scenarios
Use synthetic rounds with explicit expected outcomes. The examples below are proposed acceptance requirements, not WhiteLotto API behavior or a claim of certification. Add the agreed cases to the UAT and go-live checklist.
| Scenario | Expected round state | Ledger requirement | Audit evidence | Pass condition |
|---|---|---|---|---|
| Connection lost after commitment | Original round remains identifiable; its fixed outcome is recoverable. | One accepted stake; prize follows the recorded outcome. | Commitment and recovery share one round reference. | Reconnect and reveal do not create another purchase. |
| Duplicate acknowledgement | Same completed round, not a new one. | No duplicate debit or prize credit. | Repeated delivery is identifiable. | Repeated processing leaves the financial result unchanged. |
| Stake rejected | No accepted paid round under the agreed rejection rule. | No retained stake for a rejected purchase. | Rejection reason and related attempt recorded. | Player sees rejection, not a misleading completed game. |
| Prize credit pending | Outcome stays fixed; settlement is visibly pending. | One eventual credit after recovery. | Original prize obligation and recovery linked. | Support can explain the pending amount and final posting. |
| Promotion expires before next round | New eligibility decision precedes acceptance. | No silent cash substitution. | Mode and applicable entitlement recorded. | Player confirms any new paid purchase under its rules. |
The UKGC Remote Technical Standards illustrate a jurisdiction-specific technical framework, not a universal rulebook. Agree the applicable requirements and testing scope for the actual operation.
- Obtain the game rules, commitment boundary and component/version inventory.
- Assign round, wallet, recovery and exception ownership in writing.
- Demonstrate restrictions, unavailable services, duplicate requests and interrupted reveals.
- Reconcile synthetic stakes and prizes to player history and financial export.
- Agree game-change approval, monitoring, rollback limits and support handover.
Instant-win lottery integration: frequently asked questions
Are digital scratch cards the same as physical scratch-card inventory?
No. Digital scratch cards present an online game round and outcome. Physical inventory systems track tangible packs or tickets. Their stock, activation and settlement boundaries need separate evaluation.
What should happen after a winning round disconnects?
Recover the original committed round and its recorded outcome. The agreed settlement process should resolve the prize without buying another round or crediting the same prize twice.
Does a successful reveal prove the wallet was settled?
No. Reveal and ledger posting are separate evidence. Verify the round’s settlement reference and reconciled posting; show a pending state when settlement is not final.
What must operators verify before launch?
Game rules and versions, outcome responsibility, eligibility, financial boundaries, interrupted-play recovery, audit evidence and ownership of exceptions. Complete the agreed acceptance cases before enabling the integration.
Discuss your instant-win integration requirements
Bring the proposed game model, existing account and wallet systems, channels and testing requirements. CONTACT WhiteLotto to discuss integration boundaries, delivery responsibilities and acceptance criteria for your lottery operation.
Wojciech Lysak is the Managing Director of WhiteLotto.com. LinkedIn