PCI DSS Compliance for Merchants and Service Providers: Requirements, Levels, and SAQs

PCI DSS (Payment Card Industry Data Security Standard) is the security standard for any business that stores, processes, or transmits payment card data, maintained by the PCI Security Standards Council and enforced through card brands and acquiring banks. The current version is PCI DSS v4.0.1, and since March 31, 2025 every requirement in it is mandatory, including the e-commerce script controls that were optional until then.

This guide covers what the standard requires, how your merchant level and checkout setup decide the validation work, what changed for online payment pages, who actually fines non-compliance, and where PCI compliance stops helping once a customer files a dispute. It is written for merchants and for the service providers that handle card data for them.

Sources: PCI Security Standards Council; Mastercard Site Data Protection program.

What PCI DSS Requires: 6 Goals and 12 Requirements

PCI DSS groups its 12 principal requirements under six goals. The wording below follows the v4.0.1 requirement titles.

The requirements apply to the cardholder data environment: systems that store, process, or transmit card data, plus connected systems that could affect their security. The Council's standards page describes the standard as intended for merchants, processors, acquirers, issuers, and service providers. In day-to-day terms, requirements 5 and 6 come down to regularly updating systems and applications with the latest security patches and running anti-malware on every in-scope system. The fastest way to cut the workload is to shrink that environment, which the scope section below covers.

What Changed in v4.0.1 and the March 31, 2025 Deadline

PCI DSS v4.0 replaced v3.2.1, which was retired on March 31, 2024. The Council then published v4.0.1 as a limited revision with no requirements added or removed, and retired v4.0 on December 31, 2024. As of October 2026, v4.0.1 remains the current version of the main standard. Several widely read guides still quote the older v3.2.1 requirement list, so check which version a source describes before you rely on it.

The change that matters most for online checkout is a pair of e-skimming controls, requirements 6.4.3 and 11.6.1. They require payment page scripts to be authorized, checked for integrity, and monitored for tampering, so an attacker cannot quietly inject code that copies card details in the shopper's browser. The Council published guidance for these two requirements for merchants and for third-party service providers.

The SAQ A change catches merchants off guard. The Council removed 6.4.3 and 11.6.1 from SAQ A and added an eligibility criterion instead: you must confirm that your site is not susceptible to script-based attacks that could affect your e-commerce systems. You can confirm that through your own or a third party's protections, or by getting confirmation from the PCI DSS-compliant provider that supplies your payment iframe. A script vendor whose only service is non-payment scripts that cannot affect account data is not counted as a third-party service provider for this purpose. Get the confirmation from your payment provider in writing and keep it with your SAQ file.

PCI DSS Compliance Levels for Merchants

Your merchant level decides how you prove compliance. Each card brand sets its own levels, and your acquirer tells you which one applies to you. Mastercard's published thresholds count combined Mastercard and Maestro transactions per year, and Visa sets the level from your total Visa volume over 12 months across credit, debit, and prepaid.

Your level is not fixed. Acquirers and card brands can place you in a higher level regardless of volume, for example after a breach, and your level moves when your volume crosses a threshold, as Stripe's PCI guide notes. Scans by an Approved Scanning Vendor (ASV) are required quarterly where your SAQ or ROC calls for them, and your acquirer can require them at any level. Ask your acquirer for your level and re-check it every year.

Which SAQ Applies to Your Checkout Setup

A Self-Assessment Questionnaire is the validation form used by merchants below Level 1, and the right one depends on how card data reaches your systems rather than on your size. The table follows CompliancePoint's SAQ summary and the integration mapping in Stripe's guide.

Level 1 merchants cannot use an SAQ and need a ROC. A hosted setup does not remove the duty to validate every year, it only shrinks the questionnaire.

How to Reduce PCI Scope

Scope is the set of systems the standard applies to. Every system you take out of it is a system you no longer have to secure, scan, and evidence. The usual levers are:

