You have an online store. Customers hand you their payment card details — the most sensitive financial data they own. In exchange, you take on a set of legal and contractual obligations to protect that data. Those obligations are defined by a framework called PCI DSS — the Payment Card Industry Data Security Standard — and they apply to every business that accepts card payments, regardless of size.

PCI compliance is one of the most misunderstood areas of running an online store. Most small merchants don’t know what it requires. Many assume their payment processor handles it for them. Some have never heard of it at all. And almost everyone underestimates how much their hosting choices affect their compliance status.

This guide cuts through the jargon and explains PCI DSS in plain English: what it is, who it applies to, what it actually requires, how your hosting environment fits into the picture, and — most importantly — the single most effective thing you can do to dramatically reduce your compliance burden. No legal lectures. Just what you need to know to protect your customers and your business.

1. What Is PCI DSS?

PCI DSS stands for Payment Card Industry Data Security Standard. It is a set of security requirements developed and maintained by the PCI Security Standards Council — a body founded jointly by American Express, Discover, JCB, Mastercard, and Visa to establish a unified standard for protecting cardholder data worldwide.

PCI DSS is not a law. It’s a contractual requirement. When you sign up to accept card payments through a payment processor or merchant account, you agree to their terms of service — and those terms require PCI DSS compliance. Violating these terms doesn’t directly result in criminal charges, but it can result in substantial fines, increased transaction fees, suspension of your ability to accept card payments, and liability for fraudulent charges resulting from a breach on your systems.

What PCI DSS Protects

PCI DSS is specifically designed to protect cardholder data — defined as any information printed on, encoded in, or associated with a payment card. The most sensitive elements are:

• Primary Account Number (PAN) — the 16-digit card number. This is the crown jewel of cardholder data; its protection is the central focus of PCI DSS.
• Cardholder name — the name as it appears on the card
• Expiration date — the month and year the card expires
• Service code — a three or four digit code on the magnetic stripe
• Card Verification Value (CVV/CVC) — the three or four digit security code. This must never be stored after authorization, under any circumstances.
• PIN and PIN block data — used in chip-and-PIN transactions

PCI DSS Version 4.0

PCI DSS version 4.0 became the active standard in 2024, replacing version 3.2.1. Version 4.0 introduces more flexibility in how organizations demonstrate compliance (allowing customized approaches alongside the traditional prescriptive requirements) and adds stronger requirements around authentication, web-facing application security, and e-skimming protection — the latter being particularly relevant for online stores using third-party JavaScript on checkout pages.

2. Who Must Comply

If your business — in any form — accepts, processes, stores, or transmits credit or debit card data, PCI DSS applies to you. This is broader than most merchants assume.

It applies to you whether you:

• Run a WooCommerce store processing payments yourself
• Use a hosted checkout page on Shopify, BigCommerce, or Squarespace
• Take card payments over the phone and key them manually into a virtual terminal
• Run a physical retail location with a card reader
• Process only a handful of transactions per year
• Use a third-party payment processor that handles the technical side

The scope of what you need to do varies enormously based on how you handle card data and how many transactions you process — which is the basis of the merchant level system covered in Section 3. But the obligation to comply does not vary. Every card-accepting merchant is bound by PCI DSS through their merchant agreement.

3. The Four Merchant Levels

PCI DSS compliance requirements aren’t identical for every merchant. The PCI SSC defines four merchant levels based on annual card transaction volume. Your level determines how you must validate compliance each year.

The overwhelming majority of independent WooCommerce, Shopify, and small ecommerce store owners are Level 4 merchants. This is the most accessible compliance tier. The specific SAQ form you need to complete depends entirely on how your store handles card data — which is covered in Section 7.

4. The 12 PCI DSS Requirements

PCI DSS version 4.0 is organized into 12 high-level requirements, grouped under six control objectives. Here’s what each means in plain English for an online store owner.

For most small online store owners using a hosted payment gateway (Stripe, PayPal, Square), the practical requirements from this list that fall on you are a small subset: keeping your software updated (Req 5 & 6), using strong passwords and access control (Req 7 & 8), protecting data in transit with TLS/SSL (Req 4), and maintaining a basic security policy (Req 12). The heavy lifting — network firewalls, physical data center security, deep encryption — is handled by your hosting provider and payment processor within their respective scopes.

5. Hosting’s Role in Compliance

Your hosting environment is a central factor in your PCI compliance posture — but the relationship between hosting and compliance is more nuanced than most store owners realize. Your host doesn’t make you compliant. But the wrong host can make compliance significantly harder, or even impossible.

What a PCI-Compliant Host Provides

A hosting provider that supports PCI compliance will typically offer or maintain:

• Physical data center security — restricted physical access, surveillance, environmental controls (Req 9)
• Network security controls — hardware firewalls, intrusion detection, DDoS mitigation at the infrastructure level (Req 1)
• System hardening — secure default configurations on the servers they manage (Req 2)
• Patch management — keeping server operating systems and infrastructure software updated (Req 6)
• Logging and monitoring — infrastructure-level activity logging (Req 10)
• Penetration testing — regular security testing of their infrastructure (Req 11)

