This guide helps operators and founders prepare a commercial and delivery brief. It is not jurisdiction-specific legal advice, a provider quotation or a promise of profitability. An established operator adding lottery should also map which existing permissions, systems and customer controls can be reused and which need a fresh assessment.
1. Define the market and the lottery product before buying software
Start with a narrow launch scope: the intended market, customer location, contracting entity, product, channel, currency and language. Record who accepts the customer’s instruction, who holds funds, how participation is fulfilled and who pays a prize. Review that activity map with qualified advisers and the relevant counterparties before assuming that a licence, insurance policy or supplier agreement covers the operation.
Different lottery propositions can look similar on a website while creating very different obligations:
| Product model | What the proposition involves | Questions to resolve before launch |
|---|---|---|
| Own draw or custom lottery | Participation in a game or draw that your operation arranges. | Who may organise it? Who owns the rules, operates or verifies the draw, funds prizes and handles claims? |
| Authorised ticket distribution | Selling participation in another lottery under the applicable distribution arrangement. | What permissions and contracts cover the channel, territory, ticket evidence and prize process? |
| Ticket courier or purchase service | A service that acquires and holds a physical ticket for a customer. | Is the service permitted? Who buys, scans and safeguards the ticket, proves ownership and collects a prize? |
| Betting on an external draw | A separate contract based on another lottery’s result, rather than ownership of its ticket. | How is the product classified, disclosed and settled? What are the exposure limits, funding and any insurance exclusions? |
These are product distinctions, not a list of products that every platform or market permits. In particular, buying a ticket and betting on a draw are not interchangeable. Do not describe insurance as automatic coverage of every prize or as authority to enter every market. For a player-facing view of these models, consult the guide to official lottery tickets versus lottery betting and the service descriptions in our lottery platform reviews.
2. Choose white label, turnkey or an owned technology stack
Once the product is clear, choose how it will be delivered. White label and turnkey describe commercial and software arrangements, not universal legal categories. Providers use the terms differently, so compare the contract, responsibilities and acceptance evidence rather than the label alone.
- White label: a branded experience built on an existing platform, sometimes combined with managed services. Establish the contracting entities, control boundaries, service scope and exit terms.
- Turnkey: a supplied platform and implementation package, with operational responsibilities defined separately. Confirm what is included, what needs third-party onboarding and what your team must run.
- Owned or custom-built stack: you select or develop more of the components and coordinate their operation. Plan for engineering, supplier management, testing, maintenance and incident response as ongoing work.
Use the white-label versus turnkey comparison to prepare your questions, and review the WhiteLotto turnkey lottery solution when discussing the actual delivery scope. Neither a model name nor a supplier’s licence establishes that your planned activity is authorised.
Write a responsibility matrix before signing
For either supplied model, name the accountable entity and day-to-day owner for every critical function. Outsourced execution, decision authority and legal accountability may sit with different parties.
| Workstream | Operator or founder must establish | Provider scope to confirm | Evidence to request |
|---|---|---|---|
| Market and product scope | Entities, permitted activity and customer restrictions. | Supported configuration and any delivery restrictions. | Written scope and responsible-party map. |
| Players and funds | Customer contracting party, funds arrangements and complaint ownership. | Account, wallet, ticket and settlement functionality actually included. | Funds-flow diagram and exception scenarios. |
| Verification and safer gambling | Control owners, escalation rules and staff responsibilities. | Available tools, integrations and any managed-service duties. | Configured-control demonstrations and acceptance cases. |
| Payments and finance | Counterparty acceptance, working capital and reconciliation ownership. | Connectors, reports, callback handling and support boundaries. | Provider contracts, data flows and reconciliation samples. |
| Security and availability | Risk acceptance, access governance and incident decisions. | Hosting scope, monitoring, recovery and service commitments. | Relevant reports, a service-level agreement and recovery evidence. |
| Data and exit | Required access, lawful retention and a migration plan. | Export formats, assistance, charges and termination dependencies. | Contract terms and a representative export. |
3. Turn the operating model into a platform checklist
Describe the journeys you need, then ask a provider to show them on the proposed configuration. A feature name in a brochure is not enough to establish how it behaves or who operates it.
- Player accounts: registration, verification states, access recovery, customer restrictions and an auditable history.
- Wallet and records: traceable balance changes, purchases, payouts, refunds and controlled adjustments.
- Lottery lifecycle: product availability, draw cut-offs, time zones, participation evidence, results and prize settlement.
- Customer controls: applicable age and identity checks, risk escalation, limits, exclusion and intervention workflows.
- Operations: role-based access, support tools, complaint handling, finance exports and exception queues.
- Integrations: payment, verification, results and CRM data flows, including failure handling and ownership of API changes.
- Localisation: complete customer journeys, terms and messages in the intended language, with appropriate currency and time-zone behaviour.
- Security and continuity: access controls, logging, monitoring, recovery and evidence appropriate to the required service.
Prioritise launch-critical requirements separately from later enhancements. More games, markets or languages can introduce dependencies; catalogue size alone is not a business case.
4. Budget for the operation, not only the setup fee
There is no dependable universal price for starting a lottery business. Compare written quotations against the same market, product, responsibility and volume assumptions. Separate platform fees from third-party fees and the cost of running your company.
- Initial costs: implementation, design, configuration, integrations, independent professional work, applicable testing, onboarding and training.
- Recurring fixed costs: platform minimums, hosting or managed services where separate, staffing, support, security and reporting.
- Variable costs: agreed revenue share, transaction and verification charges, game or draw supply, marketing and affiliate costs.
- Cash requirements: settlement delays, reserves, refunds, prize exposure and other model-specific funding commitments.
- Change and exit costs: additional scope, new markets, exports, migration assistance and termination obligations.
Build low, base and high-volume scenarios with your own assumptions. Define the revenue-share base, minimums, currencies and charges explicitly. Avoid double-counting included services, but do not mistake an omitted quotation line for a free service. The lottery software pricing and three-year TCO guide provides a framework for comparing those inputs rather than an unverified market price.
5. Design payments, verification and customer handling together
A listed payment integration does not prove that a payment provider will accept your entity, product or market. Obtain the required counterparty decisions and agree deposit, withdrawal, refund, reserve, settlement and dispute processes. Include verification and safer-gambling conditions in the journey instead of treating them as a separate screen added before launch.
Trace a transaction through the platform, payment provider, settlement account and finance records. Decide who resolves a missing callback, duplicate message, delayed withdrawal or reconciliation break. Rehearse a failed verification, customer complaint and provider outage as well as a successful purchase. Use authorised test environments and permitted data, not real player accounts or uncontrolled live transactions.
The lottery payment-stack guide expands the questions on routing, reconciliation and recovery. Payment method availability, costs and customer restrictions must be verified for the proposed operation; generic conversion or fee figures should not drive the decision.
6. Evaluate a provider through evidence and acceptance criteria
Give each candidate the same brief and ask for a written response. Distinguish live capability from custom development, planned features and third-party dependencies. Run a scenario-based demonstration, not only a product tour.
- Request the proposed architecture, service scope, integrations and responsibility boundaries.
- Ask how the platform handles exceptions, reports balances and supports finance and customer-control teams.
- Check any certification or test report against the entity, system, version, scope and date it actually covers.
- Define availability measurement, exclusions, support response, recovery commitments and remedies in the contract.
- Review data access, export, change control, subcontractors and the practical cost of leaving.
Use the provider evaluation checklist and RFP brief to structure the comparison, and the security, testing and SLA checklist for the technical evidence. A polished demo, a security badge or a client logo is not a substitute for the required documentation.
7. Set an evidence-based launch date
Separate technical delivery from readiness to operate. An implementation estimate needs a defined starting point, agreed scope, timely inputs and an acceptance endpoint. Company formation, required permissions, payment-provider acceptance, external assessment and operational staffing may have independent timelines.
What would a 21-day implementation require?
If a provider proposes a 21-day implementation, request a scoped plan rather than treating the number as a general launch guarantee. Confirm whether it means calendar or business days, which work is included, which approvals must already be complete and what happens when a dependency changes.
- The market, product and contracting entities are defined, with mandatory prerequisites resolved by the appropriate owners.
- The delivery scope, content, brand assets and configuration inputs are approved and available.
- Required counterparties and integrations are ready on the agreed environments.
- Customer-control, payment, support and finance responsibilities have named owners.
- Acceptance cases, blocking defects and go/no-go authority are agreed before delivery starts.
- Training, monitoring, incident communications and recovery arrangements are ready for handover.
These are planning questions, not confirmed WhiteLotto delivery terms. Obtain the actual prerequisites and schedule for your project. The lottery go-live checklist explains the operational gates once the business and delivery scope are settled.
8. Keep a general compliance and evidence register
For each requirement, record the applicable source, responsible entity, owner, evidence, review date and unresolved conditions. Cover product and market permissions, customer eligibility, funds and payments, verification and financial-crime controls, safer gambling, privacy, complaints, marketing and technical assessment. Have qualified specialists resolve the actual jurisdiction-specific requirements.
For an example of regulator-defined technical and testing requirements, consult the UK Gambling Commission’s Remote Technical Standards. Their scope is specific; they are not a universal approval checklist for every lottery venture. Check the current requirements and effective dates rather than relying on an old summary.
The FATF Recommendations provide international financial-crime standards background, implemented through national frameworks. The NIST Cybersecurity Framework supports cybersecurity risk management. Neither establishes that a particular company or platform is licensed, certified or compliant.
Use the guide to five licensing mistakes to challenge the assumptions in this register; it does not replace a product- and market-specific assessment.
Frequently asked questions
Does a white-label agreement mean I do not need my own permissions?
Not automatically. Determine the activity, entities, player contracts and markets, then obtain current advice on the required permissions. A supplier arrangement or licence cannot be assumed to cover every role in your business.
Is turnkey always more expensive than white label?
No reliable comparison follows from the labels alone. Compare the same scope, responsibility boundaries and volume assumptions over the contract term, including minimums, revenue share, change work and exit costs.
Can I start with multiple markets at once?
Only after assessing each market’s requirements and operational dependencies. A narrower first release can reduce coordination work, but it does not waive mandatory controls or authorisations.
What should I bring to a first platform discussion?
A concise brief covering market, entity, product model, intended customers, delivery model, licence status, required integrations, target date and budget assumptions. Keep unresolved items explicit and do not send player data, credentials or confidential legal files through a general enquiry form.
Turn your lottery business model into an acceptance brief
Before choosing a supplier, connect the player proposition to the records, contracts and operating responsibilities that will support it. A purchase button can represent a request to obtain a ticket, an accepted entry in your own draw or a bet on an external result. Your acceptance brief should show which event creates the obligation, which entity owes the player a prize and how staff establish what happened.
For an own draw, identify the approved rules, draw record and prize-funding responsibility. For authorised ticket distribution or a courier/messenger service, trace the instruction through fulfilment, ticket evidence, custody and prize collection. For external-result betting, identify the accepted contract, result source, settlement rules and liability owner. A hybrid catalogue needs those distinctions for each product, including clear customer-facing wording. Compare these product responsibilities separately from the White Label and Turnkey delivery models.
| Operating boundary | Record or evidence | Acceptance question |
|---|---|---|
| Purchase and fulfilment | Instruction, acceptance time, draw reference and ticket or contract identifier. | Can support distinguish an unfulfilled request from valid participation? |
| Ticket ownership and custody | Purchase confirmation, ticket evidence, custody record and authorised access. | Who can retrieve the evidence and resolve a missing or disputed ticket? |
| Prize obligation | Named contracting entity, applicable rules, result authority and payout procedure. | Who owes the prize, who funds it and who handles a contested result? |
| Financial settlement | Linked payment, wallet, prize, refund and supplier-settlement references. | Can finance explain each movement without counting it twice? |
Use the ticket lifecycle guide to specify participation states and the wallet and reconciliation checklist to connect the corresponding financial records.
Agree the handover before the demonstration
- Ask the supplier to demonstrate one purchase, one failed fulfilment and one prize claim for each proposed product model.
- Name the operator, supplier and external partner responsible for each decision and exception.
- Record the evidence retained, the staff permitted to access it and the owner of a dispute.
- Agree how unresolved entries, pending prizes and refunds appear in the daily reconciliation.
Add these cases to your provider evaluation and RFP brief. Bring the proposed responsibility schedule when you CONTACT WhiteLotto.
Discuss your launch scope and platform fit
Discuss your lottery platform requirements with WhiteLotto. Bring the brief above so the conversation can identify fit, responsibility boundaries, prerequisites and the next evidence needed. Ask for a scoped proposal; treat legal, regulatory, banking and commercial-performance decisions as separate workstreams.
Wojciech Lysak is Managing Director of White Lotto and a senior iGaming B2B expert with nearly 20 years of experience. He specializes in white label online lottery platforms, turnkey solutions, gaming systems, and scalable B2B solutions for operators across global markets.
A recognized industry leader and visionary, he actively participates in major iGaming events worldwide and has led the creation of multiple successful platforms and projects across the gaming sector.
If you’re interested in starting your own online business in the iGaming sector, Wojciech will help you take your first steps on the path to success. LinkedIn