We will be providing a service to a client, where the end user logged on to our system can submit their payment information to Authorize .Net.

I need help figuring out if we as a service provider need to be PCI Compliant.

We will either select the Accept Hosted option or Accept.js option (SAQ A or SAQ A-EP solutions.)

But I also found out here: Understanding PCI Compliance, that PCI Valdiation requirements depend on the number of transactions as well, so does that fall on the merchant(the client) or us as service provider?

We will just route the payment information to Authorize .Net, and we will only keep the last four of card number/ bank account and the transaction ID if available.

So my question really is, whether

  1. Only we need to be PCI Compliant

  2. Only the merchant needs to be PCI Compliant

  3. We both need to get the same level of compliance

  4. We will need to get different levels of compliance

I couldn't really find any thing that differentiates Service Providers and Merchants, so not sure what needs to be done in this case.

Note: We will use the Merchant provided credentials while making calls to the Authorize .Net API.

1 Answer 1


Welcome to the strange world of PCI DSS compliance.

The merchant has a contractual relationship with its acquiring/merchant bank (aka acquirer) to comply with PCI DSS. How the merchant demonstrates its compliance with PCI DSS is up to the acquirer, it is based on card brand (Mastercard, AmEx, Visa, Discover, JCB) rules and is dependent on the number of transactions a merchant processes a year. The merchant will either need to provide a self-assessment questionnaire (SAQ) or have an on-site audit from an assessor (QSA) ending with a report on compliance (RoC).

Part of the merchant's compliance requirement is the compliance of its service providers (aka you) - this is PCI DSS requirement 12.8. In their contract with you, they should ask you to comply with the requirements of PCI DSS.

Together you will agree which of the 300 or so PCI DSS requirements are appropriate for you to comply with. And, based on your question, it would probably be those contained in SAQ A or SAQ A-EP.

If the merchant is being asked for a self-assessment questionnaire by their acquirer, they have two option:

1. Ask you to self-assess

Based on what you’d agreed with the merchant, you would complete the relative SAQ and give it to them. They may also ask you to have an external assessment - this is between you and the merchant.

You asked if you'd both use the same form of assessment and the answer is probably no. I'm going to speculate that the merchant is outsourcing everything to you, so they will probably complete SAQ-A for their acquirer. However, because you are hosting their website you may (as you say) need to fulfil the requirements in SAQ A or SAQ A-EP depending on which Authorize.net service is selected.

(Technically a service provider can only complete SAQ-D but what you would do if you had agreed with your merchant that the requirements in SAQ A-EP were the appropriate ones would be to complete "SAQ-D for Service Providers" (it is different to the merchant SAQ-D) marking all of the requirements that are not included in SAQ A-EP as "Not Applicable" - this approach is described in PCI SSC FAQ 1331.)

2. Be part of their assessment

Let's say you don't want to provide any evidence in the form of an SAQ or RoC to your merchant customer. The merchant would then have to include you in the scope of their self-assessment. So they would "visit" you and assess whether you were complying with all the relevant requirements. The merchant would then complete the relative SAQ and send it to their acquirer, you would not have to do anything. In this case the merchant would complete either SAQ A or SAQ A-EP for their acquirer.

If you - as a service provider - get fed up of people assessing you, you could have your own external assessment by a QSA, get your own RoC and then just give it to any merchant that asks.

There's one more wrinkle. Some card brands (notably Visa) maintain a list of service providers. If you want to get on their list you would have to enter a contract with the card brand directly which would require you to comply with PCI DSS. This would require you to send evidence of your compliance directly to the card brand, and then the card brand would determine whether an SAQ or RoC was applicable based on the number of transactions you process across all the merchants you are a service provider for.

I know, this is initially confusing but I hope that is useful.

  • Thanks @withoutfire, this was really helpful. Can you please point me somewhere where they define who's a Service Provider? I want to make sure that we're not doing anything that might take us out of the Service Provider role. Apr 24, 2020 at 13:16
  • 1
    There is a great and sadly neglected document called the PCI DSS and PCI PA DSS glossary of terms, abbreviations and acronyms. pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf Apr 25, 2020 at 14:07
  • 1
    Service Provider: 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. .... Apr 25, 2020 at 14:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .