5

I have a B2B SaaS that my clients then use with their own customers to gather data in a face-to-face scenario with iPads, I would like to expand it to take credit card details. The credit card details would be stored with a PCI compliant third party.

For the processing I could either have the credit card number go through my server (and connect to the third party mentioned above) or use another third party like spreedly.com to do transparent processing (where the credit card number doesn't touch my server at all).

As I'm defined as a service provider, and the volumes are low, then I think the only option is 'SAQ D for service providers'. It seems that is the strictest (and therefore greatest cost) of the SAQs, and that if I had that compliance then I could process the CC data on my servers and even store the CC data if I wanted to.

To me it seems strange I would need the same level of compliance if the CC data never touched my server as if I choose to store the CC data (or at least process it on my server)! So my question is have I got this right or am I missing something?

And apart from that, would my clients need to have some level of PCI compliance, since they would be collecting the CC data? Even though it would all be going through my system and the connected third parties.

Edit: I didn't mention that the money flow ends up in the clients bank not mine, if that makes sense. So I think the client would be responsible for ensuring they used a PCI compliant supplier and also their bank would dictate what compliance they would need to reach separate from me. So I would guess it's wouldn't be my responsibility to ensure the client has PCI compliance, but not sure.

Improve this question

3 Answers 3

Reset to default
2

If you outsource all cardholder data to a third party and you require compliance yourself, then the applicable requirements for SAQ A are applicable to you. While the PCI DSS consists of a large number of requirements (i.e. SAQ D), the vast majority of these will not be applicable to you if you do not handle cardholder data. Depending on volumes you may not qualify to complete a SAQ. In this case you'd have a complete Executive Summary in a ROC (Report on Compliance) and only those requirements applicable to you would be validated.

If you wish to transmit, process or store cardholder data, many of the requirements of the standard will be applicable for validation and the cost and time of compliance is increased though, ultimately, it may give you greater freedom (and expose you to greater risk).

If your clients handle cardholder data, they need to be compliant. If they outsource this to you, you need to demonstrate to them you are compliant. You, of course, can further transfer this to another compliant third party. e.g. merchant A can use service provider B who uses service provider C to handle merchant A's cardholder data. In this case, the merchant and both service providers need to be compliant though only a single entity, service provider C, handles cardholder data.

Improve this answer
2
  • 2
    Good answer. Just one clarifying point about the applicable SAQ version. You are correct that SAQ A applies when out sourcing payment processing to a 3rd party, but that is only for merchants. Service providers, if allowed, must complete SAQ D - Service Provider. There is no other SAQ form allowed for service providers. The other option is to go through a PCI assessment with a QSA and have them issues you a ROC.
    – Timee
    Dec 16, 2014 at 16:31
  • Thanks for the responses. If I look at this definition pcicomplianceguide.org/pci-faqs-2/#13 then I think the only option is as a service provider. But yeah the more I push to a third party then the less that is applicable in the SAQ and therefore less cost etc.
    – Richard
    Dec 16, 2014 at 23:38
1

If the CC data never touched your servers, you wouldn't be a (PCI) service provider, so no - the same level of compliance requirements do not apply in both cases. (That said, SAQ D covers the majority of cases, so yeah, it covers a broad range of involvement).

Yes, your clients will need to have some level of PCI compliance as they're collecting the data. By definition:

PCI DSS applies to all entities involved in payment card processing—including merchants, processors, financial institutions, and service providers, as well as all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.

You want to think about partnering with a service provider to take yourself as far out of the loop as possible. If you're a SaaS provider, concentrate on the S and the S and not the CC.

Update following comment below

I don't feel we have all the information here.

If you're a SaaS provider, the software is "centrally hosted", meaning it runs on your servers. If that software then stores, processes, or transmits card data, you're a PCI entity and need to figure out where you fit in the compliance world. You may be able to get help from your Acquirer or Processor to determine what your compliance requirements are (you can't do anything with those cards without an Acquirer or Processor, and they're the ones who (for example) collect your SAQ and, hopefully, help you figure out which one applies).

If you're simply providing software for other people to run on their systems, and want to add credit card related functions, you're probably straying into PA-DSS territory - "the definitive data standard for software vendors that develop payment applications." That's more complex territory.

If you're integrating someone else's software - something like a Processor's API - into your own, then I simply don't know, but again, the Processor that provides the API should provide guidance as to the PCI obligations of whoever uses their software. I'm out of my depth there and can't say much of use.

As for your comment "hard to see where you fit in" - the system is very complex; consider this from Wikipedia on Processor Vantiv: "Another evolution of payment acceptance has come in the form of Integrated Software Providers (ISPs), Payment Facilitators (PayFacs) and Value Added Resellers (VARs)." I believe PayFacs at least fall in as Merchants and not Service Providers. I checked, and PayFacs at least fall in as Service Providers (I work at Vantiv and asked a coworker in Compliance). Which goes to - again - talk to your Processor or Acquirer. They may or may not be helpful, but they're a start.

Improve this answer
3
  • Thanks for the response. That leaves me the question of what PCI compliance I would need then, if the CC data never touches my servers? Perhaps none, but then it is my code that would be directing it to the third party (even if it's transparent), so must be some level of compliance. It's hard to see where I fit in if not as a PCI service provider.
    – Richard
    Dec 15, 2014 at 23:46
  • Thanks for the update and the advice. I'll contact the processor and see what they have to say. My thought now is that I will need to complete the SAQ D for service providers but some of the areas may not be relevant if I'm using a transparent third party to process and store the CC data (but should be less work to reach compliance).
    – Richard
    Dec 16, 2014 at 23:30
  • I think I may have confused the issue by talking about the transparent processing. Yes it is a SaaS as you define it, centrally hosted etc. With the transparent processing I guess you post it to the processors servers directly, rather than first going to my servers then some API call. So it would go through my interface on the iPad but then directly to the processor, in that case. Hopefully that's a little clearer.
    – Richard
    Dec 16, 2014 at 23:43
0

My thoughts: Here is a good link that explains different SAQ levels. If you are a service provider, you need to fill out SAQ D for service provider. Your clients would definitely need to obtain PCI compliance as they are collecting CC data.

Another thing that might help you with this discovery is the PCI third party security assurance information supplement doc at this link.

I agree with above answers that it's best to ask the processor/acquirer.

Improve this answer

You must log in to answer this question.

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