在线支付网关要求

Question

我一直在寻找一个在线支付网关，authorize.net，特别是他们的直接邮寄方法。此方法将允许我在服务器上创建表单，然后直接将post参数提交给它们的服务器进行处理。所以你从来没有离开我的网站作为一个客户，但我的服务器只能看到响应，而不是最初的付款信息。

我考虑过的一个问题是PCI遵从性。我一直在阅读authorize.net博客的评论。对于具有表单的服务器是否需要兼容PCI存在争议。有些人说是的，因为表单在你的网站上，上面有你的网址，还有信用卡信息。另一些人说不行，因为表单是直接提交给authorize.net的，信用卡信息甚至从来不访问商家的服务器。

我在他们的网站上读到过几个地方，直接邮政方法将“简化商家的PCI遵从性”，或者“减轻一些对安全的担忧”。PCI依从性究竟是如何简化的？所以我的问题是，我的站点是否需要兼容PCI，如果需要，如何简化它？

一个相关的问题是事务密钥。Authorize.net说要安全地存储密钥。密钥如何安全地存储在服务器上？(没有HSM)这是PCI的关键部分吗？

Answer 1

如果您的服务器在任何时候不以任何身份存储、处理或传输持卡人数据，那么您的系统就不在符合PCI要求的范围内，而且您实际上已经将此类数据的处理外包给authorize.net --这意味着PCI简化了，因为您已经缩小了范围，并且将完成一份不那么繁重的自我评估问卷(SAQ)。作为一个商人，你需要遵从，而不是你的网站需要遵从。如何处理持卡人数据决定了您完成的SAQ -如果您已经外包了持卡人数据处理，您将完成SAQ A，这是相当简单的！

Visa和MasterCard在事务处理被外包时，对于如何保护web应用程序有指导方针，例如使用托管支付页面。令人担忧的是，应用程序可能会被操纵，持卡人数据传输可能被重定向(或复制)到第三方。

要求包括安全开发生命周期、漏洞扫描、日志记录和文件完整性监视。

您应该考虑将事务密钥单独存储到应用程序本身，例如在数据库中加密，或者存储在具有强访问控制的单独文件存储中。

Answer 2

首先，我不是律师，你应该和律师或PCI专家谈谈，而不是在互联网上随便找个人。尽管如此，我对Direct的理解是，客户端将PCI发送到Authorize.Net的服务器。您的服务器从未碰过它，因此它不应该要求符合PCI。PCI-DSS只要求与PCI相关的系统兼容，严格地说，PCI的唯一交换是客户机的浏览器和Authorize.Net的服务器之间。

尽管如此，尝试遵循许多准则仍然是明智的，因为您的服务器的妥协可能很容易在发送PCI的地方(例如恶意JavaScript更改表单的POST地址)。Authorize.Net网站上的争论可能是这样一个事实，即您的服务器的妥协仍然会损害事务的完整性，但是PCI还没有意识到这种风险，而且在技术上仍然是智能用户可以检测和阻止的东西，因为他们的系统是被欺骗来做坏事的。

Answer 3

您的“解决方案”有一个大问题:您必须将您的Authorise.net ID和API键放入表单中，以便A.net能够处理事务并将钱发送到正确的位置。

黑客要获得API键和A.net ID所需要做的就是右键单击并选择'View‘以获得商人的API密钥和A.net ID。如果您试图用一些蹩脚的javascript阻止它，黑客只需将页面保存到他的硬盘驱动器中，然后查看它并获取ID/API键。但“雇佣”黑客团队有机器人可以自动完成这一任务。

在我的书中，这甚至不会变成“黑客”--这太简单了，太明显了。

因此，如果你这么做，你很快就会向你的客户解释，为什么1、2名职员整天都在忙着，除了获得非客户信用卡的授权，并将信用卡退还给非客户，并回复非客户持卡人的愤怒电话(完全没有销售)，因为坏蛋们会兴高采烈地将信用卡交易与客户的A.net账户进行碰撞，看看他们持有的被盗信用卡是否还不错。所以这对你来说是个很棒的举动。

因此，您的选择是2:使用Stripe (并通过鼻子付费)或编写一个安全的解决方案，并将表单提交给您自己的服务器，添加API键并将包从后门发送到A.net，然后解析直接的答案。是的，这一措施确实意味着您将处于完全符合PCI标准的状态。

相信我，有很多黑客团队在网络上安装了机器人，寻找显示字符串“x_tran_ key”(将A.net的事务密钥以表单形式提交给A.net的表单元素名称)，这是对打开的A.net事务密钥的死赠予。

你要给那些家伙一个不错的薪水吗？