3

I seem to be getting conflicting answers on whether using the default Authorize.net gateway (either direct post or not) on Magento CE 1.9+ is a compliant process or not. Could someone clarify this for me?

I understand the different levels of compliance & most of what's involved in the process of becoming PCI compliant (taking the SAQs, getting quarterly scans, installing firewalls, using secure logins, practicing secure network habits, compliant hosting, etc), but I'm a little confused on the actual Magento CE payment gateway side. If everything else passes, I'd like to know: if you accept payments via Authorize.net (either Direct Post or not), is it possible to use those stock Authorize.net gateways & be PCI compliant?

1 Answer 1

3

tl;dr: Authorize.net out of box in Magento is not PCI compliant at specific SAQ levels; in fact no payment gateway method is. Provided you've satisfied all other SAQ requirements there are ways to safely implement Authorize.net Direct Post or any other gateway.

PCI compliance is a huge subject with way too many factors than can be explored here within the scope of this site.

However, your question can be answered, so I will attempt to do that.

There are a few things that can help you determine whether there is a sufficient business cause for you to accept this risk and all of the liabilities that come along with it. To help you decide we have to dispel a myth:

You cannot store credit cards

This statement is fundamentally false. It sounds like you already have this understanding. Although this is tangential to your actual question (is the stock Authorize.net PCI compliant) it is crucial for you to understand what "storing cards" means.

You can store cards

First, you can store cards. But you can't store them willy-nilly; there are secure practices that you should be following to do so. There are also difficult barriers to overcome with other liabilities, like admin work to allow you to do so (job descriptions, guest sign-in book, CCTV, etc.)

So, though it's allowed, it may not be feasible for your size of business.

Enter: tokenization.

Tokenization allows your bank to store the card for you so that you don't have to have the burden. They give you a token - a proxy for the PAN† - so this means that the bank is storing the card. If the bank is allowed to store the card, then that means somewhere along the line they've satisified the requirements to be able to do so.

Who has what information, when?

In order for the bank to get the card number, your customer has to enter it into your form. Magento receives this information, encrypts it, and stores it in volatile memory (RAM) so that it is never persisted.

This is important.

This means that the data is stored only temporarily. It will not survive a reboot. It will not survive a power outage. It is effectively ephemeral. This changes the scope of your liability, and ultimately (along with several other factors) it reduces your risk and likely the SAQ level you're having to operate at.

But, fundamentally, the card data still passes through your systems, and through the Magento platform. Assuming all of your infrastructure passes the test that begs the question....

Is your platform compliant?

Magento is PA-DSS compliant, meaning, that out of the box Magento is compliant for Preauthorization ONLY. If you read the fine print this has one major caveat (get ready for this):

Magento itself isn't PCI compliant.

If you examine the docs at http://magento.com/resources/pci you will quickly realize that the way they achieve PCI compliance is to implement Secure Payment Bridge, a technology they vetted specifically for this purpose.

This is essentially a self-hosted version of iFrame based payments. The burden is still on you to provide PCI level architecture, but this payment system is fully up to snuff for PCI.

You may ask "why in the world did they do it this way?" and the answer is quite simple: it is too costly and time consuming to re-test the entire Magento platform for every minor bugfix and version release.

The Magento platform is expansive and contains a lot of functionality that is not directly related to the payments processing portion. By removing the payments compliance from the Magento platform itself into a separate product Magento have prevented changes to unrelated systems (CMS, promotions) from having an impact on PCI.

Are all of your third party modules compliant?

Without Payment Bridge all of your third party code also comes under scrutiny. It may be easy enough for you to provide PCI certificates from large vendors like Magento, but possibly much more difficult from small module vendors.

Assuming that you set up Payment Bridge those modules are non longer in scope - meaning - they have no impact your PCI compliance.

How to safely implement payments

Because Magento itself is not compliant, the real answer is that technically the Authorize.net payment methods are not compliant. But the longer answer is that, if you've passed all of the requirements and have passed all security scans then you have achieved compliance for yourself.

As long as your business practices have not elevated your PCI level above SAQ-C then you should be in decent shape to implement a direct gateway. Again, assuming you've passed everything else (including the unbelievable restrictions on WiFi).

However, there are other ways. Many vendors (including Authorize.net) are now providing their own version of the iframe payments functionality without you needing to implement it via Payment Bridge. For out of box Magento only the Authorize.net Direct Post module comes close, but likely not close enough. For true separation the new standard is their Hosted Cim product.

Hope that helps!


† PAN - Personal Account Number

Find other terms here:

https://www.pcisecuritystandards.org/security_standards/glossary.php

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.