PCI DSS & Compliance Coverage for iGaming Payment Gateway: 12 PCI Requirements, 4 Other Frameworks, and Who Owns Each

PCI DSS and compliance coverage for an iGaming payment gateway is not one certificate hung on a wall. It is a deliberate division of responsibility — across PCI DSS, anti-money-laundering, data classification, audit trail, and sanctions screening — that determines which obligations sit with the managed gateway and which inevitably land on the operator. The honest answer is that no vendor can absorb every compliance dimension, and the ones that pretend to are the ones to worry about. This page draws the responsibility line explicitly.

A compliance lead reading a payment vendor's brochure is looking for exactly two things: which obligations the vendor genuinely handles, and which quietly land back on the operator's lap once the contract is signed. The article below uses the standard PCI DSS framework plus four adjacent compliance areas, and for each maps who owns what.

PCI DSS — The 12 Requirements and Who Owns Each

The PCI DSS framework defines 12 high-level requirements grouped into six control objectives. They're public, well-defined, and the same across every payment context. What varies vendor to vendor is which side of each requirement the gateway operates, and which side the operator is left to handle on their own. The mapping for our managed model:

The honest read on this matrix: 11 of 12 requirements are fully or primarily on our side; the remaining one (requirement 12, your own information security policy) is yours because no vendor can write your internal security policy for you. Most of the "shared" items reflect the fact that you also have an admin panel — and your admin users need their own access discipline, MFA posture, and policy on top of ours.

The Other 4 Frameworks Compliance Actually Touches

PCI DSS is the most named framework in payments, but it's far from the only one. A working iGaming gateway has to address four adjacent regimes, and a vendor that only talks about PCI is quietly under-disclosing. The four:

PCI Scope — What's In Our Scope and What's Not

The single most powerful question a compliance lead can ask a payment vendor is: "what's in your PCI scope and what's not?" The answer to that question determines exactly how much compliance burden you inherit. For our managed model:

The boundary is deliberately drawn so that your systems and processes outside the cashier surface do not handle PAN at all. That means your PCI scope on your side is dramatically smaller — typically a SAQ-A or SAQ-A-EP profile rather than a full SAQ-D — because you never see, transmit, or store raw card data. The tokens we return are scope-reducing by design.

Data Classification — Three Categories That Behave Differently

PCI DSS distinguishes between three categories of data, each with different handling rules. A clean compliance posture treats them differently from each other; lumping them together is how vendors quietly leak scope back to the operator. The honest classification:

Classification	Examples	How we handle it
PAN — Primary Account Number	Full card number (16 digits)	Captured by hosted fields inside our CDE; tokenised immediately; full PAN never crosses into systems outside our scope. Operators receive tokens only.
SAD — Sensitive Auth Data	CVV, magnetic-stripe data, PIN block	Never stored post-authorisation, full stop. Captured for the authorisation handshake; not persisted; not logged.
Metadata & Tokens	Tokens, transaction IDs, masked PAN (last 4)	Returned to operators for reference and reconciliation. Not PAN; outside PCI scope when handled correctly. Used in webhooks, admin views, audit logs.
Audit & Event Data	Order state transitions, action logs	Append-only event ledger. Retained per configured policy. Available to authorised operators and to auditors with appropriate access.

Sanctions & Adverse-Media Screening Flow

Sanctions screening is not optional for a payment business — it's enforced by acquirers, by regulators, and by basic business prudence. Every party in a transaction (payer, payee, beneficial owner) is screened against the standard lists at the moment they enter the system. The flow:

Audit-Readiness Checklist — What an Operator Receives

When your auditor (internal or external) asks for compliance evidence, the things we provide on your behalf are concrete, deliverable artefacts — not vague reassurances. The honest list:

Where Compliance Fits in the Bigger Picture

The audit trail and RBAC that this article references operationally live inside our merchant admin and order management back-end — the same back-end your operations team uses day-to-day, with append-only logging and per-action attribution. The broader infrastructure of how the managed model handles operations, security, and 24/7 response is described in our managed payment infrastructure article. Compliance is not a separate vertical; it's the discipline by which the same systems are run.

Everything Else, Compressed

Compliance & PCI-Specific Questions

The Next Step

A serious conversation about PCI DSS and compliance coverage for an iGaming payment gateway starts with a single question: where is the responsibility line drawn? The matrix and the scope diagram above are how we draw it. The four adjacent frameworks, the data classification, the sanctions flow, and the audit evidence are how we operationalise it. Operators who treat compliance as something they can outsource entirely are usually mid-way through learning that no vendor can do that legally. Operators who treat it as a shared engagement with a clearly-named line tend to pass audits cleanly.

Tell us your jurisdictional set, your current compliance posture, and any specific regulators you anticipate engaging with. We will scope the responsibility line for your situation explicitly — including the bits that remain on your side — and provide the documentation your compliance lead would want to see before any further conversation.