iGaming Platform Certification 2026: Technical Requirements & Testing Checklist

What Is iGaming Platform Certification?

iGaming platform certification is the independent technical assessment of a gaming system against specified regulatory or technical requirements.

The purpose is to determine whether the submitted platform and its relevant components operate in accordance with the requirements that apply to the intended market or regulatory approval.

Depending on the project, the testing laboratory may evaluate both individual platform components and the way those components interact within the complete gaming environment.

A modern iGaming platform can include:

• Player Account Management (PAM);
• player registration and authentication;
• KYC and account-status controls;
• player wallet and ledger;
• deposit and withdrawal processing;
• bet, win, refund and cancellation processing;
• casino or game aggregation integrations;
• bonus and promotional functionality;
• responsible gambling controls;
• back-office administration;
• user roles and permissions;
• transaction and audit logging;
• regulatory and financial reporting;
• APIs and third-party integrations;
• security and system controls.

The exact certification scope should therefore be defined against the actual platform architecture rather than assuming that every iGaming system requires an identical test package.

Operators and suppliers developing or selecting a platform can also review our iGaming Platform overview.

Platform Certification vs Game Certification

Platform certification and casino game certification are related but different technical workstreams.

A casino operator may therefore use a certified platform together with separately tested games supplied by external studios or through a game aggregator.

We cover casino game testing separately in our guide to online casino game certification.

Who Needs iGaming Platform Certification?

Platform certification can be relevant to both B2B software suppliers and B2C gambling operators. The party responsible for obtaining or providing the technical evidence depends on the jurisdiction, commercial structure and system configuration.

B2B iGaming Platform Suppliers

A B2B supplier developing its own PAM, wallet, casino platform or wider gaming system may require independent testing before the technology can be supplied into particular regulated markets.

Certification can also become commercially important when prospective operators or regulators require evidence that the platform has already been assessed against recognised technical requirements.

B2C Online Casino Operators

A B2C operator may use a third-party platform that already has technical documentation or certification. However, this does not necessarily mean that every final operator configuration is automatically covered.

The production configuration can include different games, payment methods, integrations, responsible gambling settings, reporting requirements and operational controls.

The operator should therefore establish which parts of the existing supplier certification can be relied upon and which parts of the final configuration require additional assessment.

White-Label and Turnkey Platforms

White-label and turnkey environments can involve a shared core platform with different configurations for individual operators.

From a testing perspective, the relevant configuration should be clearly identified. Material differences in system functionality, integrations or regulatory settings can affect the scope of testing required for a particular deployment.

What Parts of an iGaming Platform May Need Testing?

The certification scope depends on the architecture and applicable regulatory requirements. A useful starting point is to divide the platform into functional components.

Not every component is necessarily tested in isolation. The laboratory may also need to assess interactions between systems because failures at integration points can affect player balances, transaction records, reporting or regulatory controls.

GLI-19 and iGaming Platform Certification

GLI-19 is a technical standard for Interactive Gaming Systems and is widely used as a reference point in regulated iGaming environments. The current published version is GLI-19 v3.0.

The standard addresses interactive gaming systems rather than serving as a universal licence or automatic approval for every jurisdiction. Each regulator determines the technical requirements applicable to its market and how independent laboratory testing should be used.

GLI-19 also distinguishes between laboratory testing of technical requirements and operational controls that may be assessed through other regulatory or audit processes.

This distinction matters because platform certification is not simply a matter of sending software to a laboratory. Operators and suppliers may also need appropriate internal controls, production configurations, security procedures and change-management processes.

For a dedicated breakdown of the standard, see our GLI-19 Interactive Gaming Systems guide.

Sports and event wagering systems should be assessed separately because GLI-19 itself directs event wagering systems to the GLI-33 standard.

6. Player Account Management (PAM) Testing

The Player Account Management system is one of the central components of an iGaming platform. It maintains the relationship between the player, account status, wallet, gaming activity, compliance controls and other connected systems.

During platform certification, the testing scope can include both the individual PAM functions and the way the PAM interacts with external services such as games, payments, KYC providers and reporting systems.

Core PAM Functions to Review

The PAM should also maintain consistent account states across connected systems. For example, a player who is restricted from gambling should not remain able to initiate gaming activity through another connected component.

