31
Jan
15

Merchant, Service Provider Or Both?

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.

Advertisements

49 Responses to “Merchant, Service Provider Or Both?”


  1. 1 John
    February 1, 2017 at 2:16 PM

    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.

    • February 11, 2017 at 10:03 AM

      I would agree they are a service provider as long as they are not a division or subsidiary of your organization.

      • 3 John
        February 11, 2017 at 10:07 AM

        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.

  2. 4 Gavin
    December 14, 2016 at 3:21 PM

    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?

    • December 14, 2016 at 3:28 PM

      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.

  3. 6 Samuel
    October 14, 2016 at 6:48 AM

    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.

    • October 14, 2016 at 3:20 PM

      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.

  4. 8 Tim
    August 15, 2016 at 10:55 PM

    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?

    • August 16, 2016 at 7:11 AM

      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.

  5. June 28, 2016 at 10:29 AM

    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!

    • June 28, 2016 at 1:03 PM

      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.

  6. 12 Ash
    May 12, 2016 at 7:57 AM

    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

    • May 12, 2016 at 10:45 AM

      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.

      • 14 Chris
        May 23, 2016 at 11:22 AM

        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”?

      • May 23, 2016 at 6:45 PM

        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.

  7. 16 Hunter
    May 3, 2016 at 5:30 AM

    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?

    • May 3, 2016 at 8:38 AM

      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.

  8. 18 Mike
    April 25, 2016 at 12:38 PM

    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?

    • April 25, 2016 at 1:15 PM

      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.

      • 20 Mike
        April 26, 2016 at 11:59 AM

        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.

  9. March 9, 2016 at 4:16 PM

    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.

    • March 10, 2016 at 8:01 AM

      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.

      • March 11, 2016 at 12:49 PM

        Are there any Pros / Cons to this approach?

      • March 25, 2016 at 7:26 AM

        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.

  10. 25 Crystal Presario
    October 27, 2015 at 8:48 PM

    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.”

    • October 28, 2015 at 5:17 AM

      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.

  11. 27 F
    October 1, 2015 at 6:46 AM

    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 ?

    • October 1, 2015 at 5:14 PM

      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.

  12. July 8, 2015 at 8:36 AM

    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?

    • July 8, 2015 at 8:49 AM

      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.

  13. 31 Greg Kratz
    May 22, 2015 at 12:47 PM

    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?

    • May 25, 2015 at 12:27 PM

      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.

  14. 33 Tim Peary
    May 22, 2015 at 9:15 AM

    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?

    • May 22, 2015 at 9:42 AM

      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.

      • 35 Tim Peary
        May 26, 2015 at 3:59 AM

        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?

      • May 26, 2015 at 4:53 AM

        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.

  15. 37 ~W
    February 10, 2015 at 11:46 AM

    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.

    • February 10, 2015 at 5:13 PM

      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.

      • May 16, 2016 at 11:59 AM

        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)?

      • May 17, 2016 at 1:43 PM

        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.

  16. 41 I. Rodz
    February 9, 2015 at 8:54 AM

    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.

    • February 9, 2015 at 9:18 AM

      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.

      • 43 JG
        November 16, 2016 at 7:21 AM

        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

      • November 20, 2016 at 4:19 PM

        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.

  17. 45 Louis
    February 4, 2015 at 8:46 AM

    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…

  18. 46 Kieran HIggins
    February 3, 2015 at 11:24 AM

    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.

    • February 3, 2015 at 8:42 PM

      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.

  19. February 2, 2015 at 2:29 PM

    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.

    • February 3, 2015 at 6:46 AM

      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.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

January 2015
M T W T F S S
« Dec   Feb »
 1234
567891011
12131415161718
19202122232425
262728293031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,800 other followers


%d bloggers like this: