What is PCI DSS compliance for websites that take payments?

PCI DSS compliance means meeting the Payment Card Industry Data Security Standard, a set of security requirements that applies to every business that stores, processes, or transmits payment card data, including websites that accept card payments. If your site takes Visa, Mastercard, American Express, or other major cards, you are expected to be compliant, even if a payment gateway handles the actual card numbers. The good news is that most small online stores can dramatically reduce what they need to do by choosing the right payment integration.

This article explains what PCI DSS is, who enforces it, how the different Self-Assessment Questionnaires work, and the practical website security steps that matter most for an online store, with examples for WordPress and WooCommerce as well as custom-built sites.

This is practical guidance rather than a formal compliance opinion. Your acquiring bank or payment provider has the final say on what you need to submit, so always confirm with them.

What Is PCI DSS?

PCI DSS is maintained by the PCI Security Standards Council (PCI SSC), an organisation founded by the major card brands. The standard defines technical and operational controls for protecting cardholder data, such as the card number (PAN), cardholder name, expiry date, and the sensitive authentication data like the CVV code.

The current version is PCI DSS v4.0.1. Version 4.0 introduced a number of new requirements that were "future-dated" and became mandatory from 31 March 2025, several of which directly affect e-commerce websites.

PCI DSS is not a law. It is a contractual requirement: when you sign up with a payment processor or merchant bank, you agree to comply. Failing to do so can lead to penalties from your acquirer, higher processing fees, liability for fraud losses after a breach, or losing the ability to accept cards altogether.

Who Needs to Be PCI DSS Compliant?

Every merchant that accepts card payments needs to be compliant. That includes:

• WooCommerce, Shopify, Magento, and custom-built online stores.
• Membership and subscription sites that charge recurring fees.
• Donation pages for charities and non-profits.
• Booking sites that take deposits.
• SaaS products that bill customers by card.

Using a hosted service like Stripe, PayPal, Square, or Adyen does not remove the obligation. It does, however, drastically reduce how much of the standard applies to you, which is the single most important decision you will make.

Merchant Levels

Card brands group merchants into levels based on annual transaction volume. The exact thresholds vary by card brand, but broadly:

• Level 1: The largest merchants, processing millions of transactions per year. These typically need an annual on-site assessment by a Qualified Security Assessor (QSA).
• Levels 2 and 3: Mid-sized merchants, who usually complete a Self-Assessment Questionnaire and may need additional validation.
• Level 4: Smaller merchants, which covers most small online shops. These complete a Self-Assessment Questionnaire and, depending on the SAQ type, quarterly external vulnerability scans.

The 12 Core Requirements of PCI DSS

PCI DSS is organised into six goals and twelve principal requirements:

1. Install and maintain network security controls such as firewalls.
2. Apply secure configurations to all system components, including removing vendor defaults.
3. Protect stored account data, ideally by not storing it at all.
4. Protect cardholder data with strong cryptography during transmission over open, public networks.
5. Protect systems against malicious software.
6. Develop and maintain secure systems and software, including patching and secure coding.
7. Restrict access to cardholder data by business need to know.
8. Identify users and authenticate access to system components, including multi-factor authentication.
9. Restrict physical access to cardholder data.
10. Log and monitor all access to system components and cardholder data.
11. Test the security of systems and networks regularly.
12. Support information security with organisational policies and programs.

For a website, requirements 2, 4, 5, 6, 8, 10, and 11 are where most of the practical work lives.

Self-Assessment Questionnaires: Which One Applies to You?

Most small and mid-sized merchants validate compliance by completing a Self-Assessment Questionnaire (SAQ). The SAQ you use depends on how card data flows through your website, and the difference in effort between them is huge.

SAQ A: Fully Outsourced Payments

SAQ A applies when all card data entry happens on pages or iframes served entirely by a PCI-compliant third party. Common examples include:

• Redirecting the customer to a hosted checkout page, such as Stripe Checkout or PayPal.
• Embedding the processor's payment fields in iframes, such as Stripe Elements or a hosted payment form.

Your server never sees the card number. SAQ A has by far the fewest requirements. Note that the PCI SSC has revised SAQ A's eligibility criteria for v4.0.1, including an expectation that merchants confirm their site is protected against script-based attacks that could affect the payment page. Check the current version of the SAQ with your provider.

