PCI compliance, and what it actually asks of a small business.
The standard is long. What applies to you probably is not. How you take cards decides which questionnaire you answer, and most merchants using a modern terminal answer a very short one.
What this page settles.
Three questions, in the order most people ask them.
What the standard is for
PCI DSS — the Payment Card Industry Data Security Standard — exists because card data is valuable and businesses handle it. It sets out how card data should be protected: encrypted in transit, not stored when it does not need to be, access controlled, systems patched, defaults changed.
It is not a law. It is a contractual standard set by the card networks and reaching you through your merchant agreement. That distinction matters mainly for understanding who enforces it: your processor, not a regulator.
The full standard runs to hundreds of requirements and is written for organisations of every size. Reading it as a small merchant is a bad use of an afternoon, because most of it describes systems you do not operate.
The one principle that decides your obligations
Everything turns on a single question: how much card data touches systems you control?
A standalone terminal on a phone line or its own connection. Card data goes from the card to the terminal to the processor. It never touches your computers, your network or your staff. Your obligations are correspondingly light.
A hosted or redirected online checkout, where the payment page belongs to your gateway rather than to you. Card data never reaches your server. Light again.
A payment form on your own website that posts card data to your server. Now it touches your systems, and the obligations expand considerably.
Storing card numbers anywhere — a spreadsheet, a CRM, a filing cabinet, a notebook by the till. This is the heaviest position and the one most worth designing your way out of.
The practical consequence: the cheapest compliance strategy is not handling card data at all. A tokenizing gateway, a hosted checkout and a modern terminal between them remove most of the burden, and they are good practice for their own sake.
What validation actually involves
Three things, and for most small merchants only the first two apply.
A Self-Assessment Questionnaire. A form you complete yourself, declaring how you handle card data. Which version depends on your setup, and the difference between the shortest and the longest is substantial. The decision tree.
An Attestation of Compliance. A short declaration signed off alongside the questionnaire.
A vulnerability scan, if you take payments through your own website or have systems connected to the internet that are in scope. Run quarterly by an approved vendor, usually automatically. More on scanning.
Larger merchants above certain volume thresholds have heavier requirements, including external audit. If that is you, your acquirer will have told you.
Where it gets done: nearly every processor provides a compliance portal that picks the right questionnaire from a few opening questions and stores your answers. Most merchants have a login for one they have never used.
The six areas the questionnaire covers
Whatever version you get, it is asking about the same six things, and they are sensible questions.
Default passwords. Were they changed — on the terminal, the router, the point-of-sale?
Stored card data. Are you keeping card numbers anywhere, and if so why, and how are they protected?
Encryption. Is card data encrypted in transit?
Access. Who can get to card data or the devices that handle it, and is that limited to people who need it?
Physical security. Are terminals protected from tampering, and does anybody check them?
Process. Do you have a policy, and does somebody know what to do if there is an incident?
A business that cannot answer those well has a real problem that the fee is the smallest part of. That is worth sitting with: the questionnaire is irritating, and the questions are not stupid.
The fee, which is a separate thing
Two charges get confused here constantly, and they are not the same.
A PCI program or compliance fee is your processor charging for the portal and support. A service, and a pricing question. Covered here.
A PCI non-compliance fee is a penalty for not having validated. It stops when you complete the questionnaire, it is free to end, and it is one of the most common avoidable charges on a statement. How to end it.
If you take one thing from this page: find out whether you are currently validated. Most merchants do not know, and the ones paying the penalty longest are usually the ones who switched processors at some point and never re-validated, because validation does not transfer.
What we charge
Interchange + 0.50% + 10¢ in person, interchange + 0.75% + 25¢ keyed. No PCI program fee and no PCI non-compliance fee, and no monthly fee either.
You still complete the questionnaire — everybody does — and we will tell you which one applies and walk you through it. We just do not charge you for being reminded.
While we are on the subject
Do I really have to do this?
Yes. Every business accepting cards is expected to validate annually. Not doing it usually triggers a non-compliance fee from your processor, and leaves you exposed if card data is ever compromised.
How long does it take?
For a merchant using a standalone terminal, often under an hour. For a business storing card data in its own systems, considerably longer and genuinely worth doing properly.
Is PCI a law?
No. It is a contractual standard set by the card networks and enforced through your merchant agreement. Some state laws reference it, but the obligation reaching you comes through your contract.
Does using a compliant terminal make me compliant?
It helps substantially and it is not the whole answer. The questionnaire also asks about passwords, physical access and your own processes, which hardware cannot answer for you.