Tell me more ×
Answers OnStartups is a question and answer site for entrepreneurs looking to start or run a new business. It's 100% free, no registration required.
up vote 3 down vote favorite

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.

share|improve this question

3 Answers

up vote 1 down vote accepted

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.

share|improve this answer
up vote 5 down vote

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

share|improve this answer
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 Jan 5 '11 at 21:48
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 Jan 6 '11 at 3:02
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 Jan 6 '11 at 6:04
@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 Jan 6 '11 at 12:36
@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 Jan 6 '11 at 12:41
show 2 more comments
up vote 0 down vote

If you're not storing credit card numbers, have secure servers, etc. generally becoming PCI compliant is fairly easy and inexpensive. Shop around, sounds like that quote could be way higher than it needs to be.

share|improve this answer
Thanks for the tip. I'm in the middle of it and I'll post back here when I find out! – Alex Cook Jan 6 '11 at 22:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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