I am trying to decide between CS-Cart and PinnacleCart. Their big claim is that they are among only 2% of carts that are fully certified by the PCI. What does this certification really mean to me? CS-Cart claims to be PCI-compatible. Is this PA-DSS something CS-Cart is working to achive? Is it just marketing, or real law? Any advice will be sincerely appreciated. I don’t mind paying for for either, but I like the look and feel of CS-Cart better and it is cheaper.
PCI compliance is an “industry mandate”. Since Visa/MC control almost all of the credit card transactions, anything they state as a requirement is as good as it being signed into law since being rejected by them would be a business fatality. Most merchants who use cs-cart can get by with what's called “self certification”. I.e. you say you are PCI compliant. If you process less than (I think the number is) 20K transactions per year then you can self-certify according to PCI (but your merchant account provider has the final say).
However, your merchant account provider may require you to be scanned and pay some other 3rd party (or maybe themselves) to certify that you are PCI compliant beyond your self-certification.
Cs-cart is PCI compliant (as an application) though they do not conform to all credit-card industry policies (like storage of CVV code). However, the data is encrypted per PCI requirements. However, if you run without https in your checkout and profile areas (if you let users store cc data), you are NOT PCI compliant.
Your server must also be PCI compliant and this is yet another way for hosting companies to dig a little deeper into your pocket.
There is a whole industry evolving out of PCI compliance and DSS scanning/testing. They intentionally make it confusing and ambiguous so that pockets can be fleeced and control can be maintained.
Push back and ask whomever is asking you to tell you where you are NOT PCI compliant rather than trying to jump through the hoops to prove you are (beyond self-certification).
[quote name='tbirnseth' timestamp='1314141692' post='120184']
Cs-cart is PCI compliant (as an application) though they do not conform to all credit-card industry policies (like storage of CVV code). However, the data is encrypted per PCI requirements. However, if you run without https in your checkout and profile areas (if you let users store cc data), you are NOT PCI compliant.
[/quote]
I'm afraid to ask, but how is the storage of the cvv2 code not compliant? With the way we have ours set up we never see the cvv2 because as soon as the customer places the order and it is approved the cvv2 and other information is “xxxd” out. So we never see it. Is it still able to be read some how?
BTW Tony, great explanation on PCI. We've jumped through the hoops and the scan because our bank requires it. So far we have had no issues with CS or server.
Hello Clips,
[quote]I’m afraid to ask, but how is the storage of the cvv2 code not compliant? With the way we have ours set up we never see the cvv2 because as soon as the customer places the order and it is approved the cvv2 and other information is “xxxd” out. So we never see it. Is it still able to be read some how?[/quote]
There is no problem in using the Cvv2 for a single transaction, there is only a problem “if” you choose to retain & store it someplace for future transactions.
The ruling on this is very cut & dry specific in that you simply cannot store a customers cvv code “Anywhere”, not within an online database, not on a local pc, not on a piece of paper stored in your office safe…absolutely nowhere! 
We took this a step farther & unlike the good ole days, we refuse to store any of our customers credit card details period dot, don’t have it, can’t be stolen.
[quote name='Struck' timestamp='1314148130' post='120202']
We took this a step farther & unlike the good ole days, we refuse to store any of our customers credit card details period dot, don't have it, can't be stolen.
[/quote]
AMEN! This is the policy we adapted too. We figured if we did not keep, store or save any of the customers cc information it was only a win/win situation for both parties. The customer didn't get info stolen if we were hacked and likewise it lowers our liability because we don't store any crucial information on our server. Not to mention I rest a little easier.
Most customers actually appreciate this. Sometimes a customer will call to add something to their order, etc. and when we tell them we don't keep any of their cc info they usually like that.
[quote]AMEN! This is the policy we adapted too. We figured if we did not keep, store or save any of the customers cc information it was only a win/win situation for both parties. The customer didn't get info stolen if we were hacked and likewise it lowers our liability because we don't store any crucial information on our server. Not to mention I rest a little easier.
Most customers actually appreciate this. Sometimes a customer will call to add something to their order, etc. and when we tell them we don't keep any of their cc info they usually like that.[/quote]
Yeah, we occasionally get a little “attitude” from a few long time customers that are peeved that they have to ramble off their card details again, however, 99% of them appreciate the reason why after realizing the fact that it is for their protection. We micro-shred all handwritten notes from phone in orders and no longer retain cc info in our internal software programs.
Thanks for the quick replies! Special thanks to tbirnseth. I think that I'll go ahead and give CS-Cart a try.
To Simbirsk staff or anybody in the know: I was also asking about if there were any current attempts to attain this PA-DSS certification. I still don't really even know what it is or the true ramifications for not having it. But is sounds like it's worthwhile.
Regards, Robb
Robb,
Here is some food for thought:
There is a very definite reason why there is only a very small handful of carts with this Magical PA-DSS “Certification”, it is simply because the cost to obtain this is immense!
(And, I would not be surprised if the few shopping cart companies that did make this investment are not having second thoughts as to their return on investment regarding the costs involved!)
Another thing to really consider is that just because you may have a shopping cart that claims this certification, in no way does that in itself mean that your business is now automatically “PCI Compliant”, it only means that you should be closer to being compliant. Personally, I view it as more marketing fluff (and remember the world still hasn’t ended as was predicted to happen 6 months after the mandatory PCI Compliance laws were put into place!). 
Thanks, Struck! I'll jump. I've been considering a change from X-cart for a few years and I do keep coming back to cs-cart as my favorite.
On a somewhat divergent note: I'd like to find a technical consultant that is near my time zone (UTC-8 US Pacific time), Fluent in English, and available by phone–at least by appointment. I had a conversation with tbirnseth yesterday that was good. If anybody else would like to be considered, please contact me.
Regards, Robb
[quote name='robb@aquarianaudio.com' timestamp='1314291439' post='120350']
Thanks, Struck! I'll jump. I've been considering a change from X-cart for a few years and I do keep coming back to cs-cart as my favorite.
On a somewhat divergent note: I'd like to find a technical consultant that is near my time zone (UTC-8 US Pacific time), Fluent in English, and available by phone–at least by appointment. I had a conversation with tbirnseth yesterday that was good. If anybody else would like to be considered, please contact me.
Regards, Robb
[/quote]
Have you considered BCS Engineering? I'm having a call with them about PA-DSS (and X-payments) myself.
[quote name='tbirnseth' timestamp='1314141692' post='120184']However, the data is encrypted per PCI requirements.[/quote]
It looks like CS-Cart sends the crypt_key variable in config.local.php to Blowfish to create a secret key that's cached in $Registry. Then, this secret key is used to encrypt a string with Blowfish. Finally, the encrypted string is encoded via base64 and stored in the table.
Correct?
Yes
return base64_encode(Registry::get('crypt')->encrypt($text));
from fn_encrypt_text() in core/fn.common.php
Are $Registry values stored in the database, in memory, or in a file?
Registry info is cached data from a variety of sources (mostly from the DB). I.e. all the settings, language variables, block information,etc. are retrieved from the DB and then cached in the registry. Some info comes from files like config info which is setup during the initialization process from php files.