假设我决定使用支付网关而不是使用他们的托管页面，而是提供我自己的信用卡详细信息表单，然后通过 xml 作为explained on this page 将数据发送到他们的后端。那么：
感谢您的帮助
【问题讨论】：
1) 如果您要随时处理信用卡信息，则需要符合 PCI 标准。您需要解决编码问题，您的主机需要处理服务器的任何硬件和软件问题，支付网关公司有很多问题需要处理（这里列出的列表太长但您没有无论如何都需要担心）。
2) 不会。SSL 将帮助您符合 PCI 标准，但除了数据如何从用户传输到服务器之外，还有更多关于 PCI 合规性的内容。您如何处理这些数据以及如何处理这些数据也会发挥作用。例如，如果您要存储信用卡信息，则需要使用加密，而不是存储 PCI 禁止存储的值（即 CVV 编号）。将此信息放入会话中算作存储。
【讨论】：
问题 1 的答案：是的，您应该更加担心 PCI 合规性。
问题 2 的答案： 使用 SSL 表单收集信用卡信息负责将数据从客户端安全传输到您的服务器。因此，如果您不打算在服务器上存储信用卡数据，这就足够了。如果您想存储信用卡数据，那么您需要遵守 PCI DSS 来存储信用卡数据。
【讨论】：
其他 cmets 中没有出现的一个方面是 PCI-DSS 是根据已实施的可操作系统进行评估的，并且该系统中最重要的组件是人工流程和控制。 “我的网站将自动合规”背后的前提包括假设可以根据 PCI-DSS 评估一项技术，脱离上下文。
根据 PCI-DSS 和 PA-DSS 的定义，任何自定义应用程序都不能凭借其自身的优点被宣布为符合 PCI 标准。不可定制的交钥匙解决方案的应用程序和硬件可以根据 PA-DSS 进行评估，但即使脱离已实施的系统以及与之相关的人工控制和流程，它们也无法被认证为符合 PCI 标准。
要求 2、10、11 和 12 完全与应用程序外部的系统控制有关，并代表人工程序和任务。在其他要求中，仔细观察每个要求都会发现它们直接或间接地对人工流程和控制施加了限制。
因此，请务必阅读并吸收有关 PCI 技术要求的其他建议，但请放弃您的最终应用程序可以在工作、已实施系统的上下文之外被声明为符合 PCI 的观念。更好的方法是考虑那些与应用设计的技术细节没有直接关系的要求，并问问自己应用如何帮助客户满足这些要求。例如，您的应用程序是否可以让客户轻松“跟踪和监控对网络资源和持卡人数据的所有访问”？ （要求 10）
许多应用程序供应商的立场是，要求 12，“维护解决所有人员信息安全问题的政策”，根本不适用于他们。但客户经常会回来问一些尖锐的问题，即应用程序在这个评估项目上是帮助还是伤害了他们。客户负责培训他们的员工如何预防、检测和从漏洞中恢复，以及应用程序与安全扫描器互操作的能力、配置和数据的备份或恢复到之前的时间点都是至关重要的。 PCI 要求供应商发布的安全相关补丁在 90 天内或更短的时间内应用，因此客户会想知道您如何以及在何处通知他们这些事情，应用补丁的难易程度或破坏性，应用程序是否必须降级应用它们，等等。
希望合理详细的评估能够剔除所有存在明显技术错误的应用程序，例如未能使用 TLS 加密、通过 HTTP 呈现登录页面或恢复密码而不是发送重置链接。任何希望遵守只是 PCI 准则的技术方面的愿望只会让新应用上升到商品的水平。为了让应用在市场上脱颖而出，设计它以帮助客户满足 PCI 要求，而这是应用的直接责任。
【讨论】：
我帮助创建了Drupal PCI Compliance white paper，它为您在尝试使您的网站合规时可能遇到的这些问题和许多其他问题提供了答案。虽然您可能没有使用 Drupal，但本文档中涵盖的原则是高级别的，并且可以轻松应用于 wordpress、Joomla 或任何其他电子商务 CMS。
【讨论】：