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.
PCI DSS SAQ types decide far more than which form you fill out once a year. The type you qualify for dictates your compliance workload, your vulnerability management obligations, and, critically, whether an external ASV scan is part of your annual requirements at all.
If you’ve ever opened your acquirer’s compliance portal and been asked to choose between SAQ A, A-EP, B, B-IP, C, C-VT, D, and P2PE, the letters can feel arbitrary. They aren’t. Each one maps to a specific way of accepting payments and a specific degree of exposure to cardholder data. Most merchants don’t get to choose freely; your payment channel and your technology stack point you toward one category, defined by the PCI Security Standards Council (PCI SSC).
The problem is that many e-commerce businesses complete the wrong SAQ entirely or assume they qualify for a lighter-touch category when they don’t. A merchant who believes they fall under SAQ A but actually meets the criteria for SAQ A-EP is very likely skipping a mandatory ASV scan and skipping required controls along with it.
This guide breaks down SAQ A vs SAQ A-EP vs SAQ D, the three types that account for the vast majority of merchant confusion, and gives you a clear framework for knowing when an ASV scan is required, what scope it actually covers, and how to get your PCI self-assessment questionnaire right the first time.
PCI DSS (Payment Card Industry Data Security Standard): The security standard every business that stores, processes, or transmits cardholder data must follow.
SAQ (Self-Assessment Questionnaire): A validation tool published by the PCI Security Standards Council that lets eligible merchants and service providers self-assess PCI DSS compliance instead of undergoing a full on-site audit. There are nine SAQ types, each scoped to a different payment environment.
ASV (Approved Scanning Vendor): An organisation certified by the PCI SSC to run the external vulnerability scans required under PCI DSS Requirement 11.3.2 for in-scope environments. ASV scans must be run quarterly wherever they're required.
Cardholder Data Environment (CDE): The people, processes, and technology that store, process, or transmit cardholder data, or that connect to systems that do. The size of your CDE determines which PCI DSS requirements, including ASV scanning, apply to you.
PCI DSS SAQ types exist to scale compliance requirements to how a merchant actually accepts payments. The type you qualify for defines which controls apply to you and whether your environment is in scope for ASV scanning; get it wrong, and you either under-control a real risk or over-invest in work you don't legally need.
Your acquiring bank or payment processor assigns your SAQ based on your payment channel (e-commerce, phone, in-person) and how directly your systems touch raw card data. The less your own infrastructure is involved in the payment flow, the shorter your SAQ and the lighter your obligations, including scanning. The PCI SSC publishes eligibility criteria for each of the nine types; SAQ A, A-EP, and D cover the overwhelming majority of e-commerce and card-not-present merchants.
Get a free scope review from a PCI SSC-approved ASV before you file your self-assessment.
SAQ A applies to merchants who fully outsource payment processing with no involvement from their website in the payment flow and have no ASV scan requirement. SAQ A-EP applies when a merchant's website still delivers or controls part of the payment page, even through a third-party script, and requires quarterly ASV scans. SAQ D is the full-scope questionnaire for merchants and service providers who handle cardholder data directly and always requires quarterly ASV scans.
SAQ A was built for merchants whose website simply cannot be used as an attack vector against card data because it never touches the payment page's code or data. Typical SAQ A merchants:
If your checkout redirects entirely to your processor's domain, or the payment form is served as an iframe entirely from the processor's infrastructure, you may qualify for SAQ A, provided you meet every other eligibility criterion.
This is the category that trips up the most merchants, because it looks outsourced on the surface. SAQ A-EP applies when your own site delivers, loads, or controls any element of the payment experience, even if card data itself goes straight to a third-party processor. A common example: a JavaScript-based hosted payment form where the script is loaded from a payment service provider but referenced on your own page. If that page were compromised, an attacker could modify the script to skim card details as customers type them in.
This distinction has come under more scrutiny since PCI DSS v4.0 introduced explicit script-monitoring requirements (6.4.3 and 11.6.1) for exactly this setup, worth reading alongside our breakdown of PCI DSS v4.0 ASV scanning changes. Because your website is part of the payment experience in a way that could affect its security, it's in scope, and quarterly ASV scans are required to validate the external posture of those internet-facing systems.
SAQ D is the most comprehensive category, containing the full set of PCI DSS requirements. It applies to merchants and service providers who store, process, or transmit cardholder data directly, and to anyone who doesn't cleanly qualify for a shorter SAQ. Typical scenarios:
SAQ D is also the default fallback: if you can't confidently place yourself in a narrower category, your acquirer will typically require it, with quarterly ASV scans mandatory, no exceptions.
|
|
SAQ A
|
SAQ A-EP
|
SAQ D
|
|---|---|---|---|
|
Card data touches your systems?
|
No
|
No (but page influences payment flow)
|
Yes
|
|
Typical use case
|
Fully hosted checkout redirect
|
Iframe/direct-post checkout
|
Own gateway, stored data, or service provider
|
|
Approx. requirements to complete
|
~24
|
~200+
|
~300+ (full DSS)
|
|
Quarterly ASV scan required?
|
Generally no
|
Yes
|
Yes
|
|
Scan scope
|
N/A
|
Internet-facing systems affecting the payment page
|
Entire internet-facing perimeter of the CDE
|
PCI ASV scan scope covers every internet-facing IP address and domain associated with systems in your cardholder data environment: web servers, payment application servers, APIs that talk to your processor, and any external-facing component that could affect the security of cardholder data.
Many merchants assume that using a third-party processor automatically shrinks their scan scope to nothing. That assumption only holds if you actually qualify for SAQ A. For SAQ A-EP and SAQ D merchants, ASV scan requirements cover the external perimeter of the CDE: your public web server IPs and domains, your payment integration layer, processor-facing APIs, and any internet-accessible admin interfaces. It does not include internal-only systems or infrastructure that’s been formally segmented out and validated as out of scope; segmentation reduces scope, but only when it’s documented and maintained.
Any internet-facing system connected to your payment flow is an external attack surface that can be probed and exploited from outside your network. Quarterly ASV scans exist to find those vulnerabilities before attackers do. SAQ A merchants are exempt because, by definition, their internet-facing infrastructure can’t affect cardholder data. SAQ A-EP and SAQ D merchants aren’t exempt, because their systems genuinely are in scope.
The most consistent reason merchants fail an ASV scan isn’t a missing patch; it’s scope confusion. A staging server, a new API endpoint, or a CDN change added during the year gets left off the declared scan scope. Since ASV scans only assess whatever IPs and domains are actually submitted, an incomplete scope doesn’t just risk a failed scan; it risks a false pass, which is worse. Working with a scanning partner who validates your scope before every quarterly run, rather than just running the scan, is one of the most practical ways to keep your compliance record accurate. See our guide on how to choose an ASV vendor and what to look for.
Run your quarterly external vulnerability scan with Secusy ASV, simple onboarding, transparent pricing, PCI SSC-approved.
The SAQ type you need is determined by your payment acceptance method and how your systems interact with cardholder data; not by preference or by which questionnaire looks shortest.
Start with your payment channel: are you card-not-present (e-commerce), card-present (in-person), or both? The PCI SSC publishes eligibility criteria for each SAQ type, and working through them methodically, rather than guessing based on what “feels” outsourced, is the only reliable way to land on the right one.
For e-commerce merchants specifically, the deciding question is: what does your website actually do during the transaction? If your site displays a catalogue and redirects entirely to an external, processor-hosted payment page with zero involvement from your own code, you’re likely in SAQ A territory. If your site loads or controls any element of the payment experience, even a script the processor provides, you’re almost certainly in SAQ A-EP territory, ASV scan included. If you handle card data directly or operate as a service provider to other merchants, SAQ D is your most likely destination. If you’re still unsure after that, our page on whether you need PCI ASV scanning walks through the same decision from the scanning side.
Your acquiring bank has a real stake in your classification and may question a submitted SAQ that doesn’t match your business profile. If your setup involves a hybrid payment integration, subscription billing, or a multi-gateway configuration, a short consultation with a Qualified Security Assessor before you submit is almost always cheaper than remediation and re-assessment after a misclassification is caught.
Completing a PCI self-assessment questionnaire means working through a structured set of controls for your assigned SAQ type, attesting to your compliance status for each, and submitting the completed SAQ to your acquirer along with any required evidence, including passing ASV scan results where applicable.
SAQ A contains a relatively small set of controls scoped to a fully outsourced environment. SAQ D, by contrast, spans the complete PCI DSS requirement set across all twelve domains and requires substantive documentation and evidence. For merchants on SAQ A-EP or SAQ D, the quarterly scan cycle runs alongside the annual SAQ: you need passing results from a PCI SSC-approved ASV for all four quarters before your annual submission is considered complete. A failing scan that isn’t remediated and re-scanned within the compliance period is treated as a gap, regardless of how thorough the rest of your documentation is.
Three steps before you open the SAQ itself save the most rework later:
PCI DSS SAQ types aren’t bureaucratic labels; they’re a direct map of how close your systems sit to cardholder data, and that distance is what decides your ASV scanning obligation. SAQ A merchants are usually scan-exempt. SAQ A-EP and SAQ D merchants must run quarterly external vulnerability scans through an Approved Scanning Vendor, scoped to their internet-facing cardholder data environment. Getting the SAQ type right is the first step; getting the scan scope right is what keeps that compliance status valid quarter after quarter, and what protects your business, your customers, and your standing with your acquirer.
See transparent, no-surprise pricing for SAQ A-EP and SAQ D scan scopes before you commit.
SAQ A applies when your website has no role in the payment experience; everything is outsourced. SAQ A-EP applies when your website delivers or controls any part of the payment page, even via a third-party script, which means a compromise could expose card data. SAQ A-EP requires quarterly ASV scans; SAQ A generally doesn't.
Yes, if you restructure your payment flow to fully outsource processing and remove card data from your own systems, you can move to a shorter SAQ, but your acquirer must approve the change based on your actual environment.
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.