通常，支付 API 分为 3 类：

1. 支付页面托管在商家端并提交给商家
2. 支付页面托管在商家端，只有卡数据提交给支付提供商（通常通过 JavaScript SDK）
3. 支付页面托管在支付提供商端并提交给支付提供商，商户在授权成功后收到通知

假设支付提供商没有搞砸大事，您应该完全超出选项 2 和 3 的 PCI DSS 范围。

使用选项 2，您不在 PCI DSS 范围内，您从不使用信用卡数据，而是e4baf901-252b-4818-b826-7f89cad884db由支付处理器的 JavaScript SDK 分配给交易的永久或临时令牌（如 ）。除此之外，3ds 工作流程与选项 1 完全相同，只是您的 API 请求具有属性pan_token而不是pan属性。以 Braintree 上的托管字段 API 为例https://developers.braintreepayments.com/start/hello-client/javascript/v3

使用选项 3，您不在 PCI DSS 范围内，您实际上什么也不做，您只需将您的客户重定向到支付提供商或在 iframe 或其他东西中打开支付提供商的页面，这是这种 API 的一个示例：https ://ipgtest.webteh.hr/en/documentation/form

使用选项 1

那是另一回事，是的，您在 PCI DSS 范围内，是的，您需要有一个有效的证书，具体取决于执行 PEN 测试的地区，有一个安全的组织和所有其他“坏东西”、密码策略、跳转主机以进行连接，安全的（最好是分段的）网络，确保日志不显示任何内容，“拒绝所有”网络配置，每年进行审计等等等等。

如果你走这条路（我真的不明白为什么你应该，拜托，不要）至少你可以避免拥有 HSM 并担心加密密钥等 - 这意味着你不应该将 PCI DSS 数据存储到硬盘驾驶。

通常，避免这种情况的最简单解决方案是将信用卡数据存储在 memcache 中，过期策略为 1 小时或更短（我到目前为止所做的所有实现都需要 15 分钟）。诀窍是不要把它写在磁盘上（这就是为什么在大多数实现中不是 redis 的原因），但是像 memcache 这样的内存存储是公平的游戏。只需确保访问密钥是大而安全的，例如 uuid (ie e4baf901-252b-4818-b826-7f89cad884db)。

在实践中并不总是这样......

从历史上看，支付公司对商家 PCI DSS 合规性一直非常松懈，“数据库中充满 PAN”和“没有 PAN 接触过系统”之间的唯一实际区别是“您的自我评估问卷有多少问题”（PCI DSS商户的 SAQ）。

只有在非常特殊的情况下，当商家被确定为被盗卡的常见销售点时，商家才被迫、非常非常不情愿地并且在信用卡公司有很多“理解”的情况下接受 PCI DSS lvl2/lvl1 合规性审计。

然而，由于一系列违规行为，这种情况正在发生变化，至少在某些地区（如 SEE Europe），支付公司现在坚持从选项 1 迁移到所有没有完整 PCI DSS 合规证书的商家（不仅仅是 SAQ 问卷中的“X”标记练习）。

您是在问如何在不存储卡号的情况下进行 3D 验证，或者您描述的过程是否符合 PCI 标准？

如果是前者，最好直接询问您的支付网关提供商以确保正确操作，或提供文档链接，以便您可以通过技术方式获得帮助。

如果是后者，那就要看你的情况了。你是什​​么SAQ，什么水平？或者你在做一个中华民国？如果您的目标是 SAQ A，那么您是对的，您根本无法触摸该 PAN，如果您要使用 SAQ A-EP，您可以暂时将其保存在浏览器中。如果它发生在您的服务器上，那么它就是 SAQ D。换句话说，取决于您愿意承担的范围。

从技术上讲，如果您必须进行整页重定向，则可以使用 iframe 和/或 ajax 来完成。

这整个情况听起来是错误的。

在这种环境下，用户购买或交易的典型流程如下：