PAM Configuration Matters

Two operators using the same core PAM can have different configurations, integrations and regulatory settings. This is particularly relevant to turnkey and white-label environments.

Player limits, KYC workflows, payment integrations, responsible gambling functionality and reporting can all vary between deployments. The certification scope should therefore reflect the configuration intended for the regulated operation.

7. Player Registration and Authentication Testing

Registration and authentication controls determine who can create and access a player account. They also connect the platform with identity, compliance and account-restriction processes.

Player Registration

Testing can examine whether the platform collects and processes the information required by the applicable configuration and whether account creation follows the intended workflow.

Relevant areas can include:

• creation of a unique player account;
• collection of required registration information;
• validation of mandatory fields;
• duplicate-account controls where applicable;
• age and identity-related controls;
• acceptance of player terms and policies;
• interaction with KYC or identity verification services;
• application of jurisdiction or location restrictions;
• account activation and status changes.

Authentication and Account Access

The platform should protect player accounts against unauthorised access and correctly enforce the authentication mechanisms implemented within the system.

The assessment can include:

• login functionality;
• credential handling;
• failed login behaviour;
• password reset and account recovery;
• session management;
• additional authentication controls where implemented;
• account lock or restriction behaviour;
• logging of relevant account-access events.

Account Status Must Be Enforced Across the Platform

Account status should affect the player's ability to use relevant platform functions.

For example, where an account is suspended, closed or subject to a gambling restriction, the platform should apply the relevant limitations consistently across gaming and other affected functionality.

8. Player Wallet and Ledger Testing

The player wallet and ledger are among the most financially sensitive components of an iGaming platform. They record the player's balance and the transactions that change that balance.

Certification testing should therefore focus not only on the displayed balance but also on the integrity and traceability of the underlying transactions.

Typical Wallet Transactions

Wallet Accuracy

A player's balance should be derived from valid and traceable transactions. Testing can therefore examine whether credits and debits are applied exactly once and whether the resulting balance remains consistent with the transaction history.

Particular attention should be given to interrupted requests, duplicate messages, delayed provider responses and other conditions that can create incorrect or duplicated wallet entries if they are not handled properly.

Multiple Balance Types

Some platforms maintain more than one type of balance, such as cash and bonus balances. Where multiple balances are used, the platform should apply the relevant transaction and wagering rules consistently.

The testing scope should therefore reflect the actual wallet model rather than assuming a single unrestricted balance.

9. Bet, Win, Refund and Rollback Testing

Gaming transactions pass between the platform and external gaming systems, such as a casino aggregator or individual game provider. These transaction flows are critical because an integration failure can directly affect player balances.

The certification process can therefore examine both normal transaction flows and exceptional scenarios.

Standard Gaming Transaction Flow

A simplified casino transaction can involve:

1. the player launches a game;
2. the game or aggregator identifies the player session;
3. a bet request is sent to the platform;
4. the platform validates the request and available balance;
5. the wager is recorded and the balance is updated;
6. the game result is determined by the gaming system;
7. a win or settlement transaction is returned;
8. the platform records the result and updates the player wallet;
9. the complete transaction remains available for reconciliation and audit.

Actual architectures vary, but the underlying objective remains the same: each valid financial event should be recorded accurately and associated with the correct player and gaming transaction.

Exceptional Transaction Scenarios

Operators using multiple game providers through an aggregation layer can review our Game Aggregation page for more information about provider and operator integrations.

10. Deposit and Withdrawal Testing

Payment processing is normally delivered through external banks, acquirers, EMIs, PSPs or alternative payment providers, but the iGaming platform still controls important parts of the player-facing payment workflow.

Platform testing can therefore focus on the interaction between the payment event, player account and wallet rather than attempting to certify the external financial institution itself.

Deposit Workflow

Relevant platform behaviour can include:

• association of the payment with the correct player;
• correct handling of successful payments;
• correct handling of declined or failed payments;
• prevention of unintended duplicate credits;
• transaction recording and reference data;
• application of relevant account or payment limits;
• interaction with KYC or account restrictions where applicable.

Withdrawal Workflow

Withdrawal testing can examine:

