card.io & PCI v3.0

Question

我已经研究了很长一段时间了，但是我找不到这个问题的答案：

如果我以任何方式接触卡持卡人数据，我需要PCI DSS v3.0 SAQ认证，这是相当复杂的获得。因此，托管支付页面的高度流行:当使用这些页面时，我只需要PCI DSS v3.0 SAQ A(没有EP)。有关快速参考，请参见http://blog.spreedly.com/2014/12/18/pci-dss-v3-0-for-online-merchants/

流行的libary card.io使用户很容易输入他们的信用卡号码，但是如果我使用这个库，在将它转发到某个安全的web服务进行令牌化之前，我总是会“触摸”数据。

现在，我的理解是，正因为如此，每个使用card.io的应用程序都必须从2015年1月1日起获得PCIDS3SAQA-EP认证，这是否意味着如果没有升级到.-EP，许多应用程序可能就不再被认证了？还是我漏掉了重要的信息？

Answer 1

如果我以任何方式触摸卡持有人数据，我需要PCI DSS v3.0 SAQ A-EP认证。

不，那不是真的。如果您触摸卡持卡人数据，您需要SAQ B，C或D。SAQ A(和need )只适用于那些根据您的铺展链接“不接触、处理或存储持卡人数据”的商家。

流行的libary card.io使用户很容易输入他们的信用卡号码，但是如果我使用这个库，我将始终“触摸”数据。

对，是这样。使用card.io似乎使您没有资格参加SAQ A或A.

我说“出现”是因为Card.io的网站说"card.io不存储或传输信用卡号码“。但是，这是一种笨拙-他们拍了一张照片，并将其转化为PAN数据为您的应用程序。您的应用程序必须存储或传输，否则就没有必要对其进行扫描。如果你用card.io扫描一张卡片，然后立即删除内存中的数据，而不读它，你可能仍然会与PAN数据的“处理”冲突，并服从于DSS。

所以说他们“不储存或传送信用卡号码”而不说“但如果你利用我们，你就会这么做，这是有点误导的，句号。”

现在，我的理解是，正因为如此，每个使用card.io的应用程序都必须从2015年1月1日起获得PCI DSS 3 SAQ A-EP认证。

不，每一个使用card.io的商家都需要获得SAQ或D的认证，就像过去在DS2.0下一样。

唯一可能的例外是，如果您编写并分发了一个使用card.io的支付应用程序，并通过批准的an托管的iFrame将PAN数据直接提交给您的处理器。太棒了！你可以做SAQ A-EP！但是，你的申请可能需要获得PA认证才能做到这一点。我不认为这是个好交易。

那么，这是否意味着如果没有升级到.-EP，那么许多应用程序可能就不再被认证了吗？

应用程序不符合SAQ认证，商家可以认证。任何在过去使用card.io的商家都不会在过去获得SAQ A的资格，他们现在也不会符合A或Any的资格。

A所代表的真正转变是针对那些在DSS 2.0下符合SAQ A标准的非iFrame解决方案(Javascript或透明重定向)的商人。SAQ画了一条任意和不合逻辑的线，并说iFrame比这两条线更安全.使用Javascript或透明重定向的商家最终将出现更大的SAQ (139个问题)，而那些使用iFrame的用户可以保留在SAQ (14个问题)中。尽管如此，已经划定的界线是如此不合逻辑，我希望看到继续重新定义向前迈进。