PCI DSS explained: how your checkout design decides what you have to prove

The lightest, safest PCI position is the one you engineer for

Before any of the detail about requirements, levels and questionnaires, here is the single most useful thing a developer can tell a shop owner about card security. The amount of PCI DSS you have to deal with is decided, more than anything else, by how your checkout is built. Design the payment so that raw card numbers go straight from the customer's browser to a hosted, validated payment provider and never touch your own servers, and most of the standard simply falls out of scope. Build a card form on your own pages instead, so that card numbers pass through your systems, and you pull the full weight of the standard onto yourself.

That is the honest headline. You do not audit your way out of PCI scope. You engineer your way out of it, at the point where you choose how the payment flow works, and that choice is usually made long before anyone mentions compliance. I come back to exactly how this works below, because it is where I add the most value and where most of the money is saved or wasted. The businesses in the examples are invented. Every fact about the standard carries a footnote to a primary source.

What PCI DSS is, and who is behind it

PCI DSS stands for the Payment Card Industry Data Security Standard. It is a baseline of technical and operational requirements for protecting payment card data, and it applies to any organisation that stores, processes or transmits that data, or that could affect its security.¹ The current version is PCI DSS v4.0.1, published in June 2024.¹

It is not a government law and it is not a certificate you hang on the wall. It is a standard written and maintained by the PCI Security Standards Council, a body founded in 2006 by the five big card brands: American Express, Discover, JCB International, Mastercard and Visa, who hold equal stakes in it.² The Council develops the standard, trains and lists the assessors and scanning vendors, and publishes the supporting documents. It says of itself, plainly, that it does not monitor how the standard is implemented.²

So PCI DSS is best understood as the card industry's own rulebook for handling its cards safely. If you want to accept Visa or Mastercard payments, you agree, somewhere down the contract chain, to follow it. That chain is the thing to understand next, because it is what gives the standard its teeth.

Who enforces it: the card brands and your acquiring bank, not the Council

PCI DSS is enforced through contracts, not statute. When you take card payments you have a relationship with an acquiring bank (your acquirer, the bank that settles card transactions into your account), and the acquirer in turn answers to the card brands. Your obligation to comply with PCI DSS, and to prove it, comes from those contracts.

The Council is explicit that whether a given business must comply or validate its compliance is, in its own words, at the discretion of the organisations that manage compliance programmes, such as a payment brand, an acquirer or another such entity.² The standard itself repeats the point: whether any entity has to comply or validate is decided by the organisations that run the compliance programmes, meaning the payment brands and acquirers, and you should contact them for the criteria that apply to you.¹

This matters in practice. There is no PCI inspector who turns up at your door. What happens instead is that your acquirer asks you, usually once a year, to attest that you comply, often by completing a self assessment questionnaire and, where required, passing a network scan. If you suffer a card data breach, the brands can levy fines through your acquirer, and your acquirer can pass them to you, raise your fees or ultimately stop processing your cards. The enforcement is commercial, and it is real.

What counts as card data

The whole standard turns on one idea: account data. The standard splits it into two kinds.¹

Cardholder data is the primary account number (the long number on the front of the card, usually shortened to PAN), and alongside it the cardholder name, the expiry date and the service code. Sensitive authentication data is the more dangerous material: the full track data from the magnetic stripe or chip, the card verification code (the three or four digits used to prove the card is present), and PINs and PIN blocks.¹

The rules differ sharply between the two. You may store cardholder data if you protect it, but you must never store sensitive authentication data after a payment has been authorised.¹ The practical lesson for a developer is blunt: the less of this data your systems ever see, the smaller your problem. Every field you can avoid touching is a field you do not have to protect, log, encrypt, scan and prove you protected.

The six goals and the twelve requirements

PCI DSS organises its detail under six goals, which hold twelve principal requirements between them. In v4.0.1 they read as follows.¹

Goal	Requirements
Build and maintain a secure network and systems	1. Install and maintain network security controls. 2. Apply secure configurations to all system components.
Protect account data	3. Protect stored account data. 4. Protect cardholder data with strong cryptography during transmission over open, public networks.
Maintain a vulnerability management programme	5. Protect all systems and networks from malicious software. 6. Develop and maintain secure systems and software.
Implement strong access control measures	7. Restrict access to system components and cardholder data by business need to know. 8. Identify users and authenticate access to system components. 9. Restrict physical access to cardholder data.
Regularly monitor and test networks	10. Log and monitor all access to system components and cardholder data. 11. Test security of systems and networks regularly.
Maintain an information security policy	12. Support information security with organisational policies and programmes.