• withdrawal request creation;
• available balance validation;
• account and compliance restrictions;
• pending withdrawal treatment;
• approval or rejection workflows;
• successful payment completion;
• failed or cancelled withdrawals;
• correct restoration of funds where applicable;
• transaction history and audit records.

The precise payment flow varies between operators and PSPs. It should therefore be documented as part of the actual production architecture.

For the commercial and operational side of payment infrastructure, see our iGaming Banking and Payment Solutions page.

11. Transaction Integrity and Reconciliation

Platform certification should establish that gaming and financial transactions remain accurate, traceable and consistent across the relevant systems.

This becomes particularly important when a platform communicates with multiple external systems, including game aggregators, individual providers, payment services and reporting environments.

Transaction Integrity

Important principles include:

• each transaction should have an appropriate identifier;
• transactions should be associated with the correct player;
• credits and debits should be applied correctly;
• duplicate processing should be prevented;
• transaction status should remain traceable;
• reversals and refunds should reference the relevant original activity;
• material transaction events should be available for audit and reporting.

Reconciliation

Reconciliation is used to identify differences between records maintained by connected systems.

For example, the operator may need to compare platform transaction records with data received from a game provider, aggregator or payment service. Differences should be identifiable and capable of investigation.

Effective reconciliation is not only an accounting function. It can also help identify integration failures, duplicate transactions, missing settlements and other technical problems that affect the integrity of the gaming platform.

12. Responsible Gambling Controls Testing

Responsible gambling functionality is not only a policy issue. Many player-protection controls are implemented directly within the iGaming platform and can therefore form part of the technical testing scope.

The platform should apply configured player restrictions consistently across the relevant gaming, account and transaction functions.

Responsible Gambling Functions to Test

Controls Must Work Across Connected Systems

A restriction recorded in the PAM should be enforced by the functions that rely on that player status.

For example, a self-excluded player should not remain able to start a new gaming session through a connected casino integration simply because the restriction exists only in one part of the platform.

Testing should therefore consider the interaction between player status, wallet functionality, game launch, payments and other affected platform services.

Configuration Should Match the Target Market

Responsible gambling requirements differ between regulatory environments. The certification scope should therefore be based on the controls required for the intended jurisdiction and the actual configuration submitted for testing.

13. Back Office and Administrative Controls

The back office gives authorised personnel access to sensitive player, financial and operational functions. Administrative controls are therefore an important part of platform security and transaction integrity.

Certification testing can examine whether privileged functions are restricted appropriately and whether material administrative actions remain traceable.

Administrative Functions to Review

Depending on the platform, the back office can provide access to:

• player account information;
• account status changes;
• KYC and verification status;
• responsible gambling controls;
• deposit and withdrawal information;
• manual balance adjustments;
• bonus management;
• game and provider configuration;
• payment configuration;
• reports and transaction history;
• user and role administration;
• system configuration.

Role-Based Access Control

Administrative users should receive access appropriate to their responsibilities rather than automatically receiving unrestricted platform permissions.

Manual Balance Adjustments

Manual wallet adjustments are particularly sensitive because they can directly change a player's financial balance outside the normal gaming or payment transaction flow.

Where the platform supports manual adjustments, testing can examine authorisation, transaction recording, reason or reference information, audit logging and the resulting player balance.

14. Audit Logs and Event Traceability

Audit logging provides a record of important events within the gaming platform. Effective logs allow an operator, auditor or regulator to reconstruct relevant activity and investigate unusual events.

Logging should therefore be considered as part of the platform architecture rather than as a simple debugging function.

Events That May Require Logging

What Makes an Audit Log Useful?

A useful audit record should contain enough information to understand what happened and connect the event with the relevant player, transaction, administrative user or system process.

Depending on the event, useful information can include:

• date and time;
• event or transaction identifier;
• player or account identifier;
• administrative user where applicable;
• event type;
• previous and new values for relevant changes;
• transaction amount and status where applicable;
• related external reference or provider identifier.

Audit information should also be protected against inappropriate modification or deletion according to the applicable system and regulatory requirements.

15. Regulatory, Financial and Gaming Reporting

An iGaming platform can generate several categories of reports for operational, financial and regulatory purposes. Certification testing can examine whether relevant reports are based on accurate underlying system data.

Reporting is particularly important because regulators and operators may rely on aggregated figures that originate from large volumes of transaction-level records.

