Merchant or Service Provider? The PCI AOC Your Customers Want

You are a merchant when you accept payment cards for your own goods and services. You are a service provider when you handle card data, or can affect its security, on behalf of another entity. The PCI Security Standards Council's glossary puts it precisely: 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," and a service provider is a "business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data (CHD) and/or sensitive authentication data (SAD) on behalf of another entity." A large number of B2B SaaS companies are quietly both, and the moment that matters is the one where an enterprise customer asks for your attestation of compliance and you send them the wrong kind.

That is not a paperwork nicety. A merchant attestation answers a question about how you buy card processing for yourself. A customer asking for a service provider attestation is asking how you protect their cardholder data, and those are different documents describing different scopes. The rest of this covers how to tell which you are, what each side owes under Requirements 12.8 and 12.9, and the sentence in your sales motion that decides it.

Key takeaways

• You are a merchant when you accept cards for your own goods and services. You are a service provider when you handle card data, or can affect its security, on behalf of another entity.
• A large number of B2B SaaS companies are quietly both, and the trouble starts when only the merchant half was ever thought about.
• You do not have to touch the data to be a service provider. Code you serve onto a customer's payment page qualifies, because the definition covers affecting security.
• Requirement 12.8 is the customer side and Requirement 12.9 is the provider side. The responsibility matrix that 12.9 implies is the single most valuable document a service provider can prepare in advance.
• Merchant and service provider attestations are different documents describing different scopes. Sending the wrong one is how a vendor review goes back into the queue.

The test that actually decides it

Ask one question about each product surface: whose cardholder data is it?

If a customer buys your software and pays by card, the transaction is yours, the goods are yours, and you are a merchant for that flow. Your validation type follows from how that checkout is built, which is the subject of which PCI SAQ do you need.

If your product touches card data belonging to your customer's customers, you are a service provider for that flow. The obvious cases are payment facilitation, billing platforms and payment orchestration. The less obvious ones are where companies get caught:

• A platform that stores payment tokens on behalf of merchants, where the tokenization boundary sits inside your product.
• A hosted checkout, cart or storefront component that renders on your customer's payment page. Note the second half of the Council's definition: you do not have to touch the data if you can affect its security. Code you serve onto a payment page qualifies.
• Managed hosting, or an infrastructure service, where your customer's cardholder data environment runs on systems you administer.
• Call center, BPO or support tooling where agents can see or capture card numbers on a client's behalf.
• Fraud, chargeback or reconciliation tooling that receives account data as part of the workflow.

Being both is normal. What is not normal, and what causes the mess, is having only ever thought about the merchant half.

What each side actually owes

The two requirement families are mirror images, and knowing which one a question comes from tells you what the asker needs.

Requirement 12.8 is the customer side. If you use third-party service providers, you keep a list of them, hold written agreements, perform due diligence before engagement, monitor their compliance status at least once every 12 months, and maintain information about which PCI DSS requirements each provider manages and which you manage. That is the requirement family behind every vendor security questionnaire you receive about your payment stack, and our vendor risk management program guide covers running it as a program rather than as an annual scramble.

Requirement 12.9 is the provider side. Third-party service providers support their customers' PCI DSS compliance. In practice that means two things: providing written agreements that acknowledge responsibility for the security of account data you store, process or transmit on the customer's behalf, or that you could otherwise affect; and supporting your customers' requests for the information they need to meet 12.8.4 and 12.8.5, including your compliance status and a clear statement of which requirements are yours, which are theirs, and which are shared.

That last artifact is the responsibility matrix, and it is the single most valuable document a service provider can prepare in advance. Enterprise customers ask for it, most vendors do not have it, and producing one turns a two-week email exchange into a one-page attachment.

The attestation of compliance, and why the wrong one stalls a deal

An attestation of compliance is the summary document that accompanies a completed assessment. There are different AOC forms for different validation paths, and critically, separate merchant and service provider versions.

The failure mode is simple. A SaaS company completes a merchant self-assessment because its own checkout is fully outsourced, receives a customer request for "your PCI AOC," and sends what it has. The reviewer opens it, sees a merchant attestation describing an e-commerce checkout, and cannot map any of it to the question they asked, which was about the customer's own cardholder data flowing through the vendor's platform. The deal does not die, but it does go back into the queue, and the vendor now looks like it has not thought about the question.

