我有这个想法，但我不确定它是否符合 PCI 标准。我是 PCI 合规领域的新手，很想知道这种情况是否违反了 PCI。
所以，让我们设置场景。A 公司符合 PCI 标准，并在 https 上提供 Web 服务，公开支付处理相关的一些功能。B 公司不合规，但他们的网站是安全的。
以下是该场景的步骤。
问题是，由于 javascript 直接从用户的机器传输到 A 公司的兼容服务器，它是否符合 PCI 标准？我很想知道这个领域的专家是怎么想的。
PCI DSS（支付卡行业数据安全标准）具有“范围界定”的概念——确定哪些系统属于 PCI 保护伞。
您是商人还是软件供应商？ 如果 PAN（主帐号），即长信用卡号，从未发送到您的网站，那么您的网站通常不在 PCI 范围内。-- 假设你是商人。如果您是软件供应商，那么您的软件可能会在 PA-DSS 的范围内（见下文）。
PAN 中转您的服务器 旧的想法是 PAN 将被发送到您的网站（通过浏览器表单提交），然后您的网站将转身并将其发送到支付网关（例如 Authorize.Net）。在这种情况下，PAN 从未存储在您的服务器上，而是传输您的服务器。这曾经意味着您的商户系统不会在 PCI DSS 范围内，因为它们从未存储过 PAN。但那些日子很快就结束了，或者已经一去不复返了。（这取决于您的收单方/商户账户供应商对 PCI 的积极程度。）
控制您的网页由于您的网页不会将任何 PAN 传输到您的服务器，因此您不在 PCI 范围内。但是您怎么知道有人没有更改您的网页以将 PAN 传输回您的服务器（或其他地方，使用 JSONP 技术）？答案是您需要向自己保证没有人会篡改您的付款表单页面。
你如何保证这一点取决于你自己。您可以使用 PCI 技术或其他技术。这是您内部计算机安全和审核的问题。
支付应用程序数据安全标准 (PA-DSS)如果您将 sw 出售给商家，那么它可能在 PA-DSS 标准的范围内。见标准。
PCI 是政治性的，而不是技术性的请记住，PCI 范围由您决定。如果您是一个足够大的商家，那么您还需要与 QSA（合格的安全评估员）合作，他们将审查并确定您的 PCI 合规性和范围界定计划。
QSA 肯定有可能会说，由于您控制您的网页，因此它需要在 PCI 之下，因为它可能被某人破坏。但这将是一个咄咄逼人的论点。毕竟，你可以说任何互联网商家的每个网页都需要在 PCI 之下，因为任何网页都可能被破坏以要求人们提供 PAN，然后用它做坏事。另一方面，这正是 Visa 用来增加企业特许人的 PCI 范围的论点。条。
PCI 认证不是借口另请注意，如果您遭到闯入，卡协会保留将您踢出的权利——即使您符合 PCI 标准。所以你要确保你是一个比你所在街区的其他人更难对付的目标。
补充：关于范围界定的更多信息从上面可以看出，一个关键问题是哪些系统在或不在 PCI 范围内。PCI 委员会现在有一个特别兴趣小组 (SIG) 来研究整个问题，即什么是在 PCI 范围内，什么不在 PCI 范围内。我的猜测是，他们会希望信封增长，而不是缩小。
补充：这是您和您的律师之间的事情您的场景已开始在您的客户浏览器上完成 PAN 处理。PAN 永远不会到达您的系统，即使是瞬间也不会。所以我的解释是，您不在商家 PCI DSS 范围内。但是您是签署 PCI 合规声明的人，该声明是您与您的收购方之间的合同。因此，由您和您的律师来解释 PCI DSS 标准，而不是我。
底线您永远不应该在您的系统上存储 PAN 数据。你甚至不应该让它通过你的系统。Authorize.Net 和 Braintree 的新支付网关协议启用了无传输技术。根据您的信用卡交易量，PCI 合规性从自我管理的清单到大型项目不等。
有关更多 PCI 战争故事，请查看StorefrontBacktalk博客及其PCI 报道。
Larry K 的回答很好。这主要是政治/层面的事情。
似乎使用 iframe 从 B 发布到 A 是一种可接受的解决方案，而使用 Ajax - 使用 CORS 或 JSONP - 有点问题，但至少对于一些大玩家来说，仍然是可以接受的。
信息补充：PCI DSS 电子商务指南v2 接缝说此解决方案（直接发布 API）是可以的，但您应该注意安全编码（尽管 PCI DSS 没有规定您需要做的任何具体事情）-请参阅第3.4.3.1 节使用 Direct Post 的第三方嵌入式 API和相关的3.4.3.4 共享管理电子商务实施的安全注意事项，内容如下：
直接发布 API 方法：使用直接发布 API 方法，商家仍然负责呈现给消费者的网页，并且商家在支付页面上托管接受数据的字段——只有持卡人数据是直接从消费者那里发布的给服务提供商。由于支付页面由商家托管，因此支付页面仅与商家的网站一样安全，商家系统的泄露可能导致支付卡数据的泄露。... 具体来说，对于上述所有情况，商家应监控系统已更改的任何证据，并在检测到未经授权的更改时快速响应以将系统恢复到受信任状态。采用这些共享管理外包模型以最小化适用的 PCI DSS 要求的商家应该意识到这些类型的系统架构固有的潜在风险。为了最大限度地减少在这些情况下受到攻击的机会，商家应进行额外的尽职调查，以确保 Web 应用程序的安全开发并经过彻底的渗透测试。
例如，Stripe 支付网关从 2012 年开始使用 JSONP 上的直接发布，而不是他们之前使用的 iframe 方法。
另一方面，WePay 还提供了一个直接发布 API，但建议 iframe 完全摆脱 PCI 要求 [WP]（声称使用直接发布 API“ [..] 你仍然需要符合支付卡行业数据安全标准 (PCI-DSS) 和支付应用程序数据安全标准 (PA-DSS)，只要适用。 ”（没有具体说明“适用时”的确切含义）。
[WP] 微支付链接：https://www.wepay.com/developer/tutorial/tokenization
I've recently gone through some PCI-compliance work for our servers, so this is right in front of me. The short answer is no.
PCI compliance requires that each step of the path through which the sensitive information passes meets PCI requirements in and of itself. Something can be secure but not compliant, as you noted regarding company B. Because you already stated that company B is not PCI-compliant, yet company B is collecting the credit card information via their own web site, then the entire process, logically is not compliant.
Whether a PCI-compliance service actually connects these dots and how they would certify it as passing or failing may be another matter.
无论它“技术上”是否符合 PCI 标准（或不），我都不会相信这种做事方式。
如果表单位于 B 的主机名内的页面上，则 B 可以完全访问表单字段中的内容。（如果 B 的服务器愿意，它可以向用户发送恶意 JavaScript。）
最安全的做法（就保护信用卡号码而言）是将表单完全放在支付处理服务的主机名中，而不是放在不受信任的主机名中。