Common Reporting Areas

Report Accuracy and Reproducibility

A report should accurately represent the transactions and events stored by the platform. Where appropriate, reported totals should be capable of being traced back to the underlying records.

This allows discrepancies to be investigated and reduces the risk that a reporting problem remains hidden behind an aggregated figure.

Jurisdiction-Specific Reporting

Reporting requirements vary between jurisdictions. A platform designed for several regulated markets may therefore require different reports, data fields, calculation logic or submission formats for different deployments.

This is another reason why a platform that has previously been tested may still require additional configuration review when entering a new jurisdiction.

16. API and Third-Party Integration Testing

Modern iGaming platforms depend heavily on APIs. Games, payments, KYC, fraud monitoring, CRM tools and other services can all exchange data with the core platform through integrations.

The certification scope can therefore include the way the platform authenticates external systems, processes requests and maintains transaction integrity when third-party services respond unexpectedly.

Common iGaming Platform Integrations

• game aggregators;
• individual game providers;
• payment service providers;
• KYC and identity verification services;
• AML and sanctions-screening tools;
• fraud and risk-management systems;
• CRM and bonus systems;
• affiliate platforms;
• reporting services;
• sportsbook systems where applicable.

API Testing Areas

Integration testing is particularly important for financial transaction flows because failures between systems can create duplicate, missing or inconsistent wallet entries.

17. Game Aggregation Integration Testing

Game aggregation allows an operator to connect multiple casino game providers through a common integration layer. While this simplifies commercial and technical integration, it also creates an important transaction interface between the gaming platform and external game systems.

Platform certification can therefore include testing of the operator-side aggregation integration even where the individual games have been tested separately.

Typical Aggregation Flow

1. the authenticated player requests a game launch;
2. the platform creates or validates the relevant player session;
3. the aggregator receives the launch request;
4. the game provider delivers the game session;
5. gaming transactions are sent through the aggregation layer;
6. the platform validates and records the transactions;
7. the player wallet is updated;
8. transaction references remain available for reconciliation.

Aggregation Testing Checklist

The aggregation layer does not eliminate the platform's responsibility for maintaining accurate player and transaction records. The operator should understand how transaction identifiers, error handling, retries and reversals work across the complete integration.

For more information about aggregation architecture, see our Game Aggregation page.

18. Security Testing for iGaming Platforms

Security is a fundamental part of an iGaming platform because the system processes player information, authentication data, financial transactions and privileged administrative activity.

The exact security assessment depends on the applicable jurisdiction, testing scope and platform architecture. It can involve both technical controls within the platform and supporting infrastructure or operational procedures.

Key Security Areas

Security Testing Depends on the Architecture

A platform deployed entirely within infrastructure controlled by the supplier can present a different testing scope from a platform using multiple cloud services, external APIs, payment integrations and operator-controlled components.

The testing laboratory should therefore receive an accurate description of the production architecture and the boundaries between systems.

Privileged Access Is Particularly Sensitive

Administrative accounts can access functions that ordinary players cannot. Depending on the platform, this may include account changes, financial adjustments, configuration changes and access to sensitive information.

Privileged access should therefore be restricted, authenticated and appropriately logged.

19. Player Data and Sensitive Information

iGaming platforms process several categories of information that may be sensitive from a security, regulatory or privacy perspective.

This can include player identity information, account data, transaction history, responsible gambling information, authentication data and financial records.

Data Areas to Review

Access to sensitive information should be limited according to the function and responsibilities of the relevant user or system.

The platform architecture should also identify where material data is stored, processed or exchanged with third-party services.

20. Backup, Recovery and Business Continuity Testing

An iGaming platform should be able to recover from technical failures without losing the integrity of critical player, gaming and financial records.

Backup and recovery arrangements are therefore relevant to both system availability and transaction integrity.

Backup and Recovery Areas

• backup of critical databases and system information;
• frequency and retention of relevant backups;
• protection of backup data;
• restoration procedures;
• recovery of player account information;
• recovery of transaction and wallet records;
• recovery of configuration information;
• verification that restored information remains consistent.

Transaction Recovery

Financial and gaming transactions create an additional challenge because an interruption can occur while an external system and the platform have different information about the state of a transaction.

