Is Stripe PCI compliant? Yes. Here is what that leaves you

Stripe's PCI status, and why it is not yours

Stripe is a service provider under PCI DSS, and it publishes its own status in plain terms. Its integration guide says Stripe “is certified annually by an independent PCI Qualified Security Assessor (QSA) as a PCI Level 1 Service Provider meeting all PCI requirements.” The very next line is about you.

Both say the same thing from different ends. Stripe's audit, in its words, “includes both the Stripe Card Data Vault (CDV) and the secure software development of our integration code.” Your website, your staff, your terminals and your paperwork are yours, and each year a small merchant usually signs a Self-Assessment Questionnaire and its Attestation of Compliance for them. Stripe calls PCI compliance “a shared responsibility,” and the share that lands on you depends on how cards reach Stripe.

Stripe's proof, for your records

PCI DSS asks you to keep a list of every service provider that card data is shared with, or that could affect its security (12.8.1), to check each one's compliance “at least once every 12 months” (12.8.4), and to record “which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared” (12.8.5). Stripe's FAQ says where the papers are: “You can verify at Visa's registry and download the AoC from your dashboard.” Its Responsibility Matrix “maps every PCI requirement to whether Stripe, you, or both are responsible — and it varies by integration type.”

Find your Stripe integration

Your SAQ follows how card data moves, not the name on your merchant statement. Stripe publishes a table that maps each of its integrations to an SAQ, and says that if you use more than one, “you must illustrate compliance for them separately.” Pick each way you take cards and read Stripe's answer next to the Council's test.

Checkout and Elements: how you stay on SAQ A

That is why Stripe maps both to SAQ A, the shortest form. The Council's eligibility test is about your page, not about Stripe: “All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor” and “The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” The second line arrived in January 2025, when the Council removed “PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1” from SAQ A and added that confirmation. The January 2025 SAQ A took effect on 31 March 2025.

So the card fields can be pure Stripe and you can still fail the test: a page whose own scripts could be swapped by an attacker is the thing that second criterion asks you to rule out. Keep the checkout page lean, and know every script on it.

That is 27 requirements, not zero, and scans are among them. SAQ A for v4.x includes Requirements 11.3.2 and 11.3.2.1 (external vulnerability scans) for merchants whose pages redirect to, or embed, a processor's payment page. Stripe's own level table tells its Level 3 and Level 4 users they “must also complete quarterly network scans by an Approved Scanning Vendor (ASV),” and its FAQ is clear about who runs them: “No. If you need ASV scans, engage a PCI-approved vendor.” The results stay with you; they “don’t need to be submitted to Stripe unless requested.”

When Stripe puts you on SAQ A-EP or SAQ D

The step up comes from your code, not from Stripe. If your own page builds the card form, the Council's test points to SAQ A-EP, and Stripe agrees: Stripe.js v2 on a form you host means “completing the SAQ A-EP annually.” If card numbers pass through your server on their way to Stripe's API, Stripe puts you on SAQ D, “the most demanding of the SAQs.”

Stripe's own figure for the far end: a business handling card data directly “might be required to meet more than 300 security controls in PCI DSS.” That is Stripe's count, not the Council's; the Council's is simply “all” for SAQ D. Stripe also gates the door. It switches on raw card data APIs only after you send its support a written description of the systems that handle card data and a document such as “A current, complete PCI DSS Self-assessment Questionnaire (SAQ) D.”

Stripe Terminal: SAQ C, or SAQ P2PE if you sign up

Stripe's readers encrypt the card the moment it is presented and send it to Stripe, and Stripe says your point-of-sale app gets “only” a payment token, “never sensitive card information.” That default is end-to-end encryption. SAQ C is the Council's form for “Merchants with payment application systems connected to the Internet, no electronic account data storage.”

There is a lighter route. The Council's list of validated P2PE solutions carries “Stripe Terminal P2PE” (Stripe, Inc., P2PE v3.1), and Stripe says Level 2 to 4 users “signed up for Stripe Terminal P2PE” get a pre-filled SAQ P2PE in the Dashboard. SAQ P2PE is for “Merchants using only a validated, PCI-listed Point-to-Point Encryption (P2PE) solution. No access to clear-text account data and no electronic account data storage.” Stripe sells it as “an optional, paid feature,” so ask Stripe's sales team what it costs you.

Source: Stripe: Stripe Terminal encryption (E2EE and P2PE), read on 2026-10-22

Phone orders and the Stripe Dashboard

Stripe's guide gives phone and mail orders their own section. A pay connector, where card data is collected by “a PCI-compliant third-party solution” and flows straight into Stripe, maps to SAQ A, as long as “the user should not have access to the card data.” Keying the card into the Stripe Dashboard maps to SAQ C-VT, and Stripe wants that “for limited use cases, not recurring.” Storing card data yourself means SAQ D.

SAQ C-VT has conditions of its own: one transaction at a time, typed on “an isolated computing device and a securely connected web browser,” with no card reader attached to that computer. And whatever route the call takes, the security code never goes on file: “The card verification code is not stored upon completion of the authorization process.”

What stays yours with any Stripe setup

Pick the lightest integration and Stripe still cannot sign for you. Stripe gives you the papers to check it, and the Council's 12.8 requirements say what to do with them. The rest is your own business.

Stripe also tells you what you may keep from its replies. Its security guide says the card type, “the last four digits of the card, and the expiration date” it returns “isn’t subject to PCI compliance, so you can store any of these properties in your database.” That is Stripe's statement about its own data. A full card number or a security code in your order notes is a different matter, and the rules for storing card information cover it.

Stripe and PCI on one receipt