How to Procure an iGaming Provider

Start with the operating outcome, not a category label. Record the product, target markets, customer location, operator entity, license route, brands, channels, currencies, languages, launch volume, migration state, and required launch date. Then state whether the supplier is providing software, hosting, content, data, managed operations, a merchant or payment connection, a licensed operating shell, or a combination of those roles.

Create one baseline scope that every candidate must price. Divide it into required, optional, excluded, and undecided items. A requirement is not complete until it includes the responsible party, delivery artifact, acceptance test, target date, dependency, and commercial treatment. Optional modules need independent prices and effects on the implementation plan. Exclusions should identify who supplies the missing capability and which integration remains in scope.

Do not compare a white-label package with a software-only platform as if they were substitutes. The white-label route can include an operating entity, licenses, payment contracts, compliance operations, content agreements, support, and brand restrictions. The software route can leave every one of those items with the operator. Normalize the responsibility transferred, not the name printed on the proposal.

Record the brand, proposal issuer, contracting entity, invoicing entity, intellectual-property owner, licensed software supplier, hosting provider, data processor, payment participant, managed-service employer, and ultimate escalation party as separate fields. A group logo does not make every affiliate interchangeable. The agreement should state which entity owes each obligation and whether an affiliate or subcontractor can replace it without operator approval.

Match each product and market to the permission actually required for that role. An operator license, gambling-software license, payment authorization, test certificate, company registration, and domain approval answer different questions. A permission held by a group company does not automatically cover another entity, product, territory, or activity. Put the exact holder, number, status, scope, conditions, renewal date, and required operator action in the launch record.

Map the nested supply chain. Include game studios behind an aggregator, sports data and integrity services behind a sportsbook, payment processors behind an orchestration layer, identity and screening services behind KYC, cloud and support providers behind the platform, and any local operating partner behind a white label. The operator needs notice and control when a critical dependency changes because continuity, data access, testing, and regulatory scope may change with it.

Build a responsibility matrix for every task that can affect customers, money, a license condition, a regulatory return, or a reportable incident. At minimum cover customer registration, age and identity checks, AML risk, sanctions and PEP screening, source-of-funds work, affordability or financial-risk controls, safer-gambling monitoring and intervention, self-exclusion, marketing consent, complaints, disputed transactions, suspicious activity escalation, game and bet suspension, payment review, regulatory reporting, and record retention.

Use one accountable owner for each decision. Other parties can perform, approve, provide data, or receive notice, but two accountable columns usually hide a gap. Define operating hours, decision authority, case system, data available at the moment of decision, handoff time, quality checks, escalation threshold, and record produced. A managed service should be tested on real workflows, not accepted from a list of team names.

Contracting with a supplier does not by itself transfer the license holder's responsibility. The operator needs sufficient oversight, controls, access, and intervention rights for outsourced activity. For a white-label arrangement, the operating license holder still needs direct control of the regulated website and its customer protections. The responsibility schedule should therefore identify both the performing party and the operator control that remains in place.

A product demonstration proves only the demonstrated path under the demonstrated configuration. Acceptance must cover the operator's markets, roles, currencies, languages, devices, integrations, data volumes, limits, failure modes, and migration. Build a requirements trace from the signed scope to configuration, interface, test case, owner, result, defect, waiver, and production release.

Specify integration behavior beyond endpoint availability. Record authentication, authorization, idempotency, ordering, timestamps, retries, rate limits, batch behavior, error codes, reconciliation identifiers, webhooks, versioning, sandbox parity, backward compatibility, maintenance windows, and deprecation notice. For wallets and payments, test duplicate, delayed, reversed, partial, chargeback, currency, and ledger-reconciliation paths. For betting and games, test settlement corrections, suspended events, incomplete rounds, limits, bonus treatment, and product-specific regulatory controls.

Separate product acceptance from market release. A module can work technically and still lack required testing, a market configuration, a permission, content approval, a payment route, customer terms, reporting output, or an operating procedure. Use a release gate with named approvers and retained artifacts. A sales deadline cannot override an unresolved mandatory control.

Start with a data inventory and role decision. For each dataset, record the data subjects, fields, purpose, legal basis or operating justification, controller and processor roles, collection point, transfer route, storage locations, subprocessors, access groups, retention, deletion, export, and incident owner. Do not label the supplier a processor for every activity if it decides purposes or essential means for part of the processing.

