PCI DSS for SaaS and Fintech

Most SaaS and fintech companies dramatically underestimate their PCI DSS scope on first contact with the standard. The pattern is consistent: a CTO or head of engineering reviews the merchant levels, sees that their company processes "fewer than 6 million transactions a year," and concludes incorrectly that they qualify as a Level 4 merchant with a 24-question Self-Assessment Questionnaire and minimal compliance burden.

Then a QSA, an enterprise customer's procurement team, or an acquiring bank's compliance review explains the actual classification. The company is not a merchant. It is a Level 1 service provider. The assessment is not a short SAQ. It is a full Report on Compliance against 370+ requirements, mandatory annual penetration testing covering API attack surface, segmentation testing every six months, multi-tenant testing obligations, and a shared responsibilities matrix that every customer will scrutinise during their own audits.

The reclassification adds 9 to 18 months to the compliance timeline, an order-of-magnitude shift in cost, and a fundamentally different security programme. It is the most expensive avoidable mistake in PCI DSS for the SaaS sector and it is almost entirely a definitional misunderstanding rather than a security failure.

This guide explains how SaaS and fintech companies should think about PCI DSS in 2026: what determines service provider versus merchant classification, how cloud infrastructure scoping actually works under v4.0.1, why API security under Requirement 6.2.4 is now non-negotiable, what multi-tenant obligations under Requirement 11.4.7 mean for your customer relationships, and what the realistic path from payment processing to a signed AoC looks like for a modern cloud-native company.

1. Why SaaS and Fintech Companies Often Misclassify Themselves
2. Am I a Merchant or a Service Provider? Why the Answer Changes Everything
3. Cloud Infrastructure Scoping Under PCI DSS — AWS, Azure, GCP
4. API Security Under Requirement 6.2.4
5. Multi-Tenant Service Provider Obligations — Requirement 11.4.7
6. The Realistic Path From Payment Processing to Signed AoC
7. How SecurityWall Supports SaaS and Fintech PCI DSS Compliance

Why SaaS and Fintech Companies Often Misclassify Themselves

The misclassification typically happens because SaaS founders look at the standard merchant level definitions Levels 1 through 4, with Level 4 covering merchants under 1 million card-present or under 20,000 e-commerce transactions and place their company in the appropriate band based on their own transaction volume.

The mistake: those merchant levels apply only to merchants. PCI DSS draws a sharp distinction between a merchant (an organisation that accepts card payments for its own goods or services) and a service provider (an organisation that stores, processes, or transmits cardholder data on behalf of other organisations).

The test comes down to a single question: are you processing payments for yourself, or for someone else's customers?

• An e-commerce company selling its own products to consumers: merchant
• A SaaS payment platform processing transactions for those e-commerce companies: service provider
• A subscription billing system charging end customers on behalf of multiple SaaS clients: service provider
• A fintech payment API embedded in third-party fintech apps: service provider
• A consumer-facing fintech app charging its own users for premium subscriptions: merchant

The pattern: if your customer is the cardholder, you are a merchant. If your customer is another business whose customers are the cardholders, you are a service provider.

Service provider classification triggers a fundamentally different compliance regime:

• Lower transaction threshold for Level 1 Visa applies 300,000 transactions per year for service providers versus 6 million for merchants
• More demanding SAQ where eligible SAQ D for Service Providers contains 370 questions versus 328 for SAQ D for Merchants
• Mandatory shared responsibilities matrix in the AoC
• Segmentation testing required every six months instead of annually
• Multi-tenant service provider support obligations under Requirement 11.4.7
• Listing on card brand registries Visa Global Registry of Service Providers, Mastercard Compliant Service Provider list which most enterprise customers will require before procurement

Companies that discover this midway through compliance preparation lose months. Companies that discover it during a QSA audit, or after an enterprise customer's procurement review, fail their first validation and start over.

Am I a Merchant or a Service Provider? Why the Answer Changes Everything

If you are unsure of your classification, the test is simple. Cardholder data flowing through your environment for the benefit of another organisation's customers makes you a service provider. Cardholder data flowing through your environment for your own customers makes you a merchant.

The two classifications produce two fundamentally different compliance experiences.

The downstream consequences of getting this wrong fall into three categories: validation pathway error (you prepare for the wrong assessment), customer-facing compliance gaps (enterprise customers reject merchant-pathway SAQs), and card brand registry exclusion (companies operating without registration discover this when card brand audits trigger retroactive penalties).

Cloud Infrastructure Scoping Under PCI DSS — AWS, Azure, GCP

PCI DSS scope determination in cloud environments is the single most complex challenge for SaaS and fintech companies and the source of more failed first-pass assessments than any other technical issue.

