PCI Compliance Explained for a Small Shop

Why this matters

Once a year your processor emails asking you to "complete your PCI validation", and most small shops either click through a questionnaire answering yes to everything or ignore it and pay the monthly fee for not filing. Neither tells you anything about whether you are actually protecting card data, and both leave you exposed if a card is ever stolen through your shop. Using a hosted processor genuinely does take most of the burden off you. It does not take all of it, and the part it leaves is the part nobody explains: what is still yours, and how to answer the questionnaire about the shop you really run rather than the one you wish you ran.

What PCI DSS is, and who enforces it

PCI DSS, the Payment Card Industry Data Security Standard, is a set of security requirements written by the PCI Security Standards Council, a body founded by the major card networks. It is not a federal law. It reaches you by contract: your merchant agreement with your processor (or the acquiring bank behind it) obliges you to comply, and the card networks hold the processor responsible for its merchants. The version in force as of 2026 is 4.0.1; the council revises the standard and its forms every few years, so check its website for the current edition when you file.

A few states have pulled parts of it into statute. Nevada requires businesses that accept cards to comply with the standard. Minnesota prohibits keeping the card security code, PIN data or the full contents of the magnetic stripe after a transaction is authorized. Most states have no PCI statute at all, but every state has a data-breach notification law that can apply if card numbers leak, which is a separate obligation. See related: Handling a Data Breach Notification Obligation.

Merchant levels: you are almost certainly level 4

The networks sort merchants into levels by annual transaction volume. The largest merchants are audited by outside assessors. The smallest, which for the major networks means under about 20,000 online transactions a year and under about a million transactions total, are level 4, and level 4 merchants validate by filling in a Self-Assessment Questionnaire (SAQ) themselves. That is every field-service shop in the size range this library is written for. The exact thresholds are set by each network and your processor will tell you your level.

The questionnaire is a description of how you take cards

There is not one SAQ. There are several, each written for a different way of accepting cards, and the one you file depends entirely on your setup. The plain-terms version of the ones a trade shop meets:

Two consequences follow. First, the form is chosen by what you actually do, not by what you would like to fill in. A shop that only uses payment links but also lets the office key numbers into a virtual terminal is not an SAQ A merchant. Second, a shop with several channels may be asked to file the form covering the most exposed channel, or one per channel; your processor decides how it wants it, and many processors now walk you through a short interview that picks the form for you. Answer the interview truthfully and the form follows.

Some forms also require a quarterly external vulnerability scan by an Approved Scanning Vendor (a scan of your internet-facing systems by a council-listed company). Your processor will say whether yours does, and often provides the scan.

What the processor takes off your plate

When you use a processor's hosted page, payment links, card-on-file tokens and readers, the processor is the one actually storing and transmitting card numbers, and its own compliance covers:

• the servers that hold card data and the encryption in transit to them,
• the hosted payment page, if it is entirely theirs,
• the card-on-file vault, which hands you a token (a stand-in reference number) instead of the card,
• for validated encrypting readers, the encryption inside the device.

That is a lot. It is why a shop that takes cards only through those tools has a short questionnaire.

What stays yours

This is the negative space, and it is where small shops get hurt. None of the following is covered by your processor's compliance, however good it is.

Your people's habits. A number written on a ticket, a photo of a card in a camera roll, a security code jotted down "to run it later". The processor never sees these, and every one pulls paper and devices into your scope. The field habits are their own article. See related: Taking Card Payments in the Field Without Exposing Card Data.

The computer the virtual terminal runs on. The virtual terminal is the processor's page, but the keyboard is yours. A shared office computer used for email and web browsing can carry malware that records keystrokes, including every card number typed into that page. SAQ C-VT has requirements about that computer precisely because of this.

Your website, if it frames or links the payment page. A booking page that embeds the processor's payment form inside your own site can be altered so the customer types their card into a look-alike. The 2024 and 2025 revisions to the standard put more weight on scripts running on payment pages, and SAQ A's eligibility language was revised in 2025; re-check the current form if your site embeds payments rather than linking out.

Your devices. The readers themselves: checking that one has not been tampered with or swapped, keeping a list of which reader is assigned to which truck, and noticing when one goes missing.

Your service providers. Anyone who can touch the payment process for you, such as a web designer who manages the booking page, is a third party the standard expects you to know about and to have a written understanding with. See related: The Agency or Web Designer Holds Your Keys.

The attestation itself. The Attestation of Compliance (AOC) at the end of the questionnaire is a signed statement by your business. Signing yes to controls you do not have is not a technicality.

A worked example

A nine-person HVAC shop takes cards three ways: techs use readers from its processor on work phones, the office takes some payments over the phone by typing them into the processor's virtual terminal, and the website's booking form collects a deposit on a page hosted by the processor.

Walk the channels:

• Field readers. The processor confirms they are part of its validated encryption solution. On their own, that channel fits SAQ P2PE.
• Online deposits. Fully hosted payment page, linked from the website rather than embedded. On its own, SAQ A.
• Office phone payments. Typed into the virtual terminal on the front-desk computer, which is also the office's email and web computer. On its own, SAQ C-VT, and the shared computer is a problem under that form's requirements for the terminal's computer.

The processor's interview asks about all three and assigns SAQ C-VT for the business, because the virtual terminal channel is the one with the most of the shop inside its scope. Answering truthfully, the office manager reaches the questions about the computer used for the virtual terminal and cannot honestly say yes.

The shop has two ways out. It can dedicate a computer to the virtual terminal (used for nothing else, locked down, kept patched) and file C-VT honestly. Or it can stop keying phone payments and send payment links instead, which moves that channel to the hosted page. It took the second, because it also lowered its fraud exposure on phone bookings. With all three channels now on validated readers and a hosted page, the processor reassigned it the shorter questionnaire for its remaining setup, and the office manager could answer every question honestly in under an hour. See related: Card-Not-Present Fraud on Phone Bookings.

What would change the answer. If the shop also kept card numbers in its own spreadsheet "for regular customers", no amount of hosted tools would keep it on a short form: stored card data puts it in SAQ D territory, the full standard. Replace that spreadsheet with the processor's card-on-file tokens, and destroy the spreadsheet and every copy of it.

What it costs to ignore

Most merchant agreements charge a monthly non-compliance fee to merchants who do not file their annual validation. That is the small cost. The larger one arrives after a breach: under network rules a merchant that was not compliant can be billed by its processor for the forensic investigation, for the networks' fraud and card reissue assessments, and can lose the ability to accept cards. Those amounts are set by the networks and your merchant agreement, not by statute. If you ever face one, stop and bring the agreement and your last filed questionnaire to your attorney before agreeing to anything. This is not legal advice.

Filing it each year

Put the annual validation on the same calendar as your insurance renewal. Before filing, walk the shop once: confirm every reader in use is the processor's, check that nothing card-shaped is written on paper or in notes, and confirm the virtual-terminal setup still matches what you said last year. Then answer the questions about that shop. Keep a copy of the filed questionnaire and its attestation; it is the first thing anyone asks for if something goes wrong.

References

• PCI Security Standards Council, PCI DSS v4.0.1 and the Self-Assessment Questionnaire instructions and guidelines
• Your processor's merchant agreement and PCI validation program documentation
• Nevada Revised Statutes Chapter 603A, security of personal information; Minnesota Plastic Card Security Act
• See related: Taking Card Payments in the Field Without Exposing Card Data
• See related: Handling a Data Breach Notification Obligation