WooCommerce PCI Compliance: Your SAQ When You Host the Store

On this page 7 sections

1. Why "Is WooCommerce PCI Compliant?" Is the Wrong Question
2. How Your Gateway's Checkout Type Shapes Your WooCommerce SAQ
3. WordPress PCI Compliance Responsibilities: Hosting, Plugins and Access
4. WooCommerce Payment Page Scripts and PCI Risk on WordPress
5. Practical Hardening: Updates, Least Privilege and Monitoring
6. Completing Your SAQ and Vulnerability Scans
7. Next Steps for Your WooCommerce Store

Key takeaways

• WooCommerce is software, not a compliant service. PCI DSS applies to your store, your hosting and your processes.
• Your gateway's checkout method (redirect, embedded fields, on-page form or server-side handling) has the biggest effect on your PCI scope.
• On a self-hosted WordPress site, you control the server, the plugins, the admin accounts and every script on your checkout pages.
• Your acquirer confirms your SAQ type, validation schedule and any scan requirements, so get those answers in writing before you attest.

WooCommerce PCI compliance works differently from compliance on a fully hosted store builder. WooCommerce runs on your own WordPress installation, so more of the environment is your responsibility. This guide explains why "WooCommerce is PCI compliant" is a misleading idea and how your payment gateway's checkout method affects which Self-Assessment Questionnaire (SAQ) you complete. It also covers what you need to manage across hosting, plugins, admin access and payment page scripts.

This article is general information, not legal or security advice. PCI DSS requirements and SAQ eligibility criteria change over time. Confirm your obligations with your acquirer, your gateway or a qualified PCI security professional.

Why "Is WooCommerce PCI Compliant?" Is the Wrong Question

Store owners often ask whether WooCommerce is PCI compliant. That question treats compliance as a feature you can install, and it isn't one.

PCI DSS applies to merchants and service providers, meaning the businesses that accept or process cardholder data or that can affect its security. WooCommerce is open-source software that runs on a server you choose and configure. Whether your store meets PCI DSS depends on:

• How card data moves through your checkout
• Where the site is hosted and how that server is secured
• Which themes and plugins are installed, and whether they're up to date
• Who has admin access and how those accounts are protected
• Which scripts load on the pages where customers pay

A fully hosted commerce platform works differently. The provider runs the servers and the core software, so it takes on part of the security work. On a self-hosted WordPress store, that work falls to you.

Card numbers may never touch your server, but your site still controls the page your customer trusts. An attacker who alters that page may be able to capture payment data before it reaches the gateway.

A better question is which SAQ applies to your store and what it requires of you. Your acquirer (the processor or bank behind your merchant account) makes the final call.

How Your Gateway's Checkout Type Shapes Your WooCommerce SAQ

Your payment gateway plugin controls how the card form appears and where the customer types the card number. That choice is the main factor in your PCI scope and in which SAQ your acquirer will ask you to complete. Many gateways offer more than one integration mode, so ask your provider which mode your plugin uses rather than guessing.

The table below shows how scope generally changes with each checkout method. Use it for planning only. It isn't an eligibility ruling. Each SAQ has eligibility criteria published by the PCI Security Standards Council, and your acquirer applies them to your setup.

Redirect to a Hosted Payment Page

When the customer clicks "Place order," they go to a payment page on the gateway's domain, and your WooCommerce site never sees the card number. This method generally comes with the lightest compliance workload. You're still responsible for making sure the redirect sends customers to the real gateway and not to an attacker's copy.

Embedded Payment Fields (Iframes)

Many modern gateway plugins show card fields that look like part of your checkout but are actually served by the gateway inside an iframe. Customers stay on your site, which many merchants prefer.

You'll find plenty of online discussion about "WooCommerce SAQ A" setups built this way. Treat those posts as background reading only. Whether your iframe checkout qualifies for a particular questionnaire depends on the eligibility criteria in the current SAQ documents. Read that section carefully, or have your acquirer confirm in writing which questionnaire applies.

Payment Forms Built on Your Page

Some integrations load JavaScript on your checkout page to build the form or capture card data, then send that data straight to the gateway. The card number never reaches your server, but your web page directly affects the transaction. This setup generally means a longer questionnaire and more security controls than a redirect or iframe. Your acquirer can tell you which SAQ applies and whether recurring vulnerability scans are part of it.

Card Data Touching Your Server

Your PCI scope may be at its broadest if a plugin does any of the following:

• Posts raw card numbers to your server
• Stores card numbers in your database
• Lets staff key cards into the WordPress admin

That level of scope is a heavy lift for a small store, and stores often end up there by accident:

• An old or custom plugin collects card numbers and saves them in order notes
• Staff use a "manual payment" workaround and type card details into an order field
• Customers email card numbers, and someone pastes them into WooCommerce

For phone and mail orders, a separate virtual terminal for keyed payments keeps card entry out of WordPress entirely. For returning customers, use your gateway's tokenization or vault feature instead of saving card numbers yourself.

If you're comparing options, our WooCommerce payment gateway checklist for store owners covers integration mode along with fees, payouts and support.

WordPress PCI Compliance Responsibilities: Hosting, Plugins and Access

Even with the lightest checkout setup, a self-hosted store leaves you in charge of several areas that a hosted platform would handle for you.

Hosting. Your host runs the server, but you choose the plan and the configuration. On shared hosting, other sites run on the same server as yours. If your host's services fall within your PCI scope, ask for documentation of which security responsibilities they cover. Get a clear answer on who patches the operating system, PHP and the database.

