PCI DSS for SaaS Companies

The good news: modern payment integrations make PCI DSS achievable for most SaaS companies with minimal scope. This guide explains how PCI DSS applies specifically to SaaS, common architectures, and strategies to minimize compliance burden.

Key Takeaways

Do You Need PCI DSS Compliance?

Yes, If You:

• Accept credit card payments for your SaaS subscription
• Enable your customers to accept payments through your platform
• Store any cardholder data (even encrypted)
• Transmit cardholder data through your systems
• Provide services that interact with payment processing

Common SaaS Scenarios

Understanding Your Role: Merchant vs Service Provider

This distinction dramatically affects your compliance requirements:

Merchant

You're a merchant if: You accept payments for your own products/services.

Example: A SaaS company charging customers $99/month for their software subscription.

Compliance implications:

• Validation level based on your transaction volume
• Can typically use simplified SAQ types
• Responsible only for your own compliance

Service Provider

You're a service provider if: You handle cardholder data on behalf of other businesses.

Examples:

• Payment platform enabling merchants to accept payments
• E-commerce platform processing customer orders
• Invoicing software that facilitates payments
• Marketplace handling payments between buyers and sellers

Compliance implications:

• Higher compliance standards (Level 1 or Level 2 only)
• Must use SAQ D or undergo QSA assessment
• Listed on card brand service provider registries
• Customers will require your AOC

Dual role: Many SaaS companies are both merchants (for their own subscriptions) and service providers (for payment features). You need to address both.

The Ideal SaaS Payment Architecture

The goal: minimize PCI scope by keeping card data off your servers entirely.

Architecture 1: Redirect to Hosted Payment Page (Recommended)

1Customer → Your App → Redirect → Stripe Checkout → Token → Your App

How it works:

1. Customer clicks "Pay" in your app
2. Redirect to Stripe Checkout or Stripe Payment Links
3. Customer enters card on Stripe's domain
4. Stripe returns token to your app
5. You store the token (not card data)

SAQ impact: SAQ A (simplest)

Pros:

• Minimal PCI scope
• Stripe handles PCI compliance for payment pages
• Easy to implement

Cons:

• Less control over checkout UX
• Customer leaves your domain temporarily

Architecture 2: Embedded Payment Form (iframe)

1Customer → Your App (with Stripe Elements iframe) → Token → Your App

How it works:

1. Customer is on your checkout page
2. Card fields are Stripe Elements (iframes)
3. Card data goes directly from iframe to Stripe
4. Stripe returns token to your app
5. Your servers never see card data

SAQ impact: SAQ A (with proper implementation)

Pros:

• Seamless UX on your domain
• Minimal PCI scope
• Customizable styling

Cons:

• More implementation complexity
• Must ensure proper iframe isolation

Architecture 3: Custom Form with Client-Side Tokenization

1Customer → Your App → Stripe.js → Stripe API → Token → Your App

How it works:

1. Customer enters card on your payment page
2. Stripe.js encrypts and sends directly to Stripe
3. Stripe returns token
4. Your backend receives only the token

SAQ impact: SAQ A-EP (~191 questions in v4.0)

Why SAQ A-EP: Your server serves the payment page, making you responsible for web server security.

Pros:

• Full control over UX
• Card data doesn't hit your server

Cons:

• Larger compliance scope than SAQ A
• More controls to implement and maintain

Architecture 4: Server-Side Card Handling (Avoid If Possible)

1Customer → Your App → Your Server → Payment API → Response

How it works:

1. Card data submitted to your server
2. Your server sends to payment processor
3. You may store card data for later use

SAQ impact: SAQ D (330+ questions in v4.0)

Why SAQ D: Card data touches your systems, expanding scope dramatically.

When this is necessary:

• Legacy systems requiring migration
• Complex payment orchestration
• PCI Level 1 service providers

Recommendation: Avoid this architecture unless absolutely necessary. The compliance burden is significant.

Common SaaS Payment Patterns

Pattern 1: Subscription Billing

Use case: Monthly/annual SaaS subscriptions

Recommended approach:

• Use Stripe Billing or similar
• Checkout via Stripe Checkout or Elements
• Store customer tokens for recurring charges
• Let Stripe handle card updates (via Account Updater)

SAQ type: SAQ A

Pattern 2: Usage-Based Billing

Use case: Pay-per-use, metered billing

Recommended approach:

• Same as subscription billing
• Track usage in your system
• Bill against stored payment method tokens
• Use Stripe Usage Records or similar

SAQ type: SAQ A

Pattern 3: Marketplace / Platform Payments

Use case: Multi-sided marketplace, SaaS enabling customer payments

