如果您的服务器在任何时候都不以任何方式存储、处理或传输持卡人数据，则您的系统不在 PCI 合规范围内，并且您已有效地将此类数据的处理外包给了 authorize.net - 这意味着 PCI 是简化，因为您的范围缩小了，并且会完成一个不那么繁琐的自我评估问卷 (SAQ)。作为商家，您需要合规，而不是您的网站需要合规。您如何处理持卡人数据决定了您完成哪个 SAQ - 如果您将持卡人数据处理外包，您将完成非常简单的 SAQ A！

Visa 和 MasterCard 制定了在交易处理外包（例如使用托管支付页面）时应如何保护 Web 应用程序的指南。令人担忧的是，应用程序可能会被操纵，持卡人的数据传输会被重定向（或复制）到第三方。

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

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

首先，我不是律师，您应该与律师或 PCI 专家交谈，而不是在互联网上随便找人。也就是说，我对 Direct Post 的理解是客户端将 PCI 发送到 Authorize.Net 的服务器。您的服务器永远不会触及它，因此它不需要 PCI 合规性。PCI-DSS 只要求涉及 PCI 的系统必须符合标准，严格来说，PCI 的唯一交换是在客户端的浏览器和 Authorize.Net 的服务器之间。

也就是说，尝试遵循许多准则仍然是明智的，因为您的服务器的妥协很容易危及 PCI 的发送位置（例如恶意 JavaScript 更改表单的 POST 地址）。Authorize.Net 网站上的争论可能是关于您的服务器的妥协仍然会损害交易的完整性，但 PCI-DSS 还没有赶上这种风险，并且在技术上仍然是聪明的消费者可以做到的事情检测和预防，因为他们的系统是被诱骗做坏事的系统。

您的“解决方案”有一个大问题：您必须将您的 Authorise.net ID 和 API 密钥放入表单中，以便 A.net 可以处理交易并将钱发送到正确的地方。

黑客只需右键单击并选择“查看源代码”即可获取 API 密钥和 A.net ID，以获取商家的 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 交易密钥。

你打算给那些家伙一个不错的发薪日吗？