SAQ A-EP: Partially Outsourced E-commerce

SAQ A-EP applies when your website does not receive card data but does control how the payment page is delivered. A typical case is a checkout where your own JavaScript creates the payment form and sends card data directly from the browser to the processor. Because an attacker who compromises your site could tamper with that script, many more requirements apply, including regular vulnerability scans.

SAQ D: Everything Else

If card data passes through or is stored on your servers, for example a custom form that posts card numbers to your own backend, you fall under SAQ D. It covers essentially the entire standard. For most small businesses, this is a strong sign that the integration should be redesigned.

Other SAQs

There are also SAQs for card-present and phone-based payments, such as SAQ B, SAQ B-IP, SAQ C, SAQ C-VT, and SAQ P2PE. If you only sell online, you will usually be looking at SAQ A, A-EP, or D.

How to Reduce Your PCI Scope

Scope is the set of systems that touch cardholder data or could affect its security. The smaller your scope, the easier compliance becomes. Here is how to shrink it:

1. Never store card data: Do not save card numbers in your database, order notes, logs, or emails. Use your processor's tokenisation and saved-card features instead.
2. Never store CVV codes: Storing sensitive authentication data after authorisation is prohibited, even if encrypted.
3. Use hosted fields or redirects: Choose integrations where the processor serves the card fields, so your site qualifies for SAQ A.
4. Keep payments on a single, simple page: Fewer scripts on the checkout means fewer things that can go wrong.
5. Avoid taking card numbers over email or chat: This quietly pulls your inbox and support tools into scope.

For WooCommerce, the official gateways for Stripe, PayPal, and Square all use processor-hosted fields or redirects by default, which keeps card numbers off your server. Avoid obscure gateway plugins that ask you to collect raw card numbers in your own form.

Protecting the Payment Page From Script Attacks

Web skimming attacks, often called Magecart-style attacks, inject malicious JavaScript into checkout pages to copy card details as customers type. Because the script runs in the customer's browser, card data can be stolen even when your server never receives it.

PCI DSS v4.0 added two requirements aimed at this problem:

• Requirement 6.4.3: Every script loaded on the payment page must be authorised, its integrity assured, and an inventory kept with a written justification for each one.
• Requirement 11.6.1: A mechanism must detect unauthorised changes to the payment page's HTTP headers and content, and alert you.

Whether these apply directly to you depends on your SAQ, but the underlying protections are worth adopting on any checkout.

Use a Content Security Policy on Checkout

A Content Security Policy tells the browser which domains are allowed to load scripts and receive data. Here is an example for a WooCommerce checkout using Stripe, sent only on the checkout page. Adjust the domains to match your processor's documentation and test thoroughly, because an overly strict policy will break the checkout.

<?php
/**
 * Send a Content Security Policy on the WooCommerce checkout page only.
 */
function sajjad_checkout_csp() {
    if ( ! function_exists( 'is_checkout' ) || ! is_checkout() || headers_sent() ) {
        return;
    }

    $policy = implode(
        '; ',
        array(
            "default-src 'self'",
            "script-src 'self' 'unsafe-inline' https://js.stripe.com",
            'frame-src https://js.stripe.com https://hooks.stripe.com',
            "connect-src 'self' https://api.stripe.com",
            "img-src 'self' data: https://*.stripe.com",
            "style-src 'self' 'unsafe-inline'",
        )
    );

    header( 'Content-Security-Policy-Report-Only: ' . $policy );
}
add_action( 'template_redirect', 'sajjad_checkout_csp' );

WordPress and WooCommerce print some inline scripts, which is why 'unsafe-inline' appears in script-src here. Tightening that further with nonces is possible but takes more work.

The example uses the Content-Security-Policy-Report-Only header so violations are reported in the browser console without blocking anything. Once the checkout works cleanly, change it to Content-Security-Policy to enforce the policy.

Use Subresource Integrity for Static Scripts

If you load a third-party script that does not change often, Subresource Integrity (SRI) ensures the browser refuses it if its contents have been altered:

