Braintree PCI Compliance: Which SAQ Applies and When You Need an ASV Scan
Braintree PCI compliance explained: see which SAQ fits Hosted Fields, Drop-in or custom builds, and when quarterly ASV scans apply. Book an ASV scan today.
• SAQ A fits e-commerce merchants whose checkout is fully delivered by a PCI DSS-validated third party, through a redirect or a hosted payment page or iframe.
• SAQ A-EP applies when you outsource card processing but your own website still controls or influences the payment page, for example through a Direct Post or a JavaScript-built form.
• An ASV scan is required for both. PCI DSS v4.0.1 Requirement 11.3.2 calls for passing external scans at least once every three months, and 11.3.2.1 adds scans after significant changes.
• SAQ A-EP is heavier. It adds script-management, tamper-detection and penetration-testing obligations that SAQ A merchants do not carry.
• Since January 2025, SAQ A has a script-safety eligibility criterion. If you cannot confirm your site is not susceptible to script attacks, SAQ A-EP is likely the right fit.
• Your acquirer or card brand has the final say on whether you must validate and what evidence to submit.
SAQ A vs SAQ A-EP is the question most e-commerce merchants hit once they have outsourced payments and wonder how much PCI work is left. The two questionnaires look similar on paper, but they sit on opposite sides of one line: does your website affect how the payment is made, or does a third party own the whole payment page?
The answer decides how many requirements you validate, whether you need script controls and penetration testing, and what your scan scope looks like. It does not change one thing: under PCI DSS v4.0.1, both questionnaires include quarterly external vulnerability scanning by an Approved Scanning Vendor.
This guide walks through eligibility, requirements, the scan question and a simple decision path. It draws on the PCI Security Standards Council’s published SAQ documents, the PCI DSS v4.0.1 standard and the ASV Program Guide. It is general guidance, not a substitute for your acquirer’s instructions or a Qualified Security Assessor’s opinion.
SAQ (Self-Assessment Questionnaire): a validation tool merchants use to self-attest to PCI DSS compliance when they are eligible. Each SAQ type matches a payment setup. See our PCI DSS SAQ types explained guide for the full set.
SAQ A: the shortest e-commerce questionnaire for merchants that fully outsource account data functions to validated third parties.
SAQ A-EP: a longer e-commerce questionnaire for merchants that outsource processing but whose website can affect the security of the payment transaction.
TPSP (third-party service provider) / PSP: the payment processor or gateway that hosts, processes or transmits card data for you.
Payment page: the page or frame where the shopper enters card details.
ASV (Approved Scanning Vendor): a company approved by the PCI SSC to perform external vulnerability scans. Our PCI ASV glossary covers related terms.
Requirement 11.3.2 / 11.3.2.1: the PCI DSS requirements for quarterly external scans by an ASV and for external scans after significant changes.
The difference is control over the payment page. With SAQ A, a validated third party delivers every element of the page. With SAQ A-EP, your website serves the page or directs how card data is sent, so it can affect payment security and more requirements apply.
Think of it as a question about who holds the pen. In a redirect or a fully hosted iframe, your site hands the shopper over, and the PSP does the rest. Your pages never build the payment form.
In an SAQ A-EP setup, the card data still goes straight to the PSP, so you do not store or process it. But your page builds the form, loads the PSP’s JavaScript, or posts the data onwards. A compromised script on that page could skim card numbers, which is why the standard treats it as a higher-risk arrangement.
Which questionnaire fits depends on how the checkout is built, not on which brand you use. Two stores on the same PSP can land on different SAQs.
Meet the quarterly scan requirement for SAQ A and SAQ A-EP with a report your acquirer can review.
You qualify for SAQ A if you take card-not-present payments only, outsource all account data functions to PCI DSS-validated third parties, never handle card data on your own systems, and can confirm your site is not susceptible to script attacks.
The SAQ A eligibility criteria, as published for v4.0.1, boil down to these points:
• Your business accepts only card-not-present transactions (e-commerce or mail/telephone orders).
• All account data functions are outsourced to PCI DSS-compliant third parties.
• You do not electronically store, process or transmit account data on your systems or premises.
• Every element of the payment page delivered to the shopper’s browser comes directly from the validated third party.
• You have confirmed those providers are PCI DSS compliant.
• Any account data you retain is on paper and was not received electronically.
• For e-commerce channels, you have confirmed your site is not susceptible to attacks from scripts that could affect your e-commerce systems.
That last point is the newer one. In January 2025 the Council updated SAQ A, removing Requirements 6.4.3 and 11.6.1 as line items and adding the script criterion in their place. Merchants can support the confirmation with techniques like those in 6.4.3 and 11.6.1 or with a written statement from the provider that it covers this risk. Our guide to PCI DSS 6.4.3 and 11.6.1 explains how those script requirements work and why an ASV scan does not satisfy them.
Not sure whether your checkout is truly “hosted”? Our PCI-compliant checkout guide shows what the setup should look like.
SAQ A-EP applies when you outsource payment processing but your website controls how the shopper or their card data reaches the PSP. It carries far more requirements than SAQ A, including script controls, penetration testing and ASV scans.
SAQ A-EP is the right fit when your e-commerce site does not receive card data but still influences the payment. Typical examples are:
• A Direct Post form where your page collects card details and posts them straight to the PSP.
• A JavaScript-built payment form where your page loads PSP code that creates the fields in your own page.
• A merchant-hosted payment page that redirects the shopper to the PSP but controls where that redirect goes.
Because an attacker who changes your page could change where card data goes, the questionnaire covers much more ground. Expect requirements across secure configuration, vulnerability and patch management, access control, and testing. In v4.0.1, that includes Requirements 6.4.3 and 11.6.1 for payment-page scripts, penetration testing, and the external ASV scans in 11.3.2 and 11.3.2.1.
Self-hosted platforms often land here. If you run a store on your own hosting, check how your payment plugin renders its fields. Our WooCommerce PCI compliance guide shows where that line usually falls.
If your site does handle card data directly, neither questionnaire applies, and you are looking at SAQ D.
SAQ A is the lightest, SAQ A-EP adds website-related controls and testing, and SAQ D covers merchants that store, process or transmit card data themselves.
SAQ A | SAQ A-EP | SAQ D (merchant) | |
|---|---|---|---|
Typical setup | Redirect or fully hosted payment page/iframe | Your site controls or builds the payment page | Your systems handle card data |
Who controls the payment page | Validated third party | Your website, in part | You |
Card data on your systems | None | None | Yes, possibly |
Script requirements | Eligibility criterion | 6.4.3 and 11.6.1 | 6.4.3 and 11.6.1 |
ASV scan (11.3.2) | Required | Required | Required |
Penetration testing | Not required | Required | Required |
Overall effort | Lowest | Moderate to high | Highest |
For a deeper look at how scans differ across the lightest and heaviest questionnaires, see SAQ A vs SAQ D ASV scan requirements.
See clear ASV scan pricing so you can budget for quarterly scanning with no surprises.
Yes. Under PCI DSS v4.0.1, both SAQ A and SAQ A-EP include Requirement 11.3.2, which calls for passing external vulnerability scans by an ASV at least once every three months, plus scans after significant changes under 11.3.2.1.
Many merchants on SAQ A assume that a hosted checkout means no scanning. That was true under older versions, but it is no longer the case. The PCI SSC has published a resource guide aimed at SAQ A merchants who are completing the ASV scan requirement for the first time.
Here is what the requirement means in practice:
• Quarterly cadence. You need to pass external scan evidence at least once every three months. Our guide on how often to run an ASV scan covers scheduling.
• After significant changes. A new shopfront, hosting move or major infrastructure change triggers an extra external scan under 11.3.2.1.
• Done by an ASV. Quarterly scans must use an ASV’s approved scan solution. See our overview of PCI DSS 11.3.2 for the wording and evidence an assessor expects.
• Scope depends on your setup. The scan covers your internet-facing systems, such as the shopfront you host. If a platform hosts your site, confirm with the provider who covers scanning and what evidence you will receive.
• A pass is not full compliance. The Council notes that an ASV scan only addresses Requirement 11.3.2. It does not show that you meet any other requirement.
Whether your acquirer will accept your report is a separate matter, covered in the ASV report acquirer acceptance.
Map every payment channel, check how the payment fields reach the shopper, review the scripts on those pages, confirm with your PSP and acquirer, then document the result.
Use this path for each e-commerce channel you run:
1. Map your channels. List every way you take cards online: website, mobile web, payment links, and phone orders.
2. Identify how the payment fields appear. A full redirect or a PSP-hosted page points to SAQ A. A form your page builds, or a Direct Post, points to SAQ A-EP.
3. Review scripts on the payment page. Tag managers, analytics, chat widgets and ad pixels all matter. If you cannot confirm the page is not susceptible to script attacks, SAQ A is off the table.
4. Confirm with your PSP and acquirer. Ask the PSP which integration you are on and which SAQ it expects. Ask your acquirer what validation it requires.
5. Document your decision. Save your reasoning and your latest ASV scan report alongside the questionnaire.
For platform-specific starting points, see PCI compliance for e-commerce and PCI compliance for Shopify.
The most common mistakes are assuming the PSP's name decides your SAQ, leaving third-party scripts on the payment page, and customizing the checkout in ways that make your site build the payment form.
• Assuming “we use a big PSP” settles it. The integration method decides eligibility, not the provider. A Stripe integration, for example, can look different depending on how the payment fields are embedded.
• Leaving extra scripts on the payment page. Tag managers and marketing pixels are the usual culprits when merchants try to claim SAQ A.
• Customising checkout themes. Heavy theme or plugin customisation can turn a hosted flow into a page your site controls.
• Skipping the scan. Treating a hosted checkout as scan-free leaves a gap in your evidence. If a scan fails, our guide on what to do when an ASV scan fails walks through fixing and rescanning.
• Choosing an SAQ for convenience. SAQ eligibility depends on facts about your setup, so picking the shortest form without meeting the criteria creates compliance risk.
SAQ A vs SAQ A-EP comes down to one question: who controls the payment page? If a validated third party delivers every element and you can confirm your site is not susceptible to script attacks, SAQ A fits. If your website builds the form or directs the card data, SAQ A-EP applies, with heavier requirements and penetration testing.
Either way, the scan question has the same answer. Under PCI DSS v4.0.1, you need to pass external ASV scans every three months and after significant changes. Confirm your integration with your PSP, confirm what your acquirer expects, and keep your scan reports with your questionnaire.
Tell us how your checkout works and we will help you scope the right external scan.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.