This guide is general information, not a compliance assessment. Your acquiring bank or payment provider tells you which validation you need, and the official documents are published by the PCI Security Standards Council.
What is PCI DSS?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements for any organisation that stores, processes or transmits payment card data, or that can affect the security of that data. It is maintained by the PCI Security Standards Council, founded by the major card brands. Compliance is required by the card brands through your contract with your acquirer or payment provider.
Which version applies?
- PCI DSS v4.0 was published in March 2022, and v3.2.1 was retired on 31 March 2024.
- PCI DSS v4.0.1, a limited revision with clarifications, was published in June 2024 and v4.0 was retired at the end of 2024.
- Requirements that v4.0 marked as "future-dated" became mandatory on 31 March 2025. Two of them target eCommerce payment pages directly (see below).
Self-assessment questionnaires for eCommerce
Most small and mid-sized merchants validate compliance with a Self-Assessment Questionnaire (SAQ). Which SAQ applies depends mainly on how your checkout collects card details:
| SAQ | Typical eCommerce setup | Scope |
|---|---|---|
| SAQ A | All card data functions fully outsourced to a PCI DSS-compliant provider. Card details are entered only on the provider's page (redirect) or in the provider's iframe/hosted fields. | Smallest |
| SAQ A-EP | Card data goes directly to the provider, but your website controls how it is collected, for example a payment form served from your pages that posts directly to the provider or uses the provider's JavaScript in your page. | Larger: your web servers are in scope |
| SAQ D | Your systems receive, process or store card numbers, for example card details posted to your own server. | Full PCI DSS |
The exact eligibility criteria are listed at the start of each SAQ document. Large merchants (by annual transaction volume, as defined by each card brand) may need a Report on Compliance by a Qualified Security Assessor instead.
Payment page script requirements (6.4.3 and 11.6.1)
Attacks that inject malicious JavaScript into checkout pages to skim card details (often called Magecart or e-skimming) led to two requirements in v4.x:
- Requirement 6.4.3: manage all scripts loaded and executed on the payment page in the consumer's browser: keep an inventory with a written justification for each, confirm each script is authorised, and assure its integrity.
- Requirement 11.6.1: deploy a change- and tamper-detection mechanism that alerts on unauthorised changes to the security-relevant HTTP headers and contents of payment pages as received by the browser, run at least weekly or at a frequency defined by your risk analysis.
In January 2025 the PCI SSC revised SAQ A: these two requirements were removed from SAQ A and replaced with an eligibility criterion that the merchant confirms its site is not susceptible to attacks from scripts that could affect its eCommerce systems. If you embed a provider's payment iframe in your own page, read the current SAQ A and your provider's guidance carefully. For SAQ A-EP and SAQ D merchants, 6.4.3 and 11.6.1 apply in full.
How to keep PCI scope small
- Use a hosted payment page, redirect or provider-hosted fields so card numbers never touch your servers.
- Minimise scripts on checkout pages: no tag managers, chat widgets, A/B testing or ad pixels on payment pages unless strictly needed.
- Use a Content Security Policy and Subresource Integrity to restrict which scripts can run, and monitor for changes.
- Keep platforms, plugins and themes updated; most skimming starts with a compromised extension or admin account.
- Protect admin access with multi-factor authentication and unique accounts.
- Never store card numbers; use the provider's tokens for repeat payments and subscriptions.
Hosted platforms such as Shopify are PCI DSS compliant for the checkout they host, but you still have responsibilities, for example for scripts and apps you add, and for protecting admin access.
Our integration services design payment flows with hosted fields and minimal checkout scripts by default.