PCI DSS for a payment gateway: scope, levels and how to shrink it
What PCI DSS v4.0.1 asks of a payment gateway: who sets your validation level, when you need a Report on Compliance from a QSA, and how tokenisation and hosted fields shrink scope.
A payment gateway sits in the card data flow, so PCI DSS applies to it from the first transaction. In PCI terms, a gateway is a service provider: the PCI SSC's definition names payment gateways and payment service providers explicitly (PCI SSC Glossary). Here is the version in force, who sets your level, and how to make the assessment smaller.
This guide is general information, not legal or compliance advice: the details depend on your services and your market, so confirm them with your acquirer, a QSA and a lawyer before you start.
What PCI DSS is, in law and in practice
PCI DSS is written by the PCI Security Standards Council for every entity that stores, processes or transmits cardholder data or sensitive authentication data, or could affect the security of the cardholder data environment. Whether you must comply, and how you prove it, is decided by the organisations that run compliance programmes, such as the payment brands and acquirers (PCI SSC).
For a gateway, the obligation arrives through the card schemes' contracts. Visa requires PCI DSS of every entity that handles Visa cardholder data and holds issuers and acquirers responsible for the compliance of their service providers and merchants (Visa's account information security page), and a Visa member's contract with an agent must require PCI DSS (Visa Rules 10.2.2.2). In Visa's words, the PCI SSC owns the standard, while Visa manages compliance enforcement and validation.
The version in force: PCI DSS v4.0.1
v4.0.1 was published in June 2024 as a limited revision, with no new or deleted requirements (PCI SSC, 11 June 2024).
v4.0 was retired on 31 December 2024. Since then v4.0.1 is the only active version.
The future-dated requirements became effective on 31 March 2025. Until then they were best practice; from that date every new requirement applicable to you, including those a provider meets on your behalf, must be part of your assessment (FAQ 1564). They include the payment page script controls in Requirements 6.4.3 and 11.6.1 (PCI SSC, 30 January 2025).
A next version is being prepared. From 3 June to 20 July 2026, the PCI SSC took comments from its stakeholders on v4.0.1 to begin the next iteration of the standard (PCI SSC, 3 June 2026).
Who sets your level: the brands, not the PCI SSC
The PCI SSC does not enforce compliance or define validation reporting. The payment brands run the validation programmes (FAQ 1212), and acquirers and payment facilitators also set requirements for those they serve (PCI SSC, 30 January 2025). Service provider levels differ between the brands:
Visa | Mastercard | |
|---|---|---|
Level 1 | VisaNet processors, and service providers handling over 300,000 Visa transactions a year: annual on-site assessment and an AOC signed by a QSA | Every merchant payment gateway and third-party processor, whatever its volume, and payment facilitators over 300,000 Mastercard and Maestro transactions a year: annual ROC by a QSA |
Level 2 | Under 300,000 Visa transactions a year: SAQ D or an AOC signed by a QSA | Payment facilitators and data storage entities at or under 300,000: annual SAQ |
Sources: Visa and Mastercard's Site Data Protection page. Visa also requires issuers and acquirers to make every service provider demonstrate compliance at least every 12 months, and lists a service provider on its Global Registry of Service Providers only after validation by a QSA.
Merchant levels follow annual transaction counts. Both brands put merchants with more than 6 million of their transactions a year at Level 1, with a Report on Compliance every year.
The Report on Compliance and the QSA
The Report on Compliance (ROC) documents the detailed results of a PCI DSS assessment. The Attestation of Compliance (AOC) is the official PCI SSC form that attests to those results, from a ROC or a self-assessment questionnaire (SAQ) (Glossary).
A Qualified Security Assessor (QSA) is an independent security company qualified by the PCI SSC to validate compliance, and re-qualified every year. The PCI SSC advises checking its list each time you engage one (QSA list).
There is no PCI certificate. The PCI SSC issues no certificates or logos, and only its official forms, such as the ROC, AOC and SAQ, count as evidence (PCI SSC, 2 September 2025).
What the assessment asks of a gateway
A defined scope. The cardholder data environment is every system, person and process that handles card data, plus systems with unrestricted connectivity to them (Glossary). Requirement 12.5.2 makes confirming scope a yearly exercise, as a minimum (PCI SSC, 20 August 2024).
No sensitive authentication data after authorisation, such as the card verification code, even encrypted (FAQ 1533).
Clear duties to your merchants. They must manage their providers under Requirement 12.8, and you must tell them which requirements you cover and which stay with them, and give them your AOC on request (Requirements 12.9.1 and 12.9.2; FAQ 1312 and FAQ 1576).
How tokenisation and hosted fields shrink scope
The PCI SSC's starting point is simple: do not store card data you do not need (Tokenization Guidelines, 2011).
Tokenisation replaces the card number with a surrogate value. The tokenisation system, and anything connected to it, stays in scope. Systems that handle only tokens, cannot turn them back into card numbers and are segmented from the cardholder data environment may fall out of scope. It reduces what you validate; it does not remove validation (same guidelines). The schemes push the same way: in Mastercard's Europe region, acquirers and their service providers, gateways included, must support tokenisation of stored credentials from 1 October 2026 (Mastercard Rules, 2 June 2026, Europe Region Rule 5.16).
Hosted payment fields keep card entry out of the merchant's systems. A merchant whose card data functions are completely outsourced to PCI DSS validated and compliant providers may be eligible for SAQ A, the questionnaire written for that case (PCI SSC, 30 January 2025). With embedded fields, the merchant must confirm its site is not exposed to script attacks, for example with the provider's confirmation that its solution protects the page (FAQ 1588), and it still needs external scans by an Approved Scanning Vendor (FAQ 1604).
The same logic applies to the gateway itself. If a validated processor's fields and vault capture the card and only tokens reach you, your cardholder data environment shrinks. PCI DSS still applies if your service facilitates the transmission of card data, even by passing a redirect (FAQ 1579), and your assessment then covers the people, processes and technology behind your service, with every requirement marked not applicable justified (FAQ 1580). If Mastercard registers you as a merchant payment gateway, you are Level 1 whatever your volume. A smaller scope means fewer systems to assess; it does not change the level.
The steps
Map the card data flow and decide what your systems will touch.
Confirm your level and reporting route with your acquirer and the brands.
Run a gap assessment against v4.0.1, including the former future-dated requirements.
Fix the gaps, set up scanning and write the responsibility matrix for your merchants.
Have a QSA assess you, then submit the ROC and AOC as each brand requires.
Get registered as an agent or service provider through your acquirer or sponsor.
Repeat every year, starting with scope.
To go live before your own assessment, agree it with your acquirer first, and keep card capture on a validated provider's hosted fields and vault, relying on its AOC for what it covers (FAQ 1576).
Common mistakes
Accepting a "PCI certificate" instead of an AOC.
Treating a level as a feature of software. Levels apply to the company that handles the transactions.
Keeping card verification codes after authorisation, even encrypted.
Telling SAQ A merchants they need nothing more. They still need scans and protection against script attacks.
Forgetting connected systems. Anything connected to the cardholder data environment or the token system is in scope.
What this means for your platform
Our white-label payment gateway gives merchants a hosted payment page, payment links and an API, with cards and 3-D Secure, Apple Pay and Google Pay, routed to card processors such as Adyen, Checkout.com, Stripe, Worldpay and Braintree. Our SoftPOS platform reads cards through Tap to Pay on iPhone or a PCI MPoC kernel on Android; the SoftPOS certification guide explains that standard. Validation belongs to the company that operates the platform, so your QSA assesses your deployment; we configure the platform to match your scope and your acquirer's requirements.
Sources
All checked on 6 October 2026.
PCI SSC: Important Updates Announced for Merchants Validating to SAQ A, 30 January 2025
PCI SSC: Beware of PCI DSS Compliance Certificates, 2 September 2025
PCI SSC: Request for Comments on PCI DSS v4.0.1, 3 June 2026
PCI SSC FAQs 1212, 1312, 1533, 1564, 1576, 1579, 1580, 1588 and 1604
PCI SSC: Information Supplement, PCI DSS Tokenization Guidelines, August 2011
Visa Core Rules and Visa Product and Service Rules, 18 April 2026
