Is my SaaS company a merchant or a service provider?

It depends on how you interact with payment card data. If your SaaS platform accepts card payments for its own goods or services, you are a merchant. If your platform processes, stores, or transmits cardholder data on behalf of other businesses — or if you provide services that control or could impact the security of cardholder data — you are a service provider. Many SaaS companies are both: a merchant for their own subscription billing and a service provider for customer payment flows they facilitate. The distinction matters because merchants and service providers have different validation requirements under PCI DSS.

Do I need PCI DSS if I use Stripe?

Using Stripe or another PCI-compliant payment processor significantly reduces your PCI scope, but it does not eliminate your obligations entirely. If you use Stripe Elements or Checkout where card data never touches your servers, you likely qualify for the shortest self-assessment questionnaire (SAQ A or SAQ A-EP). However, you are still responsible for securing your integration, protecting your Stripe API keys, ensuring your pages that load payment forms are not compromised, and maintaining evidence of your reduced scope. The PCI Council is clear: outsourcing payment processing does not outsource accountability.

What is a service provider Level 1 vs Level 2?

PCI DSS classifies service providers into two levels based on transaction volume. Level 1 applies to service providers that store, process, or transmit more than 300,000 card transactions per year, or any provider designated as Level 1 by a card brand. Level 1 providers must undergo an annual on-site assessment by a Qualified Security Assessor (QSA) and submit a Report on Compliance (ROC). Level 2 service providers handle fewer than 300,000 transactions annually and can validate compliance by completing the appropriate Self-Assessment Questionnaire (SAQ D for service providers) and undergoing quarterly network scans by an Approved Scanning Vendor.

How does PCI DSS apply to marketplace and platform models?

Marketplace and platform models create layered PCI DSS responsibilities. If your platform facilitates payments between buyers and sellers — even if you never touch raw card numbers — you are likely a service provider because you influence the security of the payment transaction. Platforms that use payment facilitator (payfac) models take on additional obligations because they are effectively underwriting sub-merchants. Each layer of the payment flow must be assessed: who onboards merchants, who hosts the checkout experience, who stores transaction records, and who manages disputes. Clarity on these boundaries is essential before scoping your PCI programme.

Can SOC 2 satisfy PCI DSS requirements?

SOC 2 and PCI DSS share meaningful control overlap — particularly around access control, logging, encryption, change management, and vendor management — but SOC 2 cannot satisfy PCI DSS requirements on its own. PCI DSS is far more prescriptive, with specific technical mandates such as quarterly vulnerability scans by an Approved Scanning Vendor, segmentation testing, and detailed cardholder data flow documentation that SOC 2 does not require. However, organisations that already hold SOC 2 Type 2 reports typically find that 40 to 60 percent of their existing controls map directly to PCI DSS requirements, which accelerates the compliance timeline significantly.

How do I handle PCI DSS in a microservices architecture?

In a microservices architecture, the goal is to isolate PCI-scoped services from the rest of your environment. Identify which microservices handle, process, or transmit cardholder data and draw a clear boundary around them. Place PCI-scoped services in a dedicated network segment with strict ingress and egress rules. Use tokenisation so that non-scoped services only ever see tokens, never raw card data. Ensure that inter-service communication within the PCI boundary uses mutual TLS. Apply PCI DSS requirements — including logging, access control, vulnerability management, and code review — to all in-scope services, while documenting the segmentation controls that keep everything else out of scope.

PCI DSS for SaaS Companies: When and How to Comply

Payment Card Industry Data Security Standard (PCI DSS) compliance is not limited to banks and payment processors. Any SaaS company that stores, processes, or transmits cardholder data — or that can affect the security of a payment transaction — falls within scope. With the release of PCI DSS v4.0.1, the requirements have become more explicit about the responsibilities of third-party service providers, making this a critical concern for SaaS platforms of every size.

The challenge for SaaS companies is that PCI DSS was originally written for traditional retail environments. Translating its requirements into the context of cloud-native, multi-tenant platforms with continuous deployment pipelines requires careful interpretation. Many SaaS founders assume that using Stripe or Adyen eliminates their obligations. In practice, the picture is more nuanced: your payment architecture, integration patterns, and the degree to which your platform influences the payment flow all determine your scope and validation requirements.