• 供应商站点调用支付提供商 API，传递交易的详细信息：供应商 ID、产品名称和标识符、成本明细、客户名称和地址（如果知道），有时还有其他技术信息，例如重定向目标。
• 支付提供商 API 返回此交易的支付页面的 URL。
• 供应商通过重定向或 iframe 向用户显示支付页面。有关合规方法的更多信息，请参阅签证指南。请注意，此表单及其内容永远不会到达供应商服务器或基础架构；它们由支付提供商直接托管。
• 该表格由用户填写，现在包含需要按照 PCI DSS 处理的信用卡详细信息。
• 该表格将发布给支付提供商。这些数据永远不会直接到达供应商，因为这样做意味着他们的基础设施将属于 PCI DSS 的范围，并且需要直接合规，从而否定了第三方支付提供商的全部目的。
• 支付提供商验证详细信息并尝试提取资金。
• 如果客户的银行需要 3D Secure 或类似功能，则会发生另一个重定向以进行额外验证。
• 如果 3D Secure 验证成功，则支付提供商从卡中提取款项，并持有资金以转移给供应商。
• 支付提供商：
  • 在重定向方法的情况下，将用户的浏览器重定向回供应商的完成页面，以及向供应商证明支付成功或失败的加密签名状态（通常是 SAML），或者；
  • 在 iframe 或类似的情况下，供应商的外部页面会轮询查询支付提供商 API 的脚本，以检查完成状态。付款完成后，将向供应商传回签名消息，以证明付款成功或失败。
• 状态数据通常包括一些卡数据，但最关键的是，PAN 必须被屏蔽，以便它现在被视为 PCI DSS 指南中的“部分 PAN”，从而使其超出 PCI 范围。
• 供应商现在显示“感谢您购买”页面，并且可以将交易记录为已完成。

此过程存在差异，但关键特征是 PAN 和 CVV / CV2（以及其他敏感字段）从未由供应商实际处理或持有。支付提供商处理所有这些。即使在使用诸如“记住我的卡”之类的功能时，通常的实施也包括让支付提供商存储完整的 PAN，由供应商存储掩码的 PAN，并在双方存储的客户 ID 将它们绑定在一起，以便支付供应商可以自动为卡充电，而供应商无需知道 PAN 是什么。

另一个关键点是切换到 3D Secure 或类似功能。如果您是转到该页面的人，那么您就是支付提供商，并且您绝对在 PCI DSS 范围内。请记住，您绝对可以同时成为支付提供商和供应商（以亚马逊为例）。

PCI 合规性的定义与 3D Secure 提供的功能之间没有矛盾。

作为商家与其收单银行之间合同的条件，商家可能需要使用 3D Secure（一种欺诈预防方案）。该合同允许商家收集信用卡并将其提供给银行，有时通过支付处理器对进入商家银行账户的资金进行收费。

该合同还包括要求商家遵守 PCI 联盟制定的所有治理、架构、开发等规则的条款。这就是符合 PCI 的含义——以可审计的方式遵守联盟制定的所有规则。

因此，使用 3D Secure 可以成为 PCI 合规性的一个组成部分。

现在，PCI 规则适用于所谓的“范围内”系统。在任何时间长度内对卡数据具有任何可见性的任何系统都受 PCI 规则的约束，并且对于某些可见性定义而言，对于具有卡可见性的范围内系统具有网络可见性的任何系统也在范围内。

PCI 就像怀孕 - 没有半途而废。如果系统看到一张卡片，那么它们就在范围内，并且需要遵守这些规则。

PCI 也像一种疾病——它会传播。如果系统看到一张卡片，它在范围内，并且所有可以看到看到卡片的系统的系统也在范围内。

同样，在您所描述的内容中，没有矛盾。在您控制的系统上运行的应用程序可以看到卡片。这些系统和应用程序都在范围内。故事结局。