The data-processing schedule needs documented instructions, confidentiality, security measures, subprocessor control, assistance with rights and incidents, deletion or return, and audit terms. The service schedule should add access reviews, privileged support controls, logging, encryption, backup, recovery objectives, vulnerability handling, penetration testing, secure development, change control, incident notification, evidence delivery, and remediation timing. A certificate is one input; it does not define the customer-specific scope or close every shared responsibility.

Use a criticality-based supplier review. A content feed with no player data, a payment service controlling money movement, and a hosted PAM holding identity and wallet records need different depth. Record the systems and data that would be affected by compromise or outage, the supplier's nested dependencies, the available independent assurance, unresolved findings, compensating controls, and the conditions for re-assessment during the contract.

Compare proposals against one transaction and operating scenario. Use the same settled stakes, winnings, bonuses, jackpot contributions, gaming duties, payment mix, chargebacks, currencies, content mix, event volume, active accounts, support hours, and implementation assumptions. Then apply each supplier fee to its exact contracted base. A lower percentage can cost more when its base is broader, deductions are narrower, minimums are higher, or required services sit outside the quote.

Separate one-time implementation, license or access fees, fixed recurring fees, volume tiers, GGR or NGR shares, per-bet or per-event charges, payment transaction fees, foreign exchange, data and content pass-throughs, hosting, support tiers, minimum guarantees, deposits, reserves, professional services, testing, taxes, and exit assistance. Record which items can change unilaterally, which follow a third-party price, and which survive termination.

Define the calculation and settlement mechanics, not only the price. Specify population, period, time zone, currency conversion, tax treatment, voids, corrections, negative periods, loss carryover, minimum reconciliation, invoice data, dispute window, audit right, late adjustment, and final settlement. Use the same model for every candidate and preserve the assumptions with the decision. The linked calculator models one platform, one content or data, and one affiliate minimum for the same period and currency. It compares each minimum only with its corresponding percentage fee and keeps fixed supplier fees separate; it does not prorate annual guarantees, pool categories, or apply tiers, caps, credits, or carryover.

Service levels should measure the customer and operating outcome. Availability needs a service boundary, measurement point, exclusions, maintenance rule, dependency treatment, reporting method, and remedy. Incident targets need severity criteria, acknowledgment, containment, workaround, restoration, root-cause report, remediation, communications, and regulatory cooperation. A ticket response target alone is not a recovery commitment.

Name the operational owners, coverage hours, on-call route, escalation authority, change calendar, release process, monitoring access, capacity review, service review, problem management, and continuity exercise. Define who can suspend a market, game, bet type, payment route, campaign, account action, or system connection and how that decision reaches every affected party. Record manual workarounds and their safe operating limits.

Tie remedies and termination rights to material failures without treating service credits as the only protection. Repeated control failures, loss of a required permission, unauthorized subcontracting, severe security weakness, unrecovered data, persistent reconciliation differences, and failure to provide transition assistance may require different responses. The contract should preserve the operator's ability to protect customers and comply before the commercial dispute is resolved.

List everything required to continue, migrate, reconcile, defend a decision, answer a regulator, and settle customers after termination. This can include customer and account data, wallet balances, transactions, game rounds, bets, payment events, KYC and AML cases, safer-gambling actions, consents, complaints, limits, configuration, reports, audit logs, documents, content mappings, credentials, interface documentation, data dictionaries, transformation rules, and open incident records.

Define export format, schema, identifiers, history depth, attachment handling, encryption, delivery method, frequency, test environment, validation, correction, and final cutover. Test a representative export during implementation and again before renewal. A promise to provide data is not enough if the format cannot be imported, relationships are missing, attachments are inaccessible, or the supplier alone can interpret the fields.

Set transition services, knowledge transfer, parallel running, continued support, pricing, key-person availability, license and content continuity, sub-supplier cooperation, final invoice, reserves, disputes, data return, verified deletion, backup expiry, and post-termination audit. Define which rights survive and when credentials, domains, cloud accounts, phone numbers, certificates, and operator-owned configurations transfer. Exit readiness is an acceptance criterion, not a task to invent after notice is served.