Recovery procedures should therefore consider not only restoring a database but also identifying incomplete or uncertain transactions and reconciling them with connected systems.

Disaster Recovery

Depending on the architecture and applicable requirements, the operator or supplier may need documented arrangements for restoring critical services following a major infrastructure failure.

The technical documentation should clearly identify the systems considered critical and the recovery approach used for those systems.

21. Change Management and Platform Updates

Certification is not necessarily a one-time exercise that permanently covers every future version of a platform. iGaming systems evolve through software releases, infrastructure changes, new integrations and configuration updates.

Operators and suppliers therefore need a controlled process for identifying, documenting and assessing material changes.

Examples of Platform Changes

Not Every Change Requires Full Re-Certification

The appropriate response depends on the nature of the change, applicable regulatory requirements and the existing certification scope.

A minor change may require documentation or limited regression testing, while a material change to a critical function can require additional laboratory assessment.

The operator or supplier should therefore maintain a process for classifying changes and determining whether regulatory notification, laboratory review or additional testing is required.

22. Version Control and Release Management

The version tested by the laboratory should be identifiable. Without controlled versioning, it becomes difficult to determine whether the production platform corresponds to the system that was assessed.

Version and Release Information

Depending on the development and deployment model, useful records can include:

• platform version or release identifier;
• release date;
• components included in the release;
• change log;
• relevant source or build references;
• database or configuration changes;
• deployment records;
• testing performed before release;
• known issues or limitations;
• rollback information where applicable.

Certified Version vs Production Version

A common certification risk arises when the platform continues to change while testing is in progress. If the production release differs materially from the submitted version, the testing scope can become unclear.

Development, laboratory testing and production deployment should therefore be coordinated so that the relevant certified or assessed version can be identified.

23. Technical Documentation for Platform Certification

Good technical documentation can reduce the time required for a testing laboratory to understand the platform and identify the components that fall within the assessment scope.

The exact document package depends on the laboratory, jurisdiction and system architecture, but operators and suppliers should expect to provide information describing both the platform and its operating environment.

Platform Documentation Checklist

Architecture diagrams are particularly useful where the platform depends on multiple external services because they allow the testing scope and system boundaries to be understood more quickly.

24. What to Submit to the Testing Laboratory

The laboratory submission should provide enough information and access for the agreed certification scope to be tested efficiently.

The exact requirements should always be confirmed with the selected testing laboratory, but a platform submission may involve several categories of material.

Define the Scope Before Testing Starts

One of the most useful preparation steps is to agree what exactly is being tested before the laboratory begins detailed work.

The scope should identify the platform version, components, integrations, target jurisdiction or standard and any existing certification that may be relevant.

This reduces the risk of paying for unnecessary testing or discovering late in the process that a critical component was outside the original submission.

For support with testing scope and laboratory coordination, see our iGaming Certification and Testing page.

25. iGaming Platform Certification Process Step by Step

Platform certification is easier to manage when the scope, technical documentation and system version are defined before formal laboratory testing begins.

The exact process varies by testing laboratory, jurisdiction and platform architecture, but a typical project can be divided into the following stages.

Start With the Target Jurisdiction

A common mistake is to request a generic platform certificate before determining where the platform will actually be used.

Technical requirements can differ between jurisdictions. Defining the intended market first helps determine which standard, test scope and laboratory output are actually required.

Perform a Gap Review Before Formal Testing

A pre-certification review can identify obvious problems before the laboratory begins detailed testing.

This can reduce repeated testing cycles caused by incomplete transaction logic, missing documentation, insufficient audit records or platform functionality that does not yet meet the intended requirements.

26. How Long Does iGaming Platform Certification Take?

There is no universal certification timeline for every iGaming platform. The duration depends on the scope of testing, platform maturity, documentation quality, laboratory capacity and the number of findings identified during assessment.

What Affects the Timeline?

Operators should therefore avoid treating an estimated laboratory timeline as a guaranteed launch date.

Development remediation, regulatory review, licensing and other operational workstreams can also affect the overall project schedule even after technical testing has been completed.

27. How Much Does iGaming Platform Certification Cost?

There is no single fixed price for certifying every iGaming platform. Testing laboratories typically determine the commercial scope according to the system being assessed, applicable requirements and amount of work involved.

