The idea
The full name is the Payment Card Industry Data Security Standard. It was written by the card networks, not by a government. That is worth knowing straight away, because it explains its character. This is an industry standard, enforced through the contracts you sign with your payment provider.
The reason it exists is simple enough. Card numbers are valuable to thieves, and for years they were kept badly. Written in spreadsheets. Logged in plain text. Left on machines nobody had patched in years. The standard is the industry's answer to that.
What it broadly covers
At a high level, it is about card data and the systems that touch it. The themes are what you would expect from any serious security baseline.
- →Handling. Who can see card data, and whether they should be able to.
- →Storing. What may be kept at all, and how it must be protected if it is kept.
- →Transmitting. Card data crossing a network should be encrypted, which is where TLS and a valid SSL certificate come in.
- →Protecting the systems around it. Patching, access control, sensible passwords, keeping records of who did what.
- →Checking your work. Testing and monitoring, rather than assuming it is still fine years later.
Why most small stores never touch card data
Here is the part that surprises people. If you run a small shop on a normal platform, you have almost certainly never seen a customer's card number, and you never will.
That is by design. Reputable hosted payment providers keep the card entry inside their own systems. The details go from the shopper to the provider. Your store gets back a yes or a no and a reference. The card data never lands on your server, so the heavy part of the burden sits with the provider rather than with you.
This is the single biggest reason to use an established payment provider instead of building your own card handling. Not the convenience. The fact that you are not the one holding the dangerous thing.
Where it still concerns you
Using a provider narrows your exposure. It does not make your site irrelevant to it, and it does not make your checkout page someone else's problem.
Your pages still surround that payment step. If your site gets compromised, an attacker can inject code into the checkout that reads what a shopper types before the provider ever sees it. That is web skimming, and a hosted payment form does not make you immune to it. Keeping your own site clean, patched and monitored still matters.
What we are not going to tell you
We are going to stay away from the detail here, deliberately.
What applies to you depends on how you take payments, how many transactions you process, which networks you work with and where you are. The requirements have numbers, businesses fall into different levels, and there are consequences for getting it wrong. All of that is real, and none of it is something to learn from a glossary page.
Your payment provider knows your setup and will tell you what applies to you. That is the right place to ask. Anything on this page is background, not advice.
A PCI scan is not a trust badge
These get muddled, sometimes on purpose.
A PCI scan is a technical scan of systems, done for the standard. A trust badge is a seal shown to shoppers claiming a site has been checked. They are different things with different audiences. Some providers do sell a seal off the back of a scan, which blurs the line further.
Whatever the badge is based on, the same question applies. Can a shopper verify the claim against a record on the provider's own domain that the site owner cannot edit? If not, it is a picture. That is the thinking behind our verifiable badge.