What Your Host Does Not Cover

Even the most PCI-capable hosting provider does not make your store compliant on its own. Your responsibilities include everything above the server infrastructure layer: your WordPress or ecommerce application, your plugins and themes, your admin account security, your choice of payment processing method, your SSL certificate configuration, and how you handle any cardholder data that passes through your system.

6. Shared Responsibility Explained

PCI compliance in a cloud or managed hosting environment operates on a shared responsibility model. Understanding exactly where your host’s responsibility ends and yours begins is critical — and it depends on which hosting model you use.

The practical takeaway: the higher up the hosting stack you go — from raw VPS to managed hosting to fully hosted platforms like Shopify — the more responsibility the provider takes on. But regardless of your platform, the payment integration layer and your application-level decisions always remain your responsibility.

7. The Hosted Gateway Solution

This is the most important section in this entire guide for most small online store owners. There is one decision that, more than any other, determines the scope and complexity of your PCI compliance obligations: whether card data ever touches your server.

The Two Models

What SAQ A Means for You

SAQ A (Self-Assessment Questionnaire A) is the simplest PCI compliance validation form — just 13 requirements. It’s available to merchants who have fully outsourced card data handling to a PCI-compliant third-party payment processor, and whose only interaction with card data is through that provider’s hosted interface. The requirements cover basics: maintaining SSL on your site, not storing card data, keeping your systems free of malware, using strong passwords, and having a basic security policy.

Compare this to SAQ D — the most comprehensive form, required for merchants who store, process, or transmit card data on their own systems — which has over 250 requirements. The difference between SAQ A and SAQ D is the difference between a twenty-minute annual exercise and a serious compliance project requiring technical expertise and potentially external auditors.

How Stripe, PayPal, and Square Handle This

• Stripe — Stripe.js and Stripe Elements capture card data directly into Stripe’s servers via a secure iframe. Your server only ever sees a token, never the card number. Stripe is a PCI Level 1 certified service provider.
• PayPal — PayPal Checkout redirects users to PayPal’s hosted pages for payment entry, or uses PayPal’s JavaScript SDK with hosted fields. Card data stays on PayPal’s systems.
• Square — Square’s Web Payments SDK uses a similar iframe-based approach. Card data goes directly to Square’s servers.
• Authorize.net — Offers Accept Hosted (fully hosted page) and Accept.js (hosted fields via JavaScript), both keeping card data off your server.

8. PCI & WooCommerce Stores

WooCommerce is the platform where PCI compliance questions come up most often — because unlike Shopify (which handles much of the compliance infrastructure), WooCommerce is self-hosted software running on your own server. That means more control, and more responsibility.

WooCommerce Itself Does Not Handle Card Data

This is an important clarification: WooCommerce the plugin does not process payments. It’s a framework that integrates with payment gateways. Which gateway you choose — and how that gateway is configured — determines entirely how card data flows and what your PCI scope is.

The Right Payment Plugins for PCI

Use WooCommerce payment gateway plugins that implement hosted fields or redirect to a hosted payment page. Do not use plugins that transmit raw card data through your server.

• WooCommerce Stripe Payment Gateway — uses Stripe Elements (hosted fields). Card data goes to Stripe. SAQ A eligible.
• WooPayments (powered by Stripe) — Automattic’s official payment plugin, also Stripe-powered with hosted fields.
• PayPal Payments for WooCommerce — uses PayPal’s hosted checkout. SAQ A eligible.
• Square for WooCommerce — uses Square’s Web Payments SDK with hosted fields. SAQ A eligible.

Your WooCommerce Hosting Requirements for PCI

• SSL/TLS on all pages — not just checkout. Google marks non-HTTPS pages as insecure, and PCI requires encryption in transit across your site.
• Keep WordPress, WooCommerce, and all plugins updated — outdated software is the leading cause of ecommerce site compromises
• Hosting with isolated environments — managed WordPress hosting is preferable to basic shared hosting for PCI purposes
• No card data in your database — verify that your payment plugin stores only tokens, never raw card numbers or CVV values
• WAF (Web Application Firewall) — protects against injection attacks and malicious traffic targeting your WooCommerce store

9. Choosing a PCI-Friendly Host

When evaluating hosting for an online store, these are the questions and features to prioritize for PCI compliance.

What to Look for in a Host

• Isolated hosting environment — managed cloud or VPS hosting that keeps your account separate from other customers at the server level
• Network-level firewall — infrastructure firewall between your server and the public internet, not just a software firewall
• Intrusion detection — automated monitoring for suspicious activity at the server and network level
• Free SSL certificate — Let’s Encrypt or equivalent, easy to activate, all pages covered
• Malware scanning — automated scanning with alerts and remediation assistance
• Automated backups with off-site storage — for incident recovery
• Log access — the ability to review access logs for your hosting environment
• SOC 2 or ISO 27001 certification — indicates the provider has undergone independent security auditing

10. The Cost of Non-Compliance

PCI non-compliance is not a theoretical risk. The financial and reputational consequences of a breach — or of being found non-compliant during an audit — are substantial and well-documented.

