Retail Lottery POS Integration: Offline Rules & Reconciliation
A retail lottery POS integration connects ticket issuance, payment, retailer reconciliation and customer support across physical outlets and the central platform. Its critical design decision is what a point of sale may do when connectivity is lost. An offline card approval and a valid centrally accepted lottery ticket are different outcomes. This guide describes requirements […]
A retail lottery POS integration connects ticket issuance, payment, retailer reconciliation and customer support across physical outlets and the central platform. Its critical design decision is what a point of sale may do when connectivity is lost. An offline card approval and a valid centrally accepted lottery ticket are different outcomes.
This guide describes requirements to agree, not confirmed WhiteLotto terminal models or API operations. Place retail in the wider omnichannel architecture and confirm the actual product, market and supplier boundaries.
Separate responsibilities at the counter
Map the POS application, payment terminal, lottery platform, draw supplier and retailer back office. A terminal can process a payment without creating a lottery ticket. A printed slip may describe a pending order rather than proof of a valid entry. Define the legally and contractually meaningful ticket acceptance event with the responsible owners.
| Operation | Boundary to agree | Exception to test |
|---|---|---|
| Ticket sale | Authoritative acceptance, draw cut-off and ticket reference. | Payment succeeds but ticket confirmation is unavailable. |
| Payment | Cash/card ownership, provider status and linked order reference. | Terminal times out or confirms after the first response. |
| Receipt | What proves acceptance and what a reprint may reproduce. | Printer fails after acceptance. |
| Prize handling | Validation, payout authority and duplicate-claim controls. | The same ticket is presented at another outlet. |
| Outlet settlement | Commission, cash movements, refunds and reporting cut-off. | Local totals differ from central records. |
Define an explicit offline policy
Choose which functions remain available without a connection. They might include viewing permitted cached information or preparing an unaccepted order; valid offline ticket issuance needs a specifically authorised design and is not implied by a payment terminal’s capability.
Adyen’s offline payment documentation explains that supported offline payment modes have limitations and a risk of subsequent decline. This is a payment-provider reference, not permission to issue lottery tickets offline and not evidence that WhiteLotto supports Adyen.
Never queue a sale for a draw that has closed and later present it as accepted before cut-off. Define local storage limits, clock checks, outage messages, authorised manual handling and recovery ownership. If a completed payment cannot produce a valid ticket, the agreed reversal or refund journey must remain traceable.
Synchronise without creating duplicate sales
Assign an operation reference that survives a POS restart and network interruption. Reconnecting must establish the original outcome before sending a new sale. Preserve outlet, device and operator references so central support can distinguish a repeated transmission from a second intended purchase.
Reprints should reproduce the original accepted ticket reference, not issue a new entry. Lost acknowledgements, device replacement and delayed uploads need a supported recovery process. Use the draw integration guide for cut-off and result identity, and the payment guide for financial retries.
Give retailers a reconciliation view
At a defined business-day boundary, reconcile accepted tickets, cancellations, cash and card collections, payouts, commissions and amounts due. Specify the outlet’s local time zone and the treatment of late provider confirmations. Report unresolved orders separately rather than forcing them into successful sales.
Restrict each retailer to its authorised records. Central operators need a trace across outlets, while finance needs an agreed settlement statement and correction workflow. The KPI framework can expose exception value and ageing across channels.
Retail acceptance checklist
- Complete cash and card sales with ticket, receipt and central report matching.
- Interrupt connectivity before submission, after payment and after ticket acceptance.
- Restart a device and recover an uncertain operation without issuing another ticket.
- Test printer failure, controlled reprint, cancellation and duplicate prize claim.
- Apply draw cut-offs consistently across time zones and outlets.
- Reconcile a retailer day containing refunds, late events and unresolved orders.
- Verify device/operator revocation and denied access to another outlet.
Record the terminal, software version, network configuration and synthetic fixtures in the UAT acceptance pack. Do not test outages through live player purchases.
Retail POS FAQ
Does offline payment mean offline lottery sales are safe?
No. Payment processing and ticket acceptance have separate constraints and risks. The lottery system needs its own authorised rules.
What should a retailer provide during discovery?
Device models, connectivity, payment methods, sales/payout journeys and settlement requirements. Use anonymised examples, not player records.
Discuss your outlet network and integration boundaries with WhiteLotto. CONTACT.