Does the authorize.net (AIM) API require PCI compliance or any additional certification?

Question

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).

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.