SAQ A vs SAQ A-EP: Which Applies and Is a Scan Required?
SAQ A vs SAQ A-EP explained: see which one applies to your checkout, how the requirements differ, and whether an ASV scan is required. Read the full guide.
• Braintree secures card processing on its side, but you must still validate your own PCI compliance every year.
• Your SAQ depends on how you integrate Braintree, not on the fact that you use it.
• Drop-in UI and Hosted Fields are the Braintree integrations eligible for SAQ A. Direct card tokenisation is not.
• Custom checkout code usually moves you toward SAQ A-EP. Raw card data on your servers means SAQ D.
• Under PCI DSS v4.x, quarterly ASV scans apply to SAQ A, SAQ A-EP and SAQ D merchants. Braintree does not run them for you.
Braintree PCI compliance depends on how you integrate Braintree, not on the fact that you use it. Braintree handles the hardest part, which is processing and storing card data securely. Your checkout page, hosting and integration choices are still yours to validate.
This guide shows which SAQ your Braintree setup maps to, when an ASV scan is required, and what to do first. If you also accept payments through other gateways, see our guides on PCI compliance for Stripe and PCI compliance for PayPal merchants.
PCI DSS: the Payment Card Industry Data Security Standard, set by the PCI Security Standards Council (PCI SSC), for any organisation that stores, processes or transmits card data.
SAQ (Self-Assessment Questionnaire): the form most small- and mid-size merchants use to validate compliance. See our SAQ types explained guide.
SAQ A: the shortest form for merchants that fully outsource card entry to a PCI-compliant third party.
SAQ A-EP: for e-commerce merchants whose own website affects how card data reaches the payment provider, even though the site never receives it.
SAQ D: the full questionnaire for merchants whose systems store, process or transmit card data.
ASV (Approved Scanning Vendor): a company approved by the PCI SSC to run external vulnerability scans. See the list of approved scanning vendors.
Hosted Fields / Drop-in UI: Braintree components that render card inputs in iframes served from Braintree's domain.
Payment method nonce: a single-use token your server receives instead of the card number.
Using Braintree does not make you PCI compliant on its own. Braintree is responsible for its systems. You remain responsible for validating your own site and integration.
Braintree operates as a validated PCI DSS service provider. That covers card processing and its vault. It does not cover your website, your hosting, the scripts on your checkout page or your annual self-assessment. The better your integration keeps card data away from your systems, the less of the questionnaire applies to you. A merchant using Drop-in UI answers far fewer questions than one passing raw card numbers through their own server. Your acquirer ultimately decides how you report, so confirm the validation steps with them.
Get your quarterly external scan from a PCI Approved Scanning Vendor, with a clear report your acquirer will accept.
Merchants using Braintree Drop-in UI or Hosted Fields are eligible for SAQ A, the shortest self-assessment, because card entry happens in Braintree-hosted iframes.
Braintree’s own documentation lists both Drop-in and Hosted Fields as SAQ A compliant. The reason is architectural. The card number, expiry and CVV are typed into iframe fields served from Braintree’s domain, so your server never sees them. It receives only a payment method nonce.
Braintree integration | Typical SAQ | Why |
|---|---|---|
Drop-in UI | SAQ A | The card form is hosted by Braintree |
Hosted Fields | SAQ A | Sensitive fields are hosted by Braintree on your page |
Direct card tokenisation | Not SAQ A (typically A-EP) | Your page collects card details before tokenising |
Server-side card handling | SAQ D | Card data touches your systems |
Drop-in is the fastest route and accepts CSS customisation. Hosted Fields lets you build your own form layout while Braintree still hosts the sensitive inputs. Either way, Braintree SAQ A eligibility depends on the integration being implemented as documented. For the wider picture, see our PCI compliance for e-commerce guide.
If your own code collects card details or can influence how they reach Braintree, you typically fall into SAQ A-EP instead of SAQ A. Confirm the final call with your acquirer or QSA.
Braintree states that direct card tokenization is not SAQ A compliant. When your page collects card details before tokenizing them, your website can affect payment security. That is the situation SAQ A-EP exists for. SAQ A-EP covers more ground: system configuration, vulnerability management, access control and external ASV scanning.
Custom integrations built years ago by a team without compliance input are the most common source of surprises. Review the actual data flow, not the intended one. If card numbers pass through or are stored on your own servers, you are in SAQ D territory. Most merchants move to Hosted Fields or Drop-in specifically to avoid it.
In most cases, yes. Under PCI DSS v4.x, Requirement 11.3.2 calls for quarterly external scans by an ASV, including for SAQ A merchants.
Older guidance, written for PCI DSS v3.2.1, said SAQ A merchants did not need ASV scans. That is outdated. SAQ A under v4.x includes Requirements 11.3.2 and 11.3.2.1, added because attackers target the merchant webpages that redirect to or embed a payment form. The PCI SSC addresses this in its FAQ 1604.
A Braintree ASV scan has to cover your public checkout site, not Braintree’s infrastructure. The requirement asks for:
• An external scan at least once every three months.
• A scan performed by a PCI SSC-approved scanning vendor, not a generic scanner.
• Findings fixed and a passing result, with rescans if needed.
• A scan after any significant change (Requirement 11.3.2.1).
Keep every passing report with your SAQ evidence. Your acquirer or QSA may ask for them. Skipping required scans is a compliance finding and can lead to acquirer fees or tighter conditions on your account. Read the full rules in our ASV scan requirements, SAQ A vs SAQ D scan requirements and PCI DSS 11.3.2 explained guides, and see how often to scan.
See transparent ASV scan pricing so you can budget your quarterly compliance cycle.
Hosted Fields keeps card entry out of your environment, but you must keep your checkout page clean of scripts that could intercept or tamper with the payment form.
Hosted Fields renders each sensitive field in its own iframe, isolated from your page’s JavaScript. Even if a malicious script ran on your page, the browser’s iframe boundary prevents it from reading what the customer types into those fields. It does not stop a script from changing the page around them.
Eligibility is not set-and-forget. Review the third-party scripts on your checkout page regularly, including analytics, marketing tags and plugins. A strict Content Security Policy is a sensible control. Requirements 6.4.3 and 11.6.1 deal with payment page scripts, and an ASV scan does not cover them. Treat scanning and script controls as two separate jobs. We explain both in PCI 6.4.3 and 11.6.1 and ASV scans.
Also check that no server-rendered component touches payment data. If your server handles raw card information before or after Braintree, your eligibility can be lost even with Hosted Fields in place.
Identify your integration, confirm your SAQ with your acquirer, secure your checkout page, book an ASV scan, then fix, rescan and file the evidence.
1. Identify your integration. Drop-in, Hosted Fields, direct tokenisation or server-side card handling.
2. Confirm your SAQ with your acquirer, using the current version of the form.
3. Check the checkout page. No card inputs served from your own domain, and a reviewed list of loaded scripts.
4. Book an ASV scan covering your public checkout site and any externally facing systems in scope. Not sure it applies? Read, do I need PCI ASV scanning?
5. Fix, rescan and file. Remediate findings, get a passing report and store it with your SAQ and Attestation of Compliance. If a scan fails, see what to do after an ASV scan fails.
Keep this file together each year. It becomes your Braintree PCI compliance evidence pack for your acquirer.
Braintree PCI compliance comes down to one question: what does your checkout actually do with card data? Drop-in UI and Hosted Fields support SAQ A, direct tokenization usually points to SAQ A-EP, and raw card handling means SAQ D. Under PCI DSS v4.x, quarterly ASV scans apply across these SAQ types, and Braintree does not run them for you.
Build your annual validation around the architecture you have deployed, not the one you assume. Confirm the details with your acquirer, scan on a quarterly cycle, and keep the reports.
Walk through every SAQ type and match it to your payment flow in minutes.
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.