PCI DSS Compliance Explained: What Every Product Team Needs to Know

In December 2013, attackers installed malware on Target's point-of-sale systems and stole 40 million credit card numbers over 19 days. The breach cost Target $162 million in settlements and remediation. In 2019, Capital One suffered a breach exposing 100 million credit card applications, ultimately costing the company $190 million in regulatory fines and settlements.

Both companies were supposed to be PCI DSS compliant. Both had passed their most recent audits. Both still got breached.

This is the paradox of PCI DSS: compliance is mandatory, expensive, and does not guarantee security. But non-compliance guarantees pain. If your product touches payment card data in any form — and most fintech products do — PCI DSS is the regulatory framework that governs what you can and cannot do with that data.

For product managers, the critical question is not how to implement every technical control. It is how to architect your product so that card data never touches your systems in the first place. The scope decision is the product decision. Everything else is implementation.

What PCI DSS Actually Is

PCI DSS stands for Payment Card Industry Data Security Standard. It is not a law. It is a set of security requirements created and maintained by the PCI Security Standards Council, which was founded in 2006 by Visa, Mastercard, American Express, Discover, and JCB.

The standard applies to any organization that stores, processes, or transmits cardholder data. That includes merchants, payment processors, fintech companies, SaaS platforms with billing, and any third party that handles card information on behalf of another company.

There are no size exemptions. A one-person e-commerce shop and JPMorgan Chase are both required to comply. The difference is in how compliance is validated — which is where the four levels come in.

The PCI Council does not enforce compliance directly. Enforcement comes from the card networks (Visa, Mastercard, etc.) through the acquiring banks that process merchants' transactions. If you suffer a breach while non-compliant, the card networks impose fines on your acquiring bank, which passes them to you — along with the cost of forensic investigations, card reissuance, and potential loss of your ability to accept cards entirely.

The Four Compliance Levels

PCI DSS defines four merchant levels based on annual transaction volume. The level determines how you validate compliance — specifically, whether you need an external audit or can self-assess.

Note: Transaction thresholds vary slightly by card brand. The numbers above reflect Visa's classification, which is the most commonly referenced.

The cost difference between levels is enormous. A Level 1 QSA audit from a major firm costs $200,000 to $500,000 annually, plus the internal staff time to prepare. A Level 4 SAQ can be completed by a single person in a few hours if the scope is narrow.

This is why scope reduction is the single most important architectural decision for any fintech product team. Every card number your system touches expands your PCI scope, increases your compliance level risk, and adds cost.

The 12 Requirements, Simplified

PCI DSS v4.0 — the current version, which became mandatory on March 31, 2025, replacing v3.2.1 — organizes its requirements into six goals and twelve requirements. Here is what they actually mean in practice.

Goal 1: Build and Maintain a Secure Network and Systems

Requirement 1: Install and maintain network security controls. You need firewalls (or their cloud equivalents) controlling traffic between your cardholder data environment and everything else. In practice, this means proper VPC configuration, security groups, and network segmentation.

Requirement 2: Apply secure configurations to all system components. Do not use vendor-supplied defaults for system passwords and security parameters. Every default password, every unnecessary service, every open port is a finding.

Goal 2: Protect Account Data

Requirement 3: Protect stored account data. If you store card numbers, they must be encrypted. Primary Account Numbers (PANs) must be rendered unreadable using encryption, truncation, or tokenization. This is the requirement that drives most tokenization decisions.

Requirement 4: Protect cardholder data with strong cryptography during transmission over open, public networks. Use TLS 1.2 or higher. No exceptions.

Goal 3: Maintain a Vulnerability Management Program

Requirement 5: Protect all systems and networks from malicious software. Anti-malware on all systems. Keep it updated.

Requirement 6: Develop and maintain secure systems and software. Patch vulnerabilities promptly. Follow secure development practices. This is the requirement that mandates code reviews and vulnerability scanning.

Goal 4: Implement Strong Access Control Measures

