PCI DSS for iGaming Payments Explained

Every gambling operator that touches a card number is bound by PCI DSS, whether it has read the standard or not. There is no gambling exemption, no small-operator carve-out, and no version of the rules that lets you skip it because a PSP sits in the middle.

PCI DSS decides how you handle card data, which paperwork you file each year, and how much of your own platform an auditor gets to inspect. Get the design right and your obligation shrinks to a short questionnaire. Get it wrong and you are running a Level 1 audit you didn't need.

This guide covers what the standard is, how it applies to iGaming specifically, the merchant levels, the questionnaire that decides your workload, and the payment-page rules that turned mandatory in March 2025. Facts verified as of August 2026.

What is PCI DSS?

PCI DSS is the Payment Card Industry Data Security Standard: a set of security controls that any organisation storing, processing or transmitting card data must meet. It is written and maintained by the PCI Security Standards Council, the body founded by Visa, Mastercard, American Express, Discover and JCB.

Term: PCI DSS. Definition: The Payment Card Industry Data Security Standard, a card scheme mandated set of controls for protecting cardholder data across storage, processing and transmission.

The standard isn't law. It's a contractual requirement that flows down through the card schemes to your acquirer, and from your acquirer to you. Breach it and the enforcement is commercial, not criminal: fines passed down the chain, higher processing costs, and in the worst case the loss of your ability to take cards at all.

The current version is PCI DSS v4.0.1, published in June 2024. It became the only active version of the standard when v4.0 was retired on 31 December 2024, so any assessment signed off today is measured against 4.0.1.

Does PCI DSS apply to iGaming operators?

Yes. PCI DSS applies to every merchant that accepts card payments, and gambling operators are merchants like any other. Using a payment service provider does not remove the obligation; it changes how much of the standard you have to validate yourself.

This trips people up because operators assume that outsourcing the card form to a PSP outsources the compliance too. It doesn't. If a card number can pass through, or be captured by, any system you control, that system is in scope. Even a fully hosted checkout leaves you responsible for the page that redirects to it.

iGaming carries a few complications that mainstream retail doesn't. Deposit volumes are high, so operators hit the upper merchant levels faster. Chargeback and fraud pressure is heavier, which draws more acquirer scrutiny. And the same high-risk merchant account that makes acquiring harder also means your acquirer watches your PCI status more closely than it would a low-risk shop.

What are the PCI DSS merchant levels?

PCI DSS sorts merchants into four levels by annual card transaction volume. The level sets how you prove compliance: the top level needs an external audit, the rest can self-assess. Visa's thresholds, published in its Account Information Security programme, are the ones most acquirers apply.

• Level 1 - more than 6 million card transactions a year. Requires an annual onsite assessment by a Qualified Security Assessor (QSA) and a Report on Compliance (ROC).
• Level 2 - 1 million to 6 million transactions a year. Annual self-assessment, usually with an onsite review depending on the acquirer.
• Level 3 - 20,000 to 1 million e-commerce transactions a year. Annual self-assessment questionnaire.
• Level 4 - fewer than 20,000 e-commerce transactions, or up to 1 million total. Annual self-assessment questionnaire.

A busy online casino or sportsbook clears 6 million transactions without much effort, which pushes plenty of operators into Level 1 and the full QSA audit. That's a real annual cost in both money and engineering time, and it's the single biggest reason to think about scope reduction before your volumes climb, not after.

One more detail: a card scheme can designate any merchant as Level 1 regardless of volume, typically after a breach. A gambling brand that suffers a card data incident can find itself audited at the top level the following year even if its numbers say otherwise.

Which SAQ applies to an iGaming operator?

The Self-Assessment Questionnaire (SAQ) is the form merchants below Level 1 use to validate compliance. Which one you file depends entirely on how card data reaches your systems, and the difference between them is enormous.

Term: SAQ. Definition: A Self-Assessment Questionnaire that a merchant completes to attest PCI DSS compliance, with the type set by the merchant's payment acceptance method.

• SAQ A - for operators that fully outsource the card page to a PCI-compliant provider, so no card data touches their servers. The shortest questionnaire by a wide margin.
• SAQ A-EP - for e-commerce merchants whose site controls how the payment page is delivered but doesn't receive the card data itself. Far longer than SAQ A.
• SAQ D - for everyone else, including any merchant that stores, processes or transmits card data directly. The longest and most demanding by a distance.

The gap between SAQ A and SAQ D is the difference between a couple of dozen questions and hundreds. My advice to operators has always been the same: design the deposit flow so you qualify for SAQ A, and treat any architecture that drags you toward SAQ D as a cost you're choosing to pay. This is where tokenisation and hosted fields earn their keep.

What changed in PCI DSS v4.0.1?

Version 4.0.1 itself made no new requirements over v4.0; it corrected errata and clarified wording. The change that matters is the batch of future-dated requirements from v4.0 that became mandatory on 31 March 2025, after years as best-practice only.

Two of those requirements target payment-page skimming directly, and they hit iGaming operators hard because most run a browser-based deposit form:

