Get Demo
↑

PCI DSS Merchants vs Service Providers: Roles, Levels, and Validation

PCI DSS merchant vs service provider - official definitions, when you are both, TPSP responsibility (12.8), and how validation paths differ.

Published: September 2026 Compliance · PCI DSS 8-12 min read

Per the PCI SSC Glossary: a merchant is any entity that accepts payment cards bearing the logos of any PCI SSC Participating Payment Brand as payment for goods and/or services. A service provider is a business entity that is not a payment brand, directly involved in processing, storing, or transmitting cardholder data (CHD) and/or sensitive authentication data (SAD) on behalf of another entity - including gateways, PSPs, and ISOs - and also companies whose services control or could impact CHD/SAD security (managed firewalls, IDS, hosting, and similar). Pure public-network-access-only telecommunications links are generally not service providers for that service alone.

Related: SAQ D · ROC and AOC · SAQ types · CDE scoping · Compliance levels.

Gotcha: A merchant can also be a service provider (classic example: an ISP that bills cards and hosts other merchants). Using a PCI DSS-compliant TPSP does not make you compliant. Customers remain responsible for their own validation and for managing TPSP relationships under Requirement 12.8.

Merchant vs Service Provider

Topic
Merchant
Service provider
Core role
Accepts cards for own goods/services
Handles or impacts account data for others
Typical SAQ (if SAQ-eligible)
A, A-EP, B, B-IP, C, C-VT, P2PE, SPoC, or D for Merchants
Only SAQ D for Service Providers
Validation depth
Brand/acquirer levels; ROC common at Level 1
Brand programs often require ROC for high-volume / Level 1 SPs
TPSP duties
Manage providers per 12.8; confirm responsibility matrix
Support customer requests per 12.9.2; may have Appendix A multi-tenant requirements

Levels and Validation

Exact Level 1-4 cutovers and service-provider tiers are set by payment brands and acquirers. Confirm thresholds with your acquirer and see the compliance levels page - do not assume a single global volume table applies to every brand.

How CyberSilo Helps

Map PCI DSS v4.0.1 Controls to Continuous Evidence

CyberSilo CSA and ThreatHawk SIEM help US merchants and service providers collect QSA-ready evidence across scoping, cloud, and SAQ/ROC validation paths.

Frequently Asked Questions

We only host apps - are we a service provider?

If you store, process, or transmit CHD/SAD for others, or provide services that control or impact CHD/SAD security, yes under the glossary service-provider definition. Confirm with your QSA or brand program.

Does buying a compliant gateway make us SAQ A automatically?

Only if you meet all SAQ A eligibility criteria and your acquirer allows an SAQ. A compliant TPSP does not automatically equal SAQ A.

Must every TPSP be PCI DSS compliant for us to meet 12.8?

Requirement 12.8 requires monitoring compliance status; it does not require every TPSP to be compliant. But if a TPSP's service is meant to meet your PCI DSS requirements, that service must be demonstrated as meeting them or those requirements are not in place for you.

SAQ D · ROC and AOC · SAQ types · CDE scoping · QSA vs ISA vs ASV · Compliance levels

📰 More from CyberSilo

Latest Articles

Stay ahead of evolving cyber threats with our expert insights

✅ Link copied!