Under PCI DSS, any business that processes, stores or transmits credit card data must comply with the standard. The general rule is that when a business accepts cards in any way, it must be certified. Requirements are defined by how the business receives credit cards.
A physical shop with a POS therefore does not have the same security requirements as a business that makes electronic payments by redirecting to a bank's environment or a service provider.
Classification by transaction volume
Merchant levels classify the business and are distinct from SAQ types. The category and validation method are confirmed with the relevant accepting entity. The ROC (Report on Compliance) and AOC (Attestation of Compliance) are different deliverables.
| Merchant Level | Transactions per year | Redirect | IFRAME | Direct Post | JavaScript | XML |
|---|---|---|---|---|---|---|
| Level 1 | More than 6 million | ROC | ROC | ROC | ROC | ROC |
| Level 2 | 1–6 million | SAQ A | SAQ A | SAQ A-EP | SAQ A-EP | SAQ D |
| Level 3 | 20,000–1 million | SAQ A | SAQ A | SAQ A-EP | SAQ A-EP | SAQ D |
| Level 4 | Up to 20,000 | SAQ A | SAQ A | SAQ A-EP | SAQ A-EP | SAQ D |
The table is an overview, not a determination of eligibility. Card-brand rules, the accepting entity and the full payment environment determine your route.
Electronic transactions
Most businesses first encounter PCI DSS when they need to integrate electronic payments, for example on a website. Electronic transmission, processing and storage of credit card details also present the greatest risk compared with transactions where the card is physically present, for obvious reasons.
A common myth is that redirecting customers to the bank's environment removes the need to comply with PCI DSS. For electronic transactions, three main questionnaires determine the requirements described below.
Redirect & iFrame
For merchants without the physical presence of a card. All credit card data is processed entirely through redirection or an iframe by a third-party PCI-validated service provider.
Direct Post & Javascript
For merchants that outsource part of the payment process to banks or validated external providers, while the end customer still enters their card details in the merchant's environment.
XML-API
For merchants that receive credit cards directly into their systems and store, process or simply transmit them.
Explore the linked SAQ pages for their eligibility criteria. A payment integration method alone does not determine the SAQ.
Physical, or Card Present, transactions
Although many people are unaware of it, credit card transactions at physical business premises using payment terminals, or POS, are subject to PCI DSS requirements, with specific criteria depending on the POS type.
DIAL-UP POS
For older POS terminals that complete the transaction through a call over the conventional PSTN or ISDN telephone network.
INTERNET CONNECTED POS
Modern and now more widespread POS terminals complete transactions over the internet, through Wi-Fi, a wired data connection or an integrated SIM card (3G, 4G or 5G).
Mail Order & Telephone Order transactions (MOTO)
This category concerns transactions where the customer is not physically present at the business to use their card, but transacts by telephone. The merchant receives the card details over the phone and typically enters them into a virtual POS supplied by a PCI-validated service provider.
VIRTUAL TERMINAL
The merchant completes the transaction by entering the customer's card details into a virtual terminal from their computer or another approved device.
Would you like to know your certification type and cost?
Cost calculation tool
Use the certification selection tool to calculate your certification type and annual cost.