• Hosted checkout or embedded payment fields. Let a validated provider collect card data on its own page. This is the route to SAQ A, and your ecommerce payment service provider or a platform such as Stripe or Adyen typically offers it. Stripe maps its hosted Checkout and embedded Elements to SAQ A in its PCI guide.
• Tokenization. Replace stored card numbers with tokens so your databases hold nothing a thief can reuse. Tokenization usually takes the systems that hold tokens out of cardholder data scope, while encrypted card data keeps its systems in scope. The trade-offs are covered in tokenization vs encryption.
• Validated P2PE for in-person payments. Encrypt card data at the terminal so clear-text card numbers never reach your network.
• Network segmentation. Isolate the few systems that must handle card data from the rest of your network, and test that the separation holds.
• A merchant of record. A merchant of record sells to the customer in its own name, so much of the card-data handling sits with it instead of you. Confirm in writing which PCI duties it takes on.

Scope reduction lowers the size of your questionnaire, not your accountability. You still validate every year, and you still own the security of the pages and systems that remain yours.

PCI DSS Requirements for Service Providers

A service provider is a business that stores, processes, or transmits cardholder data on behalf of merchants or other entities, or that can affect the security of that data. Stripe's guide lists payment gateways, hosting providers, third-party data centers, payment application vendors, and tokenization providers as examples, and any payment service provider that handles card data for its merchants fits the definition.

Service providers follow the same 12 requirements but face stricter validation, because one compromise exposes every client at once. Mastercard splits them into two levels, and Visa expects issuers and acquirers to make sure the service providers they use demonstrate PCI DSS compliance at least every 12 months.

If You Buy From a Service Provider

Your own compliance depends on theirs, so treat their paperwork as part of your file:

• Ask for the current Attestation of Compliance (AOC), and check that it is dated within the last 12 months and names the PCI DSS version assessed.
• Check that the AOC covers the specific service you use. An AOC is issued for assessed services, not for the company as a whole.
• Get the responsibility split in writing. Requirement 12.8.5 expects you to keep information about which requirements each third-party service provider manages, which you manage, and which are shared.
• Write PCI DSS duties into the contract, including notice if their compliance status lapses, and collect a fresh AOC every year.

If You Are a Service Provider

Confirm your level with each card brand that applies to you. Level 1 providers validate through a Qualified Security Assessor (QSA) and a ROC, and every provider should be ready to hand customers its AOC and a clear statement of which requirements it manages for them.

What Compliance Gets You in Practice

• Lower breach exposure. Encryption, access limits, logging, and patching remove the common paths to card data.
• Uninterrupted processing. Your acquirer expects validation under your merchant agreement, and staying current avoids pass-through penalties and the risk of termination.
• Faster partner reviews. Platforms, enterprise buyers, and processors often ask for an AOC before they integrate or renew.
• A smaller audit each year. Every system you scope out is a set of questions you do not answer again, and PCI DSS is one layer of ecommerce fraud prevention rather than the whole program.

What PCI DSS Non-Compliance Costs

The PCI Security Standards Council does not fine anyone. Its own role overview says compliance and enforcement belong to the payment brands and acquiring banks, that each brand decides any penalties, and that the Council has no information about penalties or fines. The number that matters to you sits in your merchant agreement, not in the standard.

Guides often quote a range such as $5,000 to $100,000 per month, and some quote far higher, but those ranges come without a primary source and disagree with each other. Read them as an illustration of the pass-through, not a schedule: a card brand assesses the merchant acquirer, and the acquirer typically passes the cost to you under your contract.

Where PCI Compliance Stops: Disputes, Liability, and Evidence

PCI DSS protects card data. It does not decide who pays when a cardholder disputes a charge, so a fully compliant merchant still loses chargebacks. Liability shifts come from authentication such as 3D Secure 2.0 and EMV chip, not from an attestation, and friendly fraud, where the cardholder authorized the purchase and disputes it anyway, has nothing to do with how well you store card numbers. If you are new to disputes, start with what is a chargeback.

Compliance does close one fraud source. Card data stolen in a breach is used elsewhere, and the resulting card-not-present fraud comes back as chargebacks; the chain is covered in from data breach to chargeback.

What You Can and Cannot Keep in a Dispute File

Evidence packets are where compliant teams slip. Requirement 3.3.1 says sensitive authentication data is not retained after authorization, even if encrypted, which covers the card verification code and PIN. Requirement 3.4.1 says the card number is masked when displayed, and only staff with a business need see more than the BIN and last four digits. Applied to a dispute file:

