android - 在移动应用程序中从哪里开始使用 PCI-DSS？

Question

我们正在为拥有自己的支付处理解决方案的客户开发移动应用程序(iOS 和 Android)。该应用面向公众，个人消费者将在自己的手机上使用。

应用程序必须通过 SOAP API 与支付处理解决方案交互。我们需要接受用户支付卡详细信息的输入，并通过该 API 传递它们。我们无法选择将他们的网站嵌入 iframe 或类似的东西；我们必须使用这个特定的 API，这意味着我们的应用程序将不可避免地必须(短暂地)拥有和处理用户的支付卡详细信息。

应用程序需要做的就是收集详细信息(通过让用户在手机键盘上点击它们)，通过 API 发送它们，然后尽快丢弃它们。它不会存储超过完成交易所需时间的数据，并且不会将数据发送到除了通过 API 发送到客户端服务器之外的任何地方。我们永远不会在自己的服务器上拥有这些数据，我们会小心翼翼地永远不要将其写入日志，并且通常我们会在应用程序拥有的短暂时间内将其视为放射性废物。

我们可以放心地假设(至少现在)客户的系统已经按照 PCI DSS 做了他们需要做的任何事情。当然，应用程序和支付服务器之间的流量是加密的。

我们正在努力掌握我们需要做的关于 PCI DSS 的事情，我们非常感谢任何帮助我们开始的指示。我们非常高兴(确实想要)聘请顾问来帮助我们实现合规性——但我们甚至不知道我们应该和谁交谈。我们可以在网上轻松找到的所有内容(包括来自 PCI 本身的 Material )似乎都与微妙的不同场景相关，或者建议我们通过使用 iframe 之类的东西来回避问题，这对我们来说不是一个选择。

老实说，事实证明要找到一些明确的指示是多么困难，这让我们感到惊讶。许多应用程序会处理卡片详细信息!这肯定是一个普遍的问题。

那么，我们的问题:

1. 我们应该去哪里获得与我们的特定情况相关的专家建议？
2. 完全是非正式的，并且了解我们稍后将获得适当的合格建议……我们应该预料到这是一场多么可怕的噩梦？我们已经到了想知道我们是否需要担心手机上安装的键盘记录器的地步。真的是这样吗，还是我们走得太远了？
3. 是否有我们缺少的 Elixir – 例如，一个已知合规的图书馆？

Answer 1

我是 PCI QSA。

与 PCI 的许多事情一样，场景中也有几个灰色区域。您可以向 10 个 QSA 提出相同的问题，但很可能会得到 10 个不同的答案，这是一个可悲的现实，因为在此类情况下缺乏明确的指导(并且有许多古怪的情况)。

因此，以我的专业观点(我说的是观点)，一个移动应用程序，其中 100% 的卡摄取、处理和传输是在移动设备上处理的，并且在所述移动设备上使用的卡属于单个用户，风险很低。如果我没看错问题，那么您就是应用程序开发人员。您不是商家，如果您所做的只是为某个商家或服务提供商编写代码，那么这个问题更多地落在他们身上。

他们可能需要执行应用程序渗透测试和一些流量分析，以确认持卡人数据直接从设备流向收单机构(处理方)。作为软件开发人员，您无需为任何 PCI 承担责任，除非您在 App Store 或其他类似方式上销售该应用程序。那样的话，上面的答案就更准确了。您可能需要通过 PA-QSA 对此申请进行 PA-DSS 审查。假设通过，它将列在 PCI SSC 网站上的 PA-DSS 验证应用程序下。这不会使处理器符合 PCI 标准，但可以帮助评估过程。

至于 Elixir ，那就没有了。但是，如果您使用 Stripe 作为处理者并使用他们的移动 SDK 来处理和传输持卡人数据，那么 Stripe 将在您每年在他们的网站上完成一个简短的问卷调查后承担 PCI 责任。

我意识到这个问题已经很老了，但我认为答案可以帮助下游的人解决这个问题。另外，我与 Stripe 没有任何关系，但我最近遇到了这个问题，并且很惊讶地看到 Stripe 如何处理它。令人惊喜的是，我可能会补充。