Requirement 7: Restrict access to system components and cardholder data by business need to know. Not everyone needs access to production card data. Most people should never see it.

Requirement 8: Identify users and authenticate access to system components. Unique IDs for every user. Multi-factor authentication for all access to the cardholder data environment. PCI DSS v4.0 expanded MFA requirements significantly.

Requirement 9: Restrict physical access to cardholder data. Lock down server rooms and data centers. In a cloud-native world, this is largely handled by your cloud provider's SOC 2 compliance.

Goal 5: Regularly Monitor and Test Networks

Requirement 10: Log and monitor all access to system components and cardholder data. Centralized logging. Audit trails. You need to know who accessed what and when.

Requirement 11: Test security of systems and networks regularly. Quarterly vulnerability scans by an Approved Scanning Vendor (ASV). Annual penetration testing. PCI DSS v4.0 added a requirement for authenticated internal vulnerability scanning.

Goal 6: Maintain an Information Security Policy

Requirement 12: Support information security with organizational policies and programs. Written policies. Employee training. Incident response plans. This is the governance wrapper around everything else.

The common mistake product teams make is treating these twelve requirements as a checklist to be completed once a year. PCI DSS v4.0 shifted the standard toward continuous compliance — the expectation is that these controls are operational every day, not just during audit season.

SAQ Types: Why They Matter for Product Decisions

The Self-Assessment Questionnaire is not one document. It comes in multiple types, each designed for a specific way of handling card data. The type you qualify for depends entirely on your product architecture.

The jump from SAQ A (22 questions) to SAQ A-EP (191 questions) is the most critical product decision in payment page design. If you use a Stripe Checkout redirect or a hosted payment page, card data never touches your servers, and you qualify for SAQ A. If you embed Stripe Elements on your own page — where your JavaScript runs alongside the payment form — you are SAQ A-EP, with nearly 9x the compliance burden.

This is why the product architecture decision of "redirect vs. embedded form" is not just a UX discussion. It is a compliance cost discussion that can mean the difference between a weekend of self-assessment and months of security work.

Why Most Fintechs Use Stripe and Adyen: The Tokenization Strategy

The smartest thing most fintech companies do is ensure they never see card data at all. This is the tokenization strategy, and it is the single most effective way to reduce PCI scope.

Here is how it works with Stripe: When a customer enters their card number on your payment page, Stripe's JavaScript library (Stripe.js) captures the card details directly in an iframe hosted by Stripe. The card number is sent from the customer's browser to Stripe's PCI Level 1 certified servers. Your application never receives the actual card number. Instead, Stripe returns a token — a randomized string like tok_1MqVnBG4 — that represents the card.

Your servers store and use the token. Stripe stores and secures the actual card number. When you need to charge the card, you send the token to Stripe's API. Stripe resolves the token to the real card number, processes the payment, and returns the result.

The PCI compliance burden shifts almost entirely to Stripe. Stripe is a PCI Level 1 Service Provider — the highest certification level — and undergoes annual audits validating compliance with all 300+ requirements. Your company's PCI scope shrinks to whatever systems interact with Stripe's API and serve the payment page.

Adyen, Braintree, and other major processors offer similar tokenization approaches. The principle is the same: the less card data you touch, the smaller your compliance surface.

This is not free — Stripe charges processing fees (typically 2.9% + $0.30 per transaction in the US). But the alternative is building and maintaining PCI-compliant card storage infrastructure, which requires dedicated security staff, annual audits, and the risk of catastrophic breach liability. For the vast majority of companies, paying the processing fee is dramatically cheaper than handling card data directly.

The Cost of Getting It Wrong

The direct costs of a payment card breach are severe. The indirect costs are worse.

Forensic investigation. After a suspected breach, the card brands require a PCI Forensic Investigator (PFI) to conduct an investigation. This costs $100,000 to $500,000 depending on scope and typically takes 4 to 12 weeks.

