Apparently there are a lot of newcomers to the PCI compliance business and are asking bizarre questions regarding PCI. One of the most common is if their organization is a merchant or a service provider or both?
Merchant
According to the PCI DSS v3 Glossary, a merchant is defined as:
“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. 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.”
One of the points that create some of the most confusion is the point made at the end of the merchant definition that it is possible for a merchant to also be a service provider. A lot of people think that this is a black or white, either or type of situation which it is not.
The key thing to determining if your organization is a merchant is if your organization signed a merchant agreement with a bank and has a merchant account with that bank. If your organization did, then you are definitely a merchant.
Service Provider
Now let us talk about service providers. In the same document, a service provider is defined as:
“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).”
The first thing to remember about service providers is that you can be tagged as a service provider and not be directly processing, storing or transmitting cardholder data (CHD) or sensitive authentication data (SAD). We see this most often with organizations that provide managed security services (MSS). In most cases, these organizations manage/monitor the devices that provide and/or secure the communications links. As a result, these MSS providers can have access to unencrypted CHD/SAD whether they realize that or not. If the MSS could be in contact with unencrypted CHD/SAD via the devices they manage, then they are in-scope for PCI compliance.
I can tell you from personal experience that service providers that are not directly processing, storing or transmitting CHD/SAD will push back and fight very hard to be ruled out of scope for PCI compliance. It has gotten to the point that I have seen and heard of service providers taking customers to court for misrepresenting their business and to force their customer out of their service contract. In the majority of the cases I am aware; it was shown that it was the service providers’ negligence from not explicitly asking whether or not PCI compliance was required by the customer. So if you need to be PCI compliant, it is very important to make that clear to any service provider you are looking at just in case one or more of their services could come into contact with CHD/SAD.
Another way an organization can become a service provider is when they conduct card transactions on behalf of a third party. The best example of this situation is with outsourced call centers. While the call center might be conducting the card transactions on your systems, they are a third party that is processing and transmitting CHD/SAD through their workstations for your organization. As a result, the call center is a service provider and is in-scope for PCI compliance.
Another way an organization can become a third party is if they are conducting transactions through their systems using a merchant account of a third party. I have encountered this with call centers where the call center is using their own applications, but the merchant account used to process payments through is not the call center’s merchant account, it is the merchant account of the call center’s customer.
Both?
Finally, there is the example from the Merchant definition where the organization is both a merchant and a service provider. As pointed out in the definition, this most commonly occurs with Internet service providers (ISP) and shared hosting providers that provide not only services for hosting a customer’s IT environment, but then accepts cards for payment for those hosting services. From the hosting perspective, these organizations are a service provider and must comply with the PCI DSS for those services provided to their customers. However, these organizations are also merchants because their customers can pay using a credit/debit card.
Some Closing Comments
Before I finish this post, I also want to add some comments regarding compliance reporting for service providers.
The first comment I would like to make is regarding reporting and compliance testing. If you are a service provider, you only have the choice of a Self-Assessment Questionnaire (SAQ) D or a Report On Compliance (ROC). If your organization processes, stores or transmits less than 300,000 card transactions, then you can use either the SAQ D or perform a ROC. If your organization processes, stores or transmits 300,000 or more card transactions, then you are required to do a ROC.
If you are an ISP, MSS or similar service provider that does not process, store or transmit CHD/SAD, then you will not have a transaction count and therefore will fall on the under 300,000 transaction count rule.
Why would an organization that can do an SAQ D do a ROC? If an organization desires to be listed on the Visa Global Registry of Service Providers or the MasterCard PCI Compliant Service Provider lists, then the service provider must do a ROC. There are rules and fees for being included on these lists that each card brand Web site documents. A knowledgeable QSA can help facilitate your listing on these sites as well as conducting the requisite ROC assessment.
A quick side note regarding Visa and service providers. Visa is conducting a separate service provider inventory program that is outside of their Global Registry program. This new inventory process has confused a lot of service providers and QSAs alike including yours truly. For about the last year or so, Visa has been “registering” all service providers in an attempt to create a complete inventory of service providers. This service provider inventory program has nothing to do with the Visa Global Registry and does not put any organization that is processed through it on the Visa Global Registry.
It is very important for service providers to know that the Attestation Of Compliance (AOC) form for the service provider is very different from the merchant version of the AOC. The AOC for service providers provides a list of the services provided by the service provider that were assessed for the AOC. This information is necessary for customers to know if all of their services were assessed for PCI compliance. If a service was missed, then the merchant is responsible for assessing that service for PCI compliance. So it is very important that you ensure that all services provided to your customers that require PCI compliance be assessed for PCI compliance.
Then there are the number of times I have received an AOC from a service provider only to find that it is a merchant AOC, not a service provider AOC. With v3 of the PCI DSS, the Council has created separate SAQ D forms for merchants and service providers that will hopefully cure some of this issue. It is incumbent on service providers to make sure that when they sign the AOC that it is a service provider AOC and all of the services are listed. If not, then you need to go back to your QSA and get the right AOC form with the right information created.
And finally, my biggest pet peeve with service provider AOCs. Some QSACs create these wonderful “Certificates Of PCI Compliance” that, while they look really nice, have no meaning to your customers and their QSAs. No matter how many times the PCI SSC has stated that the only officially recognized document out of a PCI assessment is the AOC, I still encounter these certificates as “proof” of PCI compliance. When asked to provide the AOC, I then get the indignant response that I should have everything I need. In one case, I was even told I could not possibly be a QSA because I did not recognize the certificate as proof of compliance.
As I stated earlier, the service provider AOC is required to ensure that all service provided were assessed and QSAs are required to have copies of all service provider AOCs in order to show that all third parties have been officially assessed for PCI compliance. No AOC means that the service provider is not PCI compliant and must be assessed as part of the customer’s PCI assessment.
I hope we are all now on the same page regarding the concepts of a merchant and a service provider.
PCI Guru 
Hello PCI Guru
The large retail organisation that sales the product and provide the banking services (deposit, withdraw cash or cheques) to some banks within a branches.
Acquirer , banks and retail organisation have agreement to provide a merchant AOC on annual basis. Recently the organisation deployed the PCI approved P2PE (PED) solution and cardholder transmit to P2PE solution provider environment in encrypted format to share with acquirer and backs and no cardholder data return to business.
Do you think this organisation need to assess as a service provider? if yes, then what PCI DSS requirement applicable?
If I understand you correctly, it sounds to me like this retailer is also providing banking services on behalf of one or more financial institutions through their merchant infrastructure. The key is going to be if the retailer uses the bank’s identification information in those transactions (i.e., the merchant is performing the transaction under the bank’s banking identification) or under their own merchant identification. If they are using the bank’s identification, then they are a service provider and need to assess as such.
As to what requirements apply, that would take a consulting project to determine scope and requirements because there is no simple canned answer to what you ask.
Thanks for quick and helpful response.
Yes you are right, retailer uses a same infrastructure to provide banking service. do you mean BIN range use for identification or banks has different identification?
This has nothing to do with the BIN.
What this has to do with is under which entity’s banking relationship the banking transactions occur. Is it the merchant’s identifier (MID) and the merchant does back office work to get these transactions to the bank. Or, are the transactions switched in such a way that they are performed the same as if the person had gone to the bank and done the transaction?
Based on your question back, I am guessing that the transactions are conducted under the merchant’s banking relationship and there is back office work done to get the transactions over to the bank.
The difference is important because it will dictate HOW you assess and WHAT you assess at the merchant for being a service provider. If the merchant’s back office is involved that creates a much larger scope.
The key is to follow the transaction flow and processes used to conduct the bank’s transactions.
I hope that clarifies things.
The bottom line though is that the merchant is a service provider regardless of how the transactions are performed.
If an organization is both merchant and service provider then what is the PCI compliance requirement?
Who will determine their compliance level, Acquirer or payment card brand?
You need to do two assessments, one as a merchant and one as a service provider.
As a merchant, your acquiring bank will determine your merchant level.
As a Service Provider, it depends. If you conduct transactions on behalf of merchants, then the acquiring bank(s) you use will determine your service provider level, but there are really only two. 300K+ must do a ROC. Below 300K you do a Service Provider SAQ D.
If you are providing services that do not involve transaction processing such as a managed services provider, then you will have no transaction count and can do either the Service Provider SAQ D or, if you want to be listed on the Visa or MasterCard Global Service Provider List, you need to do a ROC.
12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually. what about merchants that have “merchant accounts” with banks, don’t they fall in this category too?
So, who monitors the PCIDSS compliance of the merchant who uses payment api of the bank where his merchant account resides?
Those acquiring banks, payment gateways and payment processors should also be providing a Service Provider Attestation Of Compliance (AOC) for all of their payment services provided to their merchants.
Hi
You must be fed up with answering comments on this thread 🙂 But I have a question relating to it that doesn’t seem to be directly answered in any below.
We provide a service to small independent bricks-and-mortar stores that enables them to act as a central collection agent for various public and private sector services; anything from utility bill payments, public transport tickets and passes, lottery tickets, Amazon vouchers – that kind of thing. To do this we provide a bespoke POS terminal to the store, manage it for them, and take card-present payments from it and route them to the seller of the services just described. We’ve always positioned ourselves therefore as a service provider and undergo a full on-site ROC annually.
In order to test this service we also have a small dummy store at our head office, have a merchant account with an acquirer for this, and we complete a merchant SAQ C for this annually.
Hopefully that’s all good anyway..
For the main service/payment gateway we obviously charge the stores a small monthly fee, which they pay by monthly direct debit.
We have a debt collection team who have to contact stores for payment if the direct debit has failed for some reason. When the do contact such stores, many store owners are asking if we can take the unpaid debt over the phone using their card. Looking at this, we think we can open another merchant account, and attest with an SAQ C-VT.
Most of the discussions on the topic of being both a merchant AND a service provider seem to come at it from the viewpoint of a merchant becoming a service provider, by processing, storing etc. But what about the other way? As a service provider, we can (and do!) have multiple ROCs for different services. But I’ve not seen a merchant SAQ work that way – it seems to have to apply to the entire enterprise. But I think the “merchant” for our dummy store and the “merchant” for our debt collection are two separate ones (they have separate acquirer MIDs already). Can we run more than one merchant SAQ as well as more than one service ROC? Some of the SAQ C-VT eligibility statements made me nervous:
“- Merchant’s only payment processing is via a virtual payment terminal accessed by an Internet-connected web browser”
and
“Merchant does not otherwise receive or transmit cardholder data electronically through any channels (for example, via an internal network or the Internet)”
In your opinion is it reasonable, acceptable even, to continue with our approach above?
Many thanks in advance
It doesn’t matter what I or any other QSA thinks. You need to talk to your acquiring bank and get their permission for your approach.
What if you have a third party (outsourced call center) you have contracted with, that is collecting cc payments (say old debt collectors) using their own merchant account and 100% their own systems/applications, and deposits into their own merchant bank account. Then say monthly makes a EFT deposit into your bank account for payments they’ve collected, and sends a report that matches the deposit. I understand they are a merchant in this case, but are they considered a “PCI” service provider to us? Are they considered a 12.8 service provider and need to provide us with their AOC SAQ D – Service Provider form?
Yes, they are a service provider to your organization. You should have their AOC to ensure they are maintaining PCI compliance. Since they are totally separate from your business processes, there is no reason to worry about any integration of controls between the two organizations, so 2g will be irrelevant.
Great site and thanks for providing your insight on this topic. In our journey down PCI road, I’m trying to figure out what our company is considered in terms of PCI.
Company B provides an online hosted solution that accepts and processes payments. As part of company B’s solution, they also provide pinpads that communicate with their online hosted solution to process card present transactions. The pinpads provided are encrypted at source and only Company B has the ability to decrypt the transactions. Company B has a merchant number with their acquirer. Company B has an Merchant AoC and Service Provider AoC.
Company A has a store front and sells Widgets. Company A is a company that uses Company B’s hosted solution. Company A is provided with pinpads by Company B that is installed in Company A’s network to process card present transactions. The pinpads are encrypted at source and Company A cannot decrypt the data. At the end of each month, Company B cuts a cheque to Company A for the dollars processed by Company A (minus Company B’s fees). Company A does not have a merchant ID with an acquirer.
Company B has stated that they are both the merchant and service provider. What is company A? Is Company A also a merchant?
Thanks
Company A is “lucky”. LOL!!!!
The scenario you lay out is how Square operates. Square is the merchant of record for all transactions they process on behalf of their subscribers. Square is also the transaction processor for those transactions, so they are a service provider as well. So while all of those people that subscribe to Square are merchants, they are not merchants in the PCI sense.
We are a software company and host a homegrown SaaS product for our clients. The software itself is PA-DSS compliant, and we manage the web servers and network hosting the web application. The web application allows our clients to build sites that accept payments, and configures their own merchant IDs within our software that process payments through third party payment processors (such as PayPal). Because we do not process any payments or collect money directly through this hosted offering,does this mean our hosted environment is exempt from the PCI scope? We have been maintaining annual assessments using Service Provider SAQ-D for many years, but I am starting to wonder if the use of our third party payment providers means that we do not need to be considered “in scope”.
You are providing a service that allows customers to process payments. Regardless of scope, you control an important function of that payment process and could adversely affect its security. Therefore you need to continue doing what you are doing under that SAQ D Servicer Provider assessment.
As always – many thanks for your insight etc.
A scenario I have not seen covered.
Company A uses a 3rd party (Merchant) to process its credit card transactions on Company A’s network etc.
Company B has an affiliate relationship with Company A and manages the POS devices (this includes connectivity to an off-site server that updates configs, break/fix etc.) for Company A. Company A and Company B have no written agreement covering any of this. Company B does not process CC data.
As it stands, is company B required to file an SAQ D- Service Provider even if the 3rd Party provider (Merchant) has never asked for it (or anything) thus far? What is incumbent upon Company B in this scenario? ….thanks very much in advance.
Who manages the merchant identifier for the processing of the transactions? That is what will determine who has the PCI compliance responsibility. Regardless, both organizations need to formalize their relationship so that if a problem occurs, there is agreement as to whom does what.
There is call center operation that works for one of the card brands. They have to store the card number to be used as an account reference when the customer calls in. There is no transactional data just the card number/account number. We have been treating it as a service provider but wanted to get an opinion.
I would agree they are a service provider as long as they are not a division or subsidiary of your organization.
Thanks. They are a division of our company. We currently perform both a merchant and service provider attestation. The merchant attestation is for a different division.
Still a little uncertain about whether we fall under any PCI compliance requirements. We are a company who has a merchant leasing space in our organization. They have a POS device connected to our phone lines (which traverse our network) for payment card transactions. Being a merchant they have PCI requirements and we do not.
They want to change the POS device over to the IP network as it is dropping transactions using the phone side. This IP connection will be static and will be going out via an internet only segment/vlan isolated from our main corporate network. With a static IP, the device would be going out port 443 connecting to the entity which will be collecting the payment information on this company’s behalf.
Because this will not be going out over a segmented vlan on our corporate network, are we now considered a service provider or are we now required to have our network reviewed by an ASV, or are the PCI requirements still only on the merchant and the payment card collecting organization that provide the pos device?
Your first mistake is that you think your organization does not have any PCI compliance requirements with this merchant. You became a service provider the minute you put them on your VoIP network so you have all sorts of potential requirements. It will only get worse if you let them go to full TCP/IP with a point of interaction (POI – aka card terminal).
You will still be a service provide under you VLAN configuration, but you will minimize the scope to only that VLAN and endpoint devices such as firewalls and switches. Just to be safe, I would encrypt the VLAN traffic the merchant is on and not rely on only TLS. That way you can truly minimize your scope to your encryption endpoints.
If Company A buys a part of Company B, yet Company B continues to operate all of the IT, security, etc… functions while Company A only takes on the selling component (salespeople), Company B’s MIDs are continued to be utilized and a cash settlement between the two companies is performed weekly/monthly for a transition period. How is Company B a PCI service provider to anybody if it’s still their MIDs? Or are they? I can see them being a service provider by non-PCI standards, but who would be concerned. This seems more like the definition of credit card money laundering or third-party merchant relationships.
If Company B still owns the merchant identifiers (MID) being used, then Company A has no PCI risk if a breach occurs. That risk is totally borne by Company B.
In PCI terms, Company B is only a service provider if Company A owns the MIDs and Company B is processing transactions on behalf of Company A using Company A’s MIDs.
Thanka for your very useful site. I have a remaining doubt over this issue. If the company provides the ability for their customers to use their digital currency (funded by pci payment brand cards) as a means to accept payment from their own customers (third parties) then the company must be both?
I believe you are pointing out that it is possible for an organization to be both a merchant and a service provider and you are correct. Service providers can accept card payments for their services which makes them a merchant as well.
As I have been handed new responsibilities in our organization, I am beginning to look into PCI compliance to see where we stand. I don’t believe any SAQ has been completed prior, so I am likely going to force some catch up work to get things in order. Based on your post and the comments, we appear to be both a merchant and service provider.
For the merchant side, the accounting department invoices clients electronically, and includes a direct link to authorize.net hosted forms for payments. Occasionally a client representative has called to make a payment, so the accounting staff has manually entered the CHD through the authorize.net virtual terminal. This usually happens because the person who received the invoice is not the person who is authorized to make the payment, so they just tell the responsible party to call to make the payment.
My understanding is that this manual entry process brings our network in scope, and would require a (significantly) different SAQ than if it were all processed directly through the authorize.net hosted forms (SAQ C or C-VT, vs SAQ A, perhaps?). Since this is a rare occasion, and there is no critical reason to enter these transactions into the virtual terminal, I have suggested that the accounting staff request an email address from individuals who call to make payments, and direct them to the authorize.net payment forms via a link in that email. This way we should eliminate CHD exposure on our network. The accounting team is small, and the CFO is willing to adjust process as needed. Does this seem like a logical move to reduce scope?
On the service provider side, one component of our business hosts event registration websites that our clients create. Those events may require payments, so we have API integrations with various gateways (authorize.net, PayFlow Pro, CashNet), that use the client’s merchant ID to process payments. So far I have confirmed that we do not record any CHD in our database for these transactions, and I am awaiting confirmation that our webserver logs do not hold CHD either. In either case, the fact that we are providing the form and pushing the CHD through the various gateways seems to mean that we fall under SAQ D as a service provider. We process under 300k transactions/yr, if that is a factor.
If we are not storing any of the CHD in the database or webserver logs, I expect (hope?) that we should be able to minimize the parts of our system that are in scope. I am still trying to get my head around what will be in scope for this transmission of data, and how we can properly segment the webservers from the rest of the network to reduce the scope as much as possible. Do you have any general advice on how to begin to approach this?
I have had a brief chat with the head developer about updating the APIs in an effort to offload all of the CHD exposure to the gateway providers, so we would be effectively out of scope for any exposure to the CHD associated with those transactions. If we were able to do this, would we still be completing an SAQ D, but marking it mostly N/A, since we have no exposure? What might still be required and included in the SAQ (monitoring, testing, other)?
We’re trying to determine the cost/benefit to reworking the gateway APIs to reduce scope so we can get started with the relevant SAQ in a timely manner and reduce risk where feasible. I’d be curious to know your thoughts on this.
My understanding is that SAQ D requires completion by either a QSA or an ISA. Is this always the case (even if we are offloading all CHD exposure to the various gateways)?
Hopefully this makes sense. Thanks in advance for your insight!
In regards to your merchant side situation. Having the accounting staff dealing with a very few transactions all comes down to a customer service issue that management needs to address. Does your organization prefer to: (a) continue things as they are and have accounting enter those few transactions or, (b) potentially irritate those few customers by telling them they have no choice but to go to the authorize.net Web site? The reason I position things that way is that those customers using mail order and telephone order (MOTO) are likely doing so for a reason such as they don’t like/trust the Web/Internet, they like old fashioned service, they do not have a computer, etc. That said, meeting the requirements in SAQ C-VT (please confirm this SAQ with your acquiring bank) are not that difficult unless you have poor security on your accounting workstations.
First, regardless of how much you limit scope, you will never be totally out of scope, even if you never come into contact with sensitive authentication data (SAD) or cardholder data (CHD). That is because you are a service provider with influence over the processing of SAD/CHD. Scope only changes whether you can use an Service Provider SAQ D or have to do a Report On Compliance (ROC). See my post on this topic ‘Get Over It, You’re A Service Provider’.
My guess is that because your organization is selling services that involve payments to merchants, your sales and marketing people will want to be listed on the Visa and MasterCard Global Service Provider lists, so you will have to do a ROC regardless.
Hi mate,
I think I asked a similar question before but just wanted to clarify something, and thought be good to post it here. What are your views around scenarios e.g. where third party vending machines (that take card payments) / parking machines are used by an organisation for their customers – these use customers’ network etc. however the card payments are cleared by those third party’s own merchant accounts and at the end of each month they just transfer the money to the customer’s bank account – these third party’s are PCI compliant for argument’s sake!
Do the customer have to worry about much here from a service provider’s point of view – especially when those third party’s have not really asked customer to do anything e.g. implement any controls etc.?
Cheers,
Ash
This can be problematic as I have encountered such third party solutions that treat the merchant’s network as a service provider because the third party solution is not encrypting network traffic. As a result, you need to make sure that any third party payment solutions perform their own encryption of their network traffic so that your network can stay out of scope.
What are your thoughts when merchant “A” contracts out part of the business to a third-party “B”?
For example, let’s say a coffee shop or parking ramp is contracted out to third-party “B” who runs credit card transactions on their own MIDs, but they just transfer the money to the merchant “A”s bank account.
Is third-party “B” a service provider to merchant “A”?
or
Is merchant “A” considered a Service Provider now to third-party “B” since they provide networking and infrastructure to third-party “B”?
or
Is third-party “A” simply a merchant of their own accord with no responsibilities to merchant “A”?
Third party “B” is technically a service provider to merchant “A” regardless of whose MIDs are used. However, merchant “A” could be a service provider as well if unencrypted traffic for “B” crosses their network.
Hi PCIGuru,
Your blog provides detailed insights and solves the confusion on Merchant / Service Provider relationship and compliance requirements. Much appreciate your inputs.
Query – for an entity who is both – Merchant and Service Provider; can there be just one AOC for both business operations? Or is it mandatory that the entity should have 2 separate AOC’s?
If 2 separate AOC’s then would it mean:
1. There should be a legal entity registered as a Merchant (e.g. ABC LLC, DBA – ABC Merchant) and another one registered as a Service Provider (e.g. ABC LLC, DBA – Payment Gateway services)?
2. Both entities should have different network segments?
3. Both entities should agree on contractual terms (req. 12.8) on owning adherence to PCI DSS compliance requirements?
4. Any other requirement you can think of?
If an organization is both a merchant and a service provider, then TWO AOCs are required. One for the merchant side of the business and one for the service provider side of the business. The two entities do not need to be incorporated or otherwise legally separate.
Should they have separate network segments depends on the business. For an organization that is a data center, the merchant side is typically going to be the accounting department. The service provider side will be the data center. In this scenario, they would like be on separate network segments. However, I have encountered situations where both businesses have devices on the same network segments.
Only the service provider side needs to worry about contractual terms because on the merchant side that is dictated by the acquiring bank.
I was just reading your article and some of the comments listed afterward. I have been working on PCI Compliance for my organization and am having difficulty figuring out where we are in regard to the type of assessment we need to do. I believe we are both a Merchant as well as a Service Provider.
From the Merchant perspective, we hold CC information and process a couple of hundred transactions a month using our own merchant ID through Authorize.Net. From the Service provider perspective we also store and transmit CC information on behalf of our customers, who provide their own merchant IDs from Authorize.Net. Information is entered directly on our site and passed to Auth.Net through their API. However, these aren’t really our transactions so I think this keeps our merchant level at the lowest. We’re hoping to do a self-assessment and avoid bringing in an external auditor. What SAQ would be appropriate and do we need a ROC?
Not unusual for an organization to be both a merchant and a service provider. Your analysis of your organization is spot on. Any transactions done through your own organization’s merchant ID count towards your merchant level and you will be required to file an appropriate SAQ (assuming your organization is under 1 million transactions annually). If your merchant transaction count is 1M or greater, then you will have to do a Report On Compliance (ROC) with either your organization’s Internal Security Assessor (ISA) or hire a third party Qualified Security Assessor (QSA).
On the other side, it is a tad more complicated. The transactions your organization conducts on behalf of other organizations count toward your service provider level. If as a service provider you do under 300,000 transactions annually for other organizations, you can do a self-assessment and file a service provider SAQ D and AOC. If your organization does 300,000 or more transactions, then you will be required to perform a service provider ROC under the same rules as the merchant ROC. If your organization wishes to listed on either Visa’s or MasterCard’s Global Service Provider lists, then the ROC must be performed by a QSA.
Thanks for the quick reply. Your article and responses to questions have really helped in clearing up the uncertainties I had in regard to merchants and service providers.
How is the Service Provider designation applied to organisations that provide Data Center services to subsidiaries of the same Company. By Example the main org is the Internal Managed service provider to only the Main org’s subsidiaries.
Technically, you are not a service provider if you are part of the same organization. That said, a lot of large corporations that have IT divisions/subsidiaries do assess themselves as PCI service providers and then provide their Service Provider Attestation Of Compliance (AOC) to the other divisions/subsidiaries. If you are taking that approach, you should discuss it with your acquiring bank(s) and get them on board before surprising them.
Are there any Pros / Cons to this approach?
Not really. Six of one, a half dozen of another. It’s done more to organize reporting of compliance by organizational boundaries more than anything.
Hello,
We’re a CA web hosting service that sells domain names but also sells hosting services. We’re SAQ-D compliant but are slowly working toward completely moving our credit card processing to a third party (and we will no longer store any CC information internally at all). As such, our management team is moving toward SAQ-A compliance.
Now, I’m realizing that I’m not exactly sure which category we fall under. As a web hosting service, do we actually qualify as a service provider? Management is under the impression that we are simply “merchants.”
As a Web hosting service, your organization could be both a service provider and a merchant. As you are aware, you are definitely a merchant because you accept cards for payment for your Web hosting services. However, unbeknownst to you, your organization could also very easily be a service provider if any of your customers are processing, storing or transmitting cardholder data (CHD) on their Web sites. This is why it is very important for organizations such as yours to ask customers whether or not they need to be PCI, HIPAA, GLBA or comploiant with any other regulatory requirements so that you know your organization’s obligations.
I’m currently completing the SAQ D for our company as a service provider, the previous audit i carried out was on PCI version 2.0, the latest one is 3.1 and includes a new column called “Not Tested” – does this mean i have to produce a formal test for each and every point ? if so is there a template which can be applied to all tests or should i create my own ?
The PCI SSC requires that you use their forms. NO EXCEPTIONS.
“Not Tested” is to be used for those instances where testing was not performed because a third party is responsible for compliance with the requirement or the requirement is out of scope for the assessment being performed. In either case, you need to explain the reason for the requirement not being tested. In the case of third party responsibility, you will need to have that third party’s Attestation Of Compliance (AOC) that supports your assertion. In the case of not testing requires because it is outside of the assessment scope. We typically only see this when, for example, an organization is only assessing a particular part of their environment such as Application Development and not the whole environment.
If you are assessing your whole environment, then you should be using ‘Not Applicable’ and documenting the reason why a requirement is not applicable to your assessment.
This is an interesting discussion.
I wonder what the case would be in the following circumstances:
1. An entity has a merchant account. It accepts payments for its own services online via an i-frame to the Acquiring Bank. So far, so good, and it appears to be in scope for an SAQ-A as a merchant;
2. Its services are the provision of a system which allows customers to browse products and services on behalf of third party merchants, and when a purchase is contemplated, to through an i-frame allow a link to a payment provider (PCI compliant) such that no card details unencrypted or otherwise are ever brought into contact with the system. Is that organisation (1) Out of Scope on the basis that no CHD is involved (2) a Service Provider.
If the latter, and assuming that the two parts of the environment were totally separate, could it assess each environment separately. Ie SAQ-A for the merchant part, and SAQ-D for the service provider element?
If so, and given that there is no card data environment, could large parts of SAQ-D be marked n/a? In other words, what would the minimum (as opposed to advisable) level of controls possible? Could the n/a provisions in SAQ-D in these circumstances reduce the service provider obligations to something approaching an SAQ-A given the use of i-frames?
They are a merchant (payment for their services) and a service provider (they control part of the payment process through the invocation of the iFrame).
They would do the SAQ A for their merchant side for their acquiring bank. Since they do not technically have transaction volume, they could do an SAQ D (service providers must do either an SAQ D or a ROC) if they have no interest in being listed on the Visa or MasterCard Service Provider lists. And yes, that SAQ D would have a lot of N/A on it.
Looking for an opinion on the scenario that a Level 1 merchant is also a payment system service provider to a company doing more than 300,000 transactions/yearly. The payment system is logically/physically separated from the Level 1 merchant via a segmented virtual environment. The merchant is assessed annually via ROC. What would the merchant be required to provide regarding PCI compliance attestation for the service provided environment?
You need to do a Report On Compliance (ROC) for a service provider. As long as the merchant environment can never come into contact with the service provider environment, the merchant environment can be assessed based on its transaction volume and how that volume is processed such as online, mail order/telephone order (MOTO), brick and mortar retail, etc.
We are company working towards compliance but have become unstuck in respect to defining our classification.
Our process is as follows – we intend to accept credit card details on our website which are then passed on to a third party via their API over a secure connection.
This third party in turn passes these details encrypted to a payment processor who returns a tokenisation of the card to them.
We anticipate that transactions will be somewhere less that 100,000 per annum. We do not store any card information.
As we do not process the cards for any payment we believe we do not fall under the category of Merchant.
If we are a Service Provider we would fall under the category of a level 2 Service Provider.
If the last statement above is the case, do we need to register with Visa/Master Card as a service provider?
Also, in our documentation requirements in providing proof of compliance do we need a AOC signed off by a QSA after an on-site assessment? or will a SAQ-D + AOC suffice?
The statement that you accept payment cards for payment on your Web site would seem to indicate that you are a merchant, not a service provider. The key to confirming whether or not you are a merchant is – are the payments processed under your organization’s merchant identifier or are the processed under the merchant identifier of customers or your organization? If processed under your organization’s merchant identifier, your organization is the merchant. If your processing on the behalf of your customers, then you are a service provider.
We do not process payments via our Merchant ID. So that would make us a service provider. That, being the case do we need to register with Visa & Mastercard as such?
As for proof of compliance does our Service Provider AOC require a QSA to sign? or can we complete a SAQ-D and AOC ourselves?
First the easy answers. You can perform your own SAQ D assessment and have it signed by an officer of company such as the CEO or CFO. Your Service Provider AOC should serve as proof of compliance for your bank, processor, customers, etc.
As to the Visa and MasterCard Global Registries, this is where things get messy. The Global Registries that both these card brands operate are merely marketing schemes. You must be sponsored by the respective card brand or your acquiring bank and then you pay to be listed on each of those sites. Once you have paid, you must have a Report On Compliance (ROC) performed annually by a QSA that results in a compliant ROC to maintain the listing.
To complicate things, Visa is also conducting a program behind the scenes to build an inventory of all service providers. That list is mandatory for all service providers to get listed. There is no fee and that inventory is private, used only by Visa. Your processor or acquiring bank will assist you with that process.
Our company has a complex commerce model. It seems like we’re both a service provider and a merchant. We sell some software products directly (merchant), but we have one custom portal that we develop/host for a large company. This portal uses iframes to push eCommerce transactions to authorize.net. So that sounds like a service provider as well.
Right now, our bank is having us fill out multiple SAQs for the our different types of commerce, but leaves it up to us to decide which ones. It sounds like our best bet is to fill out a SAQ D for the hosted service, but then mark off about everything since we don’t store, process, or transmit.
For the product we sell directly, its the same thing. We don’t ever store, process, or transmit, but only use iframes to send cardholder data to authorize.net. So for that other traffic where it’s not a service but we host an application for ourselves, I guess we fill out a SAQ A?
Finally, for our call center, If management decides to keep it on site, and if we implement virtual terminals, then we fill out a separate SAQ C-VT? Or because we’re hosting the call center for our one special customer does it get a SAQ D as well?
I’d welcome your thoughts.
For the service provider business, you only have the choice of a Service Provider SAQ D (there are now two versions of SAQ D, so make sure you use the service provider version) or have a QSA conduct a Report On Compliance (ROC).
Based on what I know about authorize.net, I’m assuming that on your merchant business, you are using your own iFrame solution. If that is true, then you are not going to be able to use SAQ A because you have not totally outsourced your payment processing. I am betting that you would have to do an SAQ D for your merchant eCommerce business as well.
Combining everything into an SAQ D would simplify things for the bank (one report) but might be more complicated for your organization to produce than doing multiple SAQs that focus on each type of commerce.
So, ~W is a service provider… but that might be because their portal serves only one merchant, and thus probably processes “on the merchant’s behalf” using the merchant’s account. My company doesn’t do that, but I’ll bet you’d still say we’re a service provider.
We operate a multi-vendor e-commerce website using a “marketplace” service of a major payment provider. A single transaction for one of our vendors is run against OUR merchant account, and the proceeds are deposited into a single bank account. From there, we can disburse the transaction amount (less our service fee) to the vendor’s bank account. Using an API much like an iFrame, we never see the CHD.
But your post notes that we could be considered a service provider if we “provide services that control or could impact the security of cardholder data”. Am I correct to assume that even given our use of iFrames and our own merchant account, my company can’t avoid the a service provider tag because we can impact the security of CHD (as by spoofing the payment provider’s site)?
It’s the fact that your organization is the conduit for conducting your customers’ transactions that makes you a service provider. But to add insult to injury, your organization is conducting transactions on your customers’ behalf using your organization’s merchant ID and that is just icing on the cake.
1. What about those who provide services such as “Merchant as a service”. They create the sites, and act as a merchant on behalf of customer, but refer to payment gateways that post data thru JavaScripts directly to Payment gateway and since “they never see the data”, which might be true, “they don’t have an obligation to report PCI Compliance”. To me they are still a service provider. I notice most of them provide Self-Assessments with the ASV certificate as an attestation of compliance. Are they required to have an AoC by a QSA? I don’t necessarily care for the Self-Assessment of a service provider, anyone would be compliant….
2. How about those providers that develop mobile payment applications. Are they subject to PA-DSS, and if so, are they subject to QSAs AoC?
Thank you.
Posting data is processing and transmitting of cardholder data (CHD) so that will place you in-scope.
The only way to be out of scope is totally avoid processing and transmitting CHD is to use a redirect to a third party or an iFrame provided by the processor or third party. Any other method puts the provider in scope.
Based on the fact that the PCI SSC has stated that mobile solutions are never going to be certified or PCI compliant given the current technology, I would say that for the time being, those applications will not be PA-DSS or PCI compliant.
Hi,
Regarding the ‘…. totally avoid processing and transmitting CHD is to use a redirect to a third party or an iFrame provided by the processor or third party….’ here also, the merchant system has ‘some’ control as to how the browser is redirected to, therefore I believe the SAQ-A comes in to force.
In other words, if the merchant system has some control in that manner where the browser is redirected to the 3rd party (which is a CDE) the merchant’s system is in scope but it would be a very narrow scope. correct? “Scope of PCI DSS Requirements : The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment.”. So, I believe such systems are still in scope and a SAQ-A is applicable & not a case of ‘ fully out of scope’. ?
a) Merchant site is redirecting to the 3rd party > sufficient to submit a ‘SAQ-A’ (if Level 4 merchant, an on-site assessment by the QSA as well) by the merchant to their acquirer/bank
b) The Merchant’s ID is used in the ‘Merchant as a Service’ site (a separate service provider for the Merchant) on behalf of the merchant to redirect the browser to the 3rd party; many such merchants with individual Merchant IDs linked in the Service Privider in that way > still the merchant can use his option as the above ‘a’ scenario for a SAQ-A, My question is if the middleman/’Merchant as a Service’ is now in the scope on it’s own and therefore obliged to complete the full Service Provider SAQ-D? And the ‘Service Providers’ have to validate to the card brands and not to the acquirers, so , a Service Provider which simply connects to the 3rd Party processor (iFrame) having to complete all 200+ requirement plus having to validate its compliance to up to 6 card brands is an overkill I suppose.
Bit confused, have I misinterpreted something here? Please advise on these.
Thanks
The merchant Web site is not required to have ASV scanning and internal scanning as the Council and card brands believe they are not part of the payment process. However, as you accurately point out, they still can influence the payment process. So I recommend that my clients still scan their Web sites and regularly patch them even though SAQ A does not require it.
I have met with folks from a corporation that offer goods directly, with online payment (they actually resell for others, but having purchased the goods themselves). But they also let one of their major client run on their system directly and sell the goods themselves
In turn, their acquirer is pressuring them to go from merchant (seller) to service provider as they accept payments for another merchant (deposits made in a different bank account) on the same ecommerce platform…
From my previous audit experience in non-PCI fields, resistance to review is a sure sign that all is not well – this should be a red flag to any ISA or QSA.
In my experience, the reluctance of some corporate operations to assess as a service provider is driven more by cost and denial. PCI is just one more thing to comply with and they have enough on their plates.
Another way to become “both” . . . a merchant who is a Corporate Franchise Servicer (see http://usa.visa.com/download/merchants/bulletin-corporate-franchise-servicer-category-06162010.pdf).
This says that a franchisor that provides centralized network/system services to franchisees may qualify as a service provider. If the franchisee does not have a segmented CDE, then you are service provider (regardless of the whether you are processing payment card data for the franchisee).
If the franchisor has separate B2C or B2B eCommerce sites or “owned and operated” POS locations then the requirement to certify as a merchant exists.
Some, but not all, corporate franchise operations tap into the franchisees’ systems. And some of that access is not even related to card processing, it’s inventory management, payroll, sales data. However, because the franchisees’ systems are “all-in-one” solutions, because corporate has access, they end up in scope.
Another famous example is Exxon/Mobil Speedpass. Exxon/Mobil corporate stores the cardholder information and all participating franchisees pass their Speedpass transactions through to corporate for processing.