Fines and Penalties

The card brands (Visa, Mastercard, etc.) can levy fines on your acquiring bank — which passes them directly to you — for PCI non-compliance. These fines range from $5,000 to $100,000 per month for ongoing non-compliance. In the event of a confirmed breach, fines can escalate dramatically, and you may be required to pay for forensic investigation, credit monitoring for affected customers, and card reissuance costs for every card exposed.

Breach Liability

If your store suffers a data breach and you were non-compliant with PCI DSS at the time, your liability exposure is significantly higher. You may be responsible for fraud losses on cards compromised through your systems. You may face civil suits from customers. And your payment processor may terminate your merchant account, ending your ability to accept card payments entirely.

Real-World Breach Costs

For small merchants, breach costs are often existential. Forensic investigation alone typically costs $10,000–$50,000. Card replacement fees can run $3–$10 per compromised card — if 5,000 cards were exposed, that’s $15,000–$50,000 in reissuance costs alone. Add customer notification, legal costs, and potential lawsuits, and a single breach can easily run well into six figures for a small business.

11. Common Compliance Mistakes

These are the mistakes that put online store owners at risk — and the ones that come up most often when stores experience payment security incidents.

Storing CVV Codes After Authorization

This is an absolute, unconditional prohibition under PCI DSS. The three or four digit CVV/CVC code on a payment card must never be stored — not in a database, not in logs, not in order notes, not anywhere — after a transaction is authorized. Any plugin or custom code that stores CVV values puts you in severe violation. Verify your payment integration explicitly: no CVV data should be stored anywhere in your system after authorization completes.

Logging Card Data Accidentally

This one catches merchants by surprise. Debug logging, error logging, and server access logs can inadvertently capture card data if your payment flow isn’t correctly isolated. If a form field submits card data to your server before sending it to a payment processor — even just for a split second — that data can appear in your logs. Use hosted payment fields (iframes) to ensure card data never traverses your server at all.

Using HTTP Instead of HTTPS

Every page of your store must be served over HTTPS — not just the checkout page. PCI DSS Requirement 4 requires encryption of cardholder data in transit, and modern browsers flag any non-HTTPS page as “Not Secure.” Obtain a free SSL certificate through your host, enable HTTPS sitewide, and set up HTTP-to-HTTPS redirects so no page can be accessed insecurely.

Neglecting the SAQ

Many Level 4 merchants simply never complete their annual Self-Assessment Questionnaire. This is non-compliance, even if their actual security posture is reasonable. Check with your payment processor — most have a compliance portal where you can complete and submit your SAQ. For merchants using hosted gateways, the SAQ A is short enough to complete in under an hour.

Outdated Plugins Creating Vulnerabilities

Outdated WordPress plugins are the primary attack vector for WooCommerce store compromises. Attackers specifically target known vulnerabilities in popular plugins. Keeping every plugin, theme, and WordPress core installation updated is one of the most direct compliance and security measures available — and one of the easiest to automate.

Assuming the Host Is Responsible for Everything

As covered in Section 6, your host handles the infrastructure layer. Your application, your plugins, your payment integration, your admin account security, and your handling of any card data are entirely your responsibility. No hosting plan, however premium, delegates those responsibilities away from you.

12. Your PCI Compliance Checklist

Use this checklist as a practical framework for getting and staying compliant. For most small stores using a hosted payment gateway, completing this list puts you in a strong compliance position.

Payment Processing Setup

• Using a hosted payment gateway (Stripe, PayPal, Square, or equivalent) — card data never touches your server
• Payment plugin confirmed to use hosted fields or hosted page — raw card data not transmitted through your server
• CVV/CVC data confirmed not stored anywhere in your database, logs, or order records
• Card numbers stored only as tokens provided by your payment gateway — never as raw PANs
• Payment processor’s compliance portal accessed — understand what they require of you

Hosting & Server Security

• SSL/TLS certificate active and covering all pages — HTTPS enforced sitewide
• Hosting environment is isolated (managed cloud or VPS — not basic shared hosting for in-scope card data)
• Network-level firewall in place (provided by host or via Cloudflare)
• Web Application Firewall (WAF) active
• Malware scanning configured with alerts
• Automated off-site backups configured and tested

Application Security

• WordPress core, WooCommerce, all plugins, and all themes are up to date
• Unused plugins and themes deleted (not just deactivated)
• Admin account uses a strong, unique password managed in a password manager
• Two-factor authentication enabled on all admin accounts
• Login attempt limiting active (via security plugin)
• WordPress admin URL changed from default /wp-admin/ (via WPS Hide Login or similar)
• Security plugin installed and configured (Wordfence or Solid Security)
• XML-RPC disabled if not in use

Annual Compliance Validation

• Determine your merchant level based on annual transaction volume
• Identify the correct SAQ form for your payment integration (SAQ A for hosted gateways)
• Complete and submit your SAQ through your payment processor’s compliance portal
• Complete quarterly ASV vulnerability scan if required by your processor or merchant level
• Document your security practices — a basic written information security policy satisfies Req 12