The fundamental misconception: "We run on AWS, and AWS is PCI compliant, so our infrastructure is covered."

That is true only for the parts of the stack AWS actually controls. AWS's PCI DSS Responsibility Summary and the equivalent attestations from Azure and GCP covers the infrastructure layer the cloud provider operates: physical data centre security, hypervisor security, hardware, and the underlying network fabric. It does not cover anything you build, configure, or operate on top.

What Remains Your Responsibility in Any IaaS Environment

• Your application code and the libraries it depends on
• Operating system configuration on every compute instance
• Identity and access management, IAM policies, role assumptions, federation, MFA enforcement
• Network configuration, VPCs, subnets, security groups, NACLs, transit gateways
• Encryption configuration, KMS keys, key rotation, encryption-in-transit settings
• Logging configuration, CloudTrail, CloudWatch, equivalent in Azure/GCP
• Secrets management, what is stored where, who can access it, how rotation works
• All cardholder data your application processes, stores, or transmits

The shared responsibility model applies regardless of which cloud you use. The line falls in different places for IaaS, PaaS, and managed services but in every case, you are responsible for everything above the line.

Cloud Scoping Mistakes That Recur in PCI DSS Audits

• Production payment workloads sharing IAM roles, security groups, or VPCs with non-payment workloads dragging out-of-scope systems into the CDE
• Backup snapshots stored in regions or accounts not previously identified as in-scope
• Logging or monitoring services that ingest payment data and route it to systems outside the CDE
• Service accounts with broader permissions than required, creating cross-environment access paths
• CI/CD pipelines that deploy to the CDE with elevated privileges, expanding scope to include the build infrastructure
• Container images stored in registries that authenticate to the CDE without segmentation controls

Each of these expands your CDE in ways that are not visible from a high-level architecture diagram. They surface during gap assessment when a hands-on examination of IAM policies, network configurations, and data flows reveals what the architecture diagram does not.

API Security Under Requirement 6.2.4

Modern SaaS and fintech companies are API-first which means the API surface is the primary attack vector for any payment-handling application. PCI DSS v4.0.1 Requirement 6.2.4 explicitly requires custom and bespoke application code to address a specific set of vulnerability classes, and Requirement 11.4 mandates that penetration testing actively probe for them.

The Vulnerability Classes Requirement 6.2.4 Names

• Injection attacks — SQL, command, NoSQL, GraphQL, LDAP
• Buffer overflows and unsafe memory handling
• Cryptographic issues — weak algorithms, hardcoded keys, predictable values
• Insecure communications — missing TLS, weak ciphers, certificate validation failures
• Improper error handling — stack traces and verbose responses leaking implementation detail
• Broken access control, including IDOR (insecure direct object references)
• Cross-site scripting and request forgery where applicable
• All "high-risk" vulnerabilities identified through ongoing vulnerability identification activity

For an API-first product, the question is not whether these matter it is which surface most often in the specific architecture you have built.

API-Specific Failure Patterns We See in SaaS and Fintech Pen Tests

• Internal APIs treated as private. Service-to-service APIs assumed to be inaccessible from outside the VPC, but reachable through misconfigured load balancers, exposed admin interfaces, or chained vulnerabilities.
• IDOR in multi-tenant data access. Customer A's session token resolves to API endpoints that serve Customer B's data because tenant isolation is enforced in the UI but not at the API layer.
• Insufficient rate limiting. Token endpoints, password reset endpoints, or payment retry endpoints that allow enumeration or brute-force without progressive backoff.
• Secrets in unexpected places. API keys in commit history, environment variables logged in error responses, or service tokens with broader scope than required.
• JWT misconfiguration. Algorithm confusion (none/HS256), missing expiration validation, signature verification accepting public keys mistakenly used as HMAC secrets.

A penetration test conducted on a SaaS product that does not specifically test these API patterns is not adequate evidence under Requirement 11.4. Web UI testing alone historically common under v3.2.1 is no longer sufficient under v4.0.1.

Multi-Tenant Service Provider Obligations — Requirement 11.4.7

PCI DSS v4.0.1 introduced Requirement 11.4.7 specifically for multi-tenant service providers and it is the requirement most multi-tenant SaaS and fintech companies do not realise applies to them until a customer asks.

The rule: if you operate a multi-tenant service where multiple customer organisations share infrastructure, and any of those customers are themselves in PCI DSS scope, you must support their external penetration testing of your environment.

The Two Acceptable Paths

• Permit your customer to conduct their own pentest. Requires you to formally allow testing within agreed scope and timing windows, with appropriate isolation to prevent the customer's testing from affecting other tenants.
• Conduct testing yourself and provide passing results. You commission an external penetration test that covers the customer-relevant attack surface, share evidence of execution and remediation, and your customer relies on your test to satisfy their own Requirement 11.4.3.

