If you take card payments, even five a day, read this before your bank emails you first.

The mistake is simple. You think your payment provider takes care of PCI DSS for you.

It doesn’t. Some of it, sure. But if your checkout page looks like most checkout pages, a big chunk of the responsibility is still sitting on your desk.

[Add two or three sentences of your own here. A time you or a client assumed “Stripe handles it” and found out otherwise. Real beats polished.]

I’ll get to the gap in a second. First, the title.

Is it actually illegal?

Mostly no, and I’d rather say so now than have someone say it for me in the comments.

PCI DSS isn’t a federal law. The card brands wrote it, and you agreed to it when you signed your merchant agreement, probably without reading page nine. Break it and your bank can fine you, raise your fees, or close your account.

But a few US states have pulled PCI DSS into their own law. Nevada is the best known. Minnesota and Washington have versions too. And after a breach, nobody asks whether the standard was legally binding. They ask whether you followed it. A lawyer on the other side will enjoy that question.

So “breaking the law” is a little strong, and “breaking your contract” is accurate nearly everywhere. Either way, you don’t want to be there.

Who’s living on your checkout page?

Open your checkout page. Right-click, view source, and search for “script.”

Go on. I’ll wait.

Analytics. A chat widget. Maybe a heatmap tool somebody trialled once. A font library. A retargeting pixel from a campaign in 2022 that nobody turned off. Every one of those is code written by a stranger, running in the same window where your customer types a card number.

Attackers love this. It’s called web skimming, and you’ll also see the name Magecart. They don’t bother attacking your bank. They compromise one small third-party script, add a few lines of JavaScript, and copy card details as people type. Your site looks fine. Your processor sees normal transactions. It can go on for weeks.

This is the gap. Your provider secures its side. It has no control over the fifteen scripts you invited onto your side.

What changed, and why old blog posts will mislead you

The old version, 3.2.1, was retired in March 2024. Version 4.0 replaced it, and a batch of requirements that started out as “best practice” became mandatory on March 31, 2025. The current release, 4.0.1, only clarifies wording. It doesn’t relax anything.

Two of the new rules hit online sellers hardest.

Requirement 6.4.3 says you need an inventory of every script on your payment pages. You have to confirm each is authorized and write down why it’s there.

Requirement 11.6.1 says you need a way to detect unauthorized changes to those pages and be alerted when something shifts.

So if nobody on your team can name every script on your checkout, you have a compliance problem and a security problem. They happen to be the same problem, which is almost funny.

What it costs when it goes wrong

The card brands don’t bill you directly. They penalize your acquiring bank, and the bank passes it along, usually with a little extra for its trouble. Figures commonly reported run from about $5,000 to $100,000 a month of non-compliance, depending on your size and how long it drags on.

That’s the fine. A real breach is its own bill: forensic investigators, reissuing cards, lawyers, notifying customers, and the quiet loss of people who just stop buying from you.

Target in 2013 is the example everyone uses, because it’s true. Attackers got in through a third-party vendor (an HVAC contractor, of all things) and left with around 40 million payment card records. A company that size absorbs it. A small shop usually can’t.

What to do this week

None of this is glamorous. That’s sort of the point.

Start by asking your bank or processor which Self-Assessment Questionnaire applies to you. It depends on how card data touches your business, and plenty of merchants fill out the wrong one. They end up compliant on paper and exposed in practice.

Then shrink your scope. If you use a fully hosted payment page or tokenization, card numbers never touch your servers, and that’s less for you to secure and explain. Do an audit of your payment page scripts while you’re at it, and delete anything that isn’t earning its spot. Your heatmap tool doesn’t need to sit next to the card field.

Never store the CVV after authorization. Ever. Turn on multi-factor authentication for any account that can reach card data. If you’re required to run quarterly external scans, use an Approved Scanning Vendor and put the dates in your calendar, because PCI DSS is yearly, not once and done.

And write a security policy. One page is fine. One page your team has read beats sixty pages nobody opened.

The honest takeaway

I don’t think PCI DSS exists to make your life miserable, though it can feel that way around audit time. It exists because card fraud is automated and endless, and small merchants are favorite targets because they assume nobody’s watching.

The businesses that stay out of trouble mostly aren’t the ones with big security budgets. They just ask three dull questions early. What touches card data? Who has access to it? What’s running on my checkout page?

Ask them this week. Your future self will be grateful, and so will your bank.

Do you know which SAQ applies to your business? Tell me in the comments. [Add your own honest answer here.]

This is general information, not legal or compliance advice. Confirm your requirements with your acquiring bank or a Qualified Security Assessor.

Your Payment Page Is Probably Breaking the Law. Here’s the PCI DSS Mistake Nobody Tells You About was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.