A SaaS payment platform can fall within PCI DSS even when it does not behave like a traditional card processor or store full card numbers in its main application database. If the service stores, processes, or transmits payment account data, or can affect the security of a customer’s cardholder data environment, the relevant service and supporting systems may be in PCI DSS scope.
Table of Contents
Copy the responsibility-and-evidence record.
For many SaaS companies, the first mistake is therefore not a missing firewall rule or an incomplete policy. It is choosing the wrong compliance model. A payment platform serving merchants may be acting as a PCI DSS service provider or third-party service provider rather than as a merchant eligible for a lightweight merchant Self-Assessment Questionnaire.
As reviewed in September 2026, the PCI Security Standards Council continues to publish PCI DSS v4.0.1 as the current PCI DSS baseline. The future-dated v4.x requirements became effective on March 31, 2025, so they are no longer optional “best practices” for environments where they apply.
The same PCI DSS baseline is relevant to payment platforms serving customers in the United States and the United Kingdom. PCI DSS is a global payment-card security standard rather than a US or UK statute, while the exact validation and reporting expectations may be set by payment brands, acquirers, customers, or other compliance-accepting entities. Privacy law, financial regulation, contractual security duties, and breach-notification rules remain separate questions.
Start With Your Role, Not With an SAQ
The phrase “PCI compliant SaaS” can hide several different architectures. One platform may simply create a redirect to a processor-hosted checkout. Another may embed hosted payment fields in a merchant’s page. A third may receive card data through its API, tokenize it, and relay transactions to multiple processors. Those systems should not be given the same scope simply because customers describe all three as payment SaaS.
| Architecture | Typical PCI question | Main scoping concern |
|---|---|---|
| Redirect to a processor-hosted checkout | Does the SaaS ever receive payment account data or control systems that can affect the payment flow? | Merchant scope may be reduced, but the SaaS must still assess its own service and integrations. |
| Embedded hosted fields or iframe | Who supplies and secures the payment elements, surrounding page, and browser scripts? | Payment-page security and shared responsibilities require careful documentation. |
| API receives PAN or other account data | Which API gateways, services, queues, logs, databases, and support systems touch or can expose that data? | The cardholder data environment can extend well beyond the payment microservice. |
| Token-only payment orchestration | Can the platform decrypt the data, recover PAN, or otherwise affect systems protecting account data? | Tokenization or encryption may reduce scope, but it does not create an automatic exemption. |
| Multi-tenant payment SaaS | Do multiple customers share infrastructure, applications, databases, or management layers? | PCI DSS service-provider requirements and potentially Appendix A1 need to be evaluated. |
Before selecting a questionnaire, map the actual payment flow. Trace browser input, APIs, application services, queues, databases, logs, backups, analytics, support consoles, administrative tools, webhooks, cloud services, token vaults, and every third party that can receive or influence account data.
This is also a useful moment to review your wider API boundaries. Kioptrix’s API security checklist for SaaS founders covers tenant authorization, tokens, webhooks, secret handling, deployed controls, and other API weaknesses that can sit immediately beside a payment flow even when they are not uniquely PCI problems.
A SaaS Payment Provider Cannot Simply Borrow a Merchant SAQ
This distinction is especially important for founders who have previously completed SAQ A for an online store and assume the same form can prove compliance for a payment SaaS product.
It cannot. PCI SSC states that SAQ D for Service Providers is the only SAQ intended for SAQ-eligible service providers. Merchant SAQs such as SAQ A, A-EP, B, C, and merchant SAQ D are designed for merchant scenarios and contain reduced or different requirement sets based on specific eligibility conditions.
For a service provider, all PCI DSS requirements must first be considered against the service, systems, access, and security impact. A requirement that genuinely does not apply can be marked not applicable when the applicable reporting method permits it, but that conclusion needs a defensible explanation. The process is not “pick the shortest SAQ and see whether it fits.”
Whether a particular provider may self-assess with SAQ D for Service Providers or needs another form of assessment or reporting should be confirmed with the entity accepting the compliance validation. PCI SSC defines the standard and assessment tools, while payment brands, acquirers, customers, and other compliance programs can impose their own validation expectations.
Not Storing PAN Does Not Automatically Put a SaaS Platform Out of Scope
“We never store card numbers” is useful architecture information, but it is not a complete PCI scoping conclusion.
A service provider may be relevant to PCI DSS because it directly or indirectly facilitates storage, processing, or transmission of payment data, or because its systems can affect the security of another entity’s payment account data. PCI SSC’s service-provider scoping guidance specifically directs providers to examine both the services they perform and their potential impact on customers’ payment environments.
Consider a SaaS billing layer that never persists PAN but generates payment sessions, loads browser-side code, manages processor credentials, receives signed payment webhooks, and lets support administrators modify merchant payment settings. “No card database” does not describe the whole security boundary. An attacker who compromises the platform may still be able to alter payment routing, steal credentials, manipulate browser behavior, or affect systems that protect cardholder data.
Encryption can change the analysis, but only under specific conditions. PCI SSC clarified in 2026 that a third-party service provider receiving or storing only data encrypted by another entity may be able to treat that encrypted data as out of scope where the provider has no ability to decrypt it, no access to the keys, and no access to clear-text data. That is much narrower than saying “encrypted equals out of scope.” Architecture and key custody matter.
The PCI DSS v4.0.1 Areas That Hit SaaS Payment Platforms Hardest
PCI DSS contains 12 broad requirement families, and a service provider must consider the full applicable standard. In practice, several areas deserve particularly early attention in a modern SaaS payment architecture.
Payment-page scripts and e-skimming
If your service delivers, hosts, embeds, or materially affects an e-commerce payment page, browser-side security deserves more than a once-a-year screenshot. PCI DSS Requirements 6.4.3 and 11.6.1 were introduced to address payment-page script and tampering risks and became effective on March 31, 2025.
The PCI SSC’s payment-page security and e-skimming guidance explains the focus: payment-page scripts need authorization, integrity protection, and inventory controls, while payment pages and relevant HTTP headers need mechanisms capable of detecting unauthorized modification. SaaS providers that supply embedded checkout technology should determine exactly which controls they operate for merchants and which controls remain with the merchant.
Identity, privileged access, and MFA
Production engineers, support personnel, database administrators, CI/CD identities, cloud administrators, and service accounts can all become part of the security story. PCI DSS v4.x requires multifactor authentication for applicable access into the cardholder data environment, while access privileges still need to follow business need and least-privilege principles.
Do not limit the exercise to customer login. A beautifully protected merchant dashboard does little good if a broadly privileged internal support account can alter payment configuration using a single credential.
Secure software development and change control
Payment SaaS changes continuously. New processor connectors, checkout options, webhooks, JavaScript dependencies, infrastructure modules, and admin features can alter scope or introduce new attack paths between assessments.
Your development process should therefore connect security requirements to design, code review, dependency management, testing, change approval, vulnerability remediation, and production deployment. PCI’s separate Secure Software Standard may also be relevant to vendors developing payment software, and eligible SaaS software can be validated under that program. That validation is separate from PCI DSS, however, and using validated payment software does not by itself make the operating SaaS provider PCI DSS compliant.
Secrets, tokens, logs, and secondary data copies
Scope often expands quietly through operational convenience. A payment API may avoid storing PAN while an error logger captures request bodies, a support tool records screenshots, a queue retains failed messages, or a debugging platform stores payloads longer than expected.
Search for account data rather than assuming engineers know every location. Review API keys, processor credentials, signing secrets, database exports, logs, observability tools, support systems, backups, dead-letter queues, developer environments, and data copied into analytics or AI tooling.
Vulnerability management and penetration testing
Automated vulnerability scanning and human-led penetration testing solve different problems, and PCI DSS can require specific testing activities depending on the environment. Payment SaaS teams should define their in-scope internet-facing assets, authenticated application roles, APIs, segmentation boundaries, administrative interfaces, cloud components, and significant-change triggers before commissioning a test.
If you are budgeting for independent testing, Kioptrix’s penetration testing cost and scope guide explains why a quote covering one public web application is not equivalent to a test covering authenticated roles, APIs, cloud infrastructure, and retesting. For PCI work, confirm that the testing methodology and assessor expectations actually match the requirements you need to validate.
Multi-Tenant Payment SaaS May Have Additional PCI DSS Requirements
Multi-tenancy deserves explicit attention because shared infrastructure can turn a seemingly ordinary authorization bug into a cross-customer payment-security problem.
PCI SSC explains that Appendix A1 applies to qualifying multi-tenant service providers offering shared environments where customers share resources such as infrastructure, applications, SaaS platforms, or databases and customers manage their own environment or exercise administrative control over their own segment.
Do not assume every multi-tenant application automatically has identical Appendix A1 applicability. Determine how tenants are separated, what customers administer, which shared layers can influence tenant security, and how the service architecture maps to the PCI definition.
From an engineering perspective, tenant isolation should also be tested at the application layer. Network segmentation cannot rescue an API that accepts a valid object identifier from Tenant A while authenticated as Tenant B.
Your Cloud Provider’s AOC Does Not Make Your SaaS Compliant
A cloud provider, processor, tokenization service, managed database, CDN, WAF provider, or payment gateway may operate controls that help you satisfy PCI DSS. Those controls do not teleport compliance into your own application.
Instead, treat PCI as a chain of defined responsibilities. For each third party, identify the service you consume, systems involved, applicable PCI requirements, evidence available, customer configuration requirements, and controls that remain yours.
The general vendor-review mechanics overlap with broader SaaS security due diligence. Kioptrix’s vendor security questionnaire template provides a useful framework for checking data access, integrations, privileged access, evidence dates, subprocessors, and product-specific scope rather than accepting a logo on a trust page as proof of universal coverage.
Build a PCI Responsibility Matrix Customers Can Actually Use
This is one of the most commercially useful pieces of a mature payment-platform compliance program.
PCI SSC guidance says a third-party service provider should give customers enough information to understand which PCI DSS requirements the provider meets and which remain the customer’s responsibility. A responsibility matrix is a practical way to document that division.
The Council’s guidance on service-provider compliance evidence also explains that providers undergoing their own PCI DSS assessment should provide sufficient evidence for customers to confirm that the assessment covered the relevant service. Where an Attestation of Compliance is available, customers can request it.
| Responsibility-matrix field | What it should answer |
|---|---|
| PCI DSS requirement | Which specific requirement or control area is being mapped? |
| Provider responsibility | What does the SaaS provider operate or maintain? |
| Customer responsibility | What must the merchant or downstream service provider configure or operate? |
| Shared responsibility | Where do both parties need controls for the requirement to be effective? |
| Service scope | Which product, region, environment, payment method, and integration model are covered? |
| Evidence | What AOC, assessment evidence, documentation, configuration guide, or other proof supports the statement? |
| Dependency | Does another processor, cloud provider, or nested service provider perform part of the control? |
Put important responsibility commitments into appropriate contracts and customer documentation rather than leaving everything in a sales questionnaire. Kioptrix’s SaaS security addendum checklist is a useful companion for defining security obligations, evidence, subprocessors, incident notification, vulnerability handling, and other operational commitments without confusing contractual language with an audit report.
Copy one responsibility-and-evidence row
Repeat this entry for each applicable requirement and specific service configuration. This is a working aid, not an official PCI SSC form or an assessment conclusion. Complete it with the people operating the control and confirm the evidence needed by the customer or assessor.
Record version / date / owner: Service, region, environment and integration covered: PCI DSS requirement / applicability rationale: Provider action / responsible team: Customer action / required configuration: Shared handoff / trigger / receiving owner: Nested provider and dependency / scope reference: Evidence reference / date / exact service covered: Assessment evidence or AOC coverage confirmed by: Operational check / actual result / remaining limits: Customer documentation or agreement reference: Unconfirmed allocation / missing evidence / resolution owner: Review trigger / next review date:
A phrase such as “shared” is not enough: state who performs each action, who receives the result and how the customer can verify it. Do not mark a requirement in place because another provider’s AOC exists without checking the relevant service and responsibilities.
A Practical PCI DSS Roadmap for a SaaS Payment Platform
- Define the service. Identify the exact product, payment features, deployment regions, legal entities, processor connections, and customer integration models included in the assessment.
- Confirm your PCI role. Determine whether you operate as a merchant, service provider, third-party service provider, payment software vendor, or more than one of these depending on the service.
- Map account-data flows. Trace cardholder data, sensitive authentication data, tokens, encrypted values, processor credentials, browser scripts, webhooks, logs, backups, and support access from entry to deletion.
- Define the CDE and connected systems. Identify systems that store, process, or transmit account data as well as systems that can connect to or affect the security of those components.
- Inventory third parties. Collect relevant PCI evidence from payment processors, hosting providers, vaults, cloud platforms, managed services, and other providers, then document the responsibilities you retain.
- Gap-assess PCI DSS v4.0.1. Consider every requirement applicable to the service rather than beginning with a merchant SAQ. Document genuine non-applicability and address additional service-provider requirements.
- Fix architectural scope where practical. Remove unnecessary account-data handling, prevent payment data from entering logs and support tools, restrict privileged paths, segment systems, and reduce unnecessary access without assuming scope reduction until it is validated.
- Collect operating evidence. Preserve change records, access reviews, vulnerability results, penetration-test evidence, monitoring records, incident exercises, inventories, third-party reviews, and other artifacts showing controls operate rather than merely exist on paper.
- Validate with the right method. Confirm the required assessment and reporting path with your acquirer, payment brand, customer, assessor, or other compliance-accepting entity, and keep the responsibility matrix synchronized with the service customers actually buy.
Common PCI Mistakes in SaaS Payment Companies
“Stripe, Adyen, or another processor is PCI compliant, so we are too.”
A compliant processor can take important payment functions out of your hands. It does not assess your application code, administrator access, integrations, cloud configuration, scripts, logs, or responsibilities that remain outside the processor’s validated service.
“We tokenize immediately, so PCI DSS ends at the tokenization call.”
Tokenization can substantially reduce exposure when designed correctly, but scope depends on where clear-text data appears, who controls the tokenization process, whether data can be recovered, which systems connect to the payment environment, and what can affect its security.
“Our SOC 2 report covers PCI.”
SOC 2 can be valuable assurance evidence, but it is not a substitute for a PCI DSS assessment. The frameworks have different criteria, purposes, reporting structures, and scopes. A customer asking for a PCI AOC is not necessarily asking for another copy of your SOC 2 report.
“We passed the assessment last year, so architecture changes are somebody else’s problem.”
PCI scope can change when you add a new processor, payment method, region, acquisition, cloud account, administrative tool, JavaScript dependency, API gateway, token vault, support workflow, or logging platform. Compliance evidence has a shelf life, while architecture has a habit of growing new rooms overnight.
Frequently Asked Questions
Does PCI DSS apply if our SaaS platform never stores card numbers?
Potentially. Storage is only one part of PCI scope. Processing, transmitting, direct or indirect facilitation, connectivity, and the ability to affect the security of a cardholder data environment can also matter. Review the complete architecture rather than the database schema alone.
Which SAQ does a SaaS payment provider use?
For an SAQ-eligible service provider, PCI SSC states that SAQ D for Service Providers is the only service-provider SAQ. Do not use merchant SAQ A or another merchant questionnaire as evidence of service-provider PCI DSS compliance. Confirm the actual validation method required by the entity accepting your compliance evidence.
Do we need a Qualified Security Assessor?
Not every service provider follows one universal assessment path. Requirements for an independent QSA assessment, ROC, SAQ, AOC, or other validation evidence can depend on payment-brand programs, transaction or service-provider classifications, acquirer rules, customer requirements, and contractual commitments. Confirm the required path before buying an assessment engagement.
Does using a PCI-compliant cloud provider reduce our responsibility?
It can allow you to rely on controls the provider performs within its validated scope, but you remain responsible for understanding the boundary. Your application, identities, configuration, code, data flows, customer settings, and controls above the cloud-provider layer do not become compliant automatically.
What should we give enterprise customers asking for proof of PCI compliance?
Where applicable, provide appropriate current compliance evidence such as the relevant Attestation of Compliance along with enough scope information for the customer to understand whether the service they use was included. A customer-facing responsibility matrix is particularly valuable because it explains which PCI DSS responsibilities you meet and which remain with the customer.
Is PCI Secure Software validation the same as PCI DSS compliance?
No. The PCI Secure Software Standard addresses payment-software security and can apply to eligible SaaS software, while PCI DSS addresses the security of environments that store, process, transmit, or can affect payment account data. Secure Software validation may support a stronger payment product, but PCI SSC explicitly treats it as separate from PCI DSS validation.
The Most Useful First Deliverable Is a Map, Not a Certificate
If a SaaS payment team is beginning PCI work, the highest-value first artifact is usually a payment-data and responsibility map: where account data enters, which components can affect it, who can reach those components, which third parties participate, and exactly where responsibility changes hands.
That map tells you what needs to be segmented, removed, tested, documented, contracted, and assessed. It also prevents the expensive version of PCI compliance in which a company spends months collecting evidence for the wrong boundary.
Use PCI DSS v4.0.1 as the baseline, confirm your service-provider role early, document shared responsibilities, and validate the required reporting route with the party that will actually accept your compliance evidence. Scope reduction is valuable, but only when the architecture earns it.
Responsibility worksheet reviewed: 2026-10-23. Checked the linked PCI SSC FAQs 1576 and 1578 and added a blank service-specific evidence record. No SaaS architecture or control was assessed for this update.