Many online merchants assume that by handing off payment processing to Stripe, PayPal or a similar provider, payment security is no longer their direct concern. That is partly true, but only partly. The PCI DSS standard, which governs the security of card payment data, still applies to every business that accepts card payments, even when the technical processing is delegated to a third party.
What PCI DSS actually means
PCI DSS, or Payment Card Industry Data Security Standard, is a set of security requirements imposed by the card networks themselves, such as Visa and Mastercard, on any business that stores, processes or transmits card data. It is not a law in the strict sense, but a contractual obligation tied to accepting card payments, and failing to meet it can result in penalties applied through the merchant's acquiring bank.
Why a small business using Stripe or PayPal is still in scope
The vast majority of small online shops fall under the simplest category, called SAQ A, reserved for merchants who fully outsource payment processing to a compliant third party provider. This is the typical case of a WooCommerce shop that redirects the customer to a payment page hosted by Stripe or PayPal, or embeds their form without ever letting the card number pass through its own server. This simplified level greatly reduces the compliance burden, but does not eliminate it entirely: the merchant retains certain responsibilities of its own, notably regarding the security of its own web page surrounding the payment module.
What has changed since 2025
Version 4.0 of the standard, fully mandatory since March 31, 2025, introduced two requirements that directly affect e-commerce sites using hosted payment: monitoring of third party scripts loaded on the payment page, and an authorization mechanism for any script added or modified on that page. Concretely, a WooCommerce site loading analytics scripts, advertising pixels, or marketing plugins on the same page as the payment module, even if hosted externally, must now keep an inventory of these scripts and monitor for any unauthorized change. These requirements exist because a compromised third party script on a payment page can intercept card data at the moment of entry, even if the payment form itself belongs to Stripe or PayPal.
The other obligations that remain, even under SAQ A
The SAQ A self assessment form remains the shortest, but it is not a simple declaration. It requires confirming that the site does not store, process or transmit any card data in the clear, that the payment provider is itself PCI DSS certified, and keeping proof of that compliance, usually through an attestation supplied by the provider. The standard also requires, at every level, multi factor authentication for any administrative access touching the payment environment, along with passwords of at least twelve characters.
What a small business should actually check
The first step is identifying which self assessment form actually applies, based on how payment is technically integrated, rather than automatically assuming the simplest level. The second is drawing up an inventory of third party scripts present on the site's payment page, often more numerous than expected once marketing and analytics plugins are accounted for. The third is asking the payment provider for its current PCI DSS attestation of compliance, a document that should normally be available on request.
A topic not to fully outsource
The often repeated message that using Stripe or PayPal makes PCI compliance automatic is inaccurate and can create a false sense of security for the merchant. Outsourcing payment processing remains the best technical decision for a small business, since it greatly reduces the scope of responsibility, but it does not exempt the merchant from checking the few obligations that remain, particularly since the standard's tightening around payment page scripts.
Points to verify before publishing: confirm at publication time that version 4.0.1 of PCI DSS remains the only active version required by the card networks, that the March 31, 2025 deadline for previously deferred requirements remains accurate, and check that the description of SAQ A scope and requirements 6.4.3 and 11.6.1 still matches the official documentation from the PCI Security Standards Council.