You're about to handle card data. Maybe you're embedding payments, maybe you're a marketplace splitting transactions, maybe you're a vertical SaaS adding a checkout. Either way, a payments partner or acquiring bank is going to run a security review before they let you move money. And that review will find exactly what you skipped.
The thing founders get wrong about PCI DSS is treating it as a certification you earn at the end. It isn't. It's a function of one architectural decision made at the start: where does the card number live. Get that decision right and your compliance surface is a short questionnaire. Get it wrong and you've signed up for a 12-requirement, 300-control audit with quarterly scans, annual penetration tests, and a six-figure ongoing cost — for a system that didn't need to touch a card number at all.
The decision that sets everything else
PCI DSS scope is defined by one question: does the cardholder data environment — the systems that store, process, or transmit the Primary Account Number — include your servers.
If a raw 16-digit PAN ever passes through your application code, sits in your database, or lands in your logs, every system connected to that path is in scope. Your API servers. Your database. Your background workers. Your log aggregator. The laptop of the engineer who can SSH into production. PCI doesn't care that you only stored the card "for a second." A second is enough. The whole network segment is in scope, and you're now defending it against the full standard.
The architecture that wins keeps the PAN out of your systems entirely. The card number goes from the customer's browser straight to your payment processor — Stripe, Adyen, Braintree — using a hosted field or client-side tokenization. The processor hands you back a token: a reference like tok_1Oq... that represents the card but is useless to an attacker. Your servers store the token. They never see the PAN.
Browser ──[card data over TLS]──> Processor (in scope, theirs)
│
└──[token only]──> Your API ──> Your DB (out of scope)
This is the difference between SAQ A and SAQ D, and that difference is the entire game.
SAQ levels, in plain terms
Self-Assessment Questionnaires are how PCI right-sizes the audit to your architecture. Pick the wrong architecture and you pick the wrong SAQ for you.
SAQ A is for merchants who have fully outsourced cardholder data handling. The PAN never touches your environment — it goes browser-to-processor via a hosted payment page or properly implemented tokenization fields. This is roughly 22 controls, most of them about vendor management and basic hygiene. A startup can complete it in a focused week.
SAQ A-EP is for e-commerce sites where the payment page is hosted by the processor but your site controls the page that loads it. More controls, because your front end is now in the attack path even if your back end never sees the PAN. Script integrity and your web server's security become relevant.
SAQ D is the full standard — about 300 controls. You land here the moment a raw PAN touches your systems. Quarterly ASV scans, annual penetration testing, file integrity monitoring, network segmentation evidence, formal key management, the works. For a Level 4 startup the realistic cost of standing up and maintaining SAQ D is $80k–$200k in the first year between tooling, a QSA, and engineering time — recurring after that.
The jump from SAQ A to SAQ D is the 10x. Same business, same transaction volume, an order of magnitude more compliance work — decided entirely by whether the PAN was allowed to touch your code.
Tokenization, and never storing PANs
Tokenization is the load-bearing pattern. The processor stores the real card in their vault and gives you a token that maps back to it on their side only. You charge the token. You refund the token. You save it for the next purchase. You never reconstitute the PAN.
The rule is absolute: do not store the PAN, do not log it, do not put it in an error message, do not let it ride along in a webhook payload you persist. The most common real-world breach of this rule is not a database column called card_number. It's a log line. An engineer adds logger.info(request.body) to debug a failed charge, the request body contains a card number, and now your log aggregator — Datadog, an S3 bucket, wherever — is in scope and holding cardholder data in plaintext. The whole logging pipeline just inherited the audit.
If you genuinely need to store the PAN — and almost no one building today does — you need a vault, format-preserving encryption, documented key management with split knowledge and dual control, and you're in SAQ D. The right answer for nearly every fintech startup is: you don't store it. The processor does.
Network segmentation
If any part of your environment is in scope, segmentation is how you keep the rest out of it. The principle is that the cardholder data environment should be the smallest possible island, firewalled off from everything that doesn't need to touch card data.
In practice this means the systems that handle the in-scope flow live in their own network segment — their own VPC or subnet, their own security groups, their own access controls — with explicit, logged, minimal connectivity to the rest of your infrastructure. Without segmentation, "in scope" means your entire AWS account. With segmentation, "in scope" means three services and a database in a walled-off subnet. The auditor scopes what's connected; segmentation controls what's connected.
The teams that skip this discover during the assessment that their analytics service, their internal admin tool, and their CI runner all have a network path to the cardholder data, and all three just entered the audit.
The 10x-scope failure modes
These are the patterns that quietly drag a clean architecture into SAQ D:
- The debug log. PAN in a log line. Covered above. The single most common scope expansion.
- The "temporary" storage. Saving the card number to a column to "retry later" instead of saving the token. The column is forever; the audit is forever.
- The proxy that sees too much. Routing the card through your own server to "add a field" before forwarding to the processor. Now the PAN transits your environment. Use the processor's client-side tokenization instead — let it skip your servers.
- The self-hosted payment form posting to your API. Collecting card fields on a form that submits to your back end, then forwarding. That's SAQ D. Use hosted fields that submit directly to the processor.
- The flat network. No segmentation, so one in-scope service pulls the entire account into the assessment.
- The webhook that carries card data. Persisting a processor webhook that includes PAN fragments beyond what's permitted.
Every one of these is cheap to avoid at design time and expensive to unwind after launch. Pulling a PAN back out of your logs, your database, and your backups after the fact is a forensic project, not a code change.
What fixed looks like
Card data goes browser-to-processor and never touches your code. You hold tokens. Your application database, your logs, and your background jobs contain nothing an attacker could use to charge a card. The in-scope footprint — if any — is a small, segmented island with logged, minimal connectivity to the rest of your stack. Your logging pipeline has a scrubbing layer that strips anything PAN-shaped before it leaves the application. Your SAQ is A, or A-EP, and your annual compliance cost is measured in weeks, not in a six-figure recurring line item.
When the payments partner runs their review, you hand them a clean architecture diagram showing the PAN never enters your boundary. The review is short because there's nothing to find.
See how we designed a payments flow to minimize scope from the first commit in the ClearVault engagement, where the cardholder data environment was a deliberately small island from day one.
This is for you if
You're a funded founder building a fintech, marketplace, or vertical SaaS product that moves money, and you're at the architecture stage — before a payments partner's security review forces the question. You want the smallest possible compliance surface, and you understand that means making the right call about where card data lives before you write the integration, not after.
This is part of a larger build engagement, typically $100k+, where the payment architecture is designed for minimal PCI scope as part of the product. It is not standalone PCI consulting and it is not a remediation of a system that already stores card data — that's a forensic project with a different shape.
It's not for you if your architecture is already live and already storing PANs. At that point the work is scope reduction and remediation, which starts with an audit of where card data has already spread.