2

We run an online software service that collects and transmits card transactions for small merchants. They use card swipe terminals connected to their business PCs that direct the traffic straight through to our secure portal via HTTPS with two factor authentication. These merchants are our customers and their business models and practices are as varied as their names. We don't control what they do inside their office space. Many are not PCI certified yet.

As part of our sign-up service, we purchase the card swipe hardware for them from hardware resellers and have those distributors drip-ship directly to our customers. Over the years we have recommended 3 different Magtek models: Imagesafe, MICRImage, and Dynamag Magnesafe. These components never enter our physical premises. They are purchased by us and shipped directly to the customer. We do not modify them and we do not own them.

So, am I required to track them as part of our hardware inventory under PCI DSS 3.0? If so, I know I would need hardware and serial numbers, policies and procedures for hardening each one, and a way to test and track each one. I'm talking thousands of small merchants, and the thought makes me sick.

My hope is that, because I wasn't the distributor, I can simply send each merchant a set of hardening instructions specific to the brand/model of terminal they have and ask for attestation that they have implemented those instructions. Will that suffice?

My worry is that, because I was the purchaser, I will be on the hook for secure deployment of these terminals in each merchant's environment.

What do you think?

Improve this question
3
  • 1
    "Many are not PCI certified yet." I think you're already past the point of Trouble. Are you their processor? I believe you're responsible for collecting their SAQs.
    – gowenfawr
    Commented Jun 9, 2015 at 2:26
  • We're not the processor. We collect and transmit their transactions to a processor.
    – Skelter
    Commented Jun 9, 2015 at 6:04
  • You're simply a service provider. You're responsible for ensuring any computer YOU control that stores, processes or transmits cardholder data is PCI compliant. So from the point the data hits your secure portal till you send it off to the processor you're responsible. They're responsible for the swiping and sending the data to your portal so THEY would need to manage all the inventory of the swipe devices and inspection and whatnot.
    – JekwA
    Commented Jul 9, 2015 at 17:31

2 Answers 2

Reset to default
1

First, it's great that you're actually taking PCI compliance rules seriously. (No, that isn't a joke or an attempt to suck up; it's just been my experience with both merchants and other entities covered by PCI requirements, that if you can get them to care enough about PCI compliance, to get them to a place "in the ballpark" of abiding by the rules that apply to them, you've pulled off a nice win. You are committed to going beyond that standard in pursuit of actual compliance.)

Second, to summarize what I think the answer to your question is: The additional requirements most likely do not apply to you in your situation as you describe it. I offer that view because of/depending on the truth of a few points that I'm inferring from the statement of your question. Among them:

  1. I'm assuming that up until this point you are used to doing your PCI stuff solely within the PA-DSS rules (ie. for payment application developers), and you are confident you don't fall within the rules covering payment processors.

  2. I'm also assuming you do not furnish any "resident payment applications" that exist on the hardware terminals the merchants you serve are using. This is a key assumption, as laid out within version 3.1 of the PA-DSS rules; if you did furnish payment application code that sits on your merchant's terminals a number of additional requirements would probably apply vs. what you are doing now. However,the good thing is that if you did indeed create on-terminal payment code as part of your solutions you would obviously know it.

  3. From your statement, it seems like you have absolutely no role regarding the payment terminals except that you technically pay for them from Magtek (or other makers). You have no role whatsoever in the setup of the terminals to accept payments; your merchants talk directly to the payment processor to register their equipment setup their encryption keys, etc. And, to be 100% clear you are never in physical possession of the terminals (ie. they ship directly from Magtek or another maker to your merchants).

  4. Finally, I'm assuming that, at very least, a substantial minority of your merchants do not use end-to-end/ P2PP /swipe-to-payment-processor encryption. That, of course, would make a lot of your PCI headaches a lot easier. (Not having unencrypted card numbers and track data touch any of your services or software always does.) And the payment card info of the people who shop at your merchants a lot safer. And as your merchants proceed to switch to card readers that can handle chip-card use that would be a good time to encourage them to make sure that their new readers/terminals get setup to encrypt magnetic stripe transactions properly as well. (A gentle hint.)

So, all those conditions above being true, in my view your situation, more likely than not, does not require you to meet the additional requirements you discuss regarding the tracking the custody, status, and integrity of the terminals. I'll close by reinforcing the "in my view" part of that last sentence: if it's a possibility that you are indeed seriously concerned about and feel you really need a rock solid answer on you should definitely engage and seek the advice of a firm that has strong expertise in payment software/service developer-end PCI compliance. So ... let that stand as my disclaimer about relying on the above analysis.

Improve this answer
2
  • Halfinformed, presumptions 2-4 are 100% correct. Presumption 1 is a little murky. Our app does act as a "payment gateway" of sorts thanks to a 3rd paty app we purchased from Monetra. We are not their issuer or acquirer. However, I feel secure in leaving the terminals out of scope for the other reasons you stated, in addition to the logic laid out in AndyMac's answer.
    – Skelter
    Commented Sep 13, 2015 at 5:33
  • Ahh, I see now. Well, still I would agree that without having physical custody or control over the card equipment at any time you aren't responsible under PCI for meeting those custody-tracking rules. Only thing I might be careful of is to try to make sure that merchants know that it's their responsibility to track the card equipment in shipment from the manufacturer and to contact them if its late or doesn't show, not yours. But as long as your role ends at providing shipping address info to the manufacturer it should be them and merchant, not you, on the hook for custody-tracking,
    – mostlyinformed
    Commented Sep 14, 2015 at 19:24
1

All those merchants will ultimately be responsible for their own compliance and this should be enforced and monitored by their acquirer. They will generally have to complete a Self Assessment Questionnaire, my guess being SAQ B-IP which includes a PED with IP connectivity. That SAQ also includes the PCI DSS requirements 9.9 to which you are referring. If you don't own those devices and you're not responsible for their management, then is the responsibility of the merchants themselves to adhere to those requirements.

Given that you provide the devices to the merchants, you could provide guidance on how they should manage those devices securely, maintain an inventory, identify whether or not they've been tampered with etc but you don't have to do this.

Improve this answer

You must log in to answer this question.

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