在没有 PCI 合规性的情况下集成支付网关时的注意事项

Question

我想对在我的网站中集成支付网关进行一些澄清，因为我们公司没有 PCI DSS 合规性想知道通过 JavaScript 将卡详细信息传递到支付网关是否合法代码？

我知道我们不应保存或存储此信息，或将其传递到我们的服务器。我们也没有这样做。

我们计划集成Razorpay支付网关，使用Razorpay提供的JavaScript file。这个 JS 文件提供了通过调用 createPayment 方法创建支付的功能，我们必须在其中传递支付数据。以下是样本数据：

var paymentData = {
      email: email,
      contact: '9999999999',
      method: 'card',
      'card[name]': cardName,
      'card[number]': cardNumber,
      'card[cvv]': cardCvv,
      'card[expiry_month]': cardExpiryMonth,
      'card[expiry_year]': cardExpiryYear
};

代码流程是这样的：

1. 我们呈现输入字段以输入卡片详细信息
2. 从 JavaScript 读取每个输入字段中的数据
3. 构造需要传递给支付网关的数据对象
4. 调用支付网关JavaScript提供的方法，并将对象作为参数传递给该函数。

所以我的问题是这种合法的实施方式吗？另外，我在Razorpay 中看不到任何与这种实现相关的文档。但他们现在也确实为这种方法提供了支持。

请让我知道在不符合 PCI DSS 的情况下实施支付网关时是否需要注意任何其他边缘情况。

Answer 1

让我先声明一下，我不是 PCI 合规方面的专家。这是我作为开发人员的工作知识，可能并不完全准确。我建议以此为起点进行更多研究。

法律将取决于上下文。在美国，任何联邦立法均不要求遵守 PCI。相反，PCI 合规性是通过与商家服务提供商的合同强制执行的。例如，以下是ProPay 文档的摘录：

所有商户都必须遵守支付卡行业数据 安全标准 (PCI DSS)。对于正在融入的商家 ProPay API，包括卡的处理和传输 数据直接，商家需要验证他们有 完成了相应的 PCI DSS 要求。

如果您想通过 ProPay 处理付款，您有义务遵守 PCI 要求。如果您要使用 ProPay，在您关系早期的某个时间点，他们会要求您通过填写证明您符合 PCI DSS 标准中列出的所有要求的文件来正式接受 PCI DSS 标准。较小的商家可以选择通过完成自我评估问卷或 SAQ（发音为“sack”）来宣誓效忠。较大的商家将不得不聘请一些 QSA 顾问代表他们提交报告 - 我对此知之甚少。

您可以选择填写哪个 SAQ，具体取决于您对信用卡数据的了解。如果您绝对无法控制信用卡数据的获取方式，则可以完成 SAQ A。如果您有资格完成 SAQ A，那么自我评估所需的工作应该非常简单。

SAQ A-EP 类似于 SAQ A，但有许多更多的自我评估要求。供参考：SAQ A 有 4 页问题，SAQ A-EP 有 30 页问题。 SAQ A 的问题较少，因为当您没有接触信用卡数据时，许多问题根本不相关。

对于您的具体示例：您正在使用的库听起来像 you 负责进入 DOM 以从 you<input>s 中提取信用卡数据> 创建。由于第 2g 部分中的要求，这使您没有资格完成 SAQ A：

传送到消费者浏览器的所有支付页面的整体 直接源自第三方 PCI DSS 验证服务 提供者。

SAQ A-EP（同样，第 2g 部分）允许您创建捕获数据的页面，只要您实际上并未将其提交到您的网络服务器：

商户的电子商务网站不接收持卡人数据，但 控制如何将消费者或其持卡人数据重定向到 PCI DSS 验证的第三方支付处理器；

...

发送到消费者浏览器的支付页面的所有元素都来自商家的网站或符合 PCI DSS 的服务提供商；

因此，如果您使用的支付网关想要使用 SAQ 验证您的 PCI 合规性，您将有义务填写冗长、糟糕的 SAQ A-EP 表格，而不是 SAQ A 小菜一碟。

奇怪的是，Razorpay's landing page 建议他们不要求商家符合 PCI。我对这种说法持怀疑态度，但如果他们真的不需要 PCI 合规性，您可能不需要追求它。我不建议您违反 PCI...但如果他们从不要求您验证您的 PCI 合规性，您将永远不必填写 SAQ A 或 SAQ A-EP。