3

after reading a lot of PCI DSS stuff I'm still not sure whether it would be ok for us to use the following process in our app:

  1. Get full credit card data from attached card reader
  2. Tokenize it using Stripe payment processor
  3. Use later for payments

Since we would not store credit card data on device, we do not have to worry about compliance, right?

Also some readers, like MagTek, offer only encrypted data over their API. I assume that decrypting it in the app and immediately tokenizing does not violate the PCI, right?

1
  • "Since we would not store credit card data on device, we do not have to worry about compliance, right?" No, as long as you handle card payment transactions in any way you are on the hook for some kind of PCI compliance. In the easiest and most straightforward --and most secure-- compliance cases you are running cards through a standalone terminal that talks directly with the payment processor or are using P2P/reader-to-payment-processor encryption. But there is always some form of PCI credit/debit card information security demands that you need to be aware of. Sep 28, 2015 at 20:23

3 Answers 3

4

You always have to be PCI compliant. It just depends on how you process the information if restrictions or requirements apply. Have a look at the following PCI Council document for accepting payments with mobile devices.

What you are doing is seemingly in accordance with the PCI requirements for payments using a mobile device. If your solution (or the one you are leveraging) has been vetted and approved by the PCI council you are considered PCI compliant. So make sure to inquire about the tokenization process and if they can proof it has been vetted by the PCI council or a QSA.

With regard to the MagTek implementation, I'm doubtful it's compliant since the whole point of having a seperate device is to prevent the actual card holder data from touching the phone. It's important when decrypting that it's not stored at anytime on the device, ever. This includes logs and crashdumps. I would inquire directly with MagTek and request proof of validation.

2

A mobile device can be used within a validated P2PE solution but, as a device which handles clear text cardholder data in any capacity at any time, it is not yet possible to validate such a solution. The guidance from the council to date does not provide a mechanism to validate mobile applications so, while they should be developed in accordance with PCI/PA requirements, they cannot be validated and/or listed as compliant.

The purpose of using a P2PE validated solution would mean the cardholder data would be encrypted within the card reader and decrypted in a decryption environment so the mobile device and its application would only ever see encrypted data and would not have the means to decrypt such data.

The solution outlined above suggests, the mobile device has a decryption key to decrypt the encrypted data received from the Magtek terminal before sending the data for tokenisation - it would not be possible to validate this solution.

1

As the other answers have said, and as I redundantly commented above, you actually are very much still covered by PCI Requirements concerning the security of credit & debit card information that is handled on your network. One area of the PCI Requirements set for merchants contains the mandate that if you store cardholder information for any reason it must be either encrypted or tokenized. (For general reference, tokenization as referred to here means where the payment processor receives the cardholder's info the first time he or she uses it at a merchant and then gives the merchant a generated "token" id that the merchant can store and provide to the processor in future transactions as a substitute for having to recall a buyer's real credit/debit card info from storage. The token protects the buyer because any token can be used only by that one specific merchant to make future charges.) Tokenization is fine and dandy as a way of not storing plain-text Primary Account Numbers on your systems; if you do it right it fulfills the rules in PCI Requirement area #3 that cover the storage of card information*. But--here's the big thing-- the other rules in the other 11 Requirement areas still also apply to you. Tokenization (again, as we're talking about it here) just gets you past dealing with the section #3 rules about storing card information.

It seems like you might be getting tokenization as a means to not store cardholder Primary Account Numbers a little mixed up with the concept of Point-to-Point encryption (aka "P2PE" or sometimes "on-swipe encryption"), which deals with the protection of card information as transaction occurs. Well-implemented P2PE is a wonderful thing; the card reader or terminal that reads the purchaser's card when he or she swipes it (or "dips" it, with the EMV/chip cards now being finally transitioned to in the U.S.) encrypts that information before it ever leaves the reader/terminal. The encrypted card information flows from the reader to you mobile app or fixed Point-of-Sale setup and then is sent along to your payment processor's network, where only there is it decrypted so the purchase transaction can be processed. Because none of your equipment as a merchant ever sees an unencrypted card number or other vital data during a transaction there's no possibility a cyberthief can steal it from you. You never had it to steal to begin with. For this reason, the PCI Requirements allow a merchant using P2PE properly to avoid putting the merchant's computer systems under the scrutiny of 10 of the 12 PCI Requirement areas. Note, however, that even here not all PCI rules are discarded; the merchant must comply in providing physical security for the areas where the card terminals/readers are used and/or stored and in issuing various policies about information security to the merchant's employees/etc.

In your situation, unfortunately, as Andymac explained very well you couldn't qualify to get out from under those PCI compliance areas that merchants using P2PE don't have to worry about. Your computer, whether smartphone, PC, or anything else, "sees" and handles unencrypted credit/debit card info when it comes from the card reader. Moreover, any setup like that obviously couldn't be further specifically approved by the PCI people to become an official "Validated P2PE Solution" of the kind you need to have if you want to use that sweet reduced-question P2PE-HW SAQ compliance assessment.

Now, there are any number of these payment "solutions" out there that will both use P2PE in a way that qualifies you for the reduced-scope PCI compliance and will also do tokenization for you so that you keep the ability to charge a customer's card without ever having to actually store card information. Google or Bing will point you to any number of vendors who would be thrilled to tell you about their P2PE-compliant offerings. Whether those offerings are suitable to use with stripe--or, if they aren't, whether you want a reduced compliance burden so much that it's worth switching to a new processor--is something you'd have to think about.

  • One thing its always good to remind anyone reading of: Storing debit card PIN numbers, data from the special authentication data track on the magnetic stipe, and/or that CVV/CAV string of 3-4 digits on the back of every card is always totally prohibited, even if encrypted, tokenized, whatever. Because those three things are items of information that a thief would need to have in order to produce a working counterfeit card, use a stolen card number online/over the phone, get money from an ATM, or do other fraudulent things. See page 15 of the linked-to PCI quick reference guide. Ironically, on the other hand a card's expiration date can be stored clear-text in perfect compliance with the rules. God, PCI requirements can be stupid.

You must log in to answer this question.

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