Under these twelve headings sit hundreds of detailed sub points, but the twelve themselves have not changed in character since the standard began. Read as plain engineering, they describe a competently run system: a firewalled network, no default passwords, encrypted data in transit, patched software, least privilege access, strong authentication, logging someone actually reads, regular testing, and written policies that say who does what. Most of it is what a careful build does anyway. The cost of PCI DSS is rarely the ideas. It is proving, control by control, that you do them, and the size of that proof depends on how much of the card data environment you own.

Merchant levels one to four

The card brands sort merchants into four levels by how many card transactions they handle in a year, and the level sets how heavily you have to validate. The thresholds and the validation requirements are set by the brands, and the figures below are Visa's.³ Mastercard runs a comparable four level scheme.⁴

Level	Who it covers (Visa)	Validation required
1	More than 6 million Visa transactions a year across all channels, or any merchant Visa designates as Level 1	Annual Report on Compliance by a Qualified Security Assessor, a quarterly network scan by an Approved Scanning Vendor, and an Attestation of Compliance.
2	1 million to 6 million Visa transactions a year	Annual self assessment questionnaire, a quarterly scan by an Approved Scanning Vendor, and an Attestation of Compliance.
3	20,000 to 1 million Visa eCommerce transactions a year	Annual self assessment questionnaire, a quarterly scan, and an Attestation of Compliance.
4	Fewer than 20,000 Visa eCommerce transactions a year, and all other merchants up to 1 million a year	A self assessment questionnaire and a scan where applicable, with the exact requirement set by your acquirer.

Two things are worth drawing out. First, almost every small and medium business is a Level 4 merchant, and sometimes Level 3, which means the normal route is a self assessment questionnaire rather than an external auditor. Second, a serious card data breach can move you up a level regardless of volume, because the brands can designate you Level 1 after a compromise.³ Staying small in PCI terms is partly about volume and partly about not having an incident.

The SAQ types, and how your checkout design chooses one for you

This is the heart of the matter. A self assessment questionnaire, or SAQ, is the form a merchant who does not need a full external audit uses to attest compliance. There are several versions, and the one you are eligible for depends almost entirely on how your payments are built. The brief version: the more card data your own systems touch, the longer and harder the questionnaire. The common types are these.⁵

SAQ	Who it is for	Rough size
A	Card not present merchants (eCommerce, or mail and telephone order) who have fully outsourced all handling of card data to validated third parties, and whose own systems never store, process or transmit it.	Smallest.
A EP	eCommerce merchants whose website does not receive card data on its own servers, but whose pages can still affect the security of the payment, for example a form that posts card data straight to a provider using code served from the merchant's own site.	Much larger than A.
B	Merchants using only standalone, dial out terminals or imprint machines, with no electronic card data storage.	Small, for physical settings.
C	Merchants with a payment application connected to the internet, where no card data is stored electronically.	Moderate to large.
D	Every other merchant, including anyone who stores card data electronically. The full standard.	Largest.

Now the engineering point that saves the most money. For an online shop, the line between SAQ A and everything heavier is drawn by one decision: does a raw card number ever reach your servers?

If your checkout hands the customer off to the provider entirely, by redirecting to the provider's own hosted payment page, or by embedding the provider's payment form in an iframe so the fields belong to the provider and not to you, then the card data goes from the customer straight to a validated third party. Your servers never see it. That is the SAQ A position, the lightest one, and it keeps the overwhelming majority of the standard's technical requirements out of your scope.

If instead you build the card fields into your own pages and your own code touches the number before passing it on, even if you never store it, your website now affects the security of the payment. That is the SAQ A EP position, which pulls a large part of the standard back onto your systems. And if you store card numbers anywhere, you are into SAQ D, the whole thing.

One caveat worth knowing, because it is recent. From 1 April 2025, even merchants using an embedded provider form (an iframe) have to confirm their site is not vulnerable to scripts that could attack the payment page, which is why the way you manage and monitor the scripts on your checkout now matters even in the lighter cases.⁶ The direction of travel is the same as the headline: keep the payment away from your own code, and keep your checkout pages clean.

The decision tree is short, and it is worth having in front of you before a line of checkout code is written.

Does a raw card number ever reach your servers? If no, you are in SAQ A territory. If yes, you are at least SAQ A EP, probably more.
Do you store card numbers at all? If yes, you are in SAQ D, and the honest question is why.
Could the design change so the answer to both becomes no? Usually yes, and that is the work worth doing first.

Who validates and tests

Three roles sit around the validation, and none of them is me.

A Qualified Security Assessor (QSA) is a person or firm the Council has trained and licensed to carry out formal assessments and write the Report on Compliance that a Level 1 merchant needs.² They are independent of you, for the same reason a financial auditor is: so the opinion means something.

An Approved Scanning Vendor (ASV) is a company the Council has approved to run the external vulnerability scans of your internet facing systems that most levels need quarterly.²