This guide provides a practical framework for determining when PCI DSS applies to your SaaS company, how to classify your organisation, and how to build a compliance programme that integrates with your existing engineering and security operations.

When PCI DSS applies to SaaS companies

PCI DSS applies whenever your organisation stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). But the standard goes further: it also applies to any entity that could affect the security of cardholder data, even if that entity never directly handles card numbers.

For SaaS companies, this creates three distinct scenarios:

Direct card handling. Your platform collects card numbers through its own forms, stores them for recurring billing, or passes them to a processor via server-side API calls. This is the most obvious trigger and places the full weight of PCI DSS requirements on your infrastructure.

Influencing the payment flow. Your platform hosts the web page where a payment form is loaded, even if the form itself is an iframe from a payment provider. If an attacker could inject malicious scripts into your page to skim card data, you are in scope. This is why PCI DSS introduced the concept of the “entity that can affect the security of the CDE” — your platform’s security posture directly impacts whether cardholder data remains protected.

Providing services that control or could impact security. Your SaaS product provides hosting, managed firewalls, authentication, tokenisation, or other services that form part of another organisation’s cardholder data environment. Even if you never see a card number, your service is in scope because a failure in your controls could compromise the payment chain.

Understanding which of these scenarios applies to your company is the first step in determining your compliance obligations.

Service provider vs merchant classification

PCI DSS draws a clear line between merchants and service providers, and SaaS companies often fall into one or both categories.

Merchant classification

A merchant is any entity that accepts payment cards as payment for goods or services. If your SaaS company charges customers via credit card for subscriptions, you are a merchant. Merchant classification is typically straightforward and driven by your acquiring bank, which assigns you a merchant level based on your annual transaction volume across all card brands.

For most SaaS companies, merchant obligations are relatively contained — especially if you use a hosted payment page or tokenisation service that keeps card data off your servers.

Service provider classification

A service provider is any entity (other than a card brand) that is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity, or that provides services that control or could impact the security of cardholder data.

This second clause is critical for SaaS platforms. If your product provides infrastructure, hosting, security services, or payment-adjacent functionality to other businesses, you may be classified as a service provider regardless of whether raw card data flows through your systems.

Common examples of SaaS companies classified as service providers include:

Payment orchestration platforms that route transactions across multiple processors
E-commerce platforms that host checkout pages for merchants
Subscription management tools that store tokenised payment methods and trigger recurring charges
Cloud hosting providers that host environments where cardholder data is processed
Managed security service providers that monitor or manage firewalls, intrusion detection, or logging for payment environments

Dual classification

Many SaaS companies are simultaneously merchants (for their own billing) and service providers (for customer payment flows). Each classification carries its own validation requirements, and you must satisfy both.

Service provider levels and validation requirements

The card brands — Visa, Mastercard, American Express, Discover — each define their own criteria for service provider levels, but the most commonly referenced thresholds are:

Level 1 service providers

Level 1 applies if your organisation:

Stores, processes, or transmits more than 300,000 card transactions per year, or
Is designated as Level 1 by any card brand for any reason (which can happen if you suffer a breach or are deemed high-risk)

Level 1 service providers must:

Undergo an annual on-site assessment conducted by a Qualified Security Assessor (QSA)
Submit a Report on Compliance (ROC) to each card brand or acquiring bank that requires it
Complete quarterly external network vulnerability scans by an Approved Scanning Vendor (ASV)
Submit an Attestation of Compliance (AOC) signed by the QSA

Level 2 service providers

Level 2 applies to service providers that store, process, or transmit fewer than 300,000 card transactions per year and have not been designated as Level 1 by a card brand.

Level 2 service providers may:

Complete the Self-Assessment Questionnaire D for Service Providers (SAQ D-SP)
Complete quarterly external vulnerability scans by an ASV
Submit an AOC signed by an officer of the company

Some acquiring banks and business partners may still require a QSA-led assessment even for Level 2 providers, particularly if your platform handles sensitive payment functions.

