PCI DSS for SaaS 
What You Actually Need to Handle Card Payments 

PCI DSS — the Payment Card Industry Data Security Standard — sounds like a heavyweight audit you need a consultant and a year to survive. For most SaaS companies, it isn't. The entire game is scope: the standard governs systems that store, process, or transmit cardholder data, so the winning move is to architect so that card data never touches your servers at all. Do that, and your PCI obligations collapse from hundreds of requirements to a short self-assessment questionnaire. Get it wrong — by letting card numbers flow through your backend to 'have control' — and you've voluntarily signed up for the full standard. Here's what actually applies, and how to keep your scope as small as possible.

The one principle: minimize scope

Everything in PCI DSS flows from a single question: does cardholder data touch this system? Any server, network, or service that stores, processes, or transmits a card number is 'in scope' and must meet the standard — and so is anything connected to it. The entire strategy, therefore, is to shrink that footprint to as close to zero as possible. The modern way to do that is to never let raw card data reach your infrastructure: the customer's card details go straight from their browser to a PCI-compliant payment provider (Stripe, Adyen, Braintree) via a hosted field, iframe, or redirect, and your backend only ever sees a token. If a card number never lands on your servers, those servers fall out of scope, and your compliance burden shrinks accordingly. This is the single most important architectural decision in payment handling — make it on day one.

The SAQ types — find the one you want to qualify for

• SAQ A: you fully outsource card handling — all payment data is entered into a third-party hosted page or iframe, and your systems never see or store it. This is the smallest, easiest questionnaire and the target most SaaS should architect toward.
• SAQ A-EP: you use a third-party processor but your website affects how payment data is collected (e.g. a JavaScript SDK on your own page rather than a fully hosted field). More requirements than SAQ A because your page is in the data path.
• SAQ D: you store, process, or transmit cardholder data directly. This is the big one — the full breadth of PCI DSS controls. Almost no SaaS should be here voluntarily.
• The lesson: which SAQ you fill out is an outcome of your architecture. Integrate so you qualify for SAQ A, and you've turned a major program into a checklist.

Merchant levels: how much scrutiny you face

Your transaction volume sets your 'merchant level,' which determines whether you self-assess or need an external audit. Roughly: Level 4 is the smallest merchants (up to ~20,000 e-commerce transactions a year), Levels 3 and 2 are mid-volume, and Level 1 is the largest (over ~6 million transactions a year), which requires an annual on-site assessment by a Qualified Security Assessor (QSA) and a Report on Compliance rather than a self-assessment. Most growth-stage SaaS sits at Level 4 or 3 and can self-assess with an SAQ — but exact thresholds vary by card brand, and a data breach can bump you to Level 1 regardless of volume. The practical takeaway: at your stage, self-assessment is almost certainly available to you, so the work is qualifying for the lightest SAQ, not bracing for a QSA.

What you still owe even with Stripe

• Validate every year. Even at SAQ A, you complete the self-assessment questionnaire annually and, for e-commerce, run quarterly external vulnerability scans (an ASV scan). Outsourcing collection doesn't outsource your obligation to attest.
• Protect the integrity of your payment page. SAQ A now expects controls against e-skimming/Magecart — script-integrity monitoring and a content security policy — because a compromised script on your checkout page can steal card data before it ever reaches the processor.
• Manage your service providers. Keep evidence that your payment processor and other in-scope vendors are themselves PCI compliant (their Attestation of Compliance), and track them like the sub-processors they are.
• Don't accidentally pull data back into scope. Logging full card numbers, accepting card details over email or a support ticket, or storing a PAN 'temporarily' in a database column instantly drags those systems into full PCI scope. The discipline is keeping card data out, permanently.

The mistakes that blow up your scope

The recurring failures are self-inflicted. A support workflow where customers read card numbers to an agent who types them in puts your phone system, your CRM, and your staff in scope. A 'temporary' PAN stored to retry a failed charge brings your database under SAQ D. Verbose request logging that captures a card field ships cardholder data into your log pipeline — and now your logging backend is in scope too. Each of these takes a company that could have filed SAQ A and pushes it toward the full standard. The fix is architectural and cultural: tokenize everything, never accept card data through any channel you control, and scrub your logs. PCI scope creep is the same failure mode as PHI in logs that we flagged for HIPAA architecture — sensitive data leaking into systems that were never meant to hold it.

How it fits your wider compliance

PCI DSS isn't an island. The access control, encryption, logging, vulnerability scanning, and vendor-management controls it demands overlap heavily with SOC 2 and ISO 27001 — implement them well once and you've done most of the work for all three. If you're already building toward SOC 2, fold PCI's payment-specific requirements into that program rather than running a separate effort. The smart sequence is: get the architecture right so you qualify for SAQ A, then satisfy the overlapping controls through your broader security program.

How Infiniti Tech Partners handles payment security

We architect payment flows that keep cardholder data off your infrastructure entirely — tokenized integrations that qualify you for the lightest SAQ — and build the script-integrity, logging-hygiene, and vendor-management controls PCI now expects, folded into your wider SOC 2 or ISO 27001 program so you're not duplicating effort. The deliverable is a payment system that's compliant by design, not a binder written after the fact. If you're adding payments or worried your current setup has quietly expanded your PCI scope, start a conversation.