Merchant? Service Provider? Or Both?

February 9, 2016 • Published Categories PCI 101 Tags

The number of organizations that accept credit cards as payment, and the number of methods they utilize to accept those payments, has grown exponentially in the last several years.  The number and complexity of services and systems to support those organizations has also proliferated at a staggering pace.

Accordingly, risks associated with the relationships between merchants who accept credit cards as payment and the entities that support them have also increased—and that has been demonstrated by the breach activity that has made headlines in the last several years.

Merchants generally know they are merchants because they have a merchant agreement with an acquiring bank, and they need to be able to accept credit card payments for their business.  However, service providers don’t always know that they are service providers and therefore are not aware of their responsibilities.

Are you a merchant?

So, let’s first tackle the merchant question.  The PCI Security Standards Council (SSC) defines a merchant this way:

“For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services.”


That seems straightforward enough.  Merchants, therefore, must validate compliance with the PCI DSS. One of the requirements that the SSC has beefed up in the last few years is the requirement that a merchant understand who their service providers are and that they have proper agreements with those service providers. These agreements should explicitly call out which PCI requirements the service provider is responsible for and which requirements are the responsibility of the merchant.

Are you a service provider?

Now, let’s discuss the service provider question.  The PCI Security Standards Council defines a service provider this way:

Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data.


Traditional service providers include payment processors, payment gateways, managed POS providers and companies that come into direct contact with card data in the payment process.

However, not all organizations recognize their role as a service provider, and this lack of awareness puts their business—and their customers’ businesses—at risk.  The last part of the service provider definition (“also includes companies that provide services that control or could impact the security of cardholder data”) is what often causes confusion.  If a company offers, for example, a managed network firewall, and their customer uses that firewall to protect their point of sale systems and back office computer that make up their card data environment, then they absolutely can impact the security of card data.

Examples of service providers that often don’t know they are service providers include hosting, billing account management, back office services and co-location providers, just to name a few.

Are you a merchant AND a service provider?

So, how can you be both a merchant and a service provider?

The PCI Security Standards Council adds the following to the above quoted definition of a service provider:

“Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.”


Even if your business operates primarily as a merchant, acknowledging any and all service provider components will enable you to take a holistic view of your scope of compliance with the PCI DSS.

OK, so you’re a service provider, now what? (Or, demonstrating your commitment to security.)

If your organization operates as a service provider, you will want to demonstrate your commitment to security so that your customers feel comfortable doing business with you.

It starts with validating and maintaining PCI Service Provider compliance:

  1. Consider completing a PCI Level 1 assessment, validating your organization’s PCI compliance status with a Qualified Security Assessor (QSA). This is the highest level of assessment for a service provider and demonstrates a strong commitment to information security for your customers and their customers.
  2. If you can’t complete a PCI Level 1 assessment, and/or you qualify as a level 2 service provider, you can complete a self-assessment. This requires a completed SAQ D-Service Provider.
  3. Work with merchants on agreements/contracts that call out which requirements you are responsible for, and help those merchants meet their PCI compliance requirements. The PCI Council has published a great document  that helps you understand best practices and even provides a sample PCI DSS responsibility matrix.
  4. Ensure that you are listed on the Visa Global Registry of Service Providers. This is where merchants go to find out if their service providers are compliant. Visa maintains this list for all the card brands.  To submit PCI DSS compliance validation documents, email (U.S., Canada, LAC regions) or (AP, CEMEA regions).

The security professionals at ControlScan are available and happy to help answer additional questions you may have. Click here to contact us now.

Subscribe to this blog for additional tips and webinar announcements.

2 thoughts on “Merchant? Service Provider? Or Both?”

  1. There continues to be confusion as to what is a Service Provider as defined by the PCI-SSC. Unfortunately, and as you point out above, the current definition lumps together different roles under a single definition when the roles should be broken out for clarity. In particular, an entity that only provides managed services to a Merchant or Payment Processor (i.e. a Managed Services Provider [MSP]), and that MSP does not transmit, receive, process or store CHD in the delivery of those services, should be defined separately as, perhaps … a Managed Services Provider ! MSPs who have direct access to systems/devices within their customer environment that are in-scope for the customer’s PCI compliance obligations are subject to only a subset of the PCI-DSS. As well, and because the MSP is not itself performing or directly involved in e-commerce transactions, I would argue the Merchant “Levels” do not apply to MSPs. I unsuccessfully petitioned the SSC several years ago to break out these definitions.

  2. Richard,

    You make very good points. Within that single category, as you clearly point out, there can be a vast difference in the nature and scope of a third party’s involvement.

    Within our own business we put ISOs, ISVs/Resellers, Payfacs and others into categories based on scope and risk.

    Once we determine an entity fits into the definition of a service provider we assess the scope from there.

    I agree 100% that merchant levels do not apply in these situations. You bring up a point that we still see a good deal of confusion about.

    As far as the PCI Council, I think the impetus to more formally recognize and categorize the various roles and the corresponding scope, would likely need to come from the card brands and acquirers.

    In our role as an assessor, and a facilitator for PCI, we would certainly support any effort that helps with clarity and consistency, in this regard.

    Thanks so much for your insights.

    Let us know if there is anything else we can assist with.


Leave a Comment