Common SaaS payment architectures and PCI implications

Your payment architecture determines the size and complexity of your PCI scope. Here are the most common patterns and their compliance implications.

Redirect or hosted payment page

You redirect customers to a payment provider’s hosted page (e.g., Stripe Checkout, Adyen’s hosted payment page). Card data never enters your environment. This is the simplest architecture from a PCI perspective. You are still responsible for securing the page that initiates the redirect and protecting your API credentials, but your scope is minimal. Most companies in this category qualify for SAQ A.

Embedded payment form (iframe or JavaScript SDK)

You embed a payment provider’s form into your own page using an iframe or JavaScript SDK (e.g., Stripe Elements, Braintree Drop-in UI). Card data is captured by the provider’s code running on your page, but your server never receives it. However, because your page hosts the payment form, a cross-site scripting (XSS) attack on your page could compromise the payment flow. This typically requires SAQ A-EP, which adds requirements around vulnerability scanning and secure development.

Direct API integration

Your server-side code collects card data from your frontend and passes it to a payment processor via API. Card data transits your infrastructure. This is the most scope-intensive architecture and requires full SAQ D or a QSA-led ROC. Every system that touches or could touch cardholder data is in scope, including web servers, application servers, databases, and the network infrastructure connecting them.

Payment orchestration and marketplace models

If your platform routes payments between buyers and sellers, aggregates transactions, or acts as a payment facilitator, you have the broadest scope. You must map every component that participates in the payment flow, identify where cardholder data is created, transmitted, and stored, and apply PCI DSS controls to the entire chain.

Marketplace models introduce additional complexity because you may need to assess not only your own platform but also the onboarding, monitoring, and risk management of sub-merchants on your platform.

Subscription billing with tokenisation

You store tokens (not raw card numbers) provided by your payment processor and use them to trigger recurring charges. The processor handles the actual card data. This is a common and effective architecture for reducing scope. However, you must ensure that tokens are managed securely, that your token vault access is restricted, and that your integration with the processor meets PCI DSS requirements for secure transmission and authentication.

Building PCI DSS into your SDLC

PCI DSS Requirement 6 mandates that organisations develop and maintain secure systems and software. For SaaS companies practising continuous delivery, this means embedding PCI controls directly into your software development lifecycle rather than treating security as a gate at the end.

Secure coding practices

Requirement 6.2.1 requires that developers are trained in secure coding techniques relevant to their role, including common vulnerability classes such as injection attacks, broken authentication, cross-site scripting, and insecure deserialisation. Training must be updated at least annually.

Maintain a secure coding standard that your engineers reference during development. This standard should address input validation, output encoding, authentication and session management, error handling and logging, and cryptographic practices.

Code reviews

Requirement 6.2.3 requires that custom code is reviewed prior to release. Code reviews must specifically examine code for vulnerabilities and must be performed by individuals other than the original developer. Automated static analysis tools can supplement manual reviews but do not replace them entirely under PCI DSS.

In practice, this means your pull request workflow must include a security-aware review step for any code that runs within the cardholder data environment. Many SaaS companies implement this as a combination of automated SAST (Static Application Security Testing) in the CI pipeline and mandatory peer review for changes to PCI-scoped services.

Dependency management

Requirement 6.3.2 requires an inventory of custom and third-party software components, and that known vulnerabilities are identified and addressed. Maintain a software bill of materials (SBOM) for your PCI-scoped services. Integrate dependency scanning (e.g., Dependabot, Snyk, or Trivy) into your CI/CD pipeline to detect and flag vulnerable dependencies before they reach production.

PCI DSS v4.0.1 places increased emphasis on managing risks from third-party scripts, particularly JavaScript libraries loaded on payment pages. Requirement 6.4.3 requires organisations to manage all payment page scripts, confirm each script is authorised, and ensure the integrity of scripts is maintained.

Change management

Requirement 6.5.1 requires that changes to production environments follow a documented change management process that includes impact analysis, documented approval by authorised parties, testing to verify the change does not introduce a security vulnerability, and rollback procedures.

