我有一个WPF应用程序，我们已将信用卡处理集成到。我们目前正在将信用信息刷入/输入到WPF Web浏览器的网页中，以满足PCI合规性要求。显然这是可以的，因为Web浏览器组件符合PCI标准，我们的代码从不处理信用卡信息。
我非常讨厌这种设计，并且很乐意编写一个独立的，PCI兼容的WPF控件/程序集，我们可以插入而不是Web浏览器组件。如果我们的应用程序的代码可以使用浏览器而不经过PCI认证，那么它可以使用我们自己的PCI认证组件，而且它本身是PCI认证的吗？它所做的所有新控制/组装都是收集卡信息，并通过WCF服务安全地将其发送到远程安全服务器。它不会存储信用卡或在本地进行任何处理。我被告知这样做需要9个月的审核流程，这就是我们采用浏览器方法的原因。
有人可以让我大致了解这需要做些什么吗？
答案 0 :(得分：2)
尽管与PCI-DSS存在大量重叠，但您正在寻找的正式名称是PA-DSS（支付应用程序数据安全标准）。
解决问题的最佳方法之一是将卡片入口/卡片处理部件分离为完全独立的解决方案。这个单独的解决方案最终将成为通过PA-DSS认证的“应用程序”。一旦获得认证，您就可以将其嵌入到更大的项目中（这不会改变大型项目的PCI合规性）
当您查看PA-DSS时，将其分离的优势将变得清晰。其中一个标准是，任何需要重新编译应用程序的更改都需要重新认证该应用程序。这不是你想经常做的事情！
帮助简化流程的另一个策略是考虑“内部”应用程序（不分发给客户端）不需要通过PA-DSS认证（但如果他们处理卡，仍然属于PCI-DSS）数据显然）。因此，在您的域中使用Web服务可能会使事情变得更容易。例如，您可以托管“付款条目详细信息”网页，然后在主应用中使用指向付款条目页面的标准网络浏览器。这可能会允许您绕过PA-DSS认证（但仍需要对您现在托管的网页进行PCI认证）
无论您决定什么，最好的建议是在您对预期设计有一个合理的把握时尽快让QSA参与其中。 QSA将就哪些领域可能导致合规性问题提供建议，并最终提供将签署合规性的QSA