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.
• No. An ASV scan does not satisfy PCI DSS 6.4.3 or 11.6.1. The scan satisfies 11.3.2, a different requirement, and it cannot see what a customer's browser loads on your payment page.
• 6.4.3 requires you to inventory, authorize and check the integrity of every script on your payment pages. 11.6.1 requires a mechanism that detects unauthorized changes to those pages and alerts you, checked at least weekly unless a targeted risk analysis says otherwise.
• Both became mandatory on March 31, 2025.
• SAQ A removed both questions in January 2025 but added an eligibility criterion: you must confirm your site is not susceptible to script attacks. PCI DSS itself did not change.
• You can meet the requirements by reducing your exposure (redirect to a hosted page), by getting written confirmation from your payment provider, or by adding script controls and monitoring.
PCI DSS 6.4.3 and 11.6.1 are the two payment page script requirements that became mandatory on March 31, 2025, and e-commerce merchants are still confused about them. The most common question we hear is whether a passing ASV scan covers them. It does not, and some vendor pages blur that point.
This guide explains what each requirement says, who it affects, why an ASV scan is not enough, what does satisfy the requirements, and how they relate to SAQ A eligibility. We are Secusy, an ASV vendor. Our scan covers requirement 11.3.2. It does not cover 6.4.3 or 11.6.1, and we would rather say so plainly. For the scan requirement, see PCI DSS 11.3.2 explained. For the deadline background, see the PCI DSS 4.0.1 deadline.
Payment page: the web page where a customer enters card details, or a page that embeds the form that collects them.
E-skimming (Magecart-style attack): malicious JavaScript injected into a checkout page that copies card data as the customer types it.
Content Security Policy (CSP): a browser security header that tells the browser which script sources are allowed to run.
Subresource Integrity (SRI): an attribute that lets the browser check that a loaded script matches a known hash.
TPSP (third-party service provider): a company that handles payment functions for you, such as a payment processor or hosted payment page provider.
SAQ A: the shortest PCI self-assessment for merchants that fully outsource payment functions. See what an ASV scan is for and how scanning fits in.
6.4.3 requires you to inventory, authorize and integrity-check every script on your payment pages. 11.6.1 requires a mechanism that detects unauthorized changes to those pages and their HTTP headers and alerts you, checked at least weekly unless a targeted risk analysis sets a different period.
Both requirements target e-skimming, where an attacker adds or alters a script on a checkout page. Both were future-dated in PCI DSS v4.0 and became mandatory on March 31, 2025.
6.4.3: manage payment page scripts. For scripts loaded and executed in the customer’s browser, you need to:
• confirm that each script is authorised;
• have a method to assure the integrity of each script;
• keep an inventory of all scripts, with a written business or technical justification for each.
This covers first-party scripts and third- and fourth-party scripts, such as analytics, chat widgets, and tag managers.
11.6.1: detect changes and tampering. You need a change- and tamper-detection mechanism that alerts personnel to unauthorised modifications to the HTTP headers and the contents of payment pages as received by the customer’s browser, including indicators of compromise, changes, additions, and deletions. It must evaluate the page at least once every seven days, or at another frequency defined by a targeted risk analysis under requirement 12.3.1. In short, 6.4.3 is about knowing and controlling what runs on the page, and 11.6.1 is about noticing when it changes.
An attacker compromises a script your payment page already loads, such as an analytics tool, chat widget or tag manager, or injects their own, and the code copies card details as the customer types them. The data reaches the attacker before your processor sees the transaction, and your own servers are never breached in the traditional sense. That is why firewalls, intrusion detection and server scans do not see it, and why the Council added requirements aimed at the payment page itself. Every third-party script on a checkout page is a possible way in, and many merchants load several without a formal inventory.
Run your quarterly ASV scan for 11.3.2.
E-commerce merchants with a payment page they control, which usually means SAQ A-EP, SAQ D and Report on Compliance validations. SAQ A merchants have a related eligibility criterion instead.
Whether you have these requirements depends on how your checkout works:
Checkout setup | 6.4.3 and 11.6.1 | Note |
|---|---|---|
Full redirect to a provider’s hosted page | Not on SAQ A | The SAQ A script criterion does not apply to redirect merchants |
Provider’s iframe embedded on your page, validating with SAQ A | Removed from SAQ A, replaced by an eligibility criterion | Merchant server, domain, hosting |
Your page collects card data and posts it to a provider, validating with SAQ A-EP | Both apply | Your page is a payment page |
You host and process payment pages, validating with SAQ D or a ROC | Both apply | Full scope |
Confirm the details with your acquirer or QSA. Setups vary, and a single-page application or a mix of flows can change the answer. If you use Stripe, see how its hosted options map to your obligations in PCI compliance for Stripe.
No. An ASV scan is an external, unauthenticated check of your servers for known vulnerabilities, run quarterly. It cannot inventory or authorize scripts in a customer's browser, and it cannot detect a changed script on your payment page at least weekly.
An ASV scan satisfies requirement 11.3.2. Requirements 6.4.3 and 11.6.1 are separate, and a pass on one is not evidence for the other. Here is why the scan falls short:
• It tests servers, not the browser. E-skimming runs in the customer’s browser. A skimmer is injected JavaScript, not a known server vulnerability, so there is nothing for the scanner to match.
• It does not see what the browser loads. The scanner does not render your checkout page, execute its JavaScript or follow the third-party scripts it pulls in. It cannot build the script inventory 6.4.3 requires.
• Its cadence is wrong. The scan runs at least every three months. 11.6.1 asks for checks at least every seven days, unless a targeted risk analysis says otherwise.
• It does not alert on change. The scan reports findings once per run. 11.6.1 needs a mechanism that detects and alerts on unauthorised modification of the page and its headers.
The scan still has a role. An unpatched web server or content management system is one way attackers get a script onto your page, and the ASV scan helps close that route. But it addresses the way in, not the script itself. For a wider view of what a pass does and does not prove, see what an ASV scan covers and misses for APIs and our guide to what a passing ASV scan means.
Reduce what runs on your payment page, get written confirmation from your payment provider, or add script controls and monitoring. The right choice depends on your checkout setup and SAQ type.
Options, from least to most effort:
1. Redirect to a hosted payment page. Sending the customer to your provider’s page removes the payment page from your site. Redirect merchants fall outside the SAQ A script criterion.
2. Use an embedded form and get provider confirmation. If you use an iframe, the Council’s FAQ 1588 allows you to satisfy the SAQ A criterion by obtaining confirmation from your PCI DSS-compliant provider that its solution, implemented as instructed, protects your page from script attacks. Keep that confirmation on file.
3. Cut third-party scripts on the payment page. Remove tag managers, analytics and widgets from checkout wherever you can. Every script you remove is one less to inventory, authorise and monitor.
4. Add a Content Security Policy and Subresource Integrity. CSP restricts which sources can run scripts and supports the authorisation part of 6.4.3. SRI helps with integrity for static scripts. Neither alerts you when something changes, so they do not satisfy 11.6.1 alone.
5. Add payment page monitoring. A monitoring tool or a scheduled check that loads the page as a browser would compare scripts and headers against a baseline and alert on change, addressing 11.6.1.
6. Document a targeted risk analysis if you check less often than every seven days. Requirement 12.3.1 requires it.
A simple starting point for items 4 and 5 is a policy that lists only the script sources you trust:
Content-Security-Policy: script-src 'self' https://js.provider.example; frame-src https://pay.provider.example; report-uri /csp-reports
Test a policy in report-only mode first so you do not block checkout. SRI works for scripts that do not change between loads, and fails for dynamic third-party scripts that update often, which is why monitoring is still needed.
Keep evidence for each control: the script inventory with justifications and owners, authorization records, the integrity method, monitoring configuration, the weekly alert and review log, any targeted risk analysis, and your provider’s written confirmation.
See what a passing scan covers and what it leaves out.
In January 2025 the PCI SSC removed 6.4.3 and 11.6.1 from SAQ A and added an eligibility criterion: you confirm your site is not susceptible to script attacks. It does not apply to redirect merchants, and PCI DSS itself did not change.
On January 30, 2025, the Council published a revised SAQ A. It removed 6.4.3, 11.6.1, and the supporting 12.3.1 targeted risk analysis from the questionnaire. In their place, it added an eligibility criterion: the merchant has confirmed that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The revised form took effect on March 31, 2025.
Three points to avoid common mistakes:
• It is not an exemption. The questions moved. The risk did not. Reading the change as meaning SAQ A merchants no longer need script security is the most common error.
• It applies to embedded forms. Per FAQ 1588, the criterion applies to merchants whose page embeds the provider’s payment form, such as an iframe. It does not apply to merchants who redirect customers away entirely or who fully outsource payment pages.
• “Site” means the payment page. The FAQ clarifies the criterion covers the page that contains the provider’s payment element, not your whole website.
If you cannot confirm the criterion, you are not eligible for SAQ A and should look at SAQ A-EP or SAQ D, where 6.4.3 and 11.6.1 apply in full. Ask your acquirer or QSA which route fits. The ASV scan requirement is separate: SAQ A merchants still have 11.3.2. See PCI ASV scan requirements.
PCI DSS 6.4.3 and 11.6.1 protect the one place an ASV scan cannot reach: the customer’s browser. The scan covers 11.3.2, your external servers. The script requirements cover what runs on your payment page and whether you notice when it changes. Payment page script security is a separate workstream from scanning, and it needs its own controls: an inventory and authorization of scripts, integrity checks, change detection and alerting, or a payment setup that takes the page off your site. Treat the ASV scan as one control among several, and check which of these obligations your SAQ type and checkout flow actually put on you.
See the v4.0.1 changes that now apply.
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.