Hello. I have a question on PCI compliance for my clients. Auth.net recommend using the AIM connection method. They claim this is the most secure method. However, after reading the PCI self-assessment questionnaire (OHHH BOY), I am not so sure. Basically, the AIM method seems to leave my clients more vulnerable since they are capturing the cc on their server. Since the client server captures the cc information, doesn't the server have to be PCI compliant? This doesn't just mean running a scan -- PCI compliant servers cost hundreds of dollars per month (per client)!
Maybe I am missing something. As I read the PCI paperwork and self-assessment questionnaire, I get the feeling the cc companies are putting so many requirements on small e-commerce businesses.
What do you think?
Well, this is just my opinion here, but after looking into PCI compliance and a lot of security as well as hacking methods, the only thing I could conclude is, 100% security is IMPOSSIBLE. No matter how many ways I secure my code or transaction phase, I am only able to block a tiny portion of the holes hackers use to steal the info. I have no control on my users(and their knowledge of security) or their system neither can I assure that my payment processor, let's say auth.net, can never ever be hacked.
To me, the PCI compliance is pretty much a safeguard for CreditCard comapanies, and from a developer point of view, there isn't much we can do about it, even while using Hosted CIM.
You can get almost to 100% on everything except password security, however. And password security is not really your responsibility, beyond your own use of passwords. My sole point all all along has not been that all security measures are pointless - rather that removing the credit card collection from your own site doesn't really increase -actual- security much, if at all, since anyone who gets into the hosting can collect credit card data by inserting or redirecting, regardless of how your ordering system is set up.
Therefore, PCI really boils down to whether the costs outweigh the benefits or not. it will cost you $500 in time and/or money to comply and the penalty is $15 per month, there's no point in complying. If it costs $100 to comply, then it's more worthwhile. On its merits alone, it fails - though a quick read-over doesn't hurt just to make sure you're doing the more common-sense things.
I'm not sure DPM would be excluded from PCI compliance, the definitions of what PCI covers are very broad.
At the end of the day, if someone gets into your server/hosting, and they're any good, they could probably skim the credit card details, at least temporarily, of any payment gateway integration option you use; the exception is perhaps the 100% hosted payment page.
With DPM, the credit card data is never even in your server's memory, never mind stored anywhere. So as far as PCI goes, I'd guess the rules don't apply. However, password security should be used anyway, since even if you use the hosted payment gateway, it's just a matter of hackers redirecting to a different "payment" page hosted on their site or a site they've compromised. Takes slightly more effort, since they have to set up a form to scrape credit card details from, but not really a whole lot.
You just have to be transmitting/relaying the data to be covered by PCI.
That said, DPM data would post directly to Authorize.net, so there would be no relay; but as you've pointed out - given server access - DPM, or even a hosted page, could be hijacked too with little trouble.
Now I'm thinking PCI compliance will eventually be extended to cover 3rd party posting methods....