我有一个 WPF 应用程序，我们已将信用卡处理集成到其中。我们目前正在 WPF Web 浏览器中将信用信息刷入/输入到网页中，以满足 PCI 合规性。显然这没问题，因为 Web 浏览器组件是 PCI 兼容的，而且我们的代码从不处理信用卡信息。
我非常讨厌这种设计，并且很想编写一个独立的、符合 PCI 的 WPF 控件/程序集，我们可以插入它而不是 Web 浏览器组件。如果我们的应用程序的代码可以使用浏览器而无需经过 PCI 认证，那么它可以使用我们自己的经过 PCI 认证的程序集而无需经过 PCI 认证，对吗？它所做的所有新控制/组装都是收集卡信息，并通过 WCF 服务将其安全地发送到远程安全服务器。它不会在本地存储信用卡或对其进行任何处理。有人告诉我这样做需要 9 个月的审查过程，这就是我们采用浏览器方法的原因。
有人可以给我一个大致的想法吗？
尽管与 PCI-DSS 有大量重叠，但您要查找的正式名称是 PA-DSS（支付应用程序数据安全标准）。
解决问题的最佳方法之一是将卡片输入/卡片处理部分分离到一个完全独立的解决方案中。这个单独的解决方案最终将成为通过 PA-DSS 认证的“应用程序”。一旦获得认证，您就可以将其嵌入到您的大型项目中（这不会改变大型项目的 PCI 合规性）
当您研究 PA-DSS 时，将其分离出来的优势将变得显而易见。标准之一是任何需要重新编译应用程序的更改都需要重新认证应用程序。这不是你想要经常做的事情！
另一个有助于简化流程的策略是考虑“内部”应用程序（不分发给客户端）不需要经过 PA-DSS 认证（但如果它们明显处理卡数据，仍然属于 PCI-DSS） . 因此，在您的域中使用 Web 服务可能会使事情变得更容易。例如，您可以托管一个“付款条目详细信息”网页，然后在您的主应用程序中使用标准网络浏览器指向您的付款条目页面。这可能会允许您绕过 PA-DSS 认证（尽管您现在托管的网页仍需要 PCI 认证）
Whatever you decide, best advice would be to get a QSA involved as soon as you have a reasonable grasp on your intended design. The QSA will offer advice on what areas may cause compliance issues, and ultimately its the QSA that will sign off your compliance