For everyone below Level 1, the normal instrument is the self assessment questionnaire, which you complete and sign yourself, backed by the scan where required. In all cases it is your acquirer, following the card brands, who tells you which level you are, which SAQ applies and what evidence to send.²³ I can build the systems so the answers are honest and the evidence exists, and I can help you work out which SAQ your design qualifies for, but I do not set the requirement and I do not sign off compliance. That split is deliberate, and it is the same split I keep in every quality standard I work with.

What it costs, and why scope is the real price

PCI DSS has no fee of its own. The Council does not charge merchants to comply. The costs are everything around it: the engineering to meet the controls, any tools and scans, a QSA's fee if you are large enough to need one, and whatever charges your acquirer attaches. Published figures vary widely because they depend entirely on scope, so treat these as planning ranges, not quotes.

A small online shop sitting on SAQ A, with payments fully outsourced, can expect its direct PCI costs to run from a few hundred to a few thousand pounds a year, mostly scanning and the time to complete the questionnaire.⁷ A business completing SAQ D, with card data in scope and often a QSA involved, is in a different world: vendor estimates for a mid sized SAQ D programme with a QSA commonly run into the tens of thousands, and a Level 1 Report on Compliance for a large merchant can reach six figures and beyond.⁷⁸ One widely cited practitioner notes that the single biggest lever on the bill is scope: taking a call centre or a storage system out of scope can cut an assessment by most of its cost.⁸

That is the whole argument in money. The difference between SAQ A and SAQ D is not mainly the questionnaire. It is the engineering, the scanning, the possible auditor and the ongoing proof, and the gap between them is often the difference between a few thousand a year and a programme that needs its own budget line. A hosted, tokenised integration is less expensive because it is smaller by design, not because anyone cut a corner.

PCI DSS versus SOC 2 and ISO 27001

These three get confused, and buying the wrong one wastes real money, so it is worth being precise. They answer different questions, and you can need more than one.

Standard	What it is	What it covers	Who gives it to you
PCI DSS	A card industry data security standard, enforced by contract	Specifically payment card data: storing, processing and transmitting it safely	You attest, via an SAQ, or a QSA writes a Report on Compliance; your acquirer sets the requirement
SOC 2	An attestation report under American accounting standards	Your controls against chosen trust services criteria, for a customer to read	A licensed accounting firm you commission
ISO 27001	An international certification	Whether you run a recognised information security management system	An accredited certification body

PCI DSS is narrow and deep: it is only about card data, but about that it is prescriptive. SOC 2 and ISO 27001 are broader and about your security management as a whole. A SaaS business selling to large or American buyers is usually asked for a SOC 2 Type II report; a European enterprise buyer often expects ISO 27001 certification instead; an online shop taking card payments needs PCI DSS whatever else it holds. They overlap in the engineering, the access control, encryption, logging and testing, so building well once helps with all of them, but none replaces another. I set out how the whole set fits together in my overview of the quality tiers for business critical software, which is the place to start if you are not sure which of these you actually need.

A worked example: a Leeds shop that stays SAQ A

Pennine Provisions is an invented company in Leeds with 14 staff and a turnover of about £3 million, selling its own range of coffee and kitchenware at pennineprovisions.example. It takes around 60,000 card orders a year, all online, so on Visa's bands it is a Level 3 or Level 4 merchant and its acquirer expects an annual self assessment questionnaire.³ The founder's question to me is simple: which questionnaire, and how do we keep it small?

The answer is decided by the build. The shop runs on Solidus, and the checkout is wired so that when a customer pays, the card fields are served inside an iframe by a validated payment provider, and on mobile the customer is redirected to the provider's hosted page. The card number, expiry and verification code go from the customer's browser to the provider. Pennine's own servers never receive them, never log them and never store them. What comes back is a token, a meaningless reference the shop can use to take the payment and issue refunds, but which is worthless to a thief.

Because no card data reaches Pennine's systems, the shop is eligible for SAQ A, the shortest questionnaire.⁵ The work to keep it there is real but modest. I confirm the provider is itself PCI DSS validated and keep its attestation on file, because Pennine's eligibility rests on it. I make sure the checkout uses the provider's hosted fields everywhere, with no stray card input built into Pennine's own forms. From April 2025 onwards I also manage and monitor the scripts on the checkout page, so Pennine can honestly confirm it is not exposed to a script attack on the payment, which SAQ A now asks.⁶ The acquirer's annual attestation then takes an afternoon, not a project.

Contrast the road not taken. Had Pennine built its own branded card form and posted the numbers through its own back end "to control the experience", it would have dropped into SAQ A EP, with a far longer questionnaire, external scanning of its payment systems and a real ongoing compliance burden, all to handle data it had no reason to hold. The money saved by the hosted design is not a discount. It is scope that was never created.

