Knowledge base — Definition
PCI Compliance
PCI compliance for online stores: what PCI DSS requires, how merchant levels and SAQ types work, and how site design choices shrink your compliance scope.
What Is PCI Compliance?
PCI compliance means meeting the Payment Card Industry Data Security Standard (PCI DSS), the security rules that apply to any business that accepts, processes, stores or transmits payment card data. The standard is maintained by the PCI Security Standards Council, founded by the major card brands, and the current version is PCI DSS v4.0.1. It is enforced not by government but through your contract with your acquiring bank or payment processor.
For a typical online store, PCI compliance is less about buying a product and more about how your checkout is built. Whether card numbers ever touch your server, whether your payment page loads third-party scripts, and how you manage admin access all decide how much of the standard applies to you. Each year you confirm compliance, usually by completing a Self-Assessment Questionnaire (SAQ) and an Attestation of Compliance for your processor.
Why PCI Compliance Matters
The consequences of ignoring PCI DSS land on the merchant, not the developer or the plugin author.
- Breach liability: If card data is stolen from your site, your processor can pass on card-brand fines, forensic investigation costs and card reissue costs.
- Keeping your merchant account: Processors can raise fees, hold funds or terminate accounts for merchants who do not attest to compliance.
- Skimming attacks on checkout pages: Attackers commonly inject JavaScript into checkout pages to copy card details as customers type, which PCI DSS v4 now addresses directly.
- Customer privacy obligations: A card breach is also a breach of personal information, which under PIPEDA can trigger mandatory reporting to the Privacy Commissioner of Canada and notification to affected people.
How PCI Compliance Works
- Merchant level: Card brands sort merchants into Levels 1 to 4 based on annual card transaction volume. Most small and mid-sized online stores are Level 3 or 4 and can self-assess; Level 1 merchants need an on-site assessment by a Qualified Security Assessor.
- Scope: Every system that stores, processes or transmits card data, or could affect its security, is "in scope". Reducing scope is the single most effective way to reduce effort.
- SAQ type: SAQ A applies when payment is fully outsourced through a hosted payment page or the provider's iframe fields. SAQ A-EP applies when your site's own page controls how card data reaches the provider, such as a direct post or a JavaScript form you host. SAQ D covers everything else and is far longer.
- The 12 requirements: PCI DSS is organized into twelve requirements, from network security controls and secure configuration to access control, logging, vulnerability management, testing and security policies.
- Script controls on payment pages: Version 4 added requirements to inventory and authorize every script on payment pages and to detect unauthorized changes to them; which ones apply depends on your SAQ type, so confirm the current wording with your processor.
- Scans and attestation: Depending on your SAQ, you may need quarterly external vulnerability scans from an Approved Scanning Vendor, then you submit your SAQ and attestation to your processor.
Common PCI Compliance Mistakes
- Assuming the gateway covers everything: A compliant payment gateway reduces your scope but does not remove it; you still attest for your own site and how it hands off payment.
- Storing card data you do not need: Card numbers saved in order notes, emails, spreadsheets or a custom database field pull your whole site into full scope. Sensitive authentication data such as the CVV must never be stored after authorization.
- Unmanaged scripts on checkout: Chat widgets, heatmaps, A/B testing tools and tag managers loading on the payment page all expand the attack surface.
- Weak admin security: Shared WordPress admin logins, no multi-factor authentication and outdated plugins on a store's server undermine every other control.
- Picking the wrong SAQ: Completing SAQ A when your integration actually requires A-EP leaves you attesting to something that is not true.
Best Practices for PCI Compliance
- Use hosted or iframe payment fields: Choose an integration where card data goes straight from the customer's browser to the provider, so it never reaches your server.
- Keep the checkout lean: Load only the scripts the payment page needs, keep an inventory of them, and use a Content Security Policy and integrity checks where practical.
- Harden the platform: Keep WordPress, WooCommerce and plugins updated, enforce MFA for every admin, use unique accounts and remove ones you no longer need. Our WordPress security entry covers the details.
- Encrypt everything in transit: Serve the whole site over HTTPS with a valid SSL certificate and modern TLS settings.
- Document as you go: Record which SAQ you use and why, your script inventory and your update routine, so the annual attestation is a review rather than a scramble.
PCI Compliance at PerfectPixels
When we build WooCommerce and custom stores, we design the payment flow to keep card data off your servers, usually with the gateway's hosted fields, which keeps most clients in the simplest SAQ category. We keep the checkout free of unnecessary scripts, harden the WordPress install and document the setup so you can complete your questionnaire with confidence. We are not a Qualified Security Assessor, so for formal assessments we work alongside your processor or assessor. See our eCommerce services for more.
Frequently Asked Questions
Do small online stores need to be PCI compliant?
Yes. PCI DSS applies to every merchant that accepts card payments, regardless of size. Smaller merchants usually validate through a self-assessment questionnaire rather than an audit, and a well-designed checkout can make that questionnaire short.
Does using Stripe, Square or PayPal make me PCI compliant?
It helps a great deal, because those providers are compliant themselves and their hosted fields keep card data off your site. You are still responsible for your own attestation and for securing the pages that load their payment form.
What is the difference between SAQ A and SAQ A-EP?
SAQ A is for merchants who fully outsource card entry to the provider, through a redirect or the provider's iframe. SAQ A-EP is for sites whose own pages influence how card data is collected, and it carries many more requirements, including regular vulnerability scans.
Related Resources
Further reading: PCI DSS standards and document library — PCI Security Standards Council.