If your application processes, stores, or transmits credit card data, you are subject to PCI DSS (Payment Card Industry Data Security Standard). There is no opt out. The requirements apply whether you process ten transactions a month or ten million.
The good news is that modern payment infrastructure has made PCI compliance dramatically simpler than it was a decade ago. The bad news is that most development teams still make architectural decisions that increase their compliance burden unnecessarily. Here is how to get it right.
Understanding PCI DSS Levels
PCI DSS applies to every organization that handles cardholder data, but the validation requirements vary by transaction volume:
Level 1: Over 6 million transactions per year. Requires an annual on site assessment by a Qualified Security Assessor (QSA) and quarterly network scans.
Level 2: 1 to 6 million transactions per year. Requires an annual Self Assessment Questionnaire (SAQ) and quarterly network scans.
Level 3: 20,000 to 1 million ecommerce transactions per year. Same as Level 2.
Level 4: Fewer than 20,000 ecommerce transactions or up to 1 million other transactions per year. Requires an annual SAQ and quarterly network scans are recommended but not always required.
Most startups and growth stage companies fall into Level 3 or 4. The validation is simpler, but the security requirements are identical across all levels. You still need to meet every applicable PCI DSS requirement. The difference is how you prove it.
The Architecture Decision That Changes Everything
The single most impactful decision for PCI compliance is whether cardholder data touches your servers. This determines which Self Assessment Questionnaire you file and how much engineering work compliance requires.
SAQ A: Cardholder data never touches your systems. You use a payment processor's hosted payment page or iframe. The card number goes directly from the customer's browser to the processor. Your servers never see it. This is the simplest compliance path with only 22 requirements.
SAQ A-EP: Your website controls the payment page but does not process card data. You use a JavaScript library (like Stripe Elements) that sends card data directly to the processor from the browser, but your website serves the page. About 139 requirements.
SAQ D: Cardholder data touches your servers. You receive, store, or process card numbers on your infrastructure. Over 300 requirements. This is the full PCI DSS assessment and you want to avoid it if at all possible.
Our recommendation for 95 percent of applications: use SAQ A or SAQ A-EP. Stripe, Braintree, and similar processors offer client side tokenization that keeps card data off your servers entirely. We covered this architecture in detail in our payment processing guide. The compliance cost difference between SAQ A-EP and SAQ D is tens of thousands of dollars annually and months of engineering time.
Tokenization: The Foundation of Modern PCI Compliance
Tokenization replaces sensitive card data with a non sensitive token. The actual card number is stored by your payment processor, not by you. Your system stores and transmits tokens that are useless to an attacker.
Here is how it works in practice:
1. Customer enters card details into a form rendered by your payment processor's JavaScript SDK
2. The SDK sends the card data directly to the processor's servers (never hitting yours)
3. The processor returns a token (like `tok_1234abcd`)
4. Your server receives the token and uses it to create charges, subscriptions, or save the payment method
5. You store the token in your database, not the card number
With this architecture, a complete breach of your database exposes tokens that cannot be used to make fraudulent charges. Your PCI scope shrinks dramatically.
The 12 PCI DSS Requirements
Even with tokenization reducing your scope, you still need to understand the full framework. PCI DSS 4.0 (the current version) has 12 high level requirements:
1. Install and maintain network security controls. Firewalls, network segmentation, restricting traffic to only what is necessary.
2. Apply secure configurations to all system components. No default passwords, disable unnecessary services, harden your servers.
3. Protect stored account data. If you store any cardholder data (which you should avoid), it must be encrypted with strong cryptography and access must be restricted.
4. Protect cardholder data with strong cryptography during transmission. TLS 1.2 or higher. No exceptions.
5. Protect all systems and networks from malicious software. Antivirus, anti malware, and regular updates on all systems in scope.
6. Develop and maintain secure systems and software. Secure coding practices, vulnerability management, patch management. This maps closely to good full stack development practices.
7. Restrict access to system components and cardholder data by business need to know. Role based access control, least privilege.
8. Identify users and authenticate access to system components. Unique IDs for all users, MFA for administrative access, strong password policies.
9. Restrict physical access to cardholder data. For cloud hosted applications, your provider handles this.
10. Log and monitor all access to system components and cardholder data. Centralized logging, audit trails, log review processes.
11. Test security of systems and networks regularly. Quarterly vulnerability scans by an Approved Scanning Vendor (ASV), annual penetration testing, and wireless network testing if applicable.
12. Support information security with organizational policies and programs. Security policies, risk assessments, security awareness training, incident response plans.
What It Costs
SAQ A (hosted payment page): $1,000 to $5,000 per year. Minimal engineering overhead. Quarterly ASV scans cost $100 to $500 each. The SAQ itself takes a few hours to complete.
SAQ A-EP (client side tokenization): $5,000 to $20,000 per year. More engineering requirements around web server security, vulnerability scanning, and change management. Annual penetration testing adds $5,000 to $15,000.
SAQ D (full scope): $50,000 to $200,000+ per year. Requires extensive security infrastructure, potentially a QSA assessment, regular penetration testing, and significant ongoing engineering effort.
The delta between SAQ A-EP and SAQ D is where architectural decisions save or cost you real money. Choosing to store card data on your servers because it seems simpler in the short term creates a six figure annual compliance obligation.
PCI DSS 4.0 Changes You Need to Know
PCI DSS 4.0 became mandatory in March 2025. Key changes that affect application developers:
Client side script management. You must inventory and authorize all JavaScript loaded on payment pages. This means tracking every third party script (analytics, chat widgets, A/B testing tools) and ensuring they cannot be tampered with. Content Security Policy headers, Subresource Integrity, and script monitoring are now essential.
Targeted risk analysis. Instead of prescriptive timelines for some controls, you can perform a risk analysis to determine the appropriate frequency. This gives flexibility but requires documentation.
Enhanced authentication. MFA is required for all access into the cardholder data environment, not just administrative access. Password requirements have been updated to a minimum of 12 characters.
Automated technical controls. Many controls that previously could be manual now require automation. Automated log review, automated detection of unauthorized changes, and automated mechanisms to detect and alert on security failures.
Reducing Your PCI Scope
Beyond tokenization, here are practical steps to minimize your compliance burden:
Network segmentation. Isolate your payment processing components from the rest of your infrastructure. Systems that do not need to interact with payment data should be on separate network segments. This reduces the number of systems in scope for PCI assessment.
Minimize data retention. Do not store anything you do not need. Transaction history should reference tokens, not card data. If you need to display the last four digits, store only the last four digits (this is not considered cardholder data under PCI).
Use your processor's features. Stripe, Braintree, and others offer hosted invoicing, subscription management, and customer portals that keep card data completely off your systems. Use them. We discussed building payment flows with these approaches and the architectural benefits are significant.
Separate environments. Your development and staging environments should never contain real cardholder data. Use test card numbers provided by your payment processor.
Common Compliance Failures
Third party scripts on payment pages. A chat widget on your checkout page can inject JavaScript that skims card data. PCI DSS 4.0 specifically addresses this with requirements for script inventory and integrity monitoring.
Logging card data. Your application logs the full request body of a payment API call, and it includes the card number. Check your logging configuration. Mask or exclude sensitive fields.
Shared hosting. Running your payment application on shared infrastructure with non PCI systems expands your scope. Isolate payment workloads.
Stale credentials. Service accounts and API keys for payment integrations that have not been rotated in years. PCI requires regular credential rotation and access reviews.
If you are building an application that processes payments and want to get the architecture right from the start, or if you need to reduce the PCI scope of an existing application, let us know. The architectural decisions you make now determine your compliance costs for years to come.