我想知道这里是否有人使用过 authorize.net“高级集成方法”API。
我已经搜索了他们网站上的常见问题解答，但我似乎无法找到一个直接的答案或在这个时间与他们联系。
我知道 API 需要 SSL（显然），但他们的 TOS 协议是否需要 PCI 合规性或任何类型的认证，前提是您不存储信用卡号？此外，如果有人碰巧知道，他们的 TOS 中是否有任何内容反对将其用于存储商家凭据的应用程序（当然需要明确的商家许可）？
为了澄清，在最后一部分，我说的是存储多个商家（同一服务器）的商家 ID 和交易密钥的 SaS 应用程序。
是的，它需要 PCI 合规性。AIM 要求您先在自己的 Web 服务器上收集用户数据，然后再将其发送到 Authorize.Net 进行处理。这意味着您正在处理和传输信用卡信息，因此必须符合 PCI 标准。
这不是 Authorize.Net 要求，而是支付卡行业要求。Authorize.Net 不对商家如何处理他们的付款负责，因为他们没有违反 Authorize.Net 的服务条款。因此，如果您不符合 PCI 标准，Authorize.Net 不在乎。但是，如果他们的网站不符合 PCI 并使用 AIM API，发卡机构会向商家提出问题。
如果您使用 AIM，那么您在 PCI 的范围内。许多开发人员希望如果他们只是使用 AIM api 将卡数据传输到 Authorize.net，他们将不在范围内。
根据当前的 PCI 规则，所有这些开发人员都是错误的。由于卡信息正在传输您的服务器，因此坏人可能会闯入您的服务器并窃取卡信息。不管它多么不可能，你现在都在 PCI 的范围内。
要使用 Authorize.Net 并远离 PCI 范围，请使用集成方法 SIM 或其新的Direct Post Method。两者都使您的服务器超出范围。
整个 PCI 合规计划完全是一团糟，将变得无法执行，因为没有真正确定的答案。存在的少数是模糊和模棱两可的。
该指南明确指出，如果您存储或传输敏感的支付数据，那么您就在范围内。您可以通过使用支付标记化服务进行存储，并直接发布到支付网关进行传输，从而超出范围。这两种技术都会使您超出范围。
直接发帖对我来说毫无意义。我看不出服务器回发步骤如何被视为传输，但直接发布到支付网关却没有。在这两种情况下，您都在发送敏感数据。如果敏感数据是通过安全回发接收的，并且在发送到网关后立即丢弃，那么有什么区别？
当您发现 Web 浏览器不必与 PCI 兼容时，您会笑死的。它甚至可以在本地存储支付数据并通过不安全的渠道传输！您可能会争辩说，被盗的可能性较小，因为它不是公共服务器并且由信用卡用户操作。无论如何，在回发期间支付数据位于服务器上以进行处理的极少时间应该具有相同的考虑。
此外，浏览器可以在任何地方运行，包括在公共信息亭和电话上。
至于你问题的第一部分..不，它不需要 PCI 合规性。使用 Authorize.net 的主要优势之一是将 PCI 合规性交给他们。话虽如此，使用 Authorize.net 当然不会自动免除您的任何 PCI 责任。