eturnalshift — 2012-01-23T20:08:20-05:00 — #1
I'm thinking about screwing around with making an eCommerce website and I keep reading up on PCI Compliance. Everywhere says, "Don't store pins, numbers, track information, etc." That's fine and dandy... but then what is the developer supposed to do? If I make a 'Shopping Cart' that totals all the items in the cart then how am I supposed to process the payment or issue refunds if I can't really store any information in regards to the transaction?
I'm hoping a few of you guys could answer this, and any other questions, that might pop up from our discussion. I'm thinking I might try to go to a workshop but I'd rather not run into it with such a poor understanding of the online payment processes.
I hope you guys will be patient with me as I figure this crap out. ^_^
force — 2012-01-23T20:30:20-05:00 — #2
Use a payment gateway service like paypal or authorize.net (and there are several others to choose from). Gateway services are set up to be PCI compliant, so you don't have to be (granted, you should still have some precautions in place, but you wouldn't be handling the actual financial information on your site/server).
votrechien1 — 2012-01-25T18:50:54-05:00 — #3
If you're developing a shopping cart that you're releasing to others, than I can't really provide any advice. However, if you're just trying to setup your own shop that is PCI compliant, my advice is not to get too worked up.
It is very easy to get a PCI compliant certificate. They'll scare you with pages of technical jargon, but at the end of the day PCI compliance is really aimed at protecting against folks doing stupid things like emailing customer credit card info to them in a plain text file (and other obvious massive security holes). If you're using a trusted third-party shopping cart software, a bank provided API, and an SSL chances are you're quite close to PCI compliant already.
Of course, I'm massively over-simplifying the process, but it really isn't as daunting as it first appears.
eturnalshift — 2012-01-26T11:21:47-05:00 — #4
Thanks for the replies, all. I've been doing some more reading on this and it looks like it's not going to be as hard as I had originally thought. For hosting, is shared hosting for the website and database OK if I'm not storing payment information within the database?
votrechien1 — 2012-01-26T12:09:59-05:00 — #5
Yes, shared hosting is fine. Again, that's one of the big things with PCI compliance to make sure businesses are aware they cannot/should not store credit card numbers.
thereddevil — 2012-01-26T23:36:36-05:00 — #6
This shows why you should not always trust the information you receive on a public forum.
PCI Compliance is not something to take lightly, however keep in mind that there is several levels of PCI Compliance, which one you need to be compliant towards depends what you try to do. Getting a shared hosting account PCI Compliant to process credit cards through an merchant like First Data or Authorize.net and so on (i.e. that the information is entered on your side and then forwarded to the merchant for processing by API) is basically impossible, as very few hosts want to start doing the modifications to the system to make it compliant with the scans required to be PCI Compliant at that level, or even if the scans picks up false positives you will have problems getting that information from the support so you can provide it to the company doing the scan.
If you plan processing by taking cards on your side and then sending it over to the merchant by API, the cheapest solution you can go for would be a small VPS system, or a fully hosted cloud system.
On the other side if you plan to process by sending people over to for example Paypal, you dont need to be PCI Compliant at all.
It is also important to remember if you accept credit card information through your side, there is also rules regarding that you need to handle that data at once, without any storing on your side and so on.
To answer your initial question, what you actually track is the transaction id. First you will have an order id for this order, so you will send that one over to the merchant system (it being Paypal, First Data or any other) this way you can track this payment towards this order. Then when you get a reply from the merchant system, you will know what order the reply is for (some systems are instant i.e. API or not instant i.e. IPN). Then if the order is successful you link the order with the transaction, if its not you would not mark it as paid. I would also recommend you keep a transaction record of both successful and failed payment attempts towards the orders, as that allow you to see if a customer tried to make a payment but failed, and why it failed etc.
tjwaldorf — 2012-04-15T18:13:01-04:00 — #7
This thread is a little old now, but wondering what direction you went with your merchant solution, and why. Did you end up going with your own merchant account and handling PCI compliance on your own, or did you go with a 3rd party system like PayPal?
jestep — 2012-04-16T14:16:09-04:00 — #8
I don't necessarily agree with this. It's possible that a shared host is setup so that it can be secure, but a shared host is not inherently secure enough to allow a website or application to be considered PCI compliant.
Can you confirm that no other organization using the server, including the host provider, has access to sensitive data (static or in transit), or SSL certificate keys, etc? What sort of physical and administrative security does the server have, and can you verify it?
Since end-to-end encryption doesn't exist over the web, it's quite possible that they would have direct access to a point where non-encrypted card data is transmitted to a payment gateway. It's also possible they they are backing up or logging certain events by default, and you probably don't know exactly what those would be. Shared servers are also notorious for being compromised from other accounts on the server. The main concern is that without more direct control over the server, you just don't know what sort of security, or lack thereof, is actually in place.
A shared host is generally not secure. I would agree that a VPS, fully dedicated would be much better, is the absolutely minimum segmentation that should be used for processing on a web server. This needs to be with a reputable company that understands PCI and security in general, and has written policies in place that keep them accountable to their policies.
timbee — 2012-04-25T19:54:26-04:00 — #9
There are really two pieces to ecommerce security. PCI compliance and PA/DSS compliance. PCI compliance is hosting. PA/DSS compliance is the payment software / platform.
The level of PCI compliance is based on the number of transactions and amounts http://www.pcicomplianceguide.org/merchants-20071022-gaining-pci-compliance.php?step=define. I'd suggest using a hosting company that already meets all the requirements.
As far as software that's PA/DSS compliant... checkout https://www.pcisecuritystandards.org/approved_companies_providers/vpa_agreement.php. PA/DSS validation and verification is an expensive proposition for software companies. Most just ignore it. (yahoo stores are not pci or pa/dss compliant).
tobuso — 2012-04-30T23:25:33-04:00 — #10
You really only need to worry about the payment gateway and your processor's PCI process. Auth.net is a good choice as it works with most shopping carts. The processor is going to require quarterly scans so be prepared for that. If you need any help PM me.