PCI DSS compliance for a marketplace starts with one question that is more important than company size, transaction volume, or which payment processor you use: what role does the marketplace actually play in the payment flow?
Table of Contents
Copy the role-and-handoff record for a specific marketplace payment flow.
A marketplace can be a merchant, a third-party service provider, or both. It may host checkout pages for thousands of sellers while never storing a full card number. It may use a payment processor for card capture but still control browser scripts, APIs, access systems, cloud infrastructure, seller onboarding, and other components capable of affecting payment security.
That is why “we use a PCI-compliant payment processor” is useful information, but it is not a complete PCI DSS strategy. The PCI Security Standards Council explains that outsourcing payment processing does not automatically eliminate a merchant’s PCI DSS responsibilities. A business may still need to validate compliance, manage its providers, document responsibility boundaries, and maintain security controls appropriate to its environment.
For marketplace operators, the safest starting point is therefore not choosing a Self-Assessment Questionnaire. It is drawing the payment architecture, identifying every party involved, and assigning responsibility before deciding what validation path applies.
If you are also budgeting the work, the broader PCI DSS compliance cost guide for ecommerce stores explains why checkout architecture usually changes the cost more dramatically than revenue alone.
PCI DSS applies to functions, not the word “marketplace”
PCI DSS does not give an online platform a special exemption simply because it calls itself a marketplace, platform, software company, merchant of record, or payments intermediary.
The relevant questions are functional. Does the organization store, process, or transmit payment account data? Can its systems affect the security of an environment that does? Is it performing PCI-related functions on behalf of another entity?
The PCI SSC’s definition of a merchant also makes an important marketplace distinction: an organization can be a merchant for one activity and a service provider when it stores, processes, or transmits cardholder data on behalf of other merchants or service providers.
That dual-role possibility matters. A platform might accept card payments for its own subscription fees while simultaneously providing payment-related technology or infrastructure to independent sellers.
| Marketplace activity | PCI question to investigate | Possible significance |
|---|---|---|
| Marketplace sells its own goods or services | Does it accept cards as the merchant? | Merchant PCI responsibilities may apply |
| Marketplace hosts payment functions for sellers | Can marketplace systems store, process, transmit, or affect payment account data? | Service-provider responsibilities may apply |
| Marketplace uses a processor-hosted checkout | What remains on the marketplace website and infrastructure? | Scope may be reduced, not necessarily eliminated |
| Marketplace provides payment APIs or payment-related infrastructure | Can those systems affect another entity’s cardholder data environment? | Service-provider scope may need assessment |
| Marketplace does both platform payments and its own billing | Are different PCI roles being performed? | The organization may need to evaluate more than one role |
Practical rule: describe what the platform does before deciding what the platform is.
Start with the payment-data flow
A marketplace PCI project becomes much easier once the team can draw the path of a card transaction without using vague boxes labeled “payments” or “Stripe.”
Map the transaction from the customer’s browser or device through every marketplace-controlled and third-party component that participates in payment acceptance, routing, authentication, fraud detection, processing, storage, settlement, support, and administration.
- Where does the customer enter card information?
- Who generates the fields that collect that information?
- Can marketplace JavaScript alter or interfere with the payment experience?
- Does payment account data ever pass through a marketplace server, API, log, queue, database, support system, analytics tool, or observability platform?
- Does the marketplace store tokens, and can any marketplace system use those tokens to retrieve or cause access to cardholder data?
- Which payment processor, gateway, acquirer, fraud service, cloud provider, hosting provider, CDN, or security vendor can affect payment processing?
- Which organization has the direct merchant relationship for each seller transaction?
- Which party is expected to submit PCI validation evidence to an acquirer, payment brand, processor, or other compliance-accepting entity?
Do not assume tokenization, an iframe, or an API automatically removes a component from scope. The implementation matters. A system that never sees the primary account number may still affect payment security.
For platforms with extensive seller-facing or payment-related APIs, this exercise should connect with ordinary application-security work. The API security checklist for SaaS founders provides a useful companion framework for reviewing authentication, authorization, tenant isolation, tokens, logging, and sensitive workflows outside the narrow PCI questionnaire.
Four marketplace payment architectures create very different PCI workloads
1. Redirect to a payment provider
The customer begins checkout on the marketplace and is redirected to a third-party payment provider that hosts the payment page.
This can substantially reduce the marketplace’s card-data footprint when implemented correctly. It does not mean the marketplace can stop thinking about PCI DSS.
One particularly important current detail is that the PCI SSC clarified in June 2026 that SAQ A includes applicable Approved Scanning Vendor external scanning requirements for merchant ecommerce webpages, including webpages that redirect payment transactions to a third-party service provider.
That makes older advice saying “a redirect means the merchant website has no PCI scanning responsibility” unsafe as a general rule.
2. Embedded provider iframe or hosted payment fields
Here the shopper may appear to remain inside the marketplace experience while the sensitive payment fields originate from the payment provider.
The architecture can remain relatively narrow, but the surrounding page still matters. Malicious or compromised browser scripts can sometimes alter what shoppers see, redirect transactions, or interfere with a legitimate payment integration.
The PCI SSC’s current SAQ A guidance for embedded payment forms includes an eligibility criterion addressing whether the merchant site is susceptible to script attacks that could affect the ecommerce system. The Council distinguishes this iframe situation from a straightforward redirect.
This is a good example of why a marketplace should identify the exact integration rather than recording a generic statement such as “payments are outsourced.”
3. Marketplace-controlled checkout posting directly to a processor
A marketplace may generate more of the checkout interface itself while card information is transmitted directly to a payment processor.
That model can create materially broader obligations because marketplace-controlled systems are closer to payment-data capture and can influence the security of the transaction. Depending on the architecture and compliance program, a broader merchant validation path such as SAQ A-EP or another assessment approach may become relevant.
Do not select SAQ A-EP merely because a diagram on the internet looks similar to yours. PCI SSC states that SAQ eligibility criteria must actually be satisfied, and the organization accepting your compliance evidence determines the required validation and reporting method.
4. Marketplace systems handle cardholder data directly
If raw cardholder data reaches marketplace servers, databases, applications, networks, logging systems, employee workflows, or other infrastructure, the PCI program usually becomes much more substantial.
You may be dealing with a real cardholder data environment rather than a lightweight outsourced-checkout model. Network segmentation, access controls, encryption, vulnerability management, logging, application security, testing, incident response, policies, and evidence collection can all become relevant depending on scope.
At this point the difference between a small merchant and a marketplace is often operational scale. One poorly defined payment component can touch multiple seller workflows, APIs, cloud environments, support teams, and administrative tools.
A marketplace may have merchant responsibilities and service-provider responsibilities at the same time
This is the distinction marketplace teams most often need to get right.
If the marketplace is providing services that store, process, transmit, or can affect the security of payment account data for sellers or other payment participants, it should evaluate whether it is acting as a PCI DSS service provider for those activities.
PCI SSC guidance is intentionally broad here. A service provider can fall within PCI DSS scope even when it does not directly store cardholder data if its services can affect the security of payment account data or the customer’s cardholder data environment.
Marketplace operators should therefore avoid a common shortcut: completing a convenient merchant questionnaire and assuming it also proves the platform’s service-provider compliance.
PCI SSC states that SAQ D for Service Providers is the only SAQ available to SAQ-eligible service providers. Other SAQs are merchant questionnaires.
For larger or more complex platforms, the required evidence may instead involve a Qualified Security Assessor and a Report on Compliance. That determination belongs with the applicable compliance program, not a blog checklist.
Do sellers have their own PCI DSS responsibilities?
Sometimes yes, but a marketplace should not answer this question with one sentence for every seller.
The answer depends on the acquiring and payment model. A seller with its own merchant relationship and connected payment account may have different responsibilities from a seller whose transactions are accepted centrally under a marketplace-controlled arrangement.
The marketplace should document which party is the merchant for the relevant card transaction, which party submits validation evidence, which systems each party controls, and which contractual responsibilities have been allocated to the seller, marketplace, and payment provider.
A sentence such as “our payment processor is PCI compliant, so sellers do not need to worry about PCI” is too broad. The processor’s compliance does not automatically describe the seller’s or marketplace’s responsibilities.
Build a PCI responsibility matrix before collecting compliance evidence
A marketplace usually has more third parties than a conventional online store, so responsibility mapping should be treated as an operating document rather than assessment-week paperwork.
| Area | Questions to document | Evidence to retain |
|---|---|---|
| Payment capture | Who provides the payment form and receives card data? | Architecture diagram, processor documentation, integration configuration |
| Marketplace website | Can scripts, deployments, redirects, DNS, CDN, or hosting changes affect checkout? | Script inventory, change records, scanning evidence, security configuration |
| Processor or gateway | Which PCI functions are performed for the marketplace? | Current AOC and documented service scope |
| Seller environment | Does the seller control any payment page, terminal, application, or payment process? | Seller integration requirements and responsibility statement |
| Marketplace APIs | Can APIs affect payment creation, refunds, account configuration, or payment credentials? | API inventory, access-control evidence, testing records |
| Administrative access | Who can change payment settings or access systems affecting payment security? | Access lists, MFA evidence, approval and review records |
| Nested providers | Does your PSP rely on other relevant providers? | Contractual documentation and available assurance evidence |
| Incident response | Who contacts the acquirer, processor, sellers, security team, and other parties after suspected compromise? | Incident plan, contact list, exercises, escalation procedures |
The matrix should show both responsibility and evidence. “Processor owns encryption” is not enough if nobody can identify which service is covered by the processor’s PCI assessment.
Copy a role-and-handoff record for one payment flow
Complete a separate entry for the marketplace’s own billing and each materially different seller payment arrangement. Describe the parties and system functions before recording a confirmed role or validation path. This worksheet does not determine a legal merchant-of-record relationship or certify PCI compliance.
Flow ID / review date / marketplace entity: Product, seller arrangement, payment channel and region: Party accepting the card transaction / confirmation reference: Marketplace services performed for sellers: Payment form owner / data destinations / supporting systems: Merchant role and service-provider role separately confirmed by: Compliance-accepting entity / validation method / written reference: Marketplace action and owner: Seller action and owner: Processor or nested-provider action / service scope: Shared handoff / trigger / receiving party / expected evidence: Provider AOC or other evidence / date / covered service: Seller-facing instructions / version / acknowledgement reference: Incident escalation owner and contact-record location: Unallocated responsibility / missing evidence / resolution owner: Change requiring review / next review date:
Keep an unresolved role or responsibility visibly open. Do not copy one seller’s conclusion to every arrangement, and do not use a merchant questionnaire as evidence for a separate service-provider function.
A processor’s AOC is evidence, not a magic shield
Marketplace vendor management should go deeper than asking whether a payment company has a PCI logo on its website.
When a third-party service provider has undergone a PCI DSS assessment, the PCI SSC says customers should receive sufficient evidence to verify that the assessed scope covers the services being provided. An applicable Attestation of Compliance can provide that evidence, and customers may need clarification about the services and requirements covered.
For each material payment provider, record:
- Legal entity name.
- Service being used.
- PCI role.
- Date of current compliance evidence.
- Services and environments included in that evidence.
- Material exclusions.
- Which PCI requirements the provider performs.
- Which requirements remain with the marketplace.
- Who reviews the provider’s status each year.
- What happens if the provider’s status changes.
PCI DSS Requirement 12.8 makes third-party oversight a continuing process for organizations using relevant service providers. The work includes due diligence, agreements, responsibility identification, and ongoing monitoring.
If your marketplace already sends broader security questionnaires to SaaS and infrastructure vendors, the vendor security questionnaire template can help organize evidence gathering without turning “PCI compliant?” into a one-box procurement ritual.
Do not let seller onboarding create uncontrolled payment integrations
A marketplace can establish a clean PCI architecture and then quietly destroy it through seller customization.
Examples include sellers adding their own checkout scripts, installing unsupported plugins, routing shoppers to unapproved payment pages, collecting card details through support messages, embedding third-party widgets, or modifying storefront templates near the payment experience.
If sellers can modify checkout-related code, the platform should define exactly which changes are allowed and which are prohibited. Technical enforcement is generally stronger than policy alone.
- Restrict who can modify checkout templates or payment configuration.
- Separate marketing customization from payment-sensitive components where practical.
- Require approved payment integrations rather than arbitrary payment code.
- Control marketplace plugins and third-party scripts capable of influencing checkout.
- Log administrative changes to payment settings.
- Define a rapid process for disabling a compromised seller or integration without taking down the entire marketplace.
This is where marketplace PCI compliance becomes a product-design problem, not merely a compliance-team problem.
Browser-side payment security deserves special attention
Modern marketplace checkout pages may contain analytics, tag managers, consent tools, fraud systems, chat widgets, advertising scripts, experimentation platforms, accessibility tools, customer-support components, and seller-specific features.
Every script does not automatically create the same PCI obligation, but payment-page JavaScript is no longer something an ecommerce team can treat as invisible plumbing.
PCI DSS v4.x introduced stronger attention to browser-side payment risks. The PCI SSC’s payment-page security and e-skimming guidance focuses on managing payment-page scripts and detecting unauthorized changes where Requirements 6.4.3 and 11.6.1 apply.
For a marketplace, the operational lesson is straightforward: know which code can execute around checkout, who authorized it, why it is needed, how changes are controlled, and how suspicious modification will be discovered.
A sprawling tag manager can become a security boundary wearing a marketing badge.
Payment APIs, webhooks, refunds, and seller dashboards belong in the threat model
PCI scope and payment-security risk are related, but they are not identical.
A marketplace API may never receive a card number and still control valuable payment operations. An attacker who compromises seller credentials or an administrative API may be able to alter payout details, change payment settings, manipulate refunds, interfere with transaction routing, or abuse marketplace accounts.
Review payment-adjacent APIs for strong authentication, authorization at the object and tenant level, appropriate secrets management, rate controls, logging, administrative restrictions, and secure webhook verification.
Keep the distinction clear: not every payment fraud control is a PCI DSS requirement, and passing PCI validation does not mean the entire marketplace payment system is resistant to fraud or account takeover.
Testing should follow scope and architecture
Do not purchase a penetration test simply because somebody says every marketplace “needs a PCI pentest.” Applicable vulnerability scanning and penetration-testing obligations depend on PCI scope and the validation path.
At the same time, a complex marketplace with custom checkout code, payment-connected APIs, administrative consoles, cloud infrastructure, seller isolation, and frequent deployments can have compelling security reasons for human-led testing even beyond a narrowly defined PCI requirement.
If you are pricing that work separately from the PCI assessment, the penetration testing cost guide explains what usually changes testing scope, remediation effort, and retest cost.
A practical PCI DSS checklist for marketplace operators
This sequence is more useful than beginning with a questionnaire because it forces the architecture and responsibility questions into the open first.
- Identify every payment model. Include buyer checkout, subscriptions, seller fees, telephone payments, refunds, virtual terminals, mobile payments, and any secondary flows.
- Draw the payment-data flow. Show customer devices, marketplace pages, scripts, APIs, processors, networks, databases, logs, cloud services, support tools, and administrative systems.
- Determine your PCI roles. Document where the marketplace acts as a merchant, service provider, or potentially both.
- Confirm the required validation path. Ask the acquirer, payment processor, payment brand, or other compliance-accepting entity what evidence is required.
- Inventory third-party service providers. Include processors, gateways, hosting, cloud, managed security, payment applications, and other parties capable of affecting the payment environment.
- Collect current assurance evidence. Confirm that each provider’s PCI evidence actually covers the service you use.
- Create a responsibility matrix. Give every applicable control an owner rather than leaving a foggy “shared” label between two companies.
- Review ecommerce webpage exposure. Account for current SAQ A scanning rules, payment-page scripts, redirects, embedded payment forms, and change risks that affect your architecture.
- Search for accidental payment-data storage. Check logs, debugging tools, support tickets, email, screenshots, exports, analytics, recordings, backups, queues, and observability systems.
- Control privileged access. Limit and monitor users who can change payment infrastructure, checkout code, integrations, DNS, cloud resources, seller configurations, and security controls.
- Verify testing and scanning obligations. Determine which ASV scans, vulnerability processes, penetration tests, segmentation tests, or application-security activities apply to the actual environment.
- Prepare incident escalation paths. Know who contacts the processor, acquirer, sellers, security responders, legal advisers, and other required parties if payment compromise is suspected.
- Repeat the review when architecture changes. A new processor, checkout redesign, seller plugin system, acquisition, mobile app, cloud migration, or fraud product can materially change the payment-security boundary.
What to ask your payment processor or acquirer
Marketplace teams can eliminate weeks of speculation by getting several questions answered in writing.
- For these transactions, who is treated as the merchant for PCI validation purposes?
- Is the marketplace also expected to validate as a service provider?
- What PCI DSS validation document do you require from the marketplace?
- Does that requirement vary by merchant account, region, transaction volume, or payment model?
- What validation, if any, must individual sellers complete?
- Which PCI responsibilities does the payment provider perform for us?
- Can you provide a current AOC covering the services we use?
- Are our marketplace webpages subject to ASV scanning under the validation path you accept?
- What must we report if we suspect payment-account compromise?
PCI SSC itself develops and maintains the standard but does not run every merchant’s compliance program. Payment brands, acquirers, and other compliance-accepting entities determine validation and reporting requirements. That is why the final validation answer should come from the party that will actually accept your compliance evidence.
Common marketplace PCI mistakes
“Our payment processor is PCI compliant, so we are compliant.”
A compliant provider can reduce scope and perform controls on your behalf. It cannot attest to marketplace controls that remain outside its service.
“No card numbers are stored, so PCI DSS does not apply.”
Storage is only one part of PCI scope. Processing, transmission, and systems capable of affecting payment-account security also matter.
“All sellers have the same responsibility.”
Different seller integrations and merchant relationships can produce different obligations. Standardize integrations where possible, but verify what the acquiring model actually requires.
“We passed last year, so the current architecture is covered.”
Marketplaces change quickly. New scripts, processors, seller tools, APIs, clouds, acquisitions, mobile applications, and checkout experiments can quietly invalidate last year’s scope assumptions.
“A merchant SAQ proves our service-provider compliance.”
It does not. Service-provider assessments have different expectations, and SAQ D for Service Providers is the only SAQ available to SAQ-eligible service providers.
How much does marketplace PCI DSS compliance cost?
There is no meaningful universal price because the largest cost variable is scope.
A marketplace that uses tightly outsourced payment capture and maintains a small, clearly defined footprint can have a very different program from a platform operating custom payment services, multiple processors, direct card-data handling, seller-specific integrations, and a service-provider assessment.
Budget separately for scoping, validation, scanning, application security, penetration testing where applicable, payment-page monitoring, vendor assurance, internal engineering time, evidence maintenance, and remediation.
Smaller operators can use the PCI DSS compliance cost guide for small businesses to separate inexpensive compliance tooling from the labor and remediation costs that often dominate the real budget.
The most reliable cost-reduction strategy is usually architectural: keep raw cardholder data out of marketplace systems where the business model allows it, reduce unnecessary payment-page dependencies, standardize seller integrations, and make responsibility boundaries boringly clear.
PCI DSS is not the same as complete marketplace security
PCI DSS is focused on payment-account security. A marketplace also needs to consider seller account takeover, fraudulent payouts, refund abuse, business email compromise, privacy obligations, cloud security, application vulnerabilities, insider access, availability, and other risks that may sit outside a particular PCI assessment boundary.
Likewise, PCI DSS compliance does not automatically establish compliance with US or UK privacy, consumer-protection, financial-services, breach-notification, or contractual obligations. Those requirements have their own scopes and enforcement mechanisms.
The useful way to think about PCI is as one security boundary inside the larger marketplace. Make that boundary small where practical, but do not confuse a smaller PCI scope with a smaller overall security responsibility.
The marketplace decision rule
If you remember one thing, make it this: outsource card capture where practical, but never outsource understanding.
Know who accepts the payment, where card data travels, what your website can affect, which services your providers have actually validated, what your sellers control, and what evidence your acquirer expects from you.
As of September 2026, PCI DSS v4.0.1 remains the supported active revision of PCI DSS. The PCI SSC published v4.0.1 as a limited revision and retired PCI DSS v4.0 at the end of 2024. The requirements that had future effective dates through March 31, 2025 are therefore no longer future tasks. They belong in today’s compliance planning.
The official PCI DSS v4.0.1 publication notice and the PCI SSC Document Library should be your reference points for current standards and assessment documents rather than an old checklist copied from a previous PCI version.
For a marketplace, compliance becomes manageable when the payment flow has names, owners, evidence, and boundaries. Without those, even an excellent payment processor can leave a rather expensive fog sitting between the buyer’s card and your annual attestation.
Responsibility workflow reviewed: 2026-10-23. Added a blank role-and-handoff record and linked the directly relevant PCI SSC FAQs 1092 and 1578. No marketplace, seller arrangement or live transaction was assessed.