A simple or previously tested configuration may require a substantially different budget from a new multi-component platform undergoing its first full assessment.

What Determines the Certification Cost?

Ask for an Itemised Testing Scope

Before approving a laboratory engagement, operators and software suppliers should understand what is included in the quotation.

The commercial proposal should ideally identify the platform version, applicable standard or jurisdiction, components being tested and any assumptions that could result in additional charges.

This makes it easier to compare laboratory proposals and reduces the risk of assuming that a quoted amount covers functionality that was actually outside the original scope.

GamingLicensing can assist with defining the certification scope and coordinating the testing process. See our iGaming Certification and Testing page for more information.

28. Can Existing Platform Certification Be Reused?

Existing technical certification can be valuable when a platform enters another regulated market, but it should not be assumed that one report or certificate automatically satisfies every jurisdiction.

Whether existing testing can be reused depends on the scope of the original assessment, the platform version, the new regulatory requirements and whether the production configuration has changed.

Questions to Ask Before Reusing Existing Certification

• Which platform version was originally tested?
• Which components were included in the original scope?
• Which technical standard or jurisdiction was used?
• Has the platform changed since the report was issued?
• Have wallet or transaction-processing functions changed?
• Have responsible gambling controls changed?
• Have new APIs or integrations been introduced?
• Does the new jurisdiction impose additional technical requirements?
• Will the regulator or selected laboratory accept the existing evidence?

Gap Testing Instead of Full Re-Testing

Where existing evidence remains relevant, it may be possible to focus new testing on differences between the previous assessment and the new requirements.

This is sometimes described as a gap assessment or delta approach. The practical scope should be agreed with the relevant laboratory and, where necessary, the regulator.

Reusing valid technical evidence can reduce duplicated work, but the decision should be based on the actual certification scope rather than the existence of a certificate alone.

29. White-Label and Multi-Tenant Platform Certification

White-label and multi-tenant platforms can support several operators from a shared technical environment. This can make certification more efficient, but it also makes configuration control particularly important.

The core platform may be common across multiple deployments while individual operators use different payment providers, games, responsible gambling settings, reporting configurations or third-party integrations.

Core Platform vs Operator Configuration

The certification strategy should distinguish between functionality that is genuinely common across deployments and functionality that changes for each operator or jurisdiction.

Why Configuration Control Matters

If an operator-specific configuration materially changes a previously tested function, the existing certification may not fully represent the final production deployment.

Suppliers should therefore maintain clear records of which components, versions and configurations are covered by existing technical evidence.

30. Platform Certification Across Different Gaming Jurisdictions

There is no single global iGaming platform certificate that automatically replaces the technical requirements of every gaming regulator.

Recognised laboratory reports and standards can provide a strong technical foundation, but the final acceptance of technical evidence depends on the rules and expectations of the relevant jurisdiction.

Jurisdictional Review Should Consider

• the applicable technical standards;
• whether independent laboratory testing is required;
• which laboratories or reports are accepted;
• whether existing certification can be reused;
• whether additional jurisdiction-specific testing is required;
• reporting and data requirements;
• responsible gambling functionality;
• security and operational requirements;
• change-management and approval obligations.

The technical certification strategy should therefore be planned together with the licensing strategy, particularly where the same platform will be used by operators in several regulated markets.

Isle of Man

Operators preparing an Isle of Man gaming operation should consider technical readiness alongside ownership, financial, compliance and operational requirements.

See our Isle of Man Gaming License guide and Isle of Man Gaming License Requirements 2026 for the wider licensing and technical preparation framework.

Malta

Malta-regulated projects should assess the technical systems and certification evidence required for the specific licensed operation together with the wider MGA application and compliance framework.

See our Malta Gaming Authority Licence guide for the jurisdiction overview.

Curaçao

Curaçao operators should consider platform, supplier, technical and compliance requirements as part of the wider licensing implementation under the current regulatory framework.

See our Curaçao Gaming License guide for the licensing overview.

Other Jurisdictions

The same principle applies to other regulated markets: determine the jurisdiction first, identify the applicable technical requirements and then establish which existing reports can be used and what additional testing is required.

This avoids unnecessary duplicate certification while ensuring that the final technical evidence corresponds to the market in which the platform will actually operate.

