Our algorithm does not take a payment provider’s “bank-level security” claim at face value. Instead, it checks the same signals a regulator or forensic auditor would: PCI DSS 4.0.1 compliance status, tokenization architecture, breach disclosure history, and whether the operator’s license conditions have ever required a third-party audit of that supplier. This article explains what those signals are, why they matter, and where the evidence for each one comes from.
Key takeaways
- PCI DSS 4.0.1’s future-dated requirements became mandatory on March 31, 2025, and now apply directly to third-party service providers, not just the merchant of record.
- Regulators including the UK Gambling Commission and Malta Gaming Authority already impose or can impose third-party audit conditions on licensees, which gives us a public, verifiable trail to check.
- Financial-services breaches averaged $5.56 million in 2025 per IBM’s Cost of a Data Breach Report, well above the global average, making cashier security a material financial risk, not just a compliance checkbox.
- Several recent gambling-sector data incidents originated at a third-party platform or vendor rather than the operator’s own systems, which is why our scoring treats the cashier as a separate attack surface.
- “Bank-level encryption” is marketing language with no fixed technical definition; our algorithm scores documented protocols (TLS versions, tokenization, PCI attestation level) instead.
Table of contents
Why third-party cashiers are the weak link
Most licensed operators do not build their own cashier. They plug in a third-party payment gateway or platform provider that handles card data, e-wallet routing, and settlement. That integration point is where a growing share of gambling-sector incidents actually originate. In a 2019 case documented by security researchers, an online casino group leaked information about 108 million bets including user details, with personal information and payment card details among the exposed records.
More recent incidents follow the same pattern. In the Merkur Group case reported in March 2025, a researcher’s disclosure showed that over 800,000 individual players’ records were exposed across Merkur’s various platforms, including bank and payment information linked to accounts. And in the Station Casinos disclosure made public in May 2026, the company confirmed that hackers were also able to obtain information such as financial account numbers, dates of birth, driver’s license numbers, email addresses, phone numbers, payment information, card information, and SSNs in some limited cases. None of these events required the operator’s core platform to be compromised directly — the exposure sat in adjacent systems that touch payment or account data.
This is the structural reason our security and fraud-detection scoring treats the cashier as a distinct attack surface rather than folding it into a generic “site security” score. An operator’s own front end can be hardened, and the cashier it depends on can still be the point of failure.
PCI DSS 4.0.1: the non-negotiable baseline
The Payment Card Industry Data Security Standard is the floor, not the ceiling, for any entity that touches cardholder data. The transition to version 4.0 introduced roughly 50 new technical requirements, and the grace period for implementing them is over. As of the current rule set, all merchants and third-party service providers involved in processing credit or debit card payments must fully adhere to the enhanced security requirements outlined in PCI DSS 4.0. Critically, the standard names third-party service providers explicitly — it is not enough for the operator to be compliant if the payment gateway behind it is not.
The compliance calendar is now fixed history rather than a future deadline. The PCI DSS future-dated requirements are no longer optional; they became mandatory on March 31, 2025, and after that date, PCI DSS 3.2.1 was fully retired and all organizations must comply with PCI DSS 4.0 requirements. Any payment gateway still citing 3.2.1 attestation, or unable to produce a current Attestation of Compliance (AOC) or Report on Compliance (ROC) reference, is operating on an expired standard. That is one of the simplest binary checks our algorithm can run, and it is surprising how often it still flags a gap.
What our payment gateway audit actually checks
A payment gateway audit, in our methodology, is not a single test but a composite of scraped and publicly verifiable signals. We do not have privileged access to any operator’s or provider’s internal infrastructure — everything below is built from public disclosures, regulatory filings, and technical fingerprinting available to any outside observer, which is consistent with the approach described on our data scraping and technical engine hub.
Encryption and tokenization signals
We fingerprint the TLS configuration exposed by the cashier’s checkout domain, checking protocol version, cipher suite strength, and certificate chain validity. We also look for evidence of tokenization — whether the gateway is designed so raw card numbers never touch the operator’s own servers. Tokenization is the practical answer to the scope problem PCI DSS creates: the wider the cardholder data environment, the more systems fall into compliance scope, and the more expensive and complex an audit becomes. A provider that tokenizes at the point of entry keeps that environment small, which is a positive signal in our scoring.
Licensing and regulatory audit trail
Where a payment or platform supplier is licensed as a critical supplier in its own right, that license carries its own audit obligations. Malta’s regime is the clearest public example: the Malta Gaming Authority states that it may require any licensee to undergo a Compliance Audit, on a regular or ad hoc basis, in accordance with any binding instrument the Authority issues, and it maintains a formal framework of MGA-approved audit firms for that purpose, as described on the MGA’s compliance and systems audits framework page. Separately, suppliers whose services materially affect an operator’s regulatory position increasingly need their own credential: the Gaming Act requires a Critical Gaming Supply licence for suppliers whose services or components materially affect gaming outcomes or the operator’s regulatory position. Our algorithm checks whether a payment provider serving MGA-licensed operators appears in that supplier ecosystem, or whether it sits entirely outside any licensing regime — a meaningful distinction that marketing copy rarely mentions.
Breach disclosure and incident history
We track disclosed security incidents tied to a given payment provider or platform across the operators that use it, cross-referencing regulatory notifications, court filings, and verified security research where available. A single disclosed incident does not automatically sink a provider’s score — response time, scope of the exposure, and whether card data specifically was affected all factor in. But a pattern of incidents, or a provider that has never disclosed anything despite known industry-wide vulnerabilities, both register differently in our weighting model, which is described in more depth on our scoring system and algorithmic weights hub.
Regulatory precedent for third-party audits
Skeptics sometimes ask why an algorithm should care about payment security when regulators already police it. The answer is that regulators frequently respond to failures after the fact by mandating exactly the kind of third-party audit our scoring tries to anticipate — which means the audit requirement itself is a lagging indicator, not a preventive one.
The UK Gambling Commission’s enforcement record shows this pattern repeatedly. Corbett Bookmakers, penalized after social responsibility and AML failings, will also undergo a third-party audit to ensure it is effectively implementing its AML and safer gambling policies, procedures and controls. Videoslots received the same condition: the operator will also receive a warning and is required to undergo a third-party audit to ensure it is effectively implementing its AML and safer gambling policies, procedures and controls. Part of that Videoslots case turned directly on payment mechanics: the Commission found that the automated scoring system in place at the time did not identify the activity as high risk, involving open-loop prepaid vouchers the Commission has since flagged as high risk for monitoring purposes.
Spreadex faced a similar outcome in 2025: following a licence review, the Commission imposed a fine of £2,022,000 on Spreadex following a review of its operating licence for AML and SR failings and attached a condition requiring Spreadex to undergo a third-party audit to ensure it is effectively implementing its AML and safer gambling policies, procedures and controls. The through-line across these cases is that “third-party audit” is not a niche compliance term — it is the standard remedy regulators reach for once payment and monitoring controls have already failed. Our approach tries to score for that risk before the fine lands, using the same category of evidence regulators cite after the fact.
| Signal category | What it verifies | Example public data source |
|---|---|---|
| PCI DSS attestation status | Whether the gateway complies with current (4.0.1) requirements, not a retired version | Published AOC/ROC references, provider compliance pages |
| TLS / encryption fingerprint | Protocol version and cipher strength on the live checkout endpoint | Direct TLS handshake scraping |
| Tokenization architecture | Whether raw card data ever reaches the operator’s own servers | Technical documentation, integration disclosures |
| Critical-supplier licensing | Whether the provider is licensed/audited as a supplier in relevant jurisdictions | MGA supplier registers, national regulator databases |
| Breach disclosure history | Frequency, scope and transparency of past incidents | Regulatory notifications, verified security research |
| Regulatory audit conditions | Whether operators using the provider have been ordered into third-party audits | Regulator enforcement notices (e.g., UKGC) |
The cost of a cashier that fails
Payment security is a financial question as much as a technical one. Globally, average breach costs dropped to USD 4.44 million, down from USD 4.88 million the year prior, according to IBM’s 2025 Cost of a Data Breach Report. That global figure masks significant sector variation: financial services breaches averaged $5.56 million in 2025, well above the global mean, reflecting the regulatory fines and fraud-liability exposure that comes with payment data specifically. Speed matters too — breaches contained within 200 days cost an average of $3.87 million, while those exceeding 200 days cost $5.01 million, a gap directly tied to how quickly an incident at a third-party provider is detected and disclosed.
For gambling operators, this is layered on top of gambling-specific regulatory exposure. The UK Gambling Commission’s largest enforcement actions already run into eight figures for AML and social-responsibility failings that touch payment monitoring, and those penalties sit alongside — not instead of — any card-network fines, breach notification costs, and customer compensation a compromised gateway would also trigger. This is the economic backdrop covered in more depth on our macro economics of iGaming hub.
“Bank-level encryption” vs. verifiable signals
“Bank-level encryption” and “military-grade security” are copywriting, not specifications. Banks themselves use a range of protocols depending on system age and jurisdiction, and there is no regulatory definition that a payment provider is bound to when it uses either phrase. Our algorithm ignores this language entirely and scores only what can be independently confirmed: TLS version and cipher suite in production, PCI DSS attestation level and date, tokenization scope, and the audit and incident history described above. This is consistent with the broader case we make on our core principles hub against relying on operator-supplied claims, and with the technology-specific detail covered on our payments and crypto gambling hub.
Where a provider cannot be verified against any of these signals — no current PCI reference, no licensing footprint, no disclosed TLS configuration on its checkout flow — our scoring treats that opacity itself as a risk factor, distinct from and in addition to any specific finding of weakness.
Frequently asked questions
What is a payment gateway audit in this context?
It is a structured review of the technical and regulatory signals that indicate whether a third-party cashier provider is handling payment data securely, covering encryption configuration, PCI DSS compliance status, tokenization design, licensing footprint, and any disclosed breach or regulatory-audit history tied to that provider.
Do all online casinos use third-party payment providers?
The large majority do. Building and maintaining PCI-compliant card processing in-house is costly and operationally complex, so most licensed operators integrate an established gateway or platform provider instead, which is why the security of that provider matters as much as the operator’s own systems.
Does PCI DSS compliance guarantee a payment provider is safe?
No. PCI DSS sets a minimum technical baseline for handling cardholder data, and noncompliance can result in significant financial penalties, legal ramifications, and damage to an organization’s reputation, but attestation is a point-in-time assessment, not a continuous guarantee. Breaches have occurred at organizations holding current PCI certification, which is why our scoring also weighs incident history and audit trail, not attestation alone.
Why do gambling regulators order third-party audits after fines?
Regulators use third-party audits as a remedial condition to verify that an operator’s control failures — often involving payment monitoring or AML systems — have actually been fixed, rather than relying on the operator’s own assurance. The UK Gambling Commission has attached this condition to multiple recent enforcement cases involving AML and payment-related failings.
Methodology
For this topic, our algorithm combines direct technical fingerprinting of checkout endpoints (TLS/cipher data), scraped regulatory disclosures (fines, licence conditions, audit requirements) from bodies such as the UK Gambling Commission and Malta Gaming Authority, and cross-referenced breach and incident reports from security research and regulatory notifications. These signals feed into the security and fraud-detection weighting described on our Security, Encryption & Data Privacy hub, and are never substituted with an operator’s or provider’s own marketing claims.
Gambling involves risk. Only play with money you can afford to lose and use the deposit limits and self-exclusion tools available in your jurisdiction.
