PCI DSS compliance: Payment security laws for app builders

In 2024, a mid-size e-commerce company discovered that a JavaScript skimmer had been injecting malicious code into their checkout page for three months. The skimmer captured credit card numbers as customers typed them and sent the data to an attacker-controlled server. Over 50,000 cards were compromised.

The forensic investigation cost $85,000. The fines from payment processors topped $200,000. And the company lost its ability to process cards for 6 weeks while it rebuilt its payment infrastructure from scratch.

The root cause? They'd integrated a payment form directly into their page instead of using an iframe-based tokenization approach. Their checkout page had access to raw card numbers - and so did every third-party script running on that page.

PCI DSS exists to prevent exactly this scenario. And if your app touches payment card data in any way, it applies to you.

Payment data remains among the most costly to expose. IBM's 2024 Cost of a Data Breach Report found that financial sector breaches now average $6.08 million per incident - 22% above the global average of $4.88 million. And 70% of breached organizations reported significant operational disruption on top of direct costs.

Who PCI DSS applies to

PCI DSS applies to every entity that stores, processes, or transmits cardholder data. There's no minimum size threshold, no revenue requirement, no exemption for small businesses.

If your app accepts credit card payments - even one transaction per year - PCI DSS applies.

Most organizations aren't as compliant as they think. Verizon's 2024 Payment Security Report found that only 14.3% of global organizations achieved full PCI DSS compliance - and the compliance gap grew year-over-year, meaning companies are trending less compliant, not more. The Ponemon Institute found non-compliance costs 2.71x more than staying compliant: $15 million average for non-compliance vs. $5.5 million to maintain it.

Cardholder data includes:

• Primary Account Number (PAN) - the credit card number

• Cardholder name

• Expiration date

• Service code

Sensitive authentication data (never store this):

• Full magnetic stripe data

• CVV/CVC (the 3-4 digit security code)

• PIN/PIN block

The critical distinction: you can store cardholder data (encrypted, with access controls). You can never store sensitive authentication data after authorization, even encrypted.

The scope question: How much does PCI DSS affect you?

Your PCI compliance burden depends entirely on how much contact your systems have with cardholder data. This is where architecture decisions made before development starts can save you hundreds of thousands of dollars.

The scope spectrum

Full scope (you handle raw card data):

• Your servers receive, process, or store primary account numbers

• All 12 PCI DSS requirement categories apply (300+ individual controls)

• Annual audits, quarterly scans, penetration testing

• Network segmentation, intrusion detection, file integrity monitoring

• Cost: $50K-$200K+ for compliance infrastructure

Reduced scope (tokenized payments):

• Your app uses Stripe Elements, Braintree Drop-in, or similar hosted payment fields

• Card data goes directly from the user's browser to the payment provider

• Your servers never see the card number - only a token

• You still need PCI compliance, but at a fraction of the requirements (SAQ A or SAQ A-EP)

• Cost: $5K-$15K for compliance infrastructure

The obvious strategy: Don't handle raw card data. Use tokenization. Stripe, Braintree, Adyen, and Square all provide hosted payment fields that handle PCI-scoped data processing for you. Your app gets a token representing the card, and the token is useless to attackers.

"Every client who's built a payment product has come to us with some version of the same question: 'Do we need to build our own card form?' The answer is almost always no. Hosted fields from Stripe or Braintree drop your PCI scope from 300+ controls to under 30. That's not just a compliance shortcut - it's a fundamentally safer architecture."

• Ashit Vora, Captain at RaftLabs

PCI DSS v4.0: What changed

PCI DSS v4.0 became mandatory in March 2025. If your app was built to v3.2.1, you need to update. Key changes:

Stronger authentication:

• MFA required for all access to the cardholder data environment (not just remote access)

• Passwords must be at least 12 characters (up from 7)

• Automated mechanisms to detect and protect against phishing

E-commerce anti-skimming (Requirement 6.4.3):

• All payment page scripts must be inventoried and authorized

• Script integrity must be verified (preventing Magecart-style attacks)

• Unauthorized scripts must be detected and alerted

• This applies even if you use hosted payment fields - your payment page still runs other scripts

Continuous monitoring:

• Shift from point-in-time annual compliance to continuous monitoring

• Automated log review (no more manual quarterly log reviews)

• Real-time alerting on security events

Customized approach:

• v4.0 lets you meet requirements through a "customized approach" - you define the control and prove it meets the security objective, rather than following the prescribed implementation

• Only for mature organizations with strong security programs

• Most businesses should stick with the "defined approach"

The 12 PCI DSS requirements (simplified)

PCI DSS has 12 high-level requirements grouped into 6 categories. Here's what each means for your app:

Build and maintain a secure network

Requirement 1: Install and maintain network security controls - Firewalls, network segmentation, and access control lists to isolate systems that handle cardholder data.

Requirement 2: Apply secure configurations to all system components - No vendor-supplied default passwords, unnecessary services disabled, secure configurations documented.

Protect account data

Requirement 3: Protect stored account data - Encrypt stored cardholder data (AES-256), mask PAN when displayed (show only last 4 digits), implement key management. With tokenization, this requirement is mostly handled by your payment provider.

