在不符合PCI标准的情况下集成支付网关时的注意事项

Question

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

  

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

我们计划使用Razorpay提供的JavaScript file集成Razorpay支付网关。该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要求的Payment Gateway时是否还有其他需要注意的边缘情况。

Answer 1

  

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

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

  

所有商家必须遵守支付卡行业数据   安全标准（PCI DSS）。对于正在融入的商人   ProPay API，其中包括卡的处理和传输   直接获取数据，要求商家验证他们是否拥有   完成了适当的PCI DSS要求。

如果您想通过ProPay处理付款，则必须遵守PCI要求。如果您要使用ProPay，则在您关系初期的某个时候，他们会要求您填写文件证明您符合PCI DSS标准中概述的所有要求，从而正式为您接受PCI DSS标准。较小的商人可以选择通过完成自我评估问卷或SAQ（发音为“麻袋”）来保证效忠。较大的商家将不得不聘请一些QSA顾问来代表他们提交报告-我所知道的甚至更少。

您可以选择填写SAQ，具体取决于您对信用卡数据的了解程度。如果您完全无法控制信用卡数据的获取方式，则可以完成SAQA。如果您有资格完成SAQ A，则自我评估所需的工作应该会很容易。

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

以您的特定示例为例：您正在使用类似 you 之类的声音的库负责进入DOM，以将信用卡数据从 you < / em>已创建。由于第2g部分中的这一要求，因此您没有资格完成SAQ A：

  

交付给消费者浏览器的所有付款页面的全部   直接源自第三方PCI DSS验证的服务   提供者。

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

  

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

     

...

     

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

因此，如果您要使用要使用SAQ验证PCI合规性的支付网关，则必须填写冗长，糟糕的SAQ A-EP表格，而不是SAQ A蛋糕。 >

奇怪的是，Razorpay's landing page建议他们不要要求商家遵守PCI。我对此说法表示怀疑，但是如果他们真的真的不需要PCI合规性，那么您可能就不需要遵循了。我不建议您违抗PCI ...但是，如果他们从不要求您验证您的PCI合规性，则您无需填写SAQ A或SAQ A-EP。