For SaaS companies with automated deployment pipelines, this translates to documented CI/CD workflows with approval gates, automated test suites that validate security controls, and deployment logs that provide an audit trail.

Multi-tenant considerations

Multi-tenancy is fundamental to SaaS economics but introduces specific challenges for PCI DSS compliance.

Data isolation

If multiple tenants share infrastructure and any of those tenants process cardholder data, you must demonstrate that a compromise of one tenant’s environment cannot lead to unauthorised access to another tenant’s cardholder data. This requires logical or physical isolation controls depending on your architecture.

Common approaches include:

Separate databases or schemas per tenant with enforced access boundaries at the application and database layers
Row-level security with cryptographic enforcement ensuring that queries can only return data belonging to the authenticated tenant
Dedicated encryption keys per tenant so that even if data isolation fails, the data remains unreadable without the tenant-specific key

Tenant-level access controls

PCI DSS Requirement 7 mandates that access to system components and cardholder data is restricted to individuals whose jobs require such access. In a multi-tenant environment, this extends to ensuring that your operational staff can only access tenant data when authorised and that all access is logged.

Implement role-based access control (RBAC) with the principle of least privilege. Ensure that administrative access to tenant-specific cardholder data environments requires explicit authorisation, is time-limited, and generates audit logs that capture who accessed what, when, and why.

Shared infrastructure risks

Shared infrastructure components — load balancers, logging pipelines, monitoring systems, container orchestration platforms — must be assessed to determine whether they are in scope. If a shared component can access, route, or log cardholder data from any tenant, it is in scope for PCI DSS even if its primary function is not payment-related.

Document your shared services architecture and identify which components are PCI-scoped. Apply segmentation controls to ensure that non-scoped components cannot access the cardholder data environment, and validate segmentation effectiveness through penetration testing as required by PCI DSS.

API security for payment services

Modern SaaS platforms expose payment functionality through APIs, creating a distinct attack surface that PCI DSS requires you to address.

Tokenised APIs

Design your APIs so that cardholder data is tokenised before it reaches your core application logic. Payment tokens should be generated by your payment processor or a dedicated tokenisation service, and your application should only work with tokens, never raw card numbers. This approach dramatically reduces your PCI scope by keeping the majority of your API endpoints out of the cardholder data environment.

Ensure that your tokenisation implementation meets PCI DSS requirements: tokens must not be reversible through any mechanism available to your application, and the token vault must be isolated and independently secured.

PCI-scoped microservices

In a microservices architecture, identify which services handle cardholder data and draw a hard boundary around them. PCI-scoped microservices should:

Run in a dedicated network segment with strict firewall rules (Requirement 1)
Use mutual TLS for all inter-service communication within the PCI boundary (Requirement 4)
Implement independent authentication and authorisation (Requirement 7 and 8)
Maintain comprehensive audit logs that capture all access to cardholder data (Requirement 10)
Be subject to quarterly internal vulnerability assessments and annual penetration tests (Requirement 11)

Non-scoped services should communicate with PCI-scoped services only through well-defined APIs, and should never receive raw cardholder data in responses.

Securing webhooks

Payment providers send webhook notifications to your endpoints when transactions are completed, disputed, or refunded. These webhooks can contain sensitive data and are a common target for spoofing attacks.

Verify webhook signatures using the provider’s published verification mechanism. Validate that webhook payloads conform to expected schemas before processing them. Ensure that webhook endpoints enforce TLS 1.2 or higher. Log all received webhooks for audit purposes, and implement idempotency to prevent replay attacks.

If webhook payloads contain cardholder data, the endpoint that receives them is in scope for PCI DSS. Design your integration so that webhooks contain only references (such as transaction IDs or tokens) rather than raw card data wherever possible.

Integrating PCI DSS with existing SOC 2 or ISO 27001 programmes

Most SaaS companies pursuing PCI DSS already hold or are working towards SOC 2 or ISO 27001 certification. Treating these frameworks as complementary rather than separate workstreams reduces effort and improves your overall security posture.

Control overlap with SOC 2

SOC 2 Trust Service Criteria and PCI DSS share significant overlap in several domains:

