在移动应用程序中从哪里开始使用 PCI-DSS？
Where to start with PCI-DSS in a mobile app?
我们正在为拥有自己的支付处理解决方案的客户开发移动应用程序（iOS 和 Android）。该应用面向 public，将由个人消费者 phone 自己使用。
该应用程序必须通过 SOAP API 与支付处理解决方案进行交互。我们需要接受用户支付卡详细信息的输入，并将它们传递给 API。我们无法选择将他们的网站嵌入 iframe 或类似的东西；我们必须使用这个特定的 API，这意味着我们的应用程序将不可避免地必须（短暂地）拥有和处理用户的支付卡详细信息。
应用程序需要做的就是收集详细信息（让用户在 phone 的键盘上点击它们），将它们发送到 API，然后丢弃它们尽快。它不会存储超过完成交易所需时间的数据，并且不会将数据发送到除了 API 之外的任何地方到客户端的服务器。我们永远不会在我们自己的服务器上拥有数据，我们会小心翼翼地永远不会将其写入日志，并且通常我们会在应用程序拥有的短暂时间内将其视为放射性废物。
我们可以放心地假设（至少现在）客户的系统已经按照 PCI DSS 做了他们需要做的任何事情。当然，应用程序和支付服务器之间的流量是加密的。
我们正在努力掌握我们需要做的关于 PCI DSS 的事情，我们非常感谢任何帮助我们开始的指示。我们非常高兴（确实想要）聘请顾问来帮助我们实现合规性——但我们甚至不知道我们应该和谁交谈。我们可以在网上轻松找到的所有内容（包括来自 PCI 本身的 material）似乎都与微妙的不同场景相关，或者建议我们通过使用 iframe 之类的东西来回避问题，这对我们来说不是一个选择。
老实说，我们很惊讶要找到一些明确的指示是多么困难。许多应用程序会处理卡片详细信息！这肯定是一个普遍的问题。
所以，我们的问题：
- 我们应该去哪里获得与我们的特定情况相关的专家建议？
- 完全是非正式的，并且了解我们稍后将获得适当的合格建议……我们应该期望这是一场多么可怕的噩梦？我们已经到了想知道我们是否需要担心安装在 phone 上的键盘记录器的地步。真的是这样吗，还是我们走得太远了？
- 是否有我们缺少的灵丹妙药——例如，一个已知合规的库？
我感受到你的痛苦，你会认为像获取信用卡详细信息这样无处不在的东西会有大量清晰简洁的信息来帮助你指导你完成整个过程，遗憾的是事实并非如此。
对于您的第一个问题，您需要找到 QSA，请查看 PCI council website 以获得这些列表和所有官方信息。我会建议货比三家，质量和价格确实有所不同，您需要熟悉您的情况的人。正如你所说，在使用我提供的观点之前，你应该得到官方的指导。
关于你的第二个问题，首先要说的是PCI是基于合同的。这完全是您客户的责任（取决于他们与商家银行或支付处理商达成的协议）。因此，如果您的合同没有说您需要提供符合 PCI 标准的解决方案，则您不必……尽管我会小心，如果您已经暗示或适合目的等，这可能是律师的问题。务实地说，根据情况有一些选择，这里有点棘手，所以我会尽力而为：
- 如果客户无法控制代码或系统，他们只是收到它的结果，您可能会被视为服务提供商，您至少需要服务提供商的 SAQ D。
- 如果您只是向客户提供源代码并由他们实施，那么他们将全权负责，如果在范围内，他们将不得不进行代码审查、渗透测试等。
- 如果您的客户希望将您的应用程序插入他们的系统，并且他们不想对其 PCI 细节负责，那么您需要符合 PA-DSS。
最终这将取决于您的客户可以承担的 PCI 范围，他们可能至少需要 SAQ A（是的，你们可能都需要证明 PCI 合规性），无论您采取什么课程。
就噩梦而言，我不确定本机应用程序但网络应用程序，如果 PAN（抄送编号）触及您的服务器，它是完整的范围，SAQ D，简而言之，是的，如果您不这样做，那将是一场噩梦'已经有一个安全的设置。最好的方案是 SAQ A，但你需要一个 iFrame，如果那不可能，那么也许 SAQ A-EP，你可以将它与直接 POST 一起使用，所以如果那样的话，SOAP 接口可能没问题直接来自您的应用程序。我不确定某个应用是否被认为 'e-commerce' 可以使用 SAQ A 和 A-EP，如果不是，您可能需要 SAQ C。至少看一下要求 6，它涵盖了软件开发。
关于你的最后一个问题，请查看 spreedly.com，它们提供与多个网关的 PCI 兼容连接可能很有用。
祝你好运！很高兴听到您最终决定做什么。
我认为以上回复没有准确回答问题。我会敦促任何需要有关移动应用程序开发和 PCI 的信息的人阅读以下摘自 Security Standard Councils documentation:
If the consumer is also the cardholder and is using the device solely for his/her own cardholder data entry, and the application can only be used by that cardholder using his own credentials, then the device is treated similarly to a cardholder’s payment card: The consumer’s environment in which the application runs is outside the scope of PCI DSS, and the consumer-facing application is not eligible for PA-DSS listing.
还有这个：...
PCI SSC agreed (see PA-DSS and Mobile Applications FAQs) that mobile payment-acceptance applications that qualify, as Category 3 will not be considered for PA-DSS validation until the development of appropriate standards to ensure that such applications are capable of supporting a merchant’s PCI DSS compliance. The PCI SSC recommends that mobile payment-acceptance applications that fit into Category 3 be developed using PA-DSS requirements and the guidance provided in this document as a baseline.
阅读第 2 页的最后一段和第 3 页的第一段。简而言之，此时（2019 年 9 月 17 日）还没有对移动应用程序的 PCI 合规性进行验证 - 只有安全标准中的建议和指导理事会.
我是 PCI QSA。
与 PCI 的许多事情一样，场景中有几个灰色区域。你可以问 10 个 QSA 同样的问题，可能会得到 10 个不同的答案，这是一个可悲的现实，因为这种情况缺乏明确的指导（而且有很多奇怪的情况）。
所以，以我的专业观点（我说的观点），一个移动应用程序，其中 100% 的卡摄取、处理和传输是在移动设备上处理的，并且在所述移动设备上使用的卡属于单个用户，风险非常低。如果我没看错问题，那么您就是应用程序开发人员。你不是商家，如果你所做的只是为某个商家或服务提供商编写代码，这个问题更多地由他们承担。
他们可能需要执行应用程序渗透测试和一些流量分析，以确认持卡人数据直接从设备流向收单方（处理方）。作为软件开发人员，您无需为任何 PCI 买单，除非您在 App Store 或其他类似方式上销售该应用程序。那样的话，上面的答案就更准确了。您可能需要通过 PA-QSA 对此申请进行 PA-DSS 审查。假设通过，它将列在 PCI SSC 网站上的 PA-DSS 验证应用程序下。这不会使处理器符合 PCI 标准，但可以帮助评估过程。
至于灵丹妙药，什么都没有。但是，如果你使用 Stripe 作为处理者和他们的移动 SDK 来处理和传输持卡人数据，那么 Stripe 将在你每年在他们的网站上完成一个简短的问卷调查后承担 PCI 责任。
我意识到这个问题很老了，但我认为这个答案可以帮助下游的人解决这个问题。另外，我与 Stripe 没有任何关系，但我最近遇到了这个问题，并且很惊讶地看到 Stripe 如何处理它。令人惊喜的是我可能会补充。
这基本上是说您只负责遵循“安全软件开发生命周期”，并在 Req 6.3、6.4 和 6.5 中概述了此类控制。
我们正在为拥有自己的支付处理解决方案的客户开发移动应用程序（iOS 和 Android）。该应用面向 public，将由个人消费者 phone 自己使用。
该应用程序必须通过 SOAP API 与支付处理解决方案进行交互。我们需要接受用户支付卡详细信息的输入，并将它们传递给 API。我们无法选择将他们的网站嵌入 iframe 或类似的东西；我们必须使用这个特定的 API，这意味着我们的应用程序将不可避免地必须（短暂地）拥有和处理用户的支付卡详细信息。
应用程序需要做的就是收集详细信息（让用户在 phone 的键盘上点击它们），将它们发送到 API，然后丢弃它们尽快。它不会存储超过完成交易所需时间的数据，并且不会将数据发送到除了 API 之外的任何地方到客户端的服务器。我们永远不会在我们自己的服务器上拥有数据，我们会小心翼翼地永远不会将其写入日志，并且通常我们会在应用程序拥有的短暂时间内将其视为放射性废物。
我们可以放心地假设（至少现在）客户的系统已经按照 PCI DSS 做了他们需要做的任何事情。当然，应用程序和支付服务器之间的流量是加密的。
我们正在努力掌握我们需要做的关于 PCI DSS 的事情，我们非常感谢任何帮助我们开始的指示。我们非常高兴（确实想要）聘请顾问来帮助我们实现合规性——但我们甚至不知道我们应该和谁交谈。我们可以在网上轻松找到的所有内容（包括来自 PCI 本身的 material）似乎都与微妙的不同场景相关，或者建议我们通过使用 iframe 之类的东西来回避问题，这对我们来说不是一个选择。
老实说，我们很惊讶要找到一些明确的指示是多么困难。许多应用程序会处理卡片详细信息！这肯定是一个普遍的问题。
所以，我们的问题：
- 我们应该去哪里获得与我们的特定情况相关的专家建议？
- 完全是非正式的，并且了解我们稍后将获得适当的合格建议……我们应该期望这是一场多么可怕的噩梦？我们已经到了想知道我们是否需要担心安装在 phone 上的键盘记录器的地步。真的是这样吗，还是我们走得太远了？
- 是否有我们缺少的灵丹妙药——例如，一个已知合规的库？
我感受到你的痛苦，你会认为像获取信用卡详细信息这样无处不在的东西会有大量清晰简洁的信息来帮助你指导你完成整个过程，遗憾的是事实并非如此。
对于您的第一个问题，您需要找到 QSA，请查看 PCI council website 以获得这些列表和所有官方信息。我会建议货比三家，质量和价格确实有所不同，您需要熟悉您的情况的人。正如你所说，在使用我提供的观点之前，你应该得到官方的指导。
关于你的第二个问题，首先要说的是PCI是基于合同的。这完全是您客户的责任（取决于他们与商家银行或支付处理商达成的协议）。因此，如果您的合同没有说您需要提供符合 PCI 标准的解决方案，则您不必……尽管我会小心，如果您已经暗示或适合目的等，这可能是律师的问题。务实地说，根据情况有一些选择，这里有点棘手，所以我会尽力而为：
- 如果客户无法控制代码或系统，他们只是收到它的结果，您可能会被视为服务提供商，您至少需要服务提供商的 SAQ D。
- 如果您只是向客户提供源代码并由他们实施，那么他们将全权负责，如果在范围内，他们将不得不进行代码审查、渗透测试等。
- 如果您的客户希望将您的应用程序插入他们的系统，并且他们不想对其 PCI 细节负责，那么您需要符合 PA-DSS。
最终这将取决于您的客户可以承担的 PCI 范围，他们可能至少需要 SAQ A（是的，你们可能都需要证明 PCI 合规性），无论您采取什么课程。
就噩梦而言，我不确定本机应用程序但网络应用程序，如果 PAN（抄送编号）触及您的服务器，它是完整的范围，SAQ D，简而言之，是的，如果您不这样做，那将是一场噩梦'已经有一个安全的设置。最好的方案是 SAQ A，但你需要一个 iFrame，如果那不可能，那么也许 SAQ A-EP，你可以将它与直接 POST 一起使用，所以如果那样的话，SOAP 接口可能没问题直接来自您的应用程序。我不确定某个应用是否被认为 'e-commerce' 可以使用 SAQ A 和 A-EP，如果不是，您可能需要 SAQ C。至少看一下要求 6，它涵盖了软件开发。
关于你的最后一个问题，请查看 spreedly.com，它们提供与多个网关的 PCI 兼容连接可能很有用。
祝你好运！很高兴听到您最终决定做什么。
我认为以上回复没有准确回答问题。我会敦促任何需要有关移动应用程序开发和 PCI 的信息的人阅读以下摘自 Security Standard Councils documentation:
If the consumer is also the cardholder and is using the device solely for his/her own cardholder data entry, and the application can only be used by that cardholder using his own credentials, then the device is treated similarly to a cardholder’s payment card: The consumer’s environment in which the application runs is outside the scope of PCI DSS, and the consumer-facing application is not eligible for PA-DSS listing.
还有这个：...
PCI SSC agreed (see PA-DSS and Mobile Applications FAQs) that mobile payment-acceptance applications that qualify, as Category 3 will not be considered for PA-DSS validation until the development of appropriate standards to ensure that such applications are capable of supporting a merchant’s PCI DSS compliance. The PCI SSC recommends that mobile payment-acceptance applications that fit into Category 3 be developed using PA-DSS requirements and the guidance provided in this document as a baseline.
阅读第 2 页的最后一段和第 3 页的第一段。简而言之，此时（2019 年 9 月 17 日）还没有对移动应用程序的 PCI 合规性进行验证 - 只有安全标准中的建议和指导理事会.
我是 PCI QSA。
与 PCI 的许多事情一样，场景中有几个灰色区域。你可以问 10 个 QSA 同样的问题，可能会得到 10 个不同的答案，这是一个可悲的现实，因为这种情况缺乏明确的指导（而且有很多奇怪的情况）。
所以，以我的专业观点（我说的观点），一个移动应用程序，其中 100% 的卡摄取、处理和传输是在移动设备上处理的，并且在所述移动设备上使用的卡属于单个用户，风险非常低。如果我没看错问题，那么您就是应用程序开发人员。你不是商家，如果你所做的只是为某个商家或服务提供商编写代码，这个问题更多地由他们承担。
他们可能需要执行应用程序渗透测试和一些流量分析，以确认持卡人数据直接从设备流向收单方（处理方）。作为软件开发人员，您无需为任何 PCI 买单，除非您在 App Store 或其他类似方式上销售该应用程序。那样的话，上面的答案就更准确了。您可能需要通过 PA-QSA 对此申请进行 PA-DSS 审查。假设通过，它将列在 PCI SSC 网站上的 PA-DSS 验证应用程序下。这不会使处理器符合 PCI 标准，但可以帮助评估过程。
至于灵丹妙药，什么都没有。但是，如果你使用 Stripe 作为处理者和他们的移动 SDK 来处理和传输持卡人数据，那么 Stripe 将在你每年在他们的网站上完成一个简短的问卷调查后承担 PCI 责任。
我意识到这个问题很老了，但我认为这个答案可以帮助下游的人解决这个问题。另外，我与 Stripe 没有任何关系，但我最近遇到了这个问题，并且很惊讶地看到 Stripe 如何处理它。令人惊喜的是我可能会补充。
这基本上是说您只负责遵循“安全软件开发生命周期”，并在 Req 6.3、6.4 和 6.5 中概述了此类控制。