Is this way of using Authorize.net's CIM PCI compliant?

Question

We have a webapp where Authorize.NET's CIM and AIM are used for payment operations. When user buys something at first time he enters his CC number and other billing information at our site. This information is entered and transmitted from browser to our server through non-SSL connection. Other PCI-DSS rules (such as password restrictions) are also not satisfied by the site. Then this billling information is transmitted from our webserver to Authorize.NET's servers. CC number isn't stored by ourselves but we store (in not encrypted way) CC expiration date, 4 last digits of CC number, first and last name of cardholder. When user purchases something at 2nd time, he should just choose to use this existing credit card to buy something.

API Login ID and Transaction Key are also stored in not encrypted way.

Is our site PCI compliant? Is it a correct way of using CIM?

Edit: Will it be enough to just switch to site-wide SSL and not store CC expiration date and 4 last digits of CC number?

Answer 1

If you're transmitting credit card information through a non-SSL connection to your servers, you're not PCI-DSS compliant. It is a requirement all personally identifiable information is transmitted through secure (encrypted) connections.

Regarding the rest - the storing of unencrypted information: expiry date, etc - the answer depends on your company's classification under the PCI-DSS rules; if a small company, there are less stringent requirements.

I recommend reading the PCI-DSS documentation thoroughly before proceeding with this. It can be found here: https://www.pcisecuritystandards.org/security_standards/documents.php

Note: once you think you're compliant, you should have a compliance test run by an external auditing company (I use SecurityMetrics but they're not the most fun company to deal with). They are then usually done quarterly to ensure continued compliance.

Answer 2

There are many factors that need to be taken into consideration in order to answer if your site is PCI compliant or not, and depending on what type of vendor your classified as, you may need to hire a Qualified Security Assessor (QSA) to verify that you are indeed PCI complaint. When you say that the CC information is transfer through a "non-SSL connection" is this connection encrypted, and if so, does it only use encryption algorithms that are consider "strong". If its not encrypted, and the CC information travels through a public network (e.g. the internet), I can tell you right now that is not PCI complaint.

The best way to handle this types of situations (in my opinion), is to pay a PCI compliant payment gateway that offers a redirection service. That is, when your client is ready to pay he/she will be redirected to the payment gateway site where the CC information will be entered. Once the payment goes through, the payment gateway will redirect the user back to your website. The payment gateway will provide you with a transaction number which you can later use for refunds, or as a reference to the transaction.

Some of these companies also offer solutions for reoccurring payments, and similar use cases. They can provide you with a token that refers to an actual CC back on their server.

The good thing about this is that the CC information never touches your infrastructure and therefore, you will only need to answer a Self-Assessment Questioner A (SAQ A). These also outsource all the PCI overhead to a third party. The down side to this is that you have to pay the third party to handle all your transactions, but most likely the amount you will pay them will be less than the fines you will face if there is a breach in your infrastructure.