PCI SAQ是否足以支持具有自定义付款页面的电子商务网站?

时间:2014-01-31 16:12:39

标签: pci-dss pci-compliance

问题 - 我们的付款流程如下:

1 - 客户将物品添加到购物篮中。

2 - 当查看购物篮时,顾客可以看到产品和产品。也可以选择输入送货地址和帐单地址,但不包含敏感的卡片详细信息。

3 - 客户前往我们网站上托管的新页面。客户在此处输入敏感卡详细信息。

4 - 最重要的是,在按下“订单”时,卡的详细信息会直接发送到我们的付款处理方。它们不会先发送到我们的服务器。

我正试图与我的商业银行争辩说我们属于SAQ A - 是这样吗?

我的理由:

1)我们的专用服务器由第三方PCI兼容主机管理。

2)我们从不存储卡的详细信息。

3)当客户在我们自己托管的网页上输入他们的卡数据时,这是动态生成的,因此仅存在于客户浏览器中。在提交订单时,详细信息将直接发布到我们的付款处理器。因此,这些细节从不接触我们的服务器和A)不作为会话存储在服务器HDD或数据库上或B)甚至不在服务器RAM中暂时保存

4)我们已经通过了来自不同机构的多次PCI扫描,以确保我们符合要求并拥有SSL,服务器的TFA等等。

5)据我所知,这里的两个主要攻击媒介是受感染的客户计算机(不在我们的管辖范围内),或者是否有人设法控制我们的服务器并改变了结账的工作方式。但这确实影响了任何电子商务网站,即使是将卡片详细信息输入的网页外包给的网站(具有服务器访问权限的恶意攻击者可能只是重定向到假设置......这几乎是游戏结束)

然而,SAQ A的资格标准有点含糊不清(无论如何我都在想)。它声明:

  • 商家不会在商家系统或场所存储,处理或传输持卡人数据,但完全依赖第三方服务提供商来处理这些功能*

对我而言,“商家系统”可以包括整个结账的更广泛的元系统。在这种情况下,我们的结账会传输卡的详细信息,尽管我认为这是一种安全的方式。但是,如果“商家系统”意味着,例如,硬件,那么我们就没有任何传输细节的POS系统或服务器。

我无法从我的合规联络中得到直接答案。有时他们建议我填写D,然后说它不适合我,所以说要填写SAQ C,但后来说这是专门针对“支付应用程序”,例如连接到互联网的物理终端。

我认为我们论证的关键支点是,即使我们托管支付页面,卡片数据也永远不会到达我们的服务器。

任何帮助将不胜感激。我会提供赏金,但它不会让我atm :(

非常感谢你!

3 个答案:

答案 0 :(得分:3)

很抱歉让你失望,但你是A-EP。

  • 对于SAQ答:您的公司无法直接控制持卡人数据的捕获,处理,传输或存储方式。
  • 对于SAQ A-EP:您的电子商务网站不接收持卡人数据,但会控制消费者或其持卡人数据如何被重定向到PCI DSS验证的第三方支付处理器。

“在直接邮政实施中,商家网站会生成用于接受付款数据的网页,然后将其直接传递给第三方付款处理商。”

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Why-is-SAQ-A-EP-used-for-Direct-Post-while-SAQ-A-is-used-for-iFrame-or-URL-redirect

答案 1 :(得分:1)

我认为你是对的,你应该可以使用SAQ A.但是,这是怎样的“3 - 客户进入我们网站上托管的新页面。客户在此处输入敏感卡详细信息。“实施了?它是完全重定向,iFrame还是其他什么?交接影响事物。请记住,这是在你和你的银行之间,如果他们想要你做SAQ D,你可能需要做一个SAQ D.

干杯, Nate

答案 2 :(得分:0)

我是新来的,无法评论,

如果我使用第三方提供商,我正试图弄清楚自己哪个SAQ使用A或A-EP。

因此发现以下内容: SAQ答:您的页面不是源自您的服务器。您可以使用购物车和付款按钮将客户重定向到托管付款表单的处理器。示例:PayPal Express。

SAQ A-EP:您的页面来自您的服务器,您填写数据并通过邮件提交给第三方。只要服务器没有捕获数据,POST有效负载就会通过普通表单提交或JS ajax直接传送到您的处理器 - 它就是A-EP。

SAQ-D:您向服务器提交数据。他们可能担心您可以记录敏感数据,或者将其转发到其他地方等等。

对于不存储数据的小型企业来说,IMHO SAQ D已经过时了。