31. iGaming Platform Pre-Certification Checklist

Before submitting an iGaming platform to a testing laboratory, operators and software suppliers should confirm that the certification scope, platform version, documentation and test environment are sufficiently prepared.

The following checklist can help identify technical and documentation gaps before formal testing begins.

Completing this review before laboratory engagement can reduce avoidable clarification requests, testing delays and repeated remediation cycles.

32. Common iGaming Platform Certification Problems

Certification projects often become slower or more expensive because the platform is submitted before the technical scope, documentation or production architecture is sufficiently stable.

The Platform Is Still Changing

Major development during laboratory testing can make it difficult to determine which version is actually being assessed.

Material changes can also affect completed tests and create additional regression or certification work.

The Certification Scope Is Unclear

Submitting a complete platform without identifying the target jurisdiction, applicable requirements and specific components requiring assessment can lead to unnecessary testing.

The scope should therefore be defined before detailed laboratory work begins.

Technical Documentation Does Not Match the Platform

Outdated architecture diagrams, API documentation or transaction flows can create confusion during testing and make it more difficult to understand system boundaries.

Documentation should reflect the version and configuration actually submitted for assessment.

Wallet Edge Cases Are Not Fully Implemented

Standard bet and win flows may work correctly while duplicate requests, refunds, rollbacks, timeouts or interrupted transactions expose problems in the wallet or ledger.

These exceptional transaction scenarios should be considered before formal certification testing begins.

Insufficient Audit Logging

If material player, financial or administrative events cannot be traced, it can become difficult to investigate errors or demonstrate how the system reached a particular state.

Administrative Permissions Are Too Broad

Administrative users should not automatically have unrestricted access to every sensitive platform function. Privileged access should reflect actual operational responsibilities.

Existing Certification Is Assumed to Cover Everything

A previous laboratory report may remain useful, but it should be reviewed against the current platform version, configuration and target jurisdiction before being relied upon.

Third-Party Integrations Are Poorly Documented

Game aggregators, payment providers, KYC services and other external systems can form part of critical platform workflows.

The certification package should clearly explain which functions are performed internally and which depend on third-party services.

Certification Is Considered Too Late

Discovering technical certification requirements immediately before a planned launch can create unnecessary pressure on development, laboratory testing and licensing timelines.

Certification should therefore be considered during platform implementation and licensing rather than only after the product is otherwise ready to launch.

33. Frequently Asked Questions About iGaming Platform Certification

What is iGaming platform certification?

iGaming platform certification is an independent technical assessment of relevant gaming-system functionality against specified regulatory or technical requirements.

Depending on the scope, testing can cover the PAM, player wallet, transaction processing, responsible gambling controls, back office, reporting, APIs, security and other platform components.

Does every iGaming platform need certification?

The requirement depends on the jurisdiction, licence structure, role of the platform and technical configuration.

Operators and suppliers should identify the intended regulatory market first and then determine what technical evidence is required.

What is GLI-19?

GLI-19 is a technical standard for Interactive Gaming Systems. It addresses technical requirements relevant to interactive gaming environments and can form part of laboratory testing and regulatory assessment.

For a dedicated explanation, see our GLI-19 Interactive Gaming Systems guide.

Is GLI-19 certification the same as platform certification?

Not necessarily. GLI-19 provides a technical standard for interactive gaming systems, while the actual certification scope depends on the jurisdiction, platform components, configuration and regulatory requirements applicable to the project.

What parts of an iGaming platform are tested?

Depending on the agreed scope, testing can include player registration, authentication, PAM functionality, wallet and ledger processing, gaming transactions, responsible gambling controls, back-office permissions, audit logs, reporting, APIs, security and third-party integrations.

Does the player wallet need to be tested?

Wallet and ledger functionality can be a critical part of platform testing because it controls player balances and records deposits, bets, wins, refunds, reversals, withdrawals and other financial events.

Are payment providers included in platform certification?

External banks, EMIs, acquirers and PSPs are separate services. Platform testing can focus on how the gaming system processes payment events and how deposits and withdrawals affect the player account and wallet.

For the wider payment infrastructure, see our iGaming Banking and Payment Solutions page.

Does a game aggregator need separate testing?

