PCI compliance for online stores

What PCI DSS means for your e-commerce site, how payment processing actually works, and why the way we build stores keeps your PCI burden small.

If your website accepts credit or debit card payments, the Payment Card Industry Data Security Standard — usually called PCI DSS — applies to you. It is not a government regulation. It is a security standard published by the PCI Security Standards Council, which the five big card brands founded in 2006: American Express, Discover, JCB International, Mastercard, and Visa.

The good news: the way most modern e-commerce sites are built keeps raw card numbers off your own server, which is what keeps your PCI work small. We structure every store build that way.

This is not legal advice

Chykalophia is a design and web agency, not a law firm. This article explains PCI DSS concepts and the practices we follow when building online stores. It is not a substitute for advice from a qualified attorney or a certified PCI QSA (Qualified Security Assessor). Your payment processor, acquiring bank, and a compliance specialist are the authoritative sources for your specific PCI obligations.

Quick summary

PCI DSS sets security requirements for any business that accepts card payments. The most important thing to know: if you never touch raw card data — because your payment processor (Stripe, PayPal, WooPayments, etc.) handles the card form on your behalf — your compliance burden is dramatically lower. We build stores to keep card data entirely off your server. You still have obligations, but they are manageable for a typical small or mid-size online store.

What PCI DSS is

PCI DSS (Payment Card Industry Data Security Standard) is a set of technical and operational security requirements for any organization that processes, stores, or transmits credit or debit card data.

It is maintained by the PCI Security Standards Council, which was founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa. The Council writes and maintains the standard but does not enforce it: whether you have to comply, and whether you have to prove it, is decided by the card brands and by your acquiring bank or payment processor. So the consequences of ignoring PCI DSS usually arrive through your card processing agreements rather than from a regulator:

Financial penalties from your payment processor or acquiring bank
Increased transaction fees
Loss of the ability to accept card payments
Liability for fraud losses if a breach occurs

The four merchant levels

Merchant levels do not come from the PCI Security Standards Council — each card brand runs its own compliance programme and sets its own thresholds. Visa's four levels work like this, and the counts are of Visa transactions, not of all your card sales:

Level	Annual Visa transactions	What Visa asks for
Level 1	Over 6 million, all channels	Annual Report on Compliance by a Qualified Security Assessor (QSA); quarterly network scan by an Approved Scanning Vendor (ASV)
Level 2	1 million to 6 million, all channels	Annual Self-Assessment Questionnaire (SAQ); quarterly ASV scan
Level 3	20,000 to 1 million e-commerce	Annual SAQ; quarterly ASV scan
Level 4	Fewer than 20,000 e-commerce, plus all other merchants up to 1 million	Annual SAQ recommended; quarterly ASV scan if applicable

Most small and mid-size online stores sit at Level 4. The main piece of work there is an annual Self-Assessment Questionnaire (SAQ) — a checklist you answer about your own security practices.

Your specific requirements are determined by your acquiring bank or payment processor, not by Chykalophia. They are the ones you submit an SAQ to, so they decide which questionnaire you use and whether you have to send one at all. Always confirm with them.

The key concept: card data scope

The single most important PCI concept for small store owners is scope — specifically, whether card data ever touches your server.

There are two main scenarios:

Card data on YOUR server

Raw card numbers pass through your infrastructure before reaching the processor. This puts your entire server environment in scope for PCI.

This approach requires significant security controls: encryption, network segmentation, access logging, vulnerability scanning, and more.

Rare in modern e-commerce. Almost no small businesses should operate this way.

Card data on the PROCESSOR'S server

The card form belongs to your payment processor (Stripe, PayPal, etc.), either embedded in your page in a frame of its own or on the processor's own page. Your server never sees the raw card number.

This dramatically reduces your PCI scope. Your store is effectively out of scope for the parts that handle actual card data.

This is how we build every store.

How modern payment processors reduce your scope

When we integrate Stripe, WooPayments, PayPal, or other reputable processors into your store, the payment form works like this:

The card form is served directly by the payment processor. What looks like a form on your site is actually a secure component (an embedded frame) served from Stripe's or PayPal's servers — not yours. Some setups send the customer to the processor's own page instead, which has the same effect.

The customer types their card number into the processor's form. That card number goes directly to the processor's servers. Your server never sees it.

The processor returns a token. Instead of card data, your store receives a token — a stand-in reference that your server uses to communicate with the processor. A token is not card data, so it is far less use to anyone who steals it.

Your server completes the order using the token. The actual charge happens processor-side. Your store records the order, processes fulfillment, and sends confirmation — all without ever holding card data.

This architecture means the most sensitive parts of PCI DSS — the requirements around securing cardholder data storage and transmission — do not apply to your store server. Some requirements still do, and the next section covers them.

Your remaining PCI responsibilities