Requirement 4: Protect cardholder data with strong cryptography during transmission - TLS 1.2+ for all cardholder data transmission. No exceptions.

Maintain a vulnerability management program

Requirement 5: Protect all systems and networks from malicious software - Anti-malware on systems that can be infected, regular updates, phishing protection mechanisms.

Requirement 6: Develop and maintain secure systems and software - Secure development practices, code reviews, vulnerability scanning, and the new Requirement 6.4.3 for payment page script management.

Implement strong access control

Requirement 7: Restrict access to system components and cardholder data by business need-to-know - Role-based access, documented access policies, regular access reviews.

Requirement 8: Identify users and authenticate access - Unique user IDs, MFA for all cardholder data access (v4.0), 12-character minimum passwords, account lockout mechanisms.

Requirement 9: Restrict physical access to cardholder data - Physical security controls for on-premises systems. Less relevant for cloud-hosted apps, but cloud provider compliance matters.

Regularly monitor and test networks

Requirement 10: Log and monitor all access to system components and cardholder data - Audit logging for all access to cardholder data, automated log review, time synchronization across systems, log retention for at least 12 months.

Requirement 11: Test security of systems and networks regularly - Quarterly vulnerability scans by an ASV (Approved Scanning Vendor), annual penetration testing, wireless access point detection, file integrity monitoring.

Maintain an information security policy

Requirement 12: Support information security with organizational policies and programs - Documented security policy, risk assessment, security awareness training, incident response plan, third-party service provider management.

How PCI DSS affects your app architecture

If you're using tokenization (and you should be), here's what you still need to implement:

If you're handling raw card data, add: network segmentation, encryption at rest, key management, intrusion detection, file integrity monitoring, and significantly more testing.

Self-assessment questionnaires: Which one are you?

PCI compliance validation depends on your transaction volume and how you handle card data:

The practical advice: architect your payment integration to qualify for SAQ A when possible. If you need more control over the checkout experience, SAQ A-EP with Stripe Elements is the next best option. Only go to SAQ D if you have a specific business requirement that mandates handling raw card data.

What PCI DSS compliance costs

The build cost for tokenized approaches covers: secure payment page implementation, CSP headers, script monitoring, admin access controls, logging, and documentation.

The full-scope cost covers everything above plus: network segmentation, encryption infrastructure, intrusion detection, file integrity monitoring, and significantly more testing and documentation.

Questions to ask your development partner

1. "How do you recommend integrating payments?" - The right answer involves tokenization (Stripe Elements, Braintree Drop-in, or similar). If they suggest building a custom payment form that collects card numbers on your servers, ask why.

2. "Which PCI SAQ will our architecture qualify for?" - They should be able to explain whether you'll qualify for SAQ A, SAQ A-EP, or SAQ D based on the integration approach.

3. "How do you handle Requirement 6.4.3 (payment page scripts)?" - This is a v4.0 requirement that many teams miss. Look for CSP headers, script inventory, and integrity monitoring.

4. "Have you built PCI-compliant payment systems before?" - Past experience matters. Ask about specific integrations, how they handled ASV scans, and what SAQ type their previous apps qualified for.

5. "How do you handle PCI compliance during development?" - They should never use real card numbers in development or testing. Test cards only. Production payment configuration should be separate from development environments.

Your PCI DSS compliance checklist

Before development starts:

• Choose a tokenized payment provider (Stripe, Braintree, Adyen, Square)

• Determine your target SAQ type (A, A-EP, or D)

• Identify your compliance level (1-4) based on expected transaction volume

• Register with your payment processor's compliance program

During development:

• Integrate payments using hosted/tokenized approach (never handle raw card data if possible)

• Implement TLS 1.2+ sitewide with HSTS headers

• Implement Content Security Policy headers on payment pages

• Build script inventory and integrity monitoring for payment pages

• Build role-based access controls for payment administration

• Build audit logging for payment-related operations

• Use test cards only - never real card numbers in dev/staging

• Follow secure coding practices per Requirement 6

Before launch:

• Complete an ASV (Approved Scanning Vendor) vulnerability scan

• Complete the appropriate SAQ

• Conduct a penetration test (required annually for SAQ A-EP and D)

• Document your incident response plan for payment data incidents

• Train staff on PCI requirements relevant to their roles

• Verify all third-party payment-related services are PCI compliant

• Submit compliance documentation to your acquiring bank/processor

PCI DSS compliance is annual. ASV scans are quarterly. New requirements in v4.0 push toward continuous monitoring. Build the architecture right from the start and ongoing compliance becomes a routine rather than a fire drill.

"The shift from point-in-time PCI audits to continuous monitoring in v4.0 changes how you think about compliance tooling. It's no longer a once-a-year scramble - it's a live dashboard. Teams that build this infrastructure early end up with a significant operational advantage when audit season hits."

• RaftLabs Engineering Team

The Verizon 2024 Data Breach Investigations Report analyzed over 10,000 confirmed breaches across 94 countries. Payment-related environments remain a top target. The case for continuous monitoring - not just annual compliance checks - has never been stronger.