The relevant testing scope depends on the architecture and jurisdiction. From the operator-platform perspective, the integration with an aggregator can require testing of game launch, wallet transactions, duplicate handling, refunds, rollbacks and reconciliation.

See our Game Aggregation page for more information.

Is platform certification the same as game certification?

No. Platform certification focuses on the gaming system and functions such as player accounts, wallets, transactions, reporting, administrative controls and integrations.

Game certification focuses on the individual game, including game functionality, mathematics, RTP, RNG behaviour and game-specific rules.

Can a previously certified platform be used in another jurisdiction?

Existing certification may provide useful technical evidence, but it should be reviewed against the requirements of the new jurisdiction and the current platform version and configuration.

Additional gap or jurisdiction-specific testing may be required.

Can the same platform certification be used for multiple operators?

A shared platform can have common technical components, but individual operators may use different configurations, integrations and regulatory settings.

The certification strategy should distinguish between the tested core platform and operator-specific functionality.

Do white-label casinos need separate platform certification?

The answer depends on the jurisdiction and the differences between the tested core platform and the individual white-label configuration.

Material operator-specific functionality, integrations or regulatory settings may require additional assessment.

How long does iGaming platform certification take?

The timeline depends on the platform scope, maturity, documentation, number of integrations, laboratory availability and findings identified during testing.

A stable platform with clear technical documentation is generally easier to assess than a system undergoing significant development during certification.

How much does iGaming platform certification cost?

There is no universal fixed price. Cost depends on the testing scope, target jurisdiction, platform complexity, integrations, existing certification and the amount of remediation or regression testing required.

An itemised testing scope should be obtained before formal laboratory work begins.

What documents are required for platform certification?

The exact submission depends on the laboratory and jurisdiction, but it can include system architecture, transaction flows, API documentation, platform descriptions, configuration information, version details, existing test reports and access to an appropriate test environment.

Do platform updates require re-certification?

Not every update necessarily requires a complete new assessment. Material changes should be reviewed against the applicable change-control and regulatory requirements to determine whether notification, gap testing or additional certification is required.

Can GamingLicensing coordinate iGaming platform certification?

GamingLicensing can assist with defining the certification scope, reviewing available technical documentation, identifying relevant testing workstreams and coordinating the project with independent testing laboratories.

Laboratory certification and regulatory acceptance remain decisions of the relevant testing body and regulator.

34. How GamingLicensing Supports Platform Certification

Platform certification involves more than sending software to a testing laboratory. The testing scope should correspond to the target jurisdiction, actual platform architecture and regulatory strategy of the project.

GamingLicensing can coordinate the certification workstream alongside the wider licensing and operational implementation.

Independent testing laboratories determine their own technical findings, reports and certification decisions. Regulators separately determine whether the submitted technical evidence is acceptable for the relevant licensing or approval process.

35. iGaming Platform Certification Resources

The following resources cover the principal technical, operational and regulatory topics connected with iGaming platform certification.

36. Get an iGaming Platform Certification Assessment

If you are preparing an iGaming platform for certification, GamingLicensing can review the project before formal laboratory testing begins.

The initial assessment can cover:

• the target gaming jurisdiction;
• the applicable technical testing scope;
• the current platform version and architecture;
• Player Account Management functionality;
• player registration and authentication;
• player wallet and ledger architecture;
• bet, win, refund and rollback processing;
• deposit and withdrawal workflows;
• responsible gambling functionality;
• back-office roles and administrative controls;
• audit logging and reporting;
• APIs and third-party integrations;
• game aggregation integration;
• security, backup and recovery arrangements;
• change management and version control;
• existing laboratory reports and certifications;
• technical documentation available for submission;
• potential gap or additional testing requirements.

Reviewing these areas before formal testing can help define the appropriate certification scope, identify missing documentation and reduce avoidable testing or remediation cycles.

Where existing certification is available, it can also be reviewed against the current platform version, configuration and target jurisdiction to determine whether the existing technical evidence remains relevant or whether additional assessment may be required.

GamingLicensing can then coordinate the technical certification workstream with the wider licensing, platform and operational implementation of the project.

Contact GamingLicensing for an iGaming platform certification assessment or visit our iGaming Certification and Testing page for the complete certification overview.