Even with a processor-hosted card form, you still have some PCI obligations. For most Level 4 merchants using reputable processors, the relevant Self-Assessment Questionnaire is SAQ A or SAQ A-EP; your processor or acquiring bank confirms which.

These require you to confirm things like:

Your website is not compromised (your software is updated and monitored)
Only authorized people have access to your store admin
You use strong, unique passwords and ideally two-factor authentication
Your hosting environment uses HTTPS (SSL)
You have a process for handling potential security incidents
If the processor's card form is embedded in your own page: that page is protected against card-skimming scripts, either by protections put in place on your side or because your processor confirms its form does that for you
External vulnerability scans are run by a PCI-approved scanning vendor. SAQ A for PCI DSS v4 includes these even when the card form is your processor's, and PCI DSS asks for them at least once every three months

Third-party scripts on checkout pages are a real risk

Adding scripts to your checkout page — from plugins, analytics tools, or ad networks — can let malicious code skim card details in the browser before they reach the processor's form. This is why SAQ A now asks a store with an embedded payment form to confirm the page is not open to script attacks: either the page is protected on your side (PCI DSS requirements 6.4.3 and 11.6.1 describe the techniques, and you or someone working for you can put them in place) or your processor confirms its form does it for you. We review every script that runs on checkout pages.

What we do to help

When we build your online store:

We integrate payment processors using their officially supported, PCI-scoped methods (Stripe Elements, PayPal SDK, etc.)
We ensure your store runs on HTTPS throughout — especially on cart and checkout pages
We keep WordPress, WooCommerce, Shopify, and all relevant plugins and themes updated to close security vulnerabilities
We avoid unnecessary scripts on checkout pages
We implement strong admin access controls (strong passwords, two-factor auth)
We include stores in our regular security monitoring under our care plans

We do not complete the SAQ on your behalf — that is a business process and legal responsibility. But we can make sure your technical environment meets the criteria it describes.

Common pitfalls

Using a payment plugin that redirects to a hosted payment page but leaving the plugin outdated. Even redirect-based checkout needs to stay updated.
Installing a plugin that injects scripts into checkout pages. Analytics plugins, social proof widgets, and popups that run on checkout pages need to be carefully vetted.
Weak admin passwords. A compromised admin account can lead to injected malicious code on your store. Strong passwords and two-factor authentication are essential.
Storing card data "just in case." If a plugin or custom code stores full card numbers, expiry dates, or CVV codes in your database, you are in a very different (and very risky) PCI compliance position. This should never happen.
Ignoring the SAQ. Your acquiring bank or payment processor may require annual SAQ completion as a condition of your merchant account. Skipping it can result in penalties.
Thinking "my processor is PCI compliant" means you are too. Stripe and PayPal being PCI certified does not automatically make your store compliant. Your store's configuration, access controls, and update practices matter.

Common questions

Does Shopify handle PCI compliance for me?

Shopify says it is certified Level 1 PCI DSS compliant, and that stores powered by Shopify are PCI compliant by default. That covers the payment processing Shopify runs. You still have responsibilities on your side — particularly around admin access security and any custom code or apps you add.

What is a Self-Assessment Questionnaire (SAQ)?

An SAQ is a set of yes/no questions that you answer to self-certify your PCI compliance posture. There are several types, and which one fits depends on how you accept payments. Most small online stores using processor-hosted forms complete SAQ A or SAQ A-EP. Your payment processor or acquiring bank will tell you which applies and may provide tools to help.

Do I need a PCI scan of my website?

Probably, yes. SAQ A for PCI DSS v4 includes external vulnerability scanning by an Approved Scanning Vendor (ASV), even where payment processing is fully outsourced — the scan covers the page that carries your processor's form or redirect, because a compromise there can expose the payment. PCI DSS asks for those scans at least once every three months. Your payment processor or acquiring bank will tell you what it needs from you and what to send.

What happens if there is a data breach on my store?

If cardholder data is compromised, you may be liable for fraud losses, investigation costs, and card replacement costs, depending on your merchant agreement. You should report suspected breaches to your payment processor immediately. Having a care plan with active security monitoring significantly reduces the risk of undetected breaches.

Is WooCommerce PCI compliant?

WooCommerce itself is a shopping platform, not a payment processor. Its PCI compliance posture depends entirely on which payment gateway you use and how the checkout is implemented. When we integrate Stripe or another certified payment gateway using hosted card fields, the architecture keeps your WooCommerce store in a low-scope PCI category. WooCommerce makes the same point about its own gateway: WooPayments is PCI DSS compliant as a service provider, but using it does not by itself make your whole site compliant — your site still presents the checkout and still has to be kept secure.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.

Learn more

PCI Security Standards Council — official standards and resources
PCI Security Standards Council — document library, where the SAQ forms and their instructions are published
Stripe — integration security guide

PCI compliance for online stores

On this page