Keep card data out of email threads, shared drives, and chat when you assemble evidence, because that is where scope quietly expands. For the evidence that does win, see how to win chargebacks as a merchant, read the guide to chargeback dispute management, and use chargeback alerts to resolve disputes before they post.

How to Achieve and Maintain PCI DSS Compliance

1. Confirm your level with your acquirer. Ask which level applies, which validation documents they expect, and when they are due.
2. Map where card data goes. Trace it from checkout through your payment provider, support tools, and dispute workflow. Every system on that path is in scope.
3. Reduce scope first. Apply hosted fields, tokenization, P2PE, or segmentation before you start answering questions.
4. Complete the right validation. Level 1 merchants undergo an assessment with a QSA and receive a ROC. Everyone else completes the SAQ that matches their setup and signs an AOC.
5. Run scans and tests. Use an ASV for quarterly external scans and after significant changes, and run penetration tests at least annually where your validation calls for it.
6. Close gaps and train people. Fix findings, document compensating controls where you use them, train staff who touch card data, and keep an incident response plan.
7. Re-validate every year. Repeat the cycle annually and after significant changes such as a new payment provider, a new checkout, or volume that crosses a level threshold.

PCI DSS Compliance FAQ

What is PCI DSS compliance?

PCI DSS compliance means meeting the Payment Card Industry Data Security Standard's 12 requirements for every system that stores, processes, or transmits payment card data, and proving it to your acquirer each year with a SAQ and Attestation of Compliance or a Report on Compliance. The standard is maintained by the PCI Security Standards Council, and v4.0.1 is the current version.

Who needs to be PCI DSS compliant?

Any business that accepts, stores, processes, or transmits payment card data must comply, along with entities that can affect the security of that data. The PCI Security Standards Council says the standard applies to merchants, processors, acquirers, issuers, and service providers, and that whether an entity must validate compliance is decided by the payment brands and acquirers that run compliance programs.

What are the 12 requirements of PCI DSS?

The 12 requirements are: install and maintain network security controls; apply secure configurations; protect stored account data; protect cardholder data in transit with strong cryptography; protect systems from malicious software; develop and maintain secure systems and software; restrict access by business need to know; identify users and authenticate access; restrict physical access; log and monitor all access; test security regularly; and support security with policies and programs.

Can I do PCI compliance myself?

Yes, in most cases below Level 1. Mastercard requires an annual SAQ from Level 2, 3, and 4 merchants, which you complete yourself, although you still need quarterly ASV scans where required and must fix any gaps. Merchants above 6 million Mastercard transactions a year are Level 1 and need an assessment that produces a Report on Compliance.

Is PCI DSS compliance mandatory?

PCI DSS is a contractual obligation rather than a standalone law: your merchant agreement with your acquirer requires it, and the card brands and acquirers decide how you validate. The PCI Security Standards Council itself does not enforce compliance or set penalties.

What is the difference between a SAQ, an AOC, and a ROC?

A Self-Assessment Questionnaire (SAQ) is the form a merchant or service provider completes to assess itself. An Attestation of Compliance (AOC) is the signed declaration of the result that you give your acquirer or customers. A Report on Compliance (ROC) is the detailed report from an on-site assessment, required for Level 1 merchants and Level 1 service providers, and it also ends in an AOC.

What happens if a merchant is not PCI compliant?

The card brands can assess penalties against the acquirer, which usually passes them to the merchant under the merchant agreement, and the acquirer can raise fees, require remediation, hold reserves, or end the relationship. After a breach the merchant also carries forensic, notification, and fraud costs. Penalty amounts are set by contract, not by the PCI Security Standards Council.

Does PCI DSS compliance protect against chargebacks?

No. PCI DSS protects card data, but it does not shift chargeback liability or stop friendly fraud, where a cardholder who authorized a purchase disputes it. It reduces one source of fraud chargebacks by lowering the chance of a card data breach, and it limits what you can keep as dispute evidence: never the CVV, and never an unmasked card number.

Strong card-data security does not stop disputes. See how Chargeflow recovers the chargebacks that still arrive.