Lottery Draw & Results API Integration: Cut-Offs & Settlement
A lottery draw and results API integration must preserve the connection between the correct draw, an accepted ticket, the authorised result and the resulting settlement. The difficult work is defining sales cut-offs, time zones, result revisions and recovery when messages are missing or repeated—not displaying winning numbers. This is a vendor-neutral requirements guide, not a […]
A lottery draw and results API integration must preserve the connection between the correct draw, an accepted ticket, the authorised result and the resulting settlement. The difficult work is defining sales cut-offs, time zones, result revisions and recovery when messages are missing or repeated—not displaying winning numbers.
This is a vendor-neutral requirements guide, not a specification of actual WhiteLotto endpoints or a promise that every interface described is included. Start with the lottery API architecture guide and agree the real contract with the delivery team.
Use stable draw identifiers, not dates alone
A draw date cannot reliably identify a draw when a product has several daily draws, rescheduling or multiple time zones. Map the product identifier, provider draw identifier and platform draw identifier. Preserve these references on tickets and reports. Decide whether a rescheduled draw retains its identity and how a cancelled draw affects accepted tickets.
| Record | Define before implementation | Acceptance evidence |
|---|---|---|
| Draw schedule | Stable ID, product, scheduled time, sales cut-off and applicable time zone. | One trace across catalogue, purchase and reporting. |
| Ticket acceptance | Authoritative acceptance time, cut-off rule and treatment of uncertain responses. | Cases immediately before, at and after the boundary. |
| Result | Authoritative source, status, publication time, version and completeness. | Unpublished, preliminary and final result scenarios. |
| Correction | Revision reference, reason, approval and affected-ticket handling. | Audit trail linking previous and corrected result. |
| Settlement | Trigger, calculation ownership, posting references and reconciliation. | One financial effect per intended settlement. |
Agree time semantics and the sales cut-off
Store an unambiguous instant alongside the named local time zone used for customer display and business rules. The RFC 3339 timestamp format is a useful reference for representing an instant with an offset. An offset alone does not describe a region’s future daylight-saving rules.
Specify whether acceptance depends on arrival at the platform, acceptance by a supplier or another contracted event. A front-end countdown is informational: it should not decide whether a ticket exists. Include time synchronisation, clock drift, delayed requests and daylight-saving transitions in testing. Display a clear outcome when sales have closed.
A timeout near cut-off needs an outcome lookup or owned exception process. Retrying blindly can create a duplicate or a ticket for a different draw. Preserve the original operation and requested draw references.
Treat result corrections as controlled changes
Distinguish received, validated, final and corrected results in the agreed state model. Do not interpret a missing field as a losing ticket. Define who may approve settlement and how the source is authenticated. If a result is corrected, preserve the earlier version and link the adjustment to its reason and approver.
Replaying a notification must not settle the same ticket twice. A late older result must not overwrite a newer authorised revision. Financial corrections should remain traceable rather than silently rewriting the original ledger history. The payment integration guide covers the related discipline for asynchronous financial events.
Make missing events visible
- Detect draws whose expected results have not arrived within the agreed operating window.
- Compare the source catalogue and local draw inventory after an outage.
- Recover missing events using a supported replay or retrieval mechanism.
- Show tickets awaiting a result separately from tickets awaiting settlement.
- Assign escalation ownership and customer messages for delayed draws and results.
The HTTP idempotency guidance helps frame safe retries, but application-level ticket and settlement guarantees must be specified separately. Use the operator KPI framework to measure settlement completeness and exception ageing.
Acceptance checklist for a results feed
Use synthetic draws and tickets in an authorised test environment. Exercise schedule changes, cancellations, duplicate and out-of-order messages, unavailable sources, incomplete results and a corrected final result. Verify ticket state, player-visible information, settlement postings and exports together. Capture the interface version and tested configuration in the UAT acceptance pack.
Separate result publication, settlement approval and withdrawal release
A results feed should not become an unrestricted instruction to move money. Define three approval boundaries: what may be displayed to players, which result version may drive ticket settlement, and what permits a related withdrawal to be released. These decisions can belong to different systems and teams. Ask the provider to demonstrate those boundaries using the actual proposed configuration, rather than assuming that a “final” field authorises every downstream action.
Give the operator a reviewable record for each decision: the source evidence, affected draw, result version, scope of authority and person or approved automated rule responsible. A display update should not silently change a withdrawal decision. Coordinate the boundary with the player account management guide and the payment integration guide; a credited prize and a completed external payment are different records.
| Decision point | Evidence to retain | Ownership question |
|---|---|---|
| Player-facing publication | Source reference, permitted display wording and result version shown. | Who approves publication or correction of customer-facing information? |
| Settlement run | Approved result, affected-ticket scope and calculation or posting summary. | Who may approve the run and resolve exceptions? |
| Wallet credit | Ticket outcome, credit reference and reconciliation against the settlement run. | Who reviews a difference between the ticket outcome and available balance? |
| Withdrawal release | Payment reference, applicable checks and the decision recorded for that withdrawal. | Who authorises release, review or a permitted pause? |
| Cut-off dispute | Requested draw, acceptance evidence and the contracted boundary rule. | Who decides participation and communicates the resolved outcome? |
Plan a correction case after funds have moved
Expand correction testing beyond a ticket that is still awaiting settlement. Include a credited prize that remains in the account, a withdrawal under review and a payment already completed outside the platform. Record the affected tickets, original postings, withdrawal references and the difference implied by the approved revision. Agree how those cases reach finance, operations and support before anyone applies an adjustment.
The response must follow the applicable contract, customer terms and authorised decision process; this guide does not prescribe a universal recovery rule. Do not assume that changing the displayed result reverses an external payment, or that a negative balance is the correct automatic response. Ask how the team records a decision not to adjust, a permitted adjustment or an unresolved case. Keep prize funding responsibilities in the jackpot risk and prize-funding review separate from result-feed delivery.
Require a worked correction scenario in the UAT acceptance pack. Use test records only and verify the operator’s review evidence and customer explanation, not only the recalculated winning amount.
Give disputed participation a documented resolution
For a purchase disputed around cut-off, assemble one case containing the original requested draw, acceptance trace, payment record and applicable rule. A debit alone should not be treated as proof of participation. Identify who can obtain supplier evidence and who approves the customer outcome. Any decision about participation, payment treatment or customer communication should remain connected to that case rather than becoming an undocumented support workaround.
Set the evidence required to close each exception, including unresolved differences between supplier, ticket and finance records. Use the operator KPI framework to distinguish case closure from merely receiving a message, and the operator readiness library to prepare the relevant teams. Bring your approval boundaries and disputed-case requirements to WhiteLotto. CONTACT
Draw API FAQ
Is publishing winning numbers enough?
No. An operator also needs draw identity, authoritative result status, accepted-ticket matching and auditable settlement.
Can a corrected result replace the old record?
The presentation may change, but the operation should preserve an audit trail and the relationship between the original settlement and any authorised adjustment.
Bring your draw providers, products, cut-off rules and reporting needs to the platform scope discussion. CONTACT.