So, if you don't care about violating the terms of PCI-DSS, you can store the CVV2/CVC/whatever. I bet lots of places do. In fact, I worked for a Visa Level-1 merchant that had a card processing system that used an Oracle DB table as a queue for outgoing authorization requests. The table held the CVV2/CVC/whatever for as long as it took to get an authorization or a timeout, whichever came first. We passed the PCI audit, even though the auditors knew about it.
Given that there's only 1,000 CVV2 values (10,000 for Amex) isn't putting so much into CVV2 value a bit ridiculous? Someone who really wanted to could get a CVV2 value in only 500 auth attempts on average.
The point is that even if someone steals your order database with credit card numbers and expiration dates, they need to try every number 1000 times. That's a decent speedbump.
If you store CVV2 in your database against your merchant agreement, and someone steals it, I'm sure the credit card comp will come after you for the losses.
If you're a "Carder", and you've got 1,000 cards, you just try them once a day. You'll get 2 CVV2's a day, average. And a bet that a once-a-day wrong CVV2 doesn't trip very many, if any, fraud checks. How much more is a card worth to a carder with CVV2/CVC than one without? Another niche service to provide in the cybercriminal underground, I guess.
As far as being non-PCI compliant, you as a merchant are only compliant right at the time of the audit. And maybe not even then, given Heartland's experience. The whole PCI thing is to give Visa and MasterCard a way to do some CYA.
Not only will they be sued, but they'll no longer be able to accept credit cards. They'll most likely go out of business. It's a serious matter to be non-PCI compliant.
You'd be surprised how many vendors and merchants simply do not care. I was employed with an e-commerce vendor that indefinitely stored CVV2 in plaintext (among other numbers).
