Quick answer: PCI compliance means following the Payment Card Industry Data Security Standard (PCI DSS) if you accept card payments. Small online merchants usually complete a Self-Assessment Questionnaire (SAQ) and keep card data out of their own servers where possible by using a gateway with hosted fields, redirects or a fully hosted checkout. Compliance is not a plugin you install once. It is a mix of how you take payments, how you secure the site and what you attest to each year.
Why PCI exists for small shops too
Card brands and banks require merchants to protect cardholder data. Even a low-volume WooCommerce or Shopify store is in scope in some form. Breaches are expensive in fees, forensic costs and trust. You do not need to memorise every control in the full PCI DSS document, but you do need to know your merchant level, your SAQ type and what your processor expects.
This article is practical orientation for mid-2020, not a substitute for your acquirer’s guidance or a Qualified Security Assessor when one is required.
Start by shrinking scope
The easiest PCI win is never touching raw card numbers.
Lower-scope approaches
- Hosted checkout / redirect: customer pays on the gateway’s page
- Hosted fields or iframes: card fields are served by the gateway while the rest of checkout stays on your site
- Fully hosted stores where the platform handles payment pages under their programme
Higher-scope approaches
- Collecting card numbers in your own forms and posting them through your server
- Storing card data yourself (almost never justified for small merchants)
If a developer proposes building a custom card form that sends numbers through your WordPress or app server, ask how that changes SAQ type and annual cost. Often it is the wrong trade. Payment architecture belongs in the same conversation as WooCommerce payment gateways and overall ecommerce website cost.
SAQ types in everyday language
Your processor or bank tells you which Self-Assessment Questionnaire applies. In broad strokes for ecommerce:
- SAQ A: merchant fully outsources card data entry to PCI validated third parties; no electronic card data on merchant systems
- SAQ A-EP: merchant site can affect the security of the payment, even if cards are entered on a third-party page (common when checkout scripts sit on your domain)
- SAQ D: broadest; for merchants who do not fit the reduced forms
Exact eligibility rules come from the PCI SSC documents and your acquirer. Do not guess from a blog post alone when you sign an attestation.
What small merchants still must do well
Even with hosted payments, you remain responsible for a secure site:
Keep software updated
CMS core, plugins, themes and server packages. Outdated plugins are a common breach path; see plugin vulnerabilities.
Use HTTPS correctly
Encrypt traffic sitewide, not only on the checkout URL. Mixed content can break trust and confuse customers. Our HTTPS migration notes cover redirects and SEO side effects. Consider HSTS once you are sure HTTPS is stable.
Restrict access
Unique admin users, strong authentication, least privilege, remove abandoned staff accounts. Two-factor authentication on admin and hosting panels helps.
Protect against common web attacks
Stay current on patches that address injection and similar flaws. Understand how SQL injection works so you do not dismiss it as “only for big companies.”
Log and monitor
Know when admin logins fail repeatedly, when plugins change and when uptime drops. Backups should be off-server and tested.
Never store forbidden data
Do not keep full track data, CVV or PIN blocks. If a legacy system stored card numbers, treat removal as a priority project with professional help.
Hosting and network basics
Your host matters. Shared hosting can be acceptable for low-scope setups if you still patch apps and use strong credentials, but you need clear responsibility lines. Ask:
- Who applies OS and panel updates?
- Is there a WAF or malware scanning option?
- How is access to the control panel secured?
- Where do backups live?
TLS configuration should meet current PCI guidance for accepted protocols and ciphers. Older deadlines around TLS 1.0 retirement already pushed merchants off obsolete encryption; do not reintroduce weak protocols for “compatibility.”
Policies and people
PCI is not only technology:
- Train anyone with admin access not to share passwords or approve random plugin installs
- Have a simple incident response outline: who to call at the host, gateway and bank
- Limit card data in support tickets and chat logs (customers sometimes type numbers into email; train staff to stop that thread and use proper payment links)
Write procedures you can actually follow. A fifty-page policy nobody reads fails audits and fails incidents.
How this fits WooCommerce, Shopify and Magento
Shopify: much of the card-handling burden sits with the platform when you use their payment surfaces correctly. You still secure staff access, apps and any custom storefront code.
WooCommerce: scope depends heavily on the gateway modules you choose. Prefer gateways that keep card data in hosted fields or redirects. Your WordPress hardening remains essential.
Magento / Adobe Commerce: often higher complexity and higher expectation of formal controls, especially as catalogue and customisation grow. Magento 1 reached end of life on 30 June 2020, which is a security and compliance conversation of its own for any shop still on it.
Whatever the platform, trust marks and clear security messaging on checkout help conversion, but they do not replace real controls; see checkout trust badges.
Annual rhythm
A practical yearly cycle for a small store:
- Confirm SAQ type with your processor
- Review how checkout actually works (scripts, domains, iframes)
- Complete the questionnaire honestly
- Schedule vulnerability scans if your type requires them
- Remediate findings
- Store the attestation where finance can find it
- Revisit after any major site or payment change
Changing hosts, adding a new payment method or installing a sketchy optimisation plugin can change your risk overnight.
Working with developers and agencies
Put PCI expectations in the project brief:
- Preferred payment UX (redirect, hosted fields, embedded)
- Forbidden approaches (card data touching your server without a formal plan)
- Plugin allowlist for anything that interacts with checkout
- Who completes the SAQ and who gathers evidence
Ask vendors to document data flow in one diagram: browser, your domain, gateway, webhook, CRM. If they cannot draw it, they do not understand scope. For Magento 1 shops past end of life, treat platform risk as urgent: unsupported software and card acceptance are a bad mix, regardless of last year’s questionnaire.
FAQ
Does a PCI badge on my footer make me compliant?
No. Badges are marketing. Compliance comes from meeting the controls and completing the required assessment.
If I only take PayPal, am I out of scope?
It depends how PayPal (or similar) is integrated and what other methods you offer. Ask your provider; do not assume.
Can my developer sign the SAQ for me?
The merchant is responsible for the attestation. Developers can help gather evidence; leadership still owns the signature.
Is PCI the same as GDPR or other privacy laws?
No. PCI focuses on cardholder data security. Privacy laws cover personal data more broadly. You may need both.
Protect payments on purpose
PCI compliance for small merchants is mostly about choosing a payment flow that keeps card data with specialists, then running a disciplined website. If you want a store built with a sensible payment architecture and security habits, see how we help businesses turn visitors into customers.