In practice, most multi-tenant SaaS providers default to option two coordinating their own testing on a schedule that satisfies multiple customers simultaneously, then providing standardised attestation evidence to each. Option one creates operational risk (one customer's testing affecting others) and is rarely the right model for production multi-tenant environments.

What This Means in Practice

• Your annual penetration test must produce evidence usable by your customers for their own assessments
• The test report needs to be sanitised for customer distribution covering scope, methodology, severity-rated findings, remediation status, retest evidence without exposing other customers' data
• You need a process for fielding customer testing requests, providing the standardised attestation, and tracking which customers have received which evidence
• You may need to test more frequently than annually if you have customers with assessment cycles staggered through the year

The companies that discover Requirement 11.4.7 during a customer's procurement review have a difficult conversation. The companies that build it into their compliance programme up front close enterprise deals faster.

The Realistic Path From Payment Processing to Signed AoC

For a Series B-and-up SaaS or fintech company that needs Level 1 service provider compliance, the journey looks like this:

Phase 1 — Classification and Scoping (4–8 weeks)

• Confirm service provider classification and applicable assessment pathway
• Map cloud architecture, payment data flows, and CDE boundaries
• Identify in-scope systems, services, dependencies, and card brand registry obligations

Phase 2 — Gap Assessment and Remediation Planning (6–10 weeks)

• Full v4.0.1 gap assessment scoped to SAQ D-SP or ROC requirements
• Prioritised remediation roadmap with effort and timeline estimates
• Validation pathway recommendation SAQ D-SP where eligible, full ROC where required

Phase 3 — Remediation (3–9 months, depending on starting posture)

• IAM hardening, MFA expansion, encryption configuration alignment
• Network segmentation and CDE isolation
• Logging and monitoring implementation with automated review
• Documentation policies, procedures, methodologies, Targeted Risk Analyses
• Vendor AoC tracking and shared responsibilities matrix drafting

Phase 4 — Pre-Assessment and Penetration Testing (6–10 weeks)

• Annual external and internal penetration testing under Requirement 11.4
• Segmentation testing every six months for service providers
• Pre-assessment to confirm readiness for formal validation
• Remediation of any findings before formal QSA engagement

Phase 5 — Formal Validation and AoC Issuance (8–12 weeks)

• QSA-led ROC engagement, or SAQ D-SP completion for eligible service providers
• Evidence review, control testing, stakeholder interviews
• ROC drafting, internal review, finalisation
• AoC drafting and signature, including shared responsibilities matrix

Phase 6 — Ongoing Compliance (continuous)

• Quarterly external ASV scans
• Quarterly internal authenticated vulnerability scans
• Semi-annual segmentation testing
• Annual penetration testing and AoC renewal
• Customer testing support under Requirement 11.4.7

Total realistic timeline: 9 to 18 months for a Series B-and-up SaaS or fintech with no prior PCI DSS programme. Companies with mature security postures, substantial cloud-native compliance controls already in place, or prior SOC 2 / ISO 27001 programmes can compress the early phases but the QSA engagement and AoC issuance still require 8–12 weeks at the end.

How SecurityWall Supports SaaS and Fintech PCI DSS Compliance

SecurityWall is a PCI SSC-listed Qualified Security Assessor (QSA) and Approved Scanning Vendor (ASV) with a practice specifically tuned to SaaS and fintech companies operating in cloud-native environments. The model is built around the reality that modern SaaS PCI DSS compliance is fundamentally different from traditional merchant compliance and the partner you choose needs to operate that way.

Single Partner from Classification to Signed AoC

Because we are a QSA, the entire compliance pathway runs through one engagement:

• Service provider versus merchant classification confirmation, including card brand registry analysis
• Gap assessment scoped to SAQ D-SP or ROC requirements
• Remediation advisory aligned to your validation pathway
• Pre-assessment to confirm readiness
• Formal ROC engagement and AoC issuance no third-party assessor handoffs

For SaaS companies that prefer advisory-assessment separation, we can split the QSA team conducting the formal ROC from the team conducting prior advisory work preserving independence without fragmenting the relationship across multiple firms.

Cloud-Native CDE Scoping

We scope cloud environments the way they actually run, not against a generic on-premises template:

• AWS, Azure, and GCP across IaaS, PaaS, and managed services
• Multi-account, multi-region, and multi-cloud architectures
• Container and Kubernetes workloads handling cardholder data
• Serverless and event-driven architectures
• Infrastructure-as-code review for security-relevant configuration

The same practitioners examining your IAM during gap assessment are testing your APIs against Requirement 11.4 consistent context across the engagement.

API Security and Requirement 6.2.4

Penetration testing under Requirement 11.4 specifically targets the vulnerability classes Requirement 6.2.4 names. For API-first products this means:

• Authentication and authorisation testing across every exposed endpoint
• Multi-tenant isolation testing IDOR, cross-tenant data access, session boundary validation
• JWT and token security testing algorithm validation, expiration, signature verification
• Rate limiting and abuse-resistance validation
• Injection testing across REST, GraphQL, and gRPC interfaces
• Secrets management review keys, tokens, configuration data

Findings are documented with CVSS scores, exploitation evidence, and remediation guidance formatted for QSA acceptance and customer-facing attestation.

Multi-Tenant Service Provider Programme

For multi-tenant SaaS and fintech companies subject to Requirement 11.4.7, we deliver:

• Annual external and internal penetration testing scoped for multi-tenant attestation
• Customer-shareable test reports, sanitised for distribution and structured for your customers' own assessments
• A standardised attestation programme so multiple customer testing requests can be satisfied from a single test cycle
• Shared responsibilities matrix drafting for your service provider AoC

Bundled Compliance Programme

PCI DSS for service providers requires three coordinated technical testing streams:

• Annual penetration testing under Requirement 11.4 internal, external, segmentation
• Quarterly external ASV scans under Requirement 11.3.2
• Semi-annual segmentation testing under Requirement 11.4.6

SecurityWall delivers all three as a single coordinated programme. Single point of contact across the year. Consistent evidence formatting. No inter-vendor coordination overhead at audit time.

Related reading:

• What Is PCI DSS Compliance? A Plain-Language Guide for 2026
• PCI DSS v4.0 & v4.0.1: Everything That Changed
• PCI DSS Gap Assessment: How to Prepare in 2026
• PCI DSS Penetration Testing Requirements in 2026
• PCI DSS Attestation of Compliance Explained

Frequently Asked Questions

We use Stripe Connect / a similar embedded payment platform — are we a merchant or a service provider?

It depends on the integration model and whether you facilitate payments for other businesses (your customers) or only for your own end customers. Embedded payments platforms whose customers are themselves merchants almost always make you a service provider, regardless of how the integration is technically implemented. SecurityWall confirms classification with reference to your contract structure, payment flow, and card brand obligations during initial scoping.

Does AWS / Azure / GCP being PCI compliant cover our application?

No. Your cloud provider's PCI DSS attestation covers their infrastructure layer physical security, hypervisor, hardware, and the controls they manage. Everything you build, configure, or operate on top remains your responsibility: applications, OS configuration, IAM, network configuration, encryption, logging, and your data. Their shared responsibilities matrix tells you exactly where the line falls.

We are a Series A SaaS — when do we actually need to start PCI DSS?

Earlier than most founders assume. Enterprise customers in regulated industries (financial services, healthcare, insurance) increasingly require valid AoCs as a procurement gate, even from smaller vendors. The compliance pathway takes 9–18 months end-to-end. If you anticipate enterprise sales motion within the next 12 months, the conversation should start now.

How does PCI DSS interact with our SOC 2 or ISO 27001 programme?

Substantial overlap exists in security control domains, particularly around access management, encryption, logging, and vulnerability management. A mature SOC 2 or ISO 27001 programme typically reduces PCI DSS remediation effort by 30–50%. The control mapping is not one-to-one, however PCI DSS has specific evidence and scope requirements that SOC 2 and ISO 27001 do not impose, particularly around the CDE, payment page script management, and segmentation testing.

Can SecurityWall serve as our QSA from start to finish?

Yes. SecurityWall is a PCI SSC-listed QSA. We deliver gap assessment, remediation advisory, formal ROC, and AoC issuance as a single coordinated engagement. Where governance frameworks require advisory-assessment separation, we split the QSA team conducting the formal ROC from the team conducting prior advisory work.

What does PCI DSS realistically cost for a SaaS company?

Cost depends on environment complexity, validation pathway (SAQ D-SP versus full ROC), and starting compliance posture. A Series B SaaS with prior SOC 2 typically runs in a range that is meaningfully lower than a greenfield programme. We provide scoped pricing within 24 hours of an initial scoping conversation there is no standard rate card because no two SaaS environments are alike.

What is the next step if we want to engage SecurityWall?

A 30-minute scoping conversation to confirm classification, validation pathway, current cloud architecture, and timeline constraints. From that conversation we produce a scoped engagement proposal with timeline, deliverables, and pricing within 24 hours. No procurement commitment is required to have the scoping call.