<script
  src="https://cdn.example.com/library/1.2.3/library.min.js"
  integrity="sha384-REPLACE_WITH_REAL_HASH"
  crossorigin="anonymous"
></script>

You can generate the hash with OpenSSL:

curl -s https://cdn.example.com/library/1.2.3/library.min.js \
  | openssl dgst -sha384 -binary | openssl base64 -A

Do not use SRI on payment processor scripts such as Stripe.js, which are updated by the provider and are meant to be loaded directly from their domain.

Remove Unnecessary Scripts From Checkout

Marketing pixels, chat widgets, heatmaps, and A/B testing tools rarely need to run on the payment step. In WordPress, you can dequeue a script on the checkout page only:

<?php
/**
 * Remove non-essential scripts from the WooCommerce checkout page.
 */
function sajjad_trim_checkout_scripts() {
    if ( function_exists( 'is_checkout' ) && is_checkout() ) {
        wp_dequeue_script( 'example-chat-widget' );
        wp_deregister_script( 'example-chat-widget' );
    }
}
add_action( 'wp_enqueue_scripts', 'sajjad_trim_checkout_scripts', 100 );

Replace example-chat-widget with the actual script handle, which you can find in the page source or with a tool like Query Monitor. Place the code in a custom plugin or your child theme's functions.php.

Website Security Controls That Support PCI DSS

Even on SAQ A, the security of your website matters because an attacker who controls it can redirect customers to a fake payment page. Focus on these areas:

Encryption

• Serve the entire site over HTTPS with TLS 1.2 or higher.
• Disable old protocols (SSL, TLS 1.0, TLS 1.1) and weak ciphers.
• Enable HSTS so browsers never fall back to HTTP.

Patching

Keep WordPress core, WooCommerce, payment gateway plugins, themes, and PHP on supported versions. PCI DSS expects critical security patches to be applied promptly, and v4.0 requires a risk-based approach to scheduling the rest.

Strong Authentication

• Unique accounts for every person with admin or shop manager access.
• Multi-factor authentication for all administrative access. PCI DSS v4.0 extends MFA requirements to all access into the cardholder data environment.
• Strong password policies and lockout after repeated failed attempts.

Logging and Monitoring

Keep logs of admin logins, user changes, plugin installations, and file changes. The WP Activity Log plugin records admin actions in WordPress, and server logs cover the rest. Review them regularly and retain them for a defined period.

Malware Protection and File Integrity

Use a web application firewall and a malware scanner. Tools like Wordfence, Sucuri, or your host's own scanning can alert you when files on your checkout or theme change unexpectedly. You can also check WordPress core files from the command line:

wp core verify-checksums
wp plugin verify-checksums --all

Vulnerability Scanning

Depending on your SAQ, you may need quarterly external vulnerability scans performed by a PCI-approved scanning vendor (ASV). Your payment provider or acquiring bank often partners with an ASV and may offer scans as part of your account.

How to Complete Your Annual Compliance

Validation is usually an annual process:

1. Map your payment flow: Document exactly how card data moves from the customer to the processor, including every page, script, and service involved.
2. Choose the correct SAQ: Use your payment provider's guidance to confirm which questionnaire applies.
3. Close the gaps: Work through each requirement in the SAQ and fix anything that is not in place.
4. Run any required scans: Complete and pass ASV scans if your SAQ requires them.
5. Complete the Attestation of Compliance (AOC): This is the signed declaration that accompanies your SAQ.
6. Submit to your acquirer or provider: Many processors provide an online portal to upload the SAQ and AOC.
7. Maintain it all year: Compliance is a continuous state, not a form you fill in once. Keep your policies, patches, and logs current between assessments.

---

FAQ: PCI DSS Compliance for Websites

---

Conclusion

PCI DSS compliance is the card industry's way of making sure every business that accepts cards protects that data properly. For websites, the most important decision is how you integrate payments: using processor-hosted fields or redirects keeps card numbers off your server and can reduce your obligations to the shortest questionnaire available.

From there, focus on the fundamentals that protect your checkout: HTTPS everywhere, prompt patching, multi-factor authentication for admins, a lean and monitored payment page, and a clear record of what scripts run where. Confirm your SAQ with your provider, complete your validation each year, and treat compliance as an ongoing habit rather than an annual chore.