4

I've researched for quite some time now, but I cannot find an answer to this question:

If I touch card holder data in any way, I need PCI DSS v3.0 SAQ A-EP certification, which is quite complex to get. Thus the high popularity of hosted payment pages: When using these, I only need PCI DSS v3.0 SAQ A (without EP). For a quick reference, see http://blog.spreedly.com/2014/12/18/pci-dss-v3-0-for-online-merchants/

The popular libary card.io makes it easy for the user to put in their credit card numbers, but I will always "touch" the data if I use this library, before forwarding it to some secure web service for tokenization.

Now, my understanding is that because of this, every application that uses card.io has to be certified PCI DSS 3 SAQ A-EP from 1st January, 2015, so does this mean that many applications out there may not be certified any more if they haven't upgraded to ...-EP? Or am I missing important information here?

7

If I touch card holder data in any way, I need PCI DSS v3.0 SAQ A-EP certification

No, that's not true. If you touch card holder data, you need to SAQ B, C, or D. The SAQ A (and A-EP) is only for merchants who "do not touch, process or store cardholder data" as per your Spreedly link.

The popular libary card.io makes it easy for the user to put in their credit card numbers, but I will always "touch" the data if I use this library

Correct. Use of card.io appears to make you ineligible for SAQ A or A-EP.

I say "appear" because card.io's site says "card.io does not store or transmit credit card numbers." But that's kind of a crock - they take a picture and turn it into PAN data for your application. Which your application must store or transmit, otherwise there was no point to scanning it in. If you scanned a card with card.io and immediately deleted the data from memory without reading it, you'd probably still run afoul of 'processing' PAN data and be subject to the DSS.

So it's a little misleading to say they "do not store or transmit credit card numbers" without saying "but if you use us, you will be doing so, period."

Now, my understanding is that because of this, every application that uses card.io has to be certified PCI DSS 3 SAQ A-EP from 1st January, 2015

No, every merchant that uses card.io will need to be certified SAQ C or D, just as it would have had to in the past under DSS 2.0.

The only possible exception would be if you wrote and distributed a payment application that used card.io and submitted the PAN data directly to your processor over an approved A-EP hosted iFrame. Great! You can do the SAQ A-EP! But you'd probably have to get PA-DSS certification for your application to make that work. I don't think that's a good trade.

so does this mean that many applications out there may not be certified any more if they haven't upgraded to ...-EP?

Applications don't certify under the SAQs, merchants do. Any merchant that was using card.io in the past would not have qualified for SAQ A in the past, and they won't qualify for A or A-EP now.

The real shift that A-EP represents is for merchants who, under DSS 2.0, qualified for SAQ A with non-iFrame solutions (Javascript or transparent-redirect). SAQ A-EP draws an arbitrary and illogical line and says iFrame is more secure than those two. Merchants using Javascript or transparent-redirect will end up in a larger SAQ A-EP (139 questions) while those using iFrame can remain in SAQ A (14 questions). That said, the line that has been drawn is so illogical that I expect to see continued redefinition moving forward.

  • 3
    I have come across organisations who attempted to "thwart" PCI-DSS and similar requirements by only storing images of the card front, to use the "we don't store PAN" argument, but (surprise surprise) their QSA did not sign off on it at all. At the end of the day, they are storing payment card information which is covered by regulatory requirements. Doesn't matter whether the PAN is stored as text, a cell in a spreadsheet, a JPEG, or whatever - it's still card information. – Polynomial Mar 19 '15 at 16:49
  • 4
    I don't know of a document touching on images, but the PCI SSC came out clearly and said audio recording of cardholder data is subject to normal DSS scope, so I agree completely that images are unlikely to fly with a QSA. – gowenfawr Mar 19 '15 at 16:56
  • That's useful to know - I wasn't aware there was any ruling on audio recordings of the data. More ammunition for getting people to do it right! – Polynomial Mar 19 '15 at 16:59
  • This is the perfect answer, thank you for taking the time to explain in such detail! – user37088 Mar 20 '15 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.