Short answer: Stripe holds Level 1 PCI service provider certification, but your business remains responsible for PCI validation. Choosing Checkout, hosted fields, or an official Stripe SDK minimizes your Self-Assessment Questionnaire, while handling card data on your own servers pushes you toward the far more demanding SAQ D. Either way, you still need to pass quarterly ASV scans and keep your own network controls current.
TL;DR:
- Using Stripe's hosted solutions like Checkout or Elements reduces PCI scope and simplifies SAQ requirements, if your server never receives raw card data.
- Choosing a full server-side API process or bundling Stripe.js yourself increases scope to SAQ D, requiring more extensive validation and network controls.
- Maintaining quarterly ASV scans, enforcing TLS 1.2 or higher, and monitoring for script tampering are mandatory controls, regardless of Stripe's PCI certification.
- Loading Stripe.js directly from js.stripe.com and avoiding self-hosted scripts is critical to stay within SAQ A-EP scope and prevent scope expansion.
- Automating evidence collection, regular rescans, and appointing a compliance owner help sustain low-scope integration over time.
Table of Contents
- How Stripe helps and the limits of that coverage
- Which SAQ applies to your Stripe integration?
- Merchant responsibilities that remain under PCI DSS
- Practical checklist for developers and security teams
- Common pitfalls that expand your PCI scope
- How automation shortens your SAQ and AOC cycles
- Does PCI compliance slow down transactions or checkout?
- Why you still need a compliance owner, not just a Stripe integration
- Skypher: automate questionnaire responses and centralize evidence
- FAQ
- Sources
How Stripe helps and the limits of that coverage
Stripe is certified annually as a PCI Level 1 Service Provider, the highest tier the PCI Security Standards Council recognizes. That certification covers Stripe's own infrastructure, including the Card Data Vault and the integration code Stripe maintains. When you route card entry through Stripe's hosted surfaces, cardholder data gets tokenized before it ever reaches your servers, and tokenization replaces the primary account number with a non-sensitive identifier that carries far less risk if it leaks.
That coverage has a boundary, though, and it sits exactly where your infrastructure begins. Stripe's certification does not extend to:
- Your own servers, databases, and admin dashboards, which stay fully in your compliance scope.
- Any code served from your domain, including the page that embeds Stripe's payment fields.
- Third-party scripts running alongside your checkout flow, even ones you did not write yourself.
- Your network security, patching cadence, and access control policies, all of which Stripe has no visibility into.
Put simply, Stripe reduces how much cardholder data touches your systems, but it does not make your systems disappear from the audit. Understanding where Stripe's certification ends and your own scope begins is the first step toward choosing the right integration, which is exactly what determines your SAQ type. For more background on what PCI certification actually guarantees, our earlier look at PCI compliance certifications walks through the distinction between a provider's certification and a merchant's own obligations.
Which SAQ applies to your Stripe integration?
The Self-Assessment Questionnaire you file depends almost entirely on how your integration touches cardholder data, not on which Stripe product you use in general. Integration method dictates which SAQ applies, and the mapping is fairly deterministic once you know what to check.
- SAQ A applies when you redirect customers to Stripe Checkout or a fully hosted payment page, so card fields never render on your own domain.
- SAQ A-EP applies when you use Stripe.js or Elements embedded directly on a page you control, since your domain still hosts the surrounding payment logic even though Stripe captures the actual card number.
- SAQ D applies when your server receives, processes, or stores raw card numbers, typically through direct API calls that pass PANs through your own backend.
- SAQ C-VT applies to manual, keyed-in transactions through a virtual terminal, common for phone or mail orders.
- SAQ B-IP or SAQ C typically applies to Stripe Terminal and other in-person point-of-sale setups, depending on how the hardware connects to your network.
To confirm which one fits your setup, run a few concrete checks rather than guessing from the product name. Ask whether your server ever receives a raw PAN in a request body or log file. Check whether Stripe.js loads live from js.stripe.com or whether someone has bundled or self-hosted a copy, which changes the scope assumptions baked into SAQ A-EP. Look for any server-side proxying or redirect logic that touches payment data before handing it to Stripe. Under PCI DSS v4.0.1, the distinction between these SAQ types has become more rigid, and even an outsourced payment method can trigger a broader scope if your pages or server logic interact with the payment flow more than intended. When in doubt, Stripe's own PCI Dashboard analyzes your integration and suggests the applicable SAQ, with prefilled fields for eligible merchants, which is worth confirming against your acquirer's expectations before you file.
Merchant responsibilities that remain under PCI DSS
Even with Stripe handling the sensitive parts of a transaction, a list of controls stays firmly on your side of the line, and auditors check every one of them regardless of how little cardholder data you touch directly.
- Quarterly ASV scans of every public-facing IP address, checking for open ports, outdated TLS, known CVEs, and DNS misconfigurations.
- TLS 1.2 or higher enforced across all customer-facing domains, with unused ports disabled and server software patched on a predictable schedule.
- Logging and monitoring with defined retention periods, paired with least-privilege access controls on admin panels and payment dashboards.
- Penetration testing for merchants filing SAQ D or operating as a service provider, which generally needs to be budgeted as an annual line item rather than a one-time cost.
ASV scans deserve particular attention because they are automated, external, and unforgiving of drift. They typically catch deprecated TLS versions, exposed administrative ports, and server software running known vulnerabilities, and a failed scan blocks your attestation until you remediate and rescan. Logging and access control sound less glamorous, but weak admin access is one of the fastest ways to turn a low-scope Stripe integration into a high-risk one, since anyone with dashboard access can effectively see transaction metadata even when they never touch a raw card number.
Pro Tip: Run your own ASV scan a week before your official one so you have time to fix TLS and patching issues without missing your compliance deadline.
Our practical guide to PCI Compliance Reports on Compliance goes deeper into what larger merchants should expect when these controls get formally audited.
Practical checklist for developers and security teams
Reducing PCI scope with Stripe is mostly a sequence of upfront decisions, followed by a handful of recurring habits that keep your attestation current instead of becoming a fire drill every renewal cycle.
- Choose the lowest-scope integration that still meets your product needs, favoring Checkout, Elements, or an official mobile SDK over a custom server-side flow.
- Load Stripe.js directly from js.stripe.com rather than bundling or self-hosting it, since self-hosting breaks the scope assumptions that SAQ A and A-EP rely on.
- Implement a content security policy and script integrity checks on every page that touches payment data.
- Maintain a script inventory and monitor payment pages regularly, which directly addresses the PCI DSS v4.0.1 requirements for tamper detection and e-skimming defense.
- Schedule quarterly ASV scans, document every remediation, and keep your SAQ and Attestation of Compliance artifacts current rather than regenerating them under deadline pressure.
- Write a short incident response runbook, including who hands results to your acquiring bank or QSA when a scan fails or an incident occurs.
Under PCI DSS v4.0.1, guidance calls for script inventory and tamper detection monitored at least weekly, or at a frequency set by your own risk analysis, specifically to catch e-skimming attempts before they reach customers. Treating that monitoring as a recurring calendar item, rather than a pre-audit scramble, is what actually keeps a Stripe integration low-scope over time. Our SaaS cybersecurity checklist covers several of these controls in more operational detail if you are building this process from scratch.
Common pitfalls that expand your PCI scope
A handful of mistakes show up repeatedly in Stripe integrations, and most of them trace back to a small architectural decision made early and never revisited.
- Third-party scripts running on checkout pages without inventory or monitoring, which is exactly the e-skimming risk PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 target.
- Forgotten staging environments or admin endpoints left on old IP addresses, which fail ASV scans because nobody remembers they exist, let alone patches them.
- Self-hosting or bundling Stripe.js instead of loading it live, which quietly moves you out of SAQ A-EP eligibility without anyone noticing until an audit flags it.
- TLS misconfiguration, expired certificates, or weak cipher suites, all of which are common and entirely preventable ASV scan failures.
Fixing this is rarely complicated once identified: audit your DNS and cloud assets for forgotten endpoints, confirm Stripe.js loads from its canonical source, and put certificate renewal on an automated schedule instead of a manual reminder. For a construction-industry perspective on holding every vendor to the same security bar, our partner content on what to demand from every vendor makes a similar point about shared responsibility that applies just as well to payment integrations.
How automation shortens your SAQ and AOC cycles
Filing an accurate SAQ and assembling the evidence behind it is usually the slowest part of the process, not the technical integration work itself. Automating the questionnaire and evidence side cuts down on repetitive copy-paste work and keeps your supporting documentation in one place instead of scattered across inboxes and shared drives.
- Centralizing evidence from Confluence, Notion, Google Drive, and SharePoint means your security team is not hunting for the latest version of a network diagram during a scan window.
- Automated parsing of questionnaire formats speeds up response generation, though this is worth validating against your own document types during vendor evaluation rather than assuming universal coverage.
- A versioned audit trail matters as much as the speed gain, since auditors want to see when evidence changed and who approved it.
Pro Tip: Keep a subject matter expert reviewing every automated answer before submission. Automation speeds up drafting, but sign-off still belongs to a person who understands the control.
Our guide on automating PCI questionnaires with SME sign-off covers this balance in more detail for smaller teams juggling compliance alongside everything else.
Does PCI compliance slow down transactions or checkout?
Properly implemented, PCI compliance measures add negligible friction to the actual payment flow a customer experiences. Hosted fields and tokenization happen in milliseconds as part of the same request cycle a card payment already requires, so customers checking out through Stripe Checkout or Elements notice no meaningful delay compared to a non-compliant flow.
Where compliance can affect experience is further upstream, in decisions like whether to add extra verification steps or redirect flows for fraud prevention, which are separate from PCI DSS itself. A well-scoped integration, where Stripe handles tokenization and your team maintains TLS and monitoring in the background, keeps checkout fast while the compliance work happens invisibly, on servers and scan schedules the customer never sees. The tradeoff merchants actually feel is internal: lower-scope integrations mean less engineering time spent on custom payment handling, which is time that goes back into product work instead.
Why you still need a compliance owner, not just a Stripe integration
Choosing Checkout or Elements over a custom server-side flow is the single highest-leverage decision you make for PCI scope, but it is not a substitute for someone who owns the calendar. ASV scans, SAQ renewals, and script monitoring all run on fixed cycles, and treating them as a sprint before an audit rather than a standing process is where most compliance programs quietly fail. Automation can keep evidence fresh year-round instead of stale until deadline week, but only if someone is accountable for checking it.
— Gaspard
Skypher: automate questionnaire responses and centralize evidence
Filing SAQs and responding to security questionnaires both come down to the same underlying problem: pulling consistent, current evidence from wherever it lives and presenting it clearly to whoever is asking. Our Questionnaire Automation Tool was built to shorten that work, parsing a wide range of document formats and populating answers from a knowledge base that stays synced with the evidence your team already maintains.
- Integration with repositories like Confluence, Notion, Google Drive, and SharePoint can help ensure evidence does not need to be re-collected for every questionnaire.
- A customizable Trust Center lets you share your security posture directly with acquirers, auditors, and prospective customers without a back-and-forth email thread.
- Real-time collaboration features enable security and sales teams to work on the same questionnaire simultaneously rather than passing documents around.
If SAQ and AOC cycles are eating more engineering and security time than they should, visiting our Trust Center page is a reasonable next step to see how a centralized evidence base fits into your existing workflow.
FAQ
Is Stripe PCI compliant?
Yes, Stripe is certified as a PCI Level 1 Service Provider, the highest certification level the PCI Security Standards Council issues. That certification covers Stripe's infrastructure and hosted payment surfaces, but it does not extend to your own servers, dashboards, or domain-hosted code.
Is PCI compliance legally required?
PCI DSS is not a government law, but it is a contractual requirement enforced by card networks and acquiring banks as a condition of accepting card payments. Failing to maintain compliance can result in fines, increased transaction fees, or loss of card processing privileges from your acquirer.
Do I need to be PCI compliant if I use a payment gateway?
Yes, using a payment gateway reduces your scope but does not eliminate your obligation to validate compliance. Your integration method determines which SAQ you file, ranging from the lighter SAQ A for hosted redirects to the more demanding SAQ D if your servers handle raw card data directly.
Do I need to be PCI compliant if I process payments through a third-party processor?
Yes, even when a third-party processor like PayPal or Stripe handles the sensitive card data, your business still needs to complete the applicable Self-Assessment Questionnaire and file an Attestation of Compliance with your acquiring bank. Stripe itself frames this clearly: it acts as a security partner that reduces complexity, but the AOC remains the merchant's responsibility.