The Payment Card Industry Data Security Standard (PCI DSS) applies to every business that stores, processes or transmits cardholder data, or that could affect the security of those that do. For a large processor that means a full audit. For most merchants it means a self-assessment questionnaire, or SAQ: a form that confirms the merchant meets the requirements relevant to how it takes card payments.
Which SAQ you complete makes an enormous difference: the shortest covers a small set of requirements, the longest covers the whole standard. And the single biggest factor in which one applies is a design decision: how your checkout collects card details. This guide explains the SAQ types, how integration choices map to them, the 2025 changes to SAQ A, and how to keep your scope small. For PCI DSS basics and the wider security picture, see our guide to payment gateway security.
Who decides how you validate
The PCI Security Standards Council (PCI SSC) maintains the standard and the SAQs, but it doesn't decide which merchants must validate compliance or how. As the Council puts it, that's determined by the individual payment brands, and merchants should ask their acquirer or the payment brands they work with about validation and reporting requirements. In practice your acquirer or payment provider tells you which level you're at and what to submit, usually an SAQ and an Attestation of Compliance (AOC) once a year.
The Council also advises merchants to confirm they meet all of an SAQ's eligibility criteria before starting, and to check with the entity they submit to. The descriptions below are a guide to which SAQ typically fits; the eligibility criteria in the SAQ itself are what count.
The SAQ types
These are the SAQs for PCI DSS v4.0.1, published by the Council in October 2024, with the usual fit for each:
| SAQ | Typically fits | Relative scope |
|---|---|---|
| A | Card-not-present merchants that fully outsource card data handling: the payment page or form comes entirely from a PCI DSS compliant provider (redirect or iframe) | Smallest |
| A-EP | E-commerce merchants that outsource processing, but whose own website controls how card data is captured, such as fields created by the merchant's JavaScript or a direct post to the provider | Larger: the website itself is in scope |
| B | Merchants using only imprint machines or standalone dial-out terminals, with no electronic card data storage | Small, for in-person |
| B-IP | Merchants using only standalone, PCI-approved payment terminals with an IP connection to the processor | Small, for in-person |
| C-VT | Merchants keying transactions one at a time into a provider's web-based virtual terminal on an isolated computer | Moderate |
| C | Merchants with payment application systems connected to the internet, without electronic card data storage | Moderate to large |
| P2PE | Merchants using only hardware terminals in a PCI-listed point-to-point encryption solution | Small, for in-person |
| SPoC | Merchants accepting in-person payments with a software-based PIN entry solution on a commercial phone or tablet | Small to moderate |
| D for merchants | Every merchant not eligible for another SAQ, including any that receive or store card data on their own systems | The whole standard |
| D for service providers | Service providers eligible to self-assess | The whole standard |
How your checkout integration maps to an SAQ
For online payments, the choice is mostly between SAQ A, SAQ A-EP and SAQ D, and it follows directly from where card details are typed and where they go:
| Integration | Where card details are entered | Usual SAQ |
|---|---|---|
| Redirect to a hosted payment page | On the provider's page, on the provider's domain | A |
| Provider's iframe or hosted fields | In fields served by the provider, embedded in your page | A, if every element of the payment form comes from the provider |
| Your JavaScript builds the form and posts to the provider | In fields your page creates | A-EP |
| Direct API: your server receives card details | On your page, sent to your servers | D |
Our guide to payment gateway integration compares these methods on other grounds too. The rule of thumb: the less of the card-capture experience you control, the smaller your scope. If you need full control of the form, expect the larger questionnaire that comes with it.
What changed for SAQ A in 2025
PCI DSS v4 added two requirements aimed at attacks on payment pages: 6.4.3, managing and authorising the scripts on payment pages, and 11.6.1, detecting unauthorised changes to payment pages. Both took effect on 31 March 2025. In January 2025 the Council revised SAQ A in response to feedback about how hard these were for merchants who outsource their payment page:
- Requirements 6.4.3 and 11.6.1, and requirement 12.3.1 (a targeted risk analysis supporting 11.6.1), were removed from SAQ A.
- In their place, an eligibility criterion was added: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.
- The revised SAQ A took effect on 31 March 2025, when the October 2024 version was retired.
The change doesn't mean the risk went away. An attacker who can change the page that embeds a provider's iframe, or the link that redirects to it, can swap in a fake payment form. SAQ A merchants now have to be able to confirm that their site isn't open to that kind of attack, so protecting the pages around checkout remains your job.
Protecting the page around the payment form
The SAQ doesn't prescribe one technique for this. Common, well-understood controls for the pages that host or link to payment forms include:
- An inventory of every script loaded on checkout pages, with an owner and a reason for each, and removal of the rest. Tag managers and marketing scripts on payment pages deserve particular scrutiny.
- A Content Security Policy that limits which scripts can run and which frames can load.
- Subresource Integrity on third-party scripts you load from fixed URLs, so a modified file won't run.
- Monitoring for unexpected changes to checkout pages and their scripts.
- Tight control over who can deploy to the website, with reviewed changes.
Content-Security-Policy: default-src 'self';
script-src 'self' https://js.provider.example;
frame-src https://checkout.provider.example;
connect-src 'self' https://api.provider.example;
object-src 'none';
base-uri 'self';
form-action 'self' https://checkout.provider.exampleA real header is sent on one line; it's broken here for reading. Use the domains your provider documents, test the policy in report-only mode first, and review it whenever the checkout changes.
Ways to keep your scope small
Every place card data touches is in scope, along with whatever can affect it. Reducing scope means reducing those places:
- Let the provider capture card details, through a redirect, hosted page or provider-served fields, so card numbers never reach your servers.
- Use tokens for saved cards and recurring payments instead of storing card data. In India this isn't optional: RBI's card-on-file rules mean merchants can't store actual card data, and saved cards work through tokens. Our card tokenisation guide explains how.
- Keep card data out of side channels: logs, analytics, error trackers, support tickets, chat transcripts, emails and call recordings. Payment pages should never send form contents to analytics tools.
- For in-person payments, use PCI-listed P2PE terminals or standalone approved terminals, rather than systems that handle card data in your own software.
- For phone or mail orders, use the provider's virtual terminal on a dedicated device, or solutions that keep card details away from your agents.
- Segment networks so systems that could touch card data are isolated from everything else.
Using an orchestration layer or several providers
When you route payments across providers, card capture should still happen in provider-served or orchestration-served fields, with tokens passed between systems rather than card numbers. Ask any platform in your payment path for its own PCI DSS Attestation of Compliance, and how integrating with it affects which SAQ you're eligible for. Our orchestration evaluation guide lists the security questions to ask, and LILPE's compliance page sets out how LILPE approaches payments regulation and security.
The annual routine
Once you know your SAQ, compliance is a yearly cycle, with some ongoing work in between:
- Confirm you still meet the SAQ's eligibility criteria; a checkout redesign can change the answer.
- Work through the SAQ's requirements, and fix gaps before attesting.
- Complete any external vulnerability scans your SAQ requires; some require quarterly scans by an Approved Scanning Vendor.
- Sign the Attestation of Compliance and submit it as your acquirer or provider instructs.
- Keep evidence: policies, script inventories, change records and scan reports.
Frequently asked questions
What is a PCI DSS SAQ?
A self-assessment questionnaire published by the PCI Security Standards Council for merchants and service providers eligible to assess their own PCI DSS compliance. Each SAQ covers the requirements relevant to a particular way of accepting card payments.
What is the difference between SAQ A and SAQ A-EP?
SAQ A fits merchants whose entire payment page or form comes from a PCI DSS compliant provider, through a redirect or iframe. SAQ A-EP fits e-commerce merchants that outsource processing but whose own website controls how card data is captured, for example by building the payment fields with their own JavaScript; it covers many more requirements.
Which SAQ applies if I use a hosted payment page?
Usually SAQ A, provided every element of the payment page comes directly from a PCI DSS compliant provider, you don't store, process or transmit card data on your own systems, and you meet the other eligibility criteria, including the 2025 criterion about protecting your site from script attacks. Confirm with your acquirer.
What changed in SAQ A in 2025?
In January 2025 the PCI Security Standards Council removed requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A and added an eligibility criterion that the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The revised SAQ A took effect on 31 March 2025.
Do small merchants in India need PCI DSS compliance?
Card networks and acquirers set which merchants must validate and how, so ask your payment provider what it requires of you. Separately, RBI's rules mean Indian merchants can't store actual card data at all, and most small merchants use provider-hosted checkouts, which keep their PCI DSS scope small.
Official sources
- PCI Security Standards Council — Important updates announced for merchants validating to SAQ A (January 2025)Removal of requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A; new eligibility criterion on script attacks; revised SAQ A effective 31 March 2025.
- PCI Security Standards Council — Bulletin: SAQs for PCI DSS v4.0.1 now available (15 Oct 2024)Clarified eligibility criteria in SAQs A, A-EP and C-VT; merchants should confirm eligibility before self-assessing.
- PCI Security Standards Council — Merchant resourcesWhether a merchant must validate compliance is determined by the payment brands; contact your acquirer or payment brand.
- PCI Security Standards Council — Document library (SAQs and SAQ Instructions and Guidelines)
- RBI — Restriction on Storage of Actual Card Data [i.e. Card-on-File (CoF)] (24 Jun 2022)
- MDN — Content Security Policy (CSP)
- MDN — Subresource Integrity
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