• Requirement 6.4.3 - you must inventory every script that loads on the payment page, authorise each one, and confirm its integrity. No unaccounted-for JavaScript.
• Requirement 11.6.1 - you must detect and alert on unauthorised changes to the payment page's scripts and HTTP security headers.

Both exist because of e-skimming, the Magecart-style attack where a criminal doesn't breach your server at all - they alter a script the browser loads and read the card number straight out of the form as the player types it. The PCI SSC set this out in its payment page security guidance. A gambling site loading analytics, chat widgets and marketing tags on the same page as the card form is exactly the target these rules were written for.

Other v4.0.1 requirements that became mandatory the same day include stricter multi-factor authentication into the cardholder data environment, a documented targeted risk analysis for certain controls, and authenticated internal vulnerability scans. None are gambling-specific, but all apply to a gambling platform.

How do iGaming operators reduce PCI DSS scope?

The winning move is to keep card data out of your systems entirely, so most of the standard simply doesn't apply. Every card number your platform never sees is a control you never have to build, test or evidence.

• Use a hosted payment page or hosted fields. If the card is entered in an iframe served by your PSP, the data goes provider to provider and your servers stay out of scope. This is the route to SAQ A.
• Tokenise everything you keep. Store a token instead of a card number so returning-player deposits never retouch raw card data. Network tokens go further and lift approval rates at the same time.
• Cut the clutter off the payment page. Requirement 6.4.3 gets easier the fewer third-party scripts you load next to the card form. Move analytics and chat off that page.
• Choose PSPs that carry the compliance weight. A provider validated as a PCI DSS Level 1 service provider absorbs the controls you'd otherwise own. Confirm it holds a current Attestation of Compliance before you integrate.

Provider selection does most of the work here. The iGamingPayments.ai directory lists PSPs by region and vertical, including which ones run their own PCI Level 1 environment rather than reselling someone else's. Our payments glossary defines the surrounding terms, and if you're weighing a switch, the approval rate calculator shows what a cleaner, tokenised flow is worth in recovered deposits.

What happens if you're not PCI compliant?

Non-compliance is a commercial risk that lands hardest when something goes wrong. There's no regulator fining you directly under PCI DSS, but the card schemes fine your acquirer, and your acquirer passes it down through your merchant agreement.

The heavier costs arrive after a breach. If card data is stolen from a merchant that wasn't compliant, the schemes can levy substantial penalties, demand a forensic investigation at the merchant's expense, and impose recovery costs for the exposed cards. For a high-risk gambling merchant already under close watch, a card data breach can also cost the account itself.

Set against that, the compliance itself is cheap. Most of what PCI DSS asks for - keeping card data out of your systems, patching, access control, monitoring the payment page - is what a competent operator should be doing regardless. The paperwork is the annoying part; the controls are just sound engineering.

Frequently asked questions

Is PCI DSS a legal requirement for gambling operators?

No, PCI DSS is a contractual requirement enforced by the card schemes through your acquirer, not a law. That said, breaching it puts you in breach of your merchant agreement, and the financial consequences after a card data incident can be as damaging as a regulatory fine.

Do I still need PCI compliance if I use a payment service provider?

Yes. Using a PSP can dramatically reduce your scope, often down to the short SAQ A, but it never removes the obligation entirely. You remain responsible for the page that presents or redirects to the card form and for confirming your PSP holds a current PCI compliance attestation.

What PCI level is an online casino?

It depends on transaction volume. A casino processing more than 6 million card transactions a year is Level 1 and needs an annual QSA audit; smaller operators fall into Levels 2 to 4 and self-assess. High deposit volumes mean many iGaming brands reach Level 1 sooner than mainstream retailers.

What is the difference between SAQ A and SAQ D?

SAQ A is for merchants that fully outsource card handling so no card data touches their systems, and it has a short list of controls. SAQ D covers merchants that store, process or transmit card data directly and runs to hundreds of questions. The gap between them is the strongest argument for a hosted, tokenised deposit flow.

What are PCI DSS requirements 6.4.3 and 11.6.1?

They are the payment-page security rules that became mandatory on 31 March 2025. Requirement 6.4.3 makes you inventory and authorise every script on the payment page; 11.6.1 makes you detect and alert on unauthorised changes to those scripts and the page's security headers. Both exist to stop browser-based card skimming.

How much does PCI compliance cost an iGaming operator?

It varies widely by scope. A Level 1 QSA audit runs into tens of thousands of pounds a year plus internal engineering time, while a well-designed SAQ A operation carries a fraction of that. The single biggest cost driver is whether card data touches your own systems, which is why scope reduction pays for itself.

Is crypto gambling subject to PCI DSS?

Only where cards are involved. Pure on-chain crypto deposits sit outside the card networks and therefore outside PCI DSS. But the moment a player funds a wallet or deposits with a card, that card transaction is in scope, so most operators that accept both still need to comply.

Find the right payment provider for your operation

Browse 342+ vetted PSPs, crypto processors, open banking providers and fraud vendors - filtered by region, vertical and payment method. Or run the numbers before your next PSP negotiation.