Recommended approach:

• Use Stripe Connect, Adyen for Platforms, or similar
• Let the platform handle onboarding and compliance
• Your merchants may need their own PCI compliance

SAQ type: SAQ D (as service provider)

Important: As a platform, you're likely a service provider. Plan for more comprehensive compliance.

Pattern 4: Invoicing with Payment Links

Use case: B2B SaaS with invoice-based payments

Recommended approach:

• Generate payment links (Stripe Payment Links, Adyen Pay by Link)
• Customer pays on hosted payment page
• Reconcile against invoice in your system

SAQ type: SAQ A

Integrating with Enterprise Customers

Enterprise SaaS deals often require both PCI DSS compliance and additional security validations:

What Enterprises Ask For

Documentation to Prepare

1. Attestation of Compliance (AOC): Summary document from your SAQ or QSA assessment
2. Evidence of SAQ completion: Signed and dated SAQ
3. Service provider list: PCI-compliant vendors you rely on (Stripe, AWS, etc.)
4. Architecture diagram: Showing card data flows
5. Stripe/Adyen AOC: Request from your payment provider to share with customers

Multi-Tenant Considerations

SaaS applications are typically multi-tenant, which introduces specific considerations:

Data Isolation

• Ensure cardholder data (tokens) are properly isolated between tenants
• Access controls prevent cross-tenant data access
• Logging captures tenant context for audit trails

Configuration Management

• Tenant-specific payment provider configurations
• Secure handling of API keys per tenant
• Proper testing environments (don't use production payment data in dev)

Compliance Inheritance

If you're a service provider:

• Your compliance helps your customers' compliance
• Document what controls your customers inherit
• Provide compliance attestation for their assessments

Common Mistakes for SaaS Companies

Mistake 1: Logging Card Numbers

Problem: Accidentally logging full PANs in application logs.

Solution:

• Audit all logging for cardholder data
• Use tokenization before any logging occurs
• Mask or exclude card data from error reports

Mistake 2: Storing CVV

Problem: Storing CVV/CVC even temporarily.

Solution: CVV should never be stored, even encrypted, after authorization. If your system stores CVV, fix this immediately.

Mistake 3: Insecure Token Storage

Problem: Treating tokens as non-sensitive because they're not full PANs.

Solution: While tokens reduce scope, protect them appropriately:

• Access controls on token data
• Encryption at rest (best practice)
• Audit logging for token access

Mistake 4: Development with Production Cards

Problem: Using real card data in development or testing.

Solution:

• Use Stripe/Adyen test mode and test cards
• Never use production credentials in non-production
• Clear test data before production deployment

Mistake 5: Ignoring Service Provider Status

Problem: Platform handling payments for customers without proper service provider compliance.

Solution:

• Assess whether you're a service provider
• Plan for SAQ D or QSA assessment
• Register with card brands if required

Checklist: PCI DSS for SaaS

Architecture:

• Card data never touches your servers (tokenization at edge)
• Using hosted payment forms or iframes
• Tokens stored instead of card numbers
• Test environments use test cards only

Documentation:

• Payment data flow documented
• SAQ type identified
• Service provider relationships documented
• Policies cover payment data handling

Implementation:

• TLS 1.2+ for all payment-related traffic
• No cardholder data in logs
• Access controls on payment functions
• Secure API key management

Validation:

• Appropriate SAQ completed
• Quarterly ASV scans (if required)
• Annual penetration test (recommended)
• AOC available for customers

Frequently Asked Questions

Does using Stripe mean I'm automatically PCI compliant?

No. Stripe handles their PCI compliance, but you still have obligations for how you integrate with Stripe. You need to complete an SAQ (typically SAQ A) to attest that your integration is properly implemented.

Can I see credit card numbers with Stripe Elements?

No. With proper Elements implementation, card numbers go directly from the iframe to Stripe. Your JavaScript cannot access the card data inside the iframe. This is what enables SAQ A eligibility.

My customers' customers enter card data. Who is responsible for PCI?

Typically, your customers are responsible for their PCI compliance as merchants. You may be a service provider supporting their compliance. Document the responsibility split clearly.

Do I need to display a PCI compliance badge?

There's no official PCI compliance badge. Don't display third-party "PCI certified" badges as they may be misleading. You can state "PCI DSS compliant" in your documentation if accurate.

Need help determining your PCI scope or implementing compliant payment integration? Talk to our team

Sources

• PCI SSC Guidance for Tokenization - Tokenization guidance
• Stripe PCI Compliance Guide - Stripe-specific guidance
• PCI DSS E-commerce Guidelines - E-commerce supplement