How I build for this

My job here is specific and I keep it honest. I design and build the payment integration so that the merchant's card data scope is as small as it can be, which in almost every online shop means a hosted or tokenised checkout that keeps raw card numbers off the merchant's servers entirely and lands the business on SAQ A. That one decision, taken at the start, does more for a shop's PCI position than any amount of later paperwork.

Around that, I build the ordinary controls the standard describes, because they are good engineering regardless: strong authentication on every admin path and the hosting console, least privilege roles in the Solidus or Rails admin, encryption in transit on every connection, patched dependencies, centralised logs that a real person reads, and a written incident procedure rather than good intentions. Every system I deliver gets a penetration testing pass with the Kali Linux toolkit before it faces the internet, using tools such as Nmap, Burp Suite and OWASP ZAP, with findings recorded by severity and fix. That record, and the clean, tokenised payment design behind it, is exactly the evidence a self assessment questionnaire asks you to stand behind.

What I do not do is validate or certify your compliance, because I cannot and should not. Your acquirer, following the card brands, sets which level and which SAQ apply, and for a large merchant an independent Qualified Security Assessor writes the Report on Compliance.²³ I build the integration that makes the honest answer a small one, and I prepare you for the attestation. Keeping those roles apart is what makes my word on your security worth anything.

What to do now

Work through these in order.

Find out, from your acquirer, which merchant level you are and which SAQ they expect. The requirement is theirs to set.
Look at where card numbers actually go in your checkout today. If any reach your own servers, that is the first thing to change.
Move to a hosted or tokenised payment design if you have not already, so the shop is eligible for SAQ A and most of the standard leaves your scope.
Keep your payment provider's own PCI DSS validation on file, because your lightest questionnaire depends on it.
Manage the scripts on your checkout pages, which SAQ A now expects, and build the ordinary controls of the twelve requirements into the rest of the system.
Only then complete the questionnaire, with the evidence already in place rather than assembled in a panic.

PCI DSS looks heavy from the outside, and for a business that stores card data it is. For most online shops it does not have to be, and the way to make it light is a design choice you make before you write the checkout, not a certificate you chase afterwards.

If you are not sure which SAQ your shop qualifies for, or whether your checkout is quietly pulling card data into scope it does not need, book the free workshop and I will work it through with you, and the first two weeks of the work are on me.

PCI Security Standards Council, Payment Card Industry Data Security Standard: Requirements and Testing Procedures, version 4.0.1, June 2024, sections on applicability, the twelve requirements (Table 1) and account data (Table 2), available from the PCI SSC Document Library, https://www.pcisecuritystandards.org/document_library/?category=pcidss ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
PCI Security Standards Council, About us (governance, founding members and the Council's role, including that it does not monitor implementation of the standards and that compliance validation is at the discretion of the payment brands and acquirers), pcisecuritystandards.org, accessed 13 November 2026, https://www.pcisecuritystandards.org/about_us/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Visa, PCI DSS compliance validation and merchant levels (transaction volume thresholds for Levels 1 to 4 and the validation each requires), visa.com, accessed 13 November 2026, https://www.visa.com.tt/run-your-business/small-business/information-security/compliance-validation.html ↩ ↩² ↩³ ↩⁴ ↩⁵
Mastercard, Security recommendations, what merchants need to know (Mastercard merchant levels), mastercard.com, accessed 13 November 2026, https://www.mastercard.us/en-us/business/overview/safety-and-security.html ↩
PCI Security Standards Council, Self Assessment Questionnaire Instructions and Guidelines (the SAQ types and their eligibility criteria), available from the PCI SSC Document Library, accessed 13 November 2026, https://www.pcisecuritystandards.org/document_library/?category=saqs ↩ ↩²
PCI Security Standards Council, FAQ clarifies new SAQ A eligibility criteria for eCommerce merchants (the script protection criterion and the 1 April 2025 effective date), PCI Perspectives blog, accessed 13 November 2026, https://blog.pcisecuritystandards.org/faq-clarifies-new-saq-a-eligibility-criteria-for-e-commerce-merchants ↩ ↩²
Scrut Automation, Calculating your actual PCI compliance cost (annual cost ranges for Level 4 merchants validating by SAQ), scrut.io, accessed 13 November 2026, https://www.scrut.io/post/calculating-your-actual-pci-compliance-cost-expert-guide-for-2026 ↩ ↩²
Paytia, The cost of PCI compliance (cost ranges by merchant level and SAQ, and the effect of scope reduction), paytia.com, accessed 13 November 2026, https://www.paytia.com/us/resources/blog/cost-of-pci-compliance ↩ ↩²