如果我有一个 Web 应用程序，并且我通过 HTTPS 接收 Web 浏览器通过 POST 请求传输的信用卡数据，并立即打开一个到远程 PCI 兼容卡处理器的套接字 (SSL) 以转发数据并等待响应，我是吗？允许这样做吗？或者这是否与我的应用程序一起接收数据并转发它已经成为“处理信用卡数据”的主题？
如果我创建一个显示在客户端浏览器中以输入 cc 数据的 iframe，并且此 iframe 通过 HTTPS 将数据发布到远程卡处理器（直接！）这是否已经是处理信用卡数据的情况？即使我的应用程序代码“不接触”任何事件处理程序输入的数据？
我对“信用卡数据处理”的定义感兴趣。什么时候开始成为 cc 数据处理应用程序？有人可以指出 PCI-DSS 标准中明确定义何时开始“成为处理应用程序”的那部分吗？
谢谢，
你传输数据，即使你自己不做任何事情。因此，您确实属于 PCI 合规性规则。
PCI DSS v .2.1，第 5 页，PCI DSS 适用性信息下：
如果存储、处理或传输主帐号 (PAN)，则适用 PCI DSS 要求。如果 PAN 未存储、处理或传输，则 PCI DSS 要求不适用。
例如，PCI DSS 第 4.1 节要求在通过公共/开放网络传输时进行加密，您在两端都使用了 SSL 和 HTTPS。
但不仅仅是与卡数据直接交易有关的要求。还有用户身份验证控制，例如 PCI DSS 第 8.x 节，特别适用于有权访问持卡人数据或管理能力的用户。
虽然有些部分可以忽略，因为您不存储卡数据，但还有其他部分涉及网络安全、防火墙、防病毒、访问控制、监控和跟踪、测试等。
这是一个很好的问题，我很想听听一些权威的答案——无论是直接代表 PCI-DSS 的人，还是至少可以访问 PCI 成员的 QSA。
我不权威的答案是托管 iframe 的网络服务器将在 PCI 范围内，并且您将被归类为服务提供商。这是基于我对 PCI 标准的解释，其中词汇表指出：
服务提供商 不是支付卡品牌成员或直接参与处理、存储、传输和交换或交易数据和持卡人信息或两者的商家的商业实体 (*1)。这还包括向控制或可能影响持卡人数据安全的商户、服务提供商或成员提供服务的公司 (*2)。示例包括提供托管防火墙、IDS 和其他服务的托管服务提供商以及托管提供商和其他实体。不包括电信公司等仅提供通信链路而没有访问通信链路应用层的实体（*3）
*1。您显然不是支付卡品牌（例如 Visa），也不是商家（您向其提供此服务）
*2。这很明显是您的角色，因为提供服务
*3。不幸的是，我认为您不符合此排除条件，因为您可以访问应用程序层数据。
好消息是，你所采取的方法可能是你能做的最好的，以尽量减少你的头痛。
理想情况下，您会对该服务器进行分段，以便对更广泛（内部）网络的访问非常受限。确保网络服务器提供的唯一“应用程序”是这个 iframe（即，不要从服务器运行任何其他网页）。确保服务器/iframe/etc 生成的日志不包含任何卡相关数据
不幸的是，我相信这确实意味着需要涉及 QSA，因为您正在处理 Web 事务。
像黑客一样思考 - 如果黑客获得了对您的站点/服务器的访问权限，他们是否会以 iframe 进入恶意支付网关的方式对其进行篡改。有 QSA（PCI 审计员）会坚持认为这是在范围内，围绕网站（开发、支持、测试、运营）的一切都需要以符合 PCI 的方式进行。
很简单——如果 CC # 在您的服务器上的任何位置，甚至只是内存，那么您正在处理它并受制于那些 PCI 要求。