Authorize.net (AIM) API 是否需要 PCI 合规性或任何其他认证？
我想知道这里是否有人使用过authorize.net“高级集成方法” API。
我已经浏览了他们网站上的常见问题解答，但此时我似乎无法找到直接的答案或联系到他们。
我知道 API 需要 SSL（显然），但如果您不存储信用卡号，他们的 TOS 协议是否需要 PCI 合规性或任何类型的认证？另外，如果有人碰巧知道，他们的服务条款中是否有任何内容反对将其用于存储商家凭证的应用程序（当然需要明确的商家许可）？
为了澄清，在最后一部分，我谈论的是一个 SaS 应用程序，它存储多个商家（同一服务器）的商家 ID 和交易密钥。
I was wondering if anyone here has used the authorize.net "Advanced Integration Method" API.
I've scoured the FAQs on their site, but I can't seem to find a straightforward answer or get through to them at this hour.
I know the API requires SSL (obviously), but does their TOS agreement require PCI compliance or any kind of certification, provided you are not storing credit card numbers? Also, if anyone would happen to know, is there anything in their TOS against using this for an app that stores merchant credential (with explicit merchant permission of course)?
To clarify, on that last part, I'm talking about a SaS application storing merchant id and transaction keys for multiple merchants (same server).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，它需要 PCI 合规性。 AIM 要求您在自己的 Web 服务器上收集用户数据，然后再将其发送到 Authorize.Net 进行处理。这意味着您正在处理和传输信用卡信息，因此必须符合 PCI 标准。
这不是 Authorize.Net 要求，而是支付卡行业要求。只要商家不违反 Authorize.Net 的服务条款，Authorize.Net 不对商家处理付款的方式承担责任。因此，如果您不符合 PCI 标准，Authorize.Net 并不关心。但如果发卡机构的网站不符合 PCI 标准且不使用 AIM API，发卡机构就会向商家提出问题。
Yes, it requires PCI compliance. AIM requires you to collect the user data on your own web server before sen ding it off to Authorize.Net for processing. This means you are handling and transmitting credit card information and therefore must be PCI compliant.
This is not an Authorize.Net requirement, it's a Payment Card Industry requirement. Authorize.Net does not take responsibility for how a merchant handles their payments in-so-far-as they do not violate Authorize.Net's terms of service. So if you're not PCI compliant Authorize.Net doesn't care. But the card issuers do and will raise issues with the merchant if their site is not PCI compliant and using the AIM API.
如果您使用 AIM，则属于 PCI 范围。许多开发人员一厢情愿地认为，如果他们只是使用 AIM api 将卡数据传输到 Authorize.net，那么他们就不在范围内。
根据当前的 PCI 规则，所有这些开发人员都错了。由于卡信息正在传输您的服务器，因此坏人可能会闯入您的服务器并窃取卡信息。不管可能性有多大，您现在都在 PCI 的范围内。
要使用 Authorize.Net 并远离 PCI 范围，请使用集成方法 SIM 或其新的直接发布方法< /a>.两者都会使您的服务器超出范围。
更多信息来自 Auth.net
If you use AIM, you're in scope for PCI. Many many developers wishfully think that they won't be in scope if they merely transmit the card data onward to Authorize.net using the AIM api.
All of those developers are wrong under the current PCI rules. Since the card info is transiting your server, a bad guy could break into your server and steal the card info. Doesn't matter how unlikely it is, you're now in the scope of PCI.
To use Authorize.Net and stay out of the PCI Scope, use integration methods SIM or their new Direct Post Method. Both keep your server out of scope.
More on this from Auth.net
整个 PCI 合规计划一团糟，并且将变得无法执行，因为没有真正明确的答案。现存的少数内容是模糊且模棱两可的。
该指南明确指出，如果您存储或传输敏感的支付数据，那么您就在范围内。您可以通过使用支付标记化服务进行存储并直接发布到支付网关进行传输来超出范围。这两种技术都会让你脱离范围。
直接发帖对我来说没有任何意义。我不明白服务器回发步骤如何符合传输资格，但直接发布到支付网关则不然。在这两种情况下您都会发送敏感数据。如果敏感数据是通过安全回发接收的，并且在发送到网关后立即丢弃，那么有什么区别呢？
当您发现 Web 浏览器不必符合 PCI 要求时，您会笑死的。它甚至可以在本地存储支付数据并通过不安全的通道传输！您可能会说盗窃的可能性较小，因为它不是公共服务器并且由信用卡用户操作。无论如何，在回发期间支付数据驻留在服务器上进行处理的极短时间应该具有相同的考虑因素。
此外，浏览器可以在任何地方运行，包括公共信息亭和电话。
The whole PCI compliance initiative is a complete mess and will become unenforceable because there's no real definitive answers. The few that exist are murky and ambiguous.
The guide clearly says that if you store or transmit sensitive payment data, then you're in scope. You can get out of scope by using a payment tokenization service for storage, and direct posting to a payment gateway for transmission. Both of these techniques, will keep you out of scope.
The direct posting makes no sense to me. I don't see how a server post-back step qualifies as transmission, but a direct post to a payment gateway doesn't. You're sending sensitive data in both cases. If the sensitive data is received through a secure post-back and it's immediately discarded after sending it to the gateway, then what's the difference?
You'll die laughing when you find out that a web browser doesn't have to be PCI compliant. It can even store payment data locally and transmit it through an unsecured channel! You could argue that the theft potential is smaller because it's not a public server and it's operated by the user of the credit card. Regardless, the tiny amount of time where payment data sits on a server to be processed during a post-back should have the same consideration.
Furthermore, browsers can run anywhere including on public kiosks and phones.
至于你问题的第一部分..不，它不需要 PCI 合规性。使用 Authorize.net 的主要优点之一是将 PCI 合规性交给他们。话虽如此，使用 Authorize.net 当然不会自动免除您的任何 PCI 责任。
as for the first part of your question.. no, it does not require PCI compliance. One of the major advantages of using Authorize.net is to offload the PCI compliance to them. Having said that, using Authorize.net , of course, does not automatically remove any PCI liability from you.