The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How to have Web app + Credit Cards = PCI Compliant

I am considering launching a web site/application to sell my software.

Credit cards would be accepted as the form of payment.

My question is, what are people doing in order to comply with PCI without spending a lot of money? 

Does the web host where my dedicated server is at have to be PCI "compliant" for me to be compliant?

I really have no need to store the credit card number on my dedicated server if a credit card processor would give me an invoice/recepit # that I could use in case of a refund is need. 

If I used SSL and didn't store the credit card # on my server, and only store the unique receipt # (if such a thing exists) - would that make me PCI compliant?

Thanks in advance for any insight.
Ben
Thursday, March 22, 2007
 
 
That's funny. I was just wondering the same thing today. I'm currently going through a PCI project for a brick and mortar retailer and it made me wonder if JOSers have to deal with this kind of thing. I'm assuming that you mISV's are not storing credit card numbers and must be delegating all authorization and settlement to third parties. If not, are you PCI compliant?
dood mcdoogle
Thursday, March 22, 2007
 
 
You might be better off asking this question over in the Business of Software forum. Lots of mISVs hang out there.
John Topley Send private email
Friday, March 23, 2007
 
 
caveat: I haven't read the entire PCI spec (https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf), however it is my understanding that PCI compliance is based off a sliding scale.  If you process a huge number of transactions, you have to be quite compliant with the full set of standards.  If you are processing 1k orders a year, you don't have much to worry about at all.

When an audit takes place, they look at *all* the transactions placed against your business ID, which does include both retail and online sales.  For this reason, many online sites have a very high PCI requirement, as they consider brick-and-mortar sales too.

For the project I worked on that was reviewed by auditors, we just needed to make sure the CC numbers were encrypted both in transit (SSL) and when persisted (storing encrypted data in the database tier).  We leveraged one of the many online credit card processing applications to actually fulfill the transaction (and run fraud rules).
brian doll
Friday, March 23, 2007
 
 
if you use one of the off site payment providers then you don't need to be PCI compliant.

if you are new to e-commerce, keep well away from PCI compliance it will only push up costs and increase the difficulty of implementation for quite a modest payoff.

worldpay, secpay, protx, paypal all offer off site solutions. If you are in the states then I am sure equivalents exist there too.
Jack Send private email
Saturday, March 24, 2007
 
 
>however it is my understanding that PCI compliance is based off a sliding scale.  If you process a huge number of transactions, you have to be quite compliant with the full set of standards.  If you are processing 1k orders a year, you don't have much to worry about at all.

Wrong...you do have to worry about it...you just don't have on site inspections and a few other bits n bobs. The rules about the system are pretty close whether you do 1 transaction or 1 billion.

If you don't have to do PCI compliance dont do it.
Jack Send private email
Saturday, March 24, 2007
 
 
What's the cost (in fines, lost sales, time re-implementing the system, reputation, banks not letting you have a merchant account because you let a billion dollars in fraudulent transactions through your server) of not getting the code right?

What's the cost of hiring someone who already knows the answers to write the code for you while you concentrate on the bits of your business where you can actually do something to help make people want to give you their credit card details?

Really, the idea of every business in the world somehow having to write its own credit card processing software seems very odd. Surely someone's made that into a product, no?

No?  We're in the software business so every piece of software from the OS to the compiler to the credit card processor to the software in the coffee maker is something we have to write ourselves?

Weird.

Monday, March 26, 2007
 
 
I haven't looked at the PCI spec at all, but I can tell you that while a software package can *break* security very badly, it cannot *provide* security.

How is your physical security? Is your database server sitting in the store office that often goes unoccupied and unlocked for hours while you're busy with customers? Or is it in a well-secured area?

How is your network security? Is your database server also your web server? Or is it tucked safely behind a couple of firewalls that won't let the internet (other than your web/app server) talk to it?

How is your database security? Is it too much bother to remember the database-administrator password, so you just don't use one? Or do you have tight security?

That said, there IS a lot of commonality here, and I don't see why there couldn't be a control that collects all the data - plus credit-card-processor specific versions of it that also handle communication on the back side.
Don Edwards Send private email
Wednesday, April 04, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz