E-commerce PCI compliance is one of the areas where merchants make the most assessment errors. Many believe that using Stripe, PayPal or a well-known payment gateway automatically exempts them from all PCI DSS obligations. The reality is more nuanced: the type of integration chosen determines which SAQ applies and how many controls remain with the merchant. Understanding this distinction allows you to minimise the compliance perimeter by choosing the right architecture from the start.
E-commerce checkout and PCI DSS: what triggers when you accept cards
Any online store that accepts card payments activates PCI DSS obligations for the merchant. The question is not whether the obligations apply, but which ones and to what extent. Everything depends on how card data flows during checkout. If the customer's browser sends card data directly to the merchant's servers (even for a moment), the merchant is subject to the most extensive obligations of SAQ D, with over 200 controls to satisfy. If instead card data never touches the merchant's servers because the payment form is hosted by the provider, the merchant may qualify for the much simpler SAQ A.
There is a middle ground represented by the SAQ A-EP approach: the merchant uses the provider's JavaScript to collect card data directly in the customer's browser, without data passing through the merchant's servers. This reduces scope compared to SAQ D but still requires more controls than SAQ A, including management of web server security and JavaScript code on checkout pages. With PCI DSS v4, the requirement on payment page scripts has further complicated the position of SAQ A-EP merchants.
Integration options and their impact on the SAQ
The main integration options for an e-commerce are three, ordered from most to least onerous in terms of PCI DSS. The first is native checkout: the merchant develops and manages the card data entry form internally. This entails SAQ D with the widest compliance perimeter. The second option is hosted fields or JavaScript injection: the provider injects input fields into the merchant's page that collect card data directly in the browser and send it to the provider. This leads to SAQ A-EP with an intermediate scope. The third and least onerous option is redirect to a hosted payment page: the user leaves the merchant's site to complete payment on a page hosted by the provider, then returns after confirmation. This architecture allows SAQ A.
Tokenization adds an additional layer of protection in any scenario. When a certified tokenization provider intercepts the PAN before it reaches the merchant's systems and returns an irreversible token, the merchant never holds sensitive card data. The token can be freely stored for future use (subscription renewals, recurring orders) without this incurring additional card data security obligations, because the token has no value outside the provider's system.
How PCI Proxy EU eliminates PCI scope from your e-commerce
With PCI Proxy EU, the merchant's checkout never sees card data. The payment form is managed by PCI Proxy EU's certified PCI DSS Level 1 infrastructure, which intercepts the PAN and returns a token to the merchant before any sensitive data reaches the online store's servers. This brings the merchant directly to SAQ A, eliminating the need for quarterly vulnerability scanning of servers, extensive penetration tests, certificate management and CDE-specific access control policies.
The operational advantage is significant even for stores managing recurring orders or subscriptions. The token stored by the merchant can be used to charge cards in the future without the merchant ever knowing the original PAN. This scenario, previously complex to manage in PCI DSS compliance, becomes straightforward with a tokenization provider: the merchant asks the provider to process a charge using the token, and the provider uses the PAN it holds in its certified vault. The merchant never sees the sensitive data and maintains the SAQ A perimeter at all stages of the customer lifecycle.
Frequently asked questions
If I use Stripe or PayPal am I already PCI DSS compliant?
It depends on the integration. If you use the redirect to Stripe or PayPal's checkout page, your scope is reduced to SAQ A. If you use their APIs or JavaScript elements with forms hosted on your domain, your scope is SAQ A-EP. If you have directly integrated the APIs passing card data through your server, you are in SAQ D. Using a well-known gateway does not automatically equal being compliant: the integration architecture matters.
Does a hosted payment iframe reduce my scope?
Yes, if the iframe is loaded from the provider's domain and card data does not pass through the merchant's servers. In this case the typical qualification is SAQ A. Be careful though: if the merchant has custom JavaScript running on the same page as the iframe that could theoretically access the data, the PCI Council may consider the merchant to be required to complete SAQ A-EP instead of SAQ A. Always verify the correct classification with your acquirer.
I have a WooCommerce store: what do I need to do?
WooCommerce itself does not determine your PCI scope: what counts is which payment gateway you use and how you have integrated it. If you use a redirect to your provider's hosted payment page, you can complete the SAQ A. If you use plugins that collect card data directly in the WooCommerce checkout and pass it via API, your scope is larger. Check your payment plugin documentation and, if necessary, switch to a hosted form solution.
Zero card data in your e-commerce means SAQ A, simplified compliance and safer customers. Discover PCI Proxy EU.