You almost never need full PCI DSS at MVP stage. If your app hands card data straight to a processor like Stripe and never stores, transmits, or even touches the raw card number, you qualify for SAQ-A — the lightest self-assessment tier, roughly $300-$5,000 a year in overhead. Full Level 1 DSS scope, the one with a paid on-site QSA assessment across 300+ controls, runs $50,000-$250,000+ a year and only applies once you're processing millions of transactions annually.
Founders hear "PCI compliance" and picture the second one — an auditor, a stack of controls, a budget line that kills the MVP before it ships. Almost nobody building an MVP needs that scope. The move that gets you out of it isn't a compliance program. It's an architecture decision: never let raw card data touch your servers. Route it straight to Stripe (or Braintree, or Adyen) with hosted fields or a redirect checkout, and you inherit the lightest tier the PCI Security Standards Council offers. This note is the tiered breakdown — what triggers each one, and what it actually costs.
Does your MVP need PCI DSS compliance at all?
Every business that accepts card payments has to attest to PCI DSS in some form — there's no "opt out" for a startup. The question isn't whether you're in scope, it's how much scope you carry. Three questions set the tier:
- Does your server ever see, store, or transmit an unencrypted card number (PAN)? If no — because a hosted payment page or a tokenizing SDK handles it before it reaches you — you're in the smallest tier.
- Do you build a custom card form in your own UI, even if the field values get tokenized client-side before your backend sees them (Stripe Elements, for example)? That's a step up in scope, not the smallest tier, because your web app's security now matters.
- How many card transactions do you process a year? Under roughly 6 million puts you in Level 2-4 (self-assessed); over that, you're Level 1 and a QSA has to sign off in person.
Almost every MVP answers "no, no, and a rounding error" — which is exactly the profile SAQ-A was built for.
What does PCI compliance cost by tier?
| Tier | What triggers it | What it covers | Rough annual cost |
|---|---|---|---|
| SAQ-A | Card data never touches your servers — hosted checkout or full redirect to a validated processor (Stripe Checkout, Stripe Payment Links) | ~22 controls, mostly about not storing card data and keeping your processor's integration intact | $300-$5,000 |
| SAQ-A-EP | You build a custom payment form with a processor's JS SDK (Stripe Elements) that tokenizes before submission, but the form lives on your page | ~140 controls — adds web app security, quarterly external vulnerability scans (ASV), and change-control discipline | $2,000-$10,000 |
| Full PCI DSS (Level 1) | You process a high volume of transactions (roughly 6M+/year) or you store, process, or transmit raw card data yourself | 300+ controls, a paid on-site Qualified Security Assessor (QSA) review, penetration testing, and a formal Report on Compliance | $50,000-$250,000+, and higher still for the largest merchants running full annual assessments |
Costs as of August 2026, self-reported by processors and compliance vendors — actual figures vary by industry vertical, transaction volume, and how much of the assessment you automate versus pay a QSA to do manually.
The gap between the top row and the bottom row is close to two orders of magnitude, and almost none of it is negotiable engineering — it's scope. The cheapest compliance strategy is the one that never lets your servers become "in scope" in the first place.
Does using Stripe make you PCI compliant?
No — Stripe is PCI DSS Level 1 compliant itself, which reduces your scope, but you still have to complete and submit your own SAQ every year. What Stripe (or any validated processor) buys you is the tier, not the exemption. If you route every card field through Stripe Checkout or a redirect flow, you land on SAQ-A. If you build your own card form using Stripe Elements, you're on SAQ-A-EP — still self-assessed, no QSA required, but a longer questionnaire and a quarterly vulnerability scan. Either way, the merchant of record — you — signs the attestation, not the processor.
When do you actually need full PCI DSS?
Three things push an MVP into Level 1 territory, and none of them are typical at launch:
- You store or process raw card numbers on your own infrastructure — usually because a legacy integration or an in-house payment feature bypasses the processor's tokenization.
- Your transaction volume crosses the Level 1 threshold — public card-network guidance puts this around 6 million transactions a year, a scale most MVPs don't hit before a Series A.
- A card network or acquiring bank asks for it directly, usually after a breach elsewhere in your category makes acquirers more conservative about who they underwrite.
If none of the three applies, the correct move mirrors the timing test we use for SOC 2: build the architecture that keeps you in the cheapest tier from day one — hosted checkout, no card data in your logs, no card data in your database — instead of retrofitting it after a processor flags your integration during onboarding.
The founders who overpay treat PCI as a compliance program to budget for. The founders who don't treat it as one architecture call, made before the first payment field ships: let Stripe hold the card number, and let the smallest questionnaire hold the rest.
Written 2026-08-28 by Naman Barkiya.