Card reissuance costs. If your breach exposes card numbers, the issuing banks must reissue those cards. The cost — typically $3 to $10 per card — is charged back to you. Target's breach exposed 40 million cards; the reissuance costs alone were estimated at $200 million across the issuing banks.

Fines from card brands. Visa and Mastercard impose fines of $5,000 to $100,000 per month for non-compliance. After a breach, these fines can be significantly higher. The fines are levied on the acquiring bank, which passes them to the merchant.

Loss of card acceptance. In extreme cases, card brands can revoke your ability to accept their cards. For most businesses, this is an existential threat.

Regulatory penalties. Beyond PCI DSS, breaches trigger investigations under state breach notification laws, GDPR (if European cardholders are affected), and sector-specific regulations. Capital One's $190 million settlement included an $80 million fine from the OCC.

Litigation. Breaches generate class-action lawsuits from affected cardholders. Target paid $18.5 million to settle a multi-state attorney general investigation and $10 million in a class-action settlement. Home Depot's 2014 breach resulted in a $25 million settlement.

The total cost of a major breach commonly exceeds $100 million. For smaller companies, even a modest breach can cost $500,000 to $2 million in forensic, remediation, and legal costs — enough to threaten the business.

PCI DSS v4.0: What Changed in 2025

PCI DSS v4.0 replaced v3.2.1 as the mandatory standard on March 31, 2025. The new version represents the most significant update since the standard's creation. Key changes that affect product teams:

Customized approach. For the first time, organizations can meet requirements using a "customized approach" — designing their own controls and proving they meet the requirement's intent — rather than following the prescribed method exactly. This gives mature security teams more flexibility but requires documented risk analysis.

Expanded multi-factor authentication. MFA is now required for all access to the cardholder data environment, not just remote access. This affects internal tools, admin panels, and any system that can reach card data.

Targeted risk analysis. Several requirements now require organizations to perform and document targeted risk analyses to determine the frequency of certain activities (like log reviews and vulnerability scans) rather than prescribing fixed intervals.

Client-side security for payment pages. Requirement 6.4.3 mandates that organizations manage all JavaScript on payment pages — inventorying scripts, authorizing them, and ensuring their integrity. This directly addresses Magecart-style attacks where malicious JavaScript is injected into payment pages to skim card numbers. If your payment page loads third-party scripts (analytics, chat widgets, A/B testing tools), each one is now in scope.

Authenticated vulnerability scanning. Internal vulnerability scans must now be authenticated — meaning the scanner logs in with credentials to check for vulnerabilities, not just scanning from the outside.

For product teams, the most impactful change is 6.4.3. If you host your own payment page with embedded payment fields (SAQ A-EP), you now need a Content Security Policy and a script inventory for that page. Every third-party JavaScript library becomes a compliance item. This is another strong argument for using hosted payment pages or redirects to keep your SAQ scope at the minimum.

Key Takeaways

• PCI DSS applies to any organization that stores, processes, or transmits cardholder data — there are no size exemptions, only different validation requirements based on transaction volume.
• The architecture decision is the compliance decision. Using tokenization via Stripe, Adyen, or similar providers can reduce your SAQ from 329 questions to 22 — cutting months of compliance work.
• SAQ A vs. SAQ A-EP is the most important product decision in payment page design. A hosted redirect keeps you at SAQ A; an embedded form on your own page pushes you to A-EP with 9x the requirements.
• PCI DSS v4.0 became mandatory on March 31, 2025, introducing client-side script management requirements that significantly impact any company hosting its own payment page.
• The cost of a breach routinely exceeds $100 million for large companies and can reach $500,000 to $2 million even for smaller organizations — far exceeding the cost of proper compliance.
• Compliance is not security. Target and Capital One were both PCI compliant when breached. PCI DSS is the floor, not the ceiling.

Related Reading

• How Visa Processes a Transaction: The Complete Technical Flow
• Payment Gateway vs. Payment Processor: What Is the Difference?
• How ACH Payments Work: The System Moving Trillions