Plugins and themes. Every plugin is code running on your site, and many of them load on checkout. Attackers commonly get in through abandoned plugins, unpatched plugins and "nulled" plugins (pirated copies of premium software).

Admin access. Anyone with administrator rights in WordPress can install plugins, edit theme files and change what loads on your payment page. In practice, admin access is access to your checkout.

Scripts. Analytics, ad pixels, chat widgets, review badges, tag managers and page builders all add JavaScript to your pages. Any of these that run on the page where customers pay are part of your security picture.

WooCommerce Payment Page Scripts and PCI Risk on WordPress

Web skimming, where attackers inject malicious JavaScript into checkout pages to steal card data, is a well-known threat to online stores. WordPress sites are especially exposed because themes and plugins usually add scripts to every page by default, including cart and checkout.

Ask your acquirer whether your SAQ includes specific requirements for managing payment page scripts or detecting page changes, and check the current version of the questionnaire you're completing. Whatever your questionnaire requires, these habits are good security practice:

• Keep an inventory of every script on your checkout page, with a short written reason why each one is needed.
• Approve scripts deliberately so nothing new lands on checkout unless someone decides it should.
• Protect script integrity so a tampered version can't quietly replace a legitimate script.
• Watch for changes to the checkout page and its security headers, and make sure someone gets an alert when they change.

Illustrative example: A store owner adds a live chat plugin, a tag manager running three marketing pixels and a page builder. None of these are payment tools, yet all of them load on the checkout page. If any one were compromised, it could read what customers type or rewrite the page around the card fields.

To put these habits into practice on WordPress:

1. Audit the checkout page. Open it in your browser's developer tools and list every script along with the domain it loads from.
2. Remove what checkout doesn't need. Marketing and chat scripts can often be turned off on cart and checkout pages. A developer can handle this, or you can use a script-management option your host supports.
3. Restrict script sources. A Content Security Policy header limits which domains can serve scripts on your payment page.
4. Add integrity checks where possible. Subresource Integrity attributes confirm that externally hosted static scripts haven't been altered.
5. Monitor for changes. Use a tool or service that alerts you when checkout scripts or headers change unexpectedly.

Practical Hardening: Updates, Least Privilege and Monitoring

Keeping a WordPress store secure depends more on routine habits than on one-time projects.

Updates and Plugin Hygiene

• Keep WordPress core, WooCommerce, your theme and every plugin up to date.
• Delete deactivated plugins and unused themes rather than leaving them installed.
• Install software only from reputable sources, and never use nulled software.
• Test updates on a staging copy of your site before applying them to the live store.

Least Privilege for Admin Accounts

• Give each person their own login, and never share an admin account.
• Assign WooCommerce's Shop Manager role, or another limited role, to staff who handle orders but don't need to install plugins.
• Require multi-factor authentication for every account that can log in to the dashboard.
• Remove accounts promptly when employees or contractors leave.
• Consider disabling the built-in theme and plugin file editor so no one can change code from the dashboard.

Monitoring and Recovery

• Turn on file integrity monitoring so you're alerted when core, theme or plugin files change.
• Use a web application firewall, either through your host or a security service.
• Log admin logins and plugin changes, and review those logs regularly.
• Keep tested, off-site backups.

Card testing is a related problem that hits WooCommerce checkouts hard. Our guide to stopping card testing and fake WooCommerce orders covers rate limits, CAPTCHA and gateway-level controls. Adding 3-D Secure authentication for online payments can also help reduce fraud on card-not-present transactions.

Completing Your SAQ and Vulnerability Scans

Once you know your checkout method, the validation process generally follows a predictable pattern. Your acquirer decides how often you need to validate.

1. Confirm your SAQ type and validation schedule with your acquirer. Your processor or acquiring bank decides what validation it requires from you and when. Get the answer in writing.
2. Map your card flow. Document how a payment travels from the customer's browser to the gateway, including every plugin and service involved.
3. Download the current SAQ from the PCI Security Standards Council, and read the eligibility criteria before you answer any questions.
4. Answer each requirement honestly. If a control isn't in place, fix it before you attest. Don't mark it as compliant in the meantime.
5. Ask whether external vulnerability scans are required. Some questionnaires call for recurring scans of your internet-facing systems by an approved scanning provider. Ask your acquirer whether yours does, and if so, how often and which systems are covered.
6. Submit your questionnaire and attestation through the portal or process your processor uses.
7. Revisit your answers when something changes. A new gateway plugin, a theme rebuild or a switch in hosting can change your SAQ type between validations.

Keep your script inventory, plugin list, user list and any scan reports in one place. That way, your next questionnaire starts from documentation instead of memory.

Next Steps for Your WooCommerce Store

Start by finding out exactly how your current gateway plugin handles card entry. That one answer determines most of your WooCommerce PCI compliance workload. If your setup puts card data on your server, or lets your own page control the payment form, ask your gateway whether a redirect or embedded-field option would reduce your scope.

MannyPay supports WooCommerce payment integration, works with payment gateways like Authorize.net and NMI and offers broader online and e-commerce payment processing. For a full walkthrough of setting up online payments, see our ecommerce payment processing guide.

If you'd like a specialist to look at your setup, you can request a free processing quote. A MannyPay specialist will respond within one business day.

ME

About the author

MannyPay Editorial Team

Beyond the Swipe's editorial desk researches the publication's guides and news and cites its sources in every article. Articles reviewed by a named MannyPay editor carry that editor's byline.

This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.