Binoy Koonammavu
PCI compliance for Stripe merchants is often misunderstood. You integrated Stripe, enabled Radar, and assumed your compliance box was ticked. Then your acquiring bank sent a questionnaire asking for your ASV scan certificate, and you realised Stripe’s shared responsibility model left a significant gap on your side of the fence. You’re not alone. This is the most common compliance blind spot among Stripe merchants.
Shared responsibility model: the division of PCI DSS obligations between Stripe (its own infrastructure) and you (everything else: servers, DNS, application layer, open ports).
SAQ (Self-Assessment Questionnaire): the PCI DSS compliance form you complete; which version applies depends on how Stripe is integrated into your checkout.
ASV (Approved Scanning Vendor) scan: the mandatory quarterly external vulnerability scan of your public-facing IPs, required under Requirement 11.3.2 regardless of your payment processor.
CDE (Cardholder Data Environment): the systems and network segments that store, process, or transmit cardholder data, or provide a path to systems that do.
PCI DSS 4.0.1: the current active version of the Payment Card Industry Data Security Standard as of 2026, organized into 12 Requirements.
No, Stripe does not make you PCI compliant. It reduces your PCI DSS 4.0.1 scope by handling cardholder data within its iframe or hosted fields, but you're still responsible for your SAQ, your quarterly ASV scan, and your own network security controls.
Does Stripe make you PCI compliant? No. Stripe reduces your PCI DSS 4.0.1 scope by handling cardholder data within its iframe or hosted fields, but it does not make you fully compliant. Merchants are still responsible for completing the correct SAQ, passing an annual ASV scan of internet-facing IP addresses, and maintaining their own network security controls.
Start your scan with Secusy ASV from $80/year.
PCI DSS 4.0.1 doesn't exempt you from using a third-party processor. Stripe owns the controls within its own infrastructure; you own everything else: servers, DNS, the application layer, and open ports.
PCI DSS 4.0.1, the current active standard as of 2026, does not exempt you because you use a third-party payment processor. It defines a shared responsibility model. Stripe owns the controls within its infrastructure. You own everything else: your servers, your DNS, your application layer, and your open ports.
The standard organises compliance into 12 Requirements. Stripe’s tokenisation and hosted payment fields help you satisfy parts of Requirements 3 and 4 (data storage and transmission encryption). Requirements 1, 2, 6, 10, and 11, covering network security, vulnerability management, logging, and external scanning, remain entirely your responsibility.
The key distinction: Stripe processes cardholder data so it never touches your servers in plaintext. That’s meaningful scope reduction. It is not scope elimination.
Your SAQ type depends on your integration method: SAQ A for redirect-based Checkout, SAQ A-EP for Stripe.js/Elements, SAQ D for server-side Direct API, and SAQ B-IP or C for Stripe Terminal, and all of them require an ASV scan if public-facing IPs exist.
Which Self-Assessment Questionnaire (SAQ) applies to you depends entirely on how Stripe is integrated into your checkout flow.
Integration Method | SAQ Type | ASV Scan Required? | Approx. Question Count |
|---|---|---|---|
Stripe Checkout (redirect) | SAQ A | Yes (if public-facing IPs exist) | ~22 |
Stripe.js / Elements (iframe) | SAQ A-EP | Yes | ~191 |
Stripe Direct API (server-side) | SAQ D | Yes | ~329 |
Stripe Terminal (in-person) | SAQ B-IP or C | Yes | ~82–139 |
Critical nuance for 2026: Under PCI DSS 4.0.1, SAQ A-EP has been brought closer in scope to SAQ D. If you use Stripe.js with any server-side redirect logic or custom JavaScript that touches your payment page, your acquirer may escalate you to SAQ D. Confirm with your Qualified Security Assessor (QSA) before self-assessing.
An ASV scan is a mandatory quarterly external vulnerability scan of your public-facing IPs; it checks open ports, TLS configuration, known CVEs, and DNS misconfigurations, but it does not test Stripe's own infrastructure or your application logic.
An Approved Scanning Vendor (ASV) scan is a mandatory quarterly requirement under PCI DSS Requirement 11.3.2 for any merchant with internet-facing IP addresses in scope. It is an external vulnerability scan, performed from outside your network perimeter, that checks for exploitable weaknesses on your public attack surface.
What ASV scans test:
What ASV scans do not test:
A common hidden failure point: merchants who migrated to cloud hosting (AWS, GCP, Azure) often have legacy load balancer endpoints or staging environments still exposed on old IPs. These get flagged on ASV scans because the merchant forgot to remove them from scope.
Have your pass certificate ready before your next SAQ submission.
Stripe owns cardholder data storage and encryption in transit; you own network security, vulnerability management, external ASV scanning, and your own incident response plan.
Here’s the practical split, mapped to PCI DSS 4.0.1 requirement families:
PCI DSS Requirement Area | Stripe’s Responsibility | Merchant’s Responsibility |
|---|---|---|
Cardholder data storage (Req. 3) | ✅ Stripe tokenises and stores card data | ❌ Do not store PANs locally |
Encryption in transit (Req. 4) | ✅ TLS 1.2+ enforced by Stripe | ⚠️ Your domain must also enforce TLS 1.2+ |
Network security controls (Req. 1) | ❌ Not applicable | ✅ You manage firewalls, WAF, security groups |
Vulnerability management (Req. 6) | ❌ Not applicable | ✅ Patch your servers, CMS, dependencies |
External ASV scanning (Req. 11.3.2) | ❌ Not applicable | ✅ Quarterly scans of your public IPs |
Access control (Req. 7–8) | ⚠️ Stripe dashboard access controls | ✅ Your internal systems, admin panels |
Logging & monitoring (Req. 10) | ⚠️ Stripe provides event logs | ✅ You manage your server/application logs |
Incident response plan (Req. 12) | ❌ Not applicable | ✅ You maintain your own IR policy |
Confirm your integration type and scope, lock down TLS and open ports, patch your stack, then complete your SAQ and pass your quarterly ASV scan before submitting attestation.
Use this before submitting your SAQ to your acquiring bank:
Scope & Integration
Technical Controls
Compliance Documentation
Secusy ASV is a PCI SSC-listed vendor that runs the scan in minutes, not weeks. Add your IPs, get a pass certificate or remediation report within 24 hours, and rescan for free.
Running a compliant ASV scan doesn’t require a six-week engagement or a $2,000 invoice. Secusy ASV is a PCI SSC-listed Approved Scanning Vendor built specifically for merchants who need to pass, not wait.
The Secusy workflow:
Pricing transparent, no hidden fees:
IPs Covered | Annual Price |
|---|---|
1 – 5 IPs | $80 – $350/year |
6 – 15 IPs | $420 – $900/year |
16 – 25 IPs | $928 – 1350/year |
25+ IPs |
All prices in USD. Quarterly scans included. Re-scans after remediation included. No per-scan overage fees. For most Stripe merchants running on a single application server or load balancer, the Starter plan at $80/year covers the full requirement. Multi-region deployments or merchants with separate staging environments in scope typically fit the Growth plan.
Stripe handles the hardest part of PCI compliance, keeping card numbers off your servers, but it was never designed to cover Requirements 1, 2, 6, 10, and 11 on your behalf. Confirm your SAQ type, lock down TLS and open ports, and treat your quarterly ASV scan as a fixed part of your operating calendar, not an afterthought. Do that, and PCI compliance for Stripe merchants stops being a surprise questionnaire and becomes a routine checkbox.
From $80/year for a single IP, you get a PCI SSC-listed scan, a pass certificate within 24 hours, and free re-scans if remediation is needed.
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.