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 you in a lower-risk category.
If your website accepts credit or debit card payments, the Payment Card Industry Data Security Standard — usually called PCI DSS — applies to you. This is not a government law; it is a security standard set by the major card networks (Visa, Mastercard, American Express, Discover, and JCB) through the PCI Security Standards Council.
The good news: the way most modern e-commerce sites are built keeps merchants in the lowest-risk tier, and we structure every store build to minimize your PCI burden.
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, WooCommerce Payments, 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, a body formed by Visa, Mastercard, American Express, Discover, and JCB. Non-compliance does not result in government fines directly, but it can lead to:
- 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
PCI DSS organizes merchants into four levels based on transaction volume:
| Level | Annual card transactions | What's typically required |
|---|---|---|
| Level 1 | Over 6 million | Annual on-site audit by a QSA; quarterly network scans |
| Level 2 | 1–6 million | Annual Self-Assessment Questionnaire (SAQ); quarterly scans |
| Level 3 | 20,000–1 million (e-commerce) | Annual SAQ; quarterly scans may be required |
| Level 4 | Fewer than 20,000 (e-commerce) | Annual SAQ; quarterly scans may apply |
Most small and mid-size online stores fall into Level 4. The primary requirement is completing an annual Self-Assessment Questionnaire (SAQ) — a checklist that confirms your security practices.
Your specific requirements are determined by your acquiring bank or payment processor, not by Chykalophia. 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 is hosted by your payment processor (Stripe, PayPal, etc.) in an embedded component called an iframe. 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, WooCommerce Payments, 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 (iframe) hosted on Stripe's or PayPal's servers — not yours.
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. Tokens are useless to attackers.
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.
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.
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
- Third-party scripts on your checkout page are monitored and authorized
Third-party scripts on checkout pages are a real risk
Adding arbitrary JavaScript to your checkout page — from plugins, analytics tools, or ad networks — can create a vulnerability called "formjacking," where malicious code skims card data from the browser before it reaches the processor's form. We review every script that runs on checkout pages to prevent this.
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
Related guides
- Payment security & PCI compliance
- PCI compliance basics (WooCommerce)
- Keeping your store secure
- Accepting credit cards (Stripe & more)
- Security & account safety
- Website care & maintenance
Need a hand?
Learn more
HIPAA basics for websites handling health info
What HIPAA means for your website if you work in healthcare or collect health-related information, and the technical safeguards we implement.
Keeping your accounts & website safe
Practical security guides for business owners and their teams — from strong passwords to what to do if something goes wrong.