4 Fixed brain-o that put A-EP people into C or D.
source | link

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, and may cause merchants. Merchants using those solutions toJavascript or transparent-redirect will end up in a larger SAQ A-EP (139 questions) while those using iFrame can remain in SAQ A (C or D14 questions). That said, the line that has been drawn is so illogical that I expect to see continued redefinition moving forward.

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, and may cause merchants using those solutions to end up in a larger SAQ (C or D). That said, the line that has been drawn is so illogical that I expect to see continued redefinition moving forward.

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 Forgot to address last line.
source | link

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, and may cause merchants using those solutions to end up in a larger SAQ (C or D). That said, the line that has been drawn is so illogical that I expect to see continued redefinition moving forward.

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.

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, and may cause merchants using those solutions to end up in a larger SAQ (C or D). That said, the line that has been drawn is so illogical that I expect to see continued redefinition moving forward.

2 added 2 characters in body
source | link

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.

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-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.

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.

1
source | link