Forum Moderators: buckworks
PCI Compliance Guide [pcicomplianceguide.org]
In a nutshell, this is a data security standard considered acceptable by credit card companies. It involves a rigorous auditing process that reviews your network security systems and methods of collection and storage of credit card information. This means your servers must be under your control, not on a shared or leased hosting, which is out of the reach for most merchants.
The second consideration is that you you review your offline merchant account, you will likely be in violation of your contract if you use it for this purpose. This is why an online merchant account is structured differently and generally more expensive than an offline account.
The best option, really, is to relinquish yourself of this responsibility and set up an online merchant account, which places the responsibility of PCI compliance on them or the gateway that interfaces with the merchant account. You then only need to install an SSL cert on your web site and securely pass the info to them, without actually storing this data on your server.
In fact many 3rd party gateways REQUIRE compliance and will provide you with a PCI monitoring service free of charge to self-audit that compliance.
(Such as PayPal Payments Pro)
I now accept customers' credit card details by fax.
What happens when customer dials the wrong number and gets a fax machine elsewhere. We get wrong number faxes occasionally.
What it sounds like you want to do since you post the sale later is to use AUTHONLY as a sales type online. With AUTHONLY it pre-authorizes the credit card which will “reserve" the amount specified, it will not actually bill the consumer’s credit card. This process is used for Book and Ship sales transactions, where a merchant gets an order and at a later date, completes the transfer of funds.
Basically you go into the remote control panel for the credit card processor and complete and book the transaction later.
100% secure, NO sensitive credit card, NO details stored on your server or premises, nothing an employee or hacker can steal.
Do anything less and you're at risk and you don't want to be at risk because fines from Visa can be nasty, like $50K or some other ugly amount to cover their costs of damage control, and you can lose your merchant account.
[edited by: incrediBILL at 9:24 pm (utc) on Dec. 9, 2007]
My first question is, is this a lost cause to begin with - i.e. is it even possible to achieve compliance on a virtual dedicated account (specifically with godaddy)? I ask because I have received mixed information on this (from godaddy reps themselves as well as gleaned from chatter around the intertubese). If it's not possible, is the only option to pay hefty prices for enterprise level hosting and merchant accounts - effectively cutting out very small businesses of ecommerce? Otherwise, if it is possible, how does one determine specific requirements?
I have read comments from people in numerous places (including on this website) indicating they have achieved compliance on godaddy servers using paypal pro, which is what I am hoping to do. However, godaddy's legal agreement specifically states: "The Services are not intended to provide a PCI (Payment Card Industry) compliant environment and therefore should not be considered as one." Well, if the fundamental infrastructure of the hosting environment is "not to be considered" compliant, then certainly the buck simply stops there - i.e. nothing you do to secure your VPS, including software firewalls, antivirus, ssl, bulletproof code, etc. can change the fact that the system on which these measures rest is non-compliant to begin with, right? But if this is true, why has godaddy told me essentially, (after much prodding and with very indirect language) "it's possible, wink, wink, nudge, nudge, know what I mean -- but you are responsible for all the security of your own server, wink, wink, nudge, nudge." Really? How can I be responsible for the server's security, if I have no access to or control over the hardware or network - items which fall explicitly under the scope of PCI requirements? I don't know how godaddy manages their data centers, and clearly they are not in a position to describe it to me since that in itself would be a security breach...sigh...so how do I find out where I stand?
If I have ultimate control over the ability to achieve compliance, GREAT, but again, how does that reconcile with policies such as those quoted from godaddy above? Furthermore, if I do in fact have the power to achieve compliance, what are the specific responsibilities I will have and how do I uphold them?
For example, if i were to go with godaddy VPS and website payments pro (assuming compliance is possible with this setup), is there an issue with choosing redhat vs centos? should I pay extra for plesk to manage firewall and/or AV or should I stick to ipfw etc. and the additional complexity of manual configuration? Recommendations for working with the paypal API vis a vis PCI?
Bottom line, i represent a small business with a very low volume of transactions looking to offer online purchasing to customers as a convenience, and have a very small budget for hosting and merchant services. At the same time, I want to protect customer data and comply with required standards to avoid debilitating fines. To do this, I need straight answers and practical guidance that doesn't always end with "pay them, they're experts and they'll just do it for you."
Thanks for any help anyone out there can provide...and sorry for rambling!
Thanks!
This means your servers must be under your control, not on a shared or leased hosting, which is out of the reach for most merchants.
I'm glad I read that closely. We're in the process of preparing to store encrypted CC information. As soon as I read this topic I IM'd my lead programmer to get his input...
Assuming someone ever got hold of our database, without the encryption key(s) they can't do anything about it. They can run a server farm for years to try and decrypt our key(s).
Also, the key(s) are on a separate server from the database. They would need to hack into multiple servers first.
Phishing is much faster than hacking and a lot easier.
Unless the hacked server is so lax in security.
Those were just a few of the comments that "immediately" flew in when I questioned our methods in regards to this. We store CC information due to subscription based charges.
Yes, I realize that security is only as good as your systems and those who manage them. I'm giving more thought to this now that this topic has surfaced.
We store CC information due to subscription based charges.
Just FYI, this is NOT necessary for subscriptions if you are using a processor that supports recurring billing. Authorize.net, Netbilling, payPal, to name three. When you cross this line is when PCI compliance becomes an issue.
To a8news, welcome aboard! I think you may be misunderstanding what goDaddy is saying (big surprise there lol . . . )
PCI compliance is an issue if you are storing credit card information. While that's not the "whole story," it's the most important one. PCI compliance involves, MOSTLY, the security of the hardware and network on which the data is stored. This is what G.D. is saying, "our servers cannot be made PCI compliant."
This shouldn't be a problem for you if you use a reputable payment processor. If you use Website Payment's Pro, PCI compliance is payPal's job, not yours.
If you wish to accept credit card information on the form to be directly posted to payPal - not stored - all you need is a good SSL cert. When you make your "post" (to the gateway/payPal) the processor will only accept connections from a secure server anyway.
I hope that points you in the right direction.
I hope that points you in the right direction.
That's exactly what it does, and it's exactly the kind of answer I was looking for and hoping for. Thank you [and everyone else]!