Access control — SOC 2 CC6.1-CC6.3 maps closely to PCI DSS Requirements 7 and 8 (restrict access, identify and authenticate users)
Change management — SOC 2 CC8.1 aligns with PCI DSS Requirement 6.5 (change control procedures)
Monitoring and logging — SOC 2 CC7.1-CC7.2 corresponds to PCI DSS Requirement 10 (logging and monitoring)
Risk assessment — SOC 2 CC3.1-CC3.2 maps to PCI DSS Requirement 12.2 (risk assessment process)
Vendor management — SOC 2 CC9.2 aligns with PCI DSS Requirement 12.8 (third-party service provider management)

Where controls overlap, maintain a single implementation and map it to both frameworks. Use a unified policy library, a single evidence repository, and shared control testing schedules.

Control overlap with ISO 27001

ISO 27001 Annex A controls provide broader coverage that maps to many PCI DSS requirements:

A.8 (Asset management) maps to PCI DSS Requirement 2 (inventory of system components)
A.9 (Access control) maps to PCI DSS Requirements 7 and 8
A.12 (Operations security) maps to PCI DSS Requirements 5, 6, and 11 (malware protection, secure development, security testing)
A.14 (System acquisition, development, and maintenance) maps to PCI DSS Requirement 6
A.18 (Compliance) maps to PCI DSS Requirement 12 (information security policy)

Organisations with a mature ISO 27001 ISMS will find that the management framework — risk assessment methodology, internal audit programme, management review process — translates directly to PCI DSS Requirement 12.

Where PCI DSS goes further

Despite the overlap, PCI DSS imposes requirements that neither SOC 2 nor ISO 27001 mandate:

Quarterly ASV scans of external-facing systems (Requirement 11.3.2)
Annual penetration testing that specifically tests segmentation controls (Requirement 11.4)
Specific encryption standards for cardholder data at rest and in transit, including prohibition of certain deprecated protocols (Requirements 3 and 4)
Payment page script management including integrity monitoring of all scripts loaded on payment pages (Requirement 6.4.3)
Cardholder data flow diagrams and network diagrams that specifically trace the path of cardholder data through your environment (Requirement 1.2.4)

Plan for these additional requirements as discrete workstreams that supplement your existing control framework.

Practical timeline for SaaS compliance

The time required to achieve PCI DSS compliance depends on your current security maturity, payment architecture, and whether you are pursuing Level 1 or Level 2 validation.

Months 1-2: Scoping and gap analysis

Determine your classification (merchant, service provider, or both) and level
Document cardholder data flows and identify all systems, personnel, and processes in scope
Conduct a gap analysis against PCI DSS v4.0.1 requirements
Identify quick wins and major remediation efforts
Select a QSA if pursuing Level 1 validation

Months 2-4: Remediation and control implementation

Address gaps identified in the analysis, prioritising high-risk findings
Implement or strengthen network segmentation to minimise scope
Deploy required technical controls: encryption, logging, access management, vulnerability scanning
Develop or update policies and procedures to meet Requirement 12
Train development teams on secure coding practices per Requirement 6

Months 4-5: Validation and testing

Engage an ASV for quarterly external vulnerability scans
Conduct internal vulnerability assessments
Perform penetration testing, including segmentation validation
Run tabletop exercises for your incident response plan
Collect and organise evidence for all 12 requirement families

Months 5-6: Assessment and certification

Complete the SAQ (Level 2) or undergo the QSA on-site assessment (Level 1)
Remediate any findings identified during the assessment
Submit your AOC and, if applicable, ROC to your acquiring bank and business partners
Establish a continuous compliance cadence: quarterly scans, annual assessments, ongoing monitoring

Accelerated timeline

SaaS companies with mature security programmes — particularly those already holding SOC 2 Type 2 or ISO 27001 certification — can often compress this timeline to three to four months. The key accelerators are: minimal cardholder data scope through tokenisation, existing control frameworks that map to PCI DSS, automated evidence collection, and early QSA engagement to avoid surprises during the formal assessment.

Companies starting from scratch or with a direct API integration architecture that places extensive infrastructure in scope should plan for six to nine months and budget accordingly for both technical remediation and assessor fees.