PCI Compliance: How Small Is Your Scope?

PCI compliance is a contractual obligation, not a law. That single fact explains most of the confusion around it. Nobody from the government is coming to inspect your store. The card brands require it, your acquiring bank enforces it through your merchant agreement, and the consequences of ignoring it arrive as fees, liability and occasionally a terminated account.

The standard is the Payment Card Industry Data Security Standard, written by a council the major card networks formed. If you accept card payments, it applies to you. How much of it applies is the useful question, and the answer is mostly decided by one thing.

The question that determines everything

Does cardholder data ever touch a system you control?

That is the whole game. The standard's requirements attach to what it calls the cardholder data environment, meaning any system that stores, processes or transmits card data. Shrink that environment and you shrink your obligation.

Three broad arrangements, in order of how much they put on you.

The card details never reach your server. You use a hosted payment page or an iframe or a JavaScript element from your processor, the customer types into their field rather than yours, and your server receives a token that is useless to anyone who steals it. Your scope is small. Not zero, because the page that loads the payment element still matters, and that distinction has been tightening.

The data passes through your server. Your form, your POST, then forwarded to the processor. Now every system that data crosses is in scope, and your obligation is dramatically larger.

You store card numbers. Almost nobody needs to and the requirements here are serious. If you are doing this without a specific reason and specialist advice, stop.

Most stores should be in the first arrangement, and a lot of stores believe they are while being in the second because somebody built a custom checkout form years ago.

How compliance is actually demonstrated

Through a Self-Assessment Questionnaire for most merchants, and there are several versions. Which one you complete depends on how you take payments, and the version for a merchant who never touches card data is far shorter than the one for a merchant who does.

Your acquirer tells you which applies, and validation requirements scale with transaction volume. High-volume merchants face a formal audit by a Qualified Security Assessor instead. Ask your acquirer what they expect from you rather than guessing, because they are the party that enforces it.

Also worth knowing: the standard is versioned and it changes. Requirements around scripts on payment pages have been an area of active change. Read the current version at the PCI Security Standards Council rather than a summary, including this one.

What people get wrong

Assuming the processor's compliance is yours. Your processor being compliant covers their systems. Your site, your servers and your staff are yours. This is the single most common misunderstanding.

Thinking a scan is compliance. A quarterly vulnerability scan is one requirement among many, and passing it is not the same as being compliant.

Ignoring where else card data lands. A customer emails you a card number because your checkout failed. Somebody reads one over the phone and writes it on a pad. A support tool logs a full request body. Each of those pulls systems into scope that nobody assessed, and the email one happens constantly.

Third-party scripts on the payment page. Analytics, chat widgets, ad pixels. Anything executing on the page where a customer enters card details can, if compromised, read those details. Attacks of exactly this kind are why this area has been tightened. Keep that page as bare as you can defend.

Treating it as annual. The questionnaire is annual. The controls are continuous, and a lapse between assessments is still a lapse when something goes wrong.

What it costs to get wrong

Not a fine from a regulator. Monthly non-compliance fees from your acquirer. If a breach happens and you were not compliant, liability for fraud losses, card reissuance costs and a forensic investigation you pay for. Possibly losing your ability to accept cards, which for an online store is the end of the business.

Separately, actual privacy laws may apply to the same incident, and those do come from governments.

The practical starting point

Answer four questions honestly. Where does a card number go from the moment a customer types it? Which questionnaire does your acquirer expect? What third-party scripts run on your payment page? And is there any path by which a card number reaches an email inbox, a ticket, or a log file?

The fourth one catches most people, and it is free to check.

Where we fit, and what we are not

Being exact: we are not a QSA and this is not compliance advice. Your acquirer and, above a certain size, a qualified assessor determine what you must do.

What a backend can do is keep your scope small. Payments route to your processor with the card details captured by the processor's own element, so raw card numbers do not arrive at your server or ours, and what is stored is a token. Payment routing is yours, so the relationship and the compliance conversation stay between you and your processor.

Where we are the wrong answer: a hosted platform handles its own checkout end to end and that is a legitimately simpler position to be in. If you want the smallest possible scope and are not writing a storefront, take one. And if you genuinely need to store card numbers, that is a specialist problem and you need specialist advice rather than a platform recommendation.

If you want to see how payment tokens flow through the API, the docs have the checkout endpoints.