What's the most efficient and cost-effective way to become PCI compliant?
I'm working on a business-to-business web app.
About a year ago we gave our users the ability to charge credit cards (from customers calling them over the phone) directly within our software system.
Then we found out we needed to become PCI compliant, and we were quoted anywhere from $8,000 to $20,000 to make it happen.
Can anyone comment on this experience? Have you ever become PCI compliant, and what has it cost you?
We're not storing any credit card information, our server is secure, and we use best practices. $8,000-$20,000 to look at some code and verify that we're using best security practices seems astronomically high - especially for a startup. Maybe the process of having a 3rd party audit is more complicated than I think.
Software Credit Cards Security
2 Answers
"We're not storing any credit card information"
But, are you pulling into your servers any cc information, even if only to then transmit it?
Many web apps basically inline service provider screens/code, and do not actually traffic the sensitive data through their own servers. The data may be on your page, but it gets directly sent to a processing server outside your control. (Which means you are an SAQ-A on the Self-Assessment Questionnaire )
At that point, the primary item is that you should be using compliant software (if you have any shopping cart software you purchased and host) and service providers (the payment processors you may be relying on). You only need to comply with PCI DSS reqs 9 and 12.
Additionally, VISA has its own overlapping requirements based on transaction volumes. Assuming you don't process much volume, chances are high you only need to submit the SAQ, and maybe an independent scan. A full audit is probably not required.
However, if you actually receive credit card data, even to then only transmit, or if you have internal processing systems connected to the Internet, you must comply with more requirements, which may include regular penetration testing or actual full audits.
-
Thanks for the detailed response. Yes - we are pulling it in, then transmitting it to a payment server, which then handles the transaction. Sounds like we'd have to be compliant via regular penetration tests and full audits. – Alex Cook 14 years ago
-
I don't know which processor you are using, but Authorize.net has a decent API and you can go further and keep all the info in their CIM app. – Apollo Sinkevicius 14 years ago
-
I'm using a company called Merchant Warehouse. As far as I know, it doesn't matter which gateway/processor you use - if you're transmitting the data at any point you're required to be PCI compliant. Correct me if I'm wrong, though. – Alex Cook 14 years ago
-
@Alex: If you have a web page where there is some form and/or script that takes user input, and the data in that form goes to the merchant (iow. the data is encapsualted in an HTTPS message that is being directed to a URL that is not under your control) and not directly to your server, you qualify for SAQ A. – Alphadogg 14 years ago
-
@Alex: Or, if the act of purchasing involves redirecting the user to the processor's site, whereby the processor handles the cc data. For example, Authorize.net has hosted payment forms and they are, obviously, PCI compliant. – Alphadogg 14 years ago
-
Thanks alphadogg. We could update so the http request goes to the merchant's server (without going to our server first). Are there security concerns there? I know our payment gateway gives back detailed responses, like "cvc not valid", or "street address not valid". Thanks for the tip! – Alex Cook 14 years ago
-
Yes. Check out Authorize.Net's version of a direct method: http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Direct-Post-Method-DPM/ba-p/7014. There are no more concerns than that of any HTTPS transaction. The form goes to Authorize via HTTPS. Authorize sends you results. You send back an OK. Authorize responds to customer with the next step for the client's browser. The older approach is that you'd redirect to Authorize and they server up forms and responses, eventually redirecting back to your site. You'll still need to guard your site with an SSL certificate. – Alphadogg 14 years ago
Honestly, if it is at all possible get out of the credit card processing business. Push that over to a processing company the way @alphadogg recommends with Authorize.net (and there are several merchants who will do this for you.) PCI is a pain but it is easily doable even if you have to pay 20k.
My much larger concern for you is what happens WHEN there is a security breach. It might be a hacker but is much more likely to be someone on the inside (employee, contractor, etc.) Based on your posting you are actually processing credit cards from your customer's customers. When you have a security breach you'll have egg all over your face and have to deal with the possibility of legal action, lost customers, and bad PR.
If they are entering the credit card information in the web-app it is very likely you can move to using a processor to handle this part of the transaction. It will eliminate the PCI compliance issue, improve your site's security (if you don't have CC data you are less attractive to the for-profit hacking world), and avoid any expenses related a system breach.
-
Put more simply, and what I tell my clients: If you aren't in the business of processing credit cards, outsource it to someone who is. You don't want that headache. – John Franklin 11 years ago
