PCI Compliant Payment Gateways: What to Check Before You Choose One

A PCI compliant payment gateway is a payment service provider that has validated its own systems against the Payment Card Industry Data Security Standard (PCI DSS), normally through an annual assessment by a Qualified Security Assessor that produces a Report on Compliance and an Attestation of Compliance (AOC). Choosing one decides how much of PCI DSS lands on you, but it does not make you compliant. You still secure what you control and validate it every year, and the integration you choose decides which Self-Assessment Questionnaire (SAQ) you complete.

What does “PCI compliant” mean for a payment gateway?

It means the gateway has shown, as a service provider, that the systems it uses to capture, process, transmit and store card data meet PCI DSS. It does not cover your website, products left out of its assessment scope, or channels such as phone orders keyed into your own systems.

Does a PCI compliant payment gateway make me compliant?

No. PCI DSS applies to every merchant that accepts cards, and to any system that could affect the security of card data, not only the systems that hold it. A compliant gateway is evidence you rely on, not a substitute for your own validation.

PCI DSS v4.0.1 expects you to manage the gateway as a third-party service provider under Requirement 12.8: keep a list of providers, have a written agreement, check their compliance status at least once every 12 months, and record which requirements each one manages. Your acquirer, or the provider if it holds your merchant contract, then expects your own annual SAQ or Report on Compliance; our guide to Worldpay PCI compliance shows how one acquirer runs this. Merchants that do not validate can be charged non-compliance fees by their acquirer, whichever gateway they use.

What should I ask a PCI payment gateway before I sign?

Ask any PCI DSS payment gateway for documents, not assurances. These questions cover what an assessor will look for later.

You can also check whether a provider appears on a card brand’s service provider listing, such as Visa’s Global Registry of Service Providers, but the AOC is still the document to keep on file.

How does your integration decide your SAQ?

If every element of the payment page comes only and directly from the gateway, through a redirect or a provider-hosted iframe, you are usually eligible for SAQ A. If your own website serves the form or scripts that handle card data, it is usually SAQ A-EP. If card data reaches your servers, it is SAQ D. Our guide to PCI SAQ A compares the first two in detail, and our page on PCI SAQ D covers the third. Not sure which describes your checkout? Our free PCI compliance check suggests your likely SAQ. On Magento or Adobe Commerce, the payment module makes this choice for you, and our guide to Magento PCI compliance maps each type of module to an SAQ.

One detail matters when you compare gateways. Since January 2025, SAQ A includes an eligibility criterion that you have confirmed your site is not susceptible to attacks from scripts that could affect your e-commerce systems. The PCI SSC’s FAQ 1588 says this applies to pages that embed the provider’s payment form, such as an iframe, and not to pages that simply redirect customers to the provider. One way to meet it is confirmation from your provider that its embedded form includes protection against script attacks, which is why question 4 above matters. Requirements 6.4.3 and 11.6.1, mandatory since 31 March 2025, still apply in SAQ A-EP and SAQ D; our guide to payment page script requirements explains them.

Stripe, PayPal and Square: which SAQ does each integration point to?

These notes reflect each provider’s public documentation as we read it on 13 October 2026. Providers change products and wording, and the entity that accepts your validation has the final say, so confirm your SAQ with them.

Whichever provider you choose, one rule holds: if your server receives or forwards card numbers, you are in SAQ D.

Stripe PCI compliance

Stripe says it is assessed every year as a PCI Level 1 service provider, and its PCI compliance guide maps each integration to an SAQ:

Stripe’s guide also lists SAQ C for businesses that take cards only through Stripe Terminal and SAQ C-VT for manual entry in the Dashboard.

PayPal PCI compliance

Square PCI compliance

Square’s position saves paperwork but does not change what PCI DSS expects of you: keep card numbers out of your own systems, never take card details by email or on paper, and control the scripts on any website that hosts Square’s form.

Why do tokens, recurring billing and 3-D Secure matter when choosing a gateway?

They decide whether card data ever has to come back into your systems.

• Tokens and recurring billing. A gateway that stores the card and returns a token lets you take repeat and subscription payments without holding card numbers. Check what happens to those tokens if you switch provider, because a migration that routes card data through your own systems would bring it back into scope. Our guide to PCI DSS tokenisation explains what tokens take out of scope and what stays in.
• 3-D Secure. Customer-initiated online card payments in the UK need Strong Customer Authentication unless an exemption applies, and 3-D Secure is the usual way to meet it and to cut card-not-present fraud. Merchant-initiated payments, such as a subscription charge taken against a stored card, fall outside it. The gateway runs the flow; you set the exemption and fraud rules.

What keeps merchants in SAQ D even with a compliant gateway?

Usually something other than the website. Common causes are phone orders keyed into a web form on staff computers, card numbers stored in an order system or CRM for repeat orders, a legacy checkout still running alongside the new one, and server-side integrations that pass card numbers through to the gateway’s API. Map every sales channel; our overview of cyber security for retail and e-commerce lists the standards that apply to stores, online shops and hotels.

Why Sovereign Secure

• PCI SSC-approved QSA company, also approved as a Qualified PIN Assessor (QPA), Card Production Security Assessor (CPSA), P2PE Assessor and 3DS Assessor, and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028.
• Integration reviews before you commit. Our PCI DSS consultancy reviews your checkout design and your gateway’s AOC and responsibility matrix, and confirms which SAQ applies.
• Testing for the scope you keep. Penetration testing of checkout pages and ASV scans, delivered through our PCI SSC Approved Scanning Vendor partner, cover the requirements that stay with you.
• Independent advice. This guide does not rank gateways, and our advice is about your scope, not about which provider you choose.
• UK company since 2012, headquartered in Accrington, Lancashire, with offices in Los Angeles, Singapore, Dubai and Dhaka.

Choosing or changing a payment gateway?

Send us your shortlist or details of your current checkout, and we will tell you which SAQ each option points to and what evidence to collect from the provider. Contact us or call +44 161 523 5276. The SAQs themselves, with their full eligibility criteria, are in the PCI SSC document library.