Two more things worth knowing about the artifact. The payment brands maintain registries of service providers, and some of them require registration for certain provider types, which is separate from validating. And a service provider AOC has a date and a scope statement: reviewers read both, and an assessment nearing a year old prompts a follow-up. The Council even maintains an FAQ on that exact situation, numbered 1601 in its FAQ library.

What to do if you have just realized you are a service provider

Do not panic-buy an assessment. Do this instead, in order.

Establish the scope honestly. Which product surfaces touch or can affect customer cardholder data? The Council defines the cardholder data environment to include system components that "may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD," so map connectivity, not just data.

Try to shrink it before you assess it. Segmentation, which the Council defines as isolating "system components that store, process, or transmit cardholder data from systems that do not," is the lever with the best return, because assessment effort scales with the size of the environment.

Write the responsibility matrix. You will need it for 12.9.2 regardless, and drafting it forces the scope conversation you have been deferring.

Then decide the validation path, which depends on the payment brands' requirements for your provider type and volume, and is a question for your acquirer or the brands rather than for a blog. Do you need a QSA covers how that decision gets made and who makes it.

The honest caveat

Some companies are told they are service providers when they are not. If your product genuinely never receives cardholder data, serves nothing onto a payment page, and has no administrative access to systems in a customer's cardholder data environment, then the correct answer to a service provider questionnaire is a clear explanation of why the requirements do not apply, not a compliance project.

We have written that explanation for clients more than once, and it is a better deliverable than an assessment they did not need. If a consultancy tells you a customer's questionnaire means you need a service provider assessment, before anyone has mapped whether card data can reach you, get a second opinion.

Where Top Floor fits

Top Floor is not a QSA. We do not issue attestations and we cannot sign a Report on Compliance. What we do under PCI DSS is the scoping, the segmentation argument, the responsibility matrix and the readiness work that decides whether the assessment you eventually buy is small or large. Where a company is answering these questions alongside SOC 2 and ISO 27001, Compliance as a Service is the multi-framework version, and audit and assurance covers preparing for the assessment itself.

How to decide this week

Take your product surface list and mark each one merchant, service provider, or neither, using the whose-data question. Include anything that renders code on a customer's page.

Find the last PCI-related customer request in your inbox and read what it actually asked for. If it asked about your customers' cardholder data, a merchant attestation was never going to answer it.

Then draft one page: which PCI DSS requirements you cover, which the customer covers, and which are shared. Even in draft, it is the fastest thing you can produce that makes a reviewer's job easy, and Requirement 12.9.2 will require it eventually anyway.

Frequently asked questions

What is the difference between a PCI merchant and a service provider?

The PCI Security Standards Council defines a merchant as any entity that accepts payment cards bearing the logos of a participating payment brand as payment for goods or services, and a service provider as a business entity, other than a payment brand, that is directly involved in the processing, storage or transmission of cardholder data or sensitive authentication data on behalf of another entity. The distinction is whose data it is. Many SaaS companies are both: a merchant for their own subscription checkout, and a service provider for whatever their product does with customers' card data.

Can a SaaS company be a service provider without ever touching card data?

Yes. The definition also reaches entities that can affect the security of cardholder data, so serving code onto a customer's payment page, administering the systems where a customer's cardholder data environment runs, or providing tooling whose compromise would expose card data can all make you a service provider. The Council's own definition of the cardholder data environment includes system components that do not store, process or transmit card data but have unrestricted connectivity to components that do.

Which AOC do our enterprise customers want?

If they are asking about their cardholder data passing through your platform, they want a service provider attestation of compliance, and a merchant self-assessment describing your own checkout does not answer that question. Reviewers also read the date and the scope statement on an AOC, so an assessment approaching a year old will prompt follow-up questions. If you are not yet in a position to provide one, the most useful interim artifact is a written responsibility matrix stating which PCI DSS requirements you cover, which are the customer's, and which are shared.

What does PCI DSS Requirement 12.9 make a service provider do?

It makes third-party service providers support their customers' PCI DSS compliance. Two obligations follow: providing written agreements that acknowledge responsibility for the security of account data the provider stores, processes or transmits on the customer's behalf, or that it could otherwise affect; and supporting customer requests for the information they need to satisfy Requirements 12.8.4 and 12.8.5, which means compliance status information and a clear statement of which requirements are managed by the provider and which by the customer. That statement is the responsibility matrix, and preparing it in advance removes most of the friction from enterprise vendor reviews.