Is storing CVV compliant with PCI standards?

Question

From personal, job-related experience I know that many "Booking Engines" store the CVV info for customers' credit cards from the time a reservation is made until the time the guest leaves the hotel. For people who reserve their rooms a year in advance, that means their CVV data is in the Booking Engine for a complete year!

I'm aware of this because my duties require me to regularly interface with several providers of this service, and this allows me to have access to a multitude of customers' CVC/CVV/CVV2 codes. I have personally observed the applications' behavior of collecting the code at reservation time and retaining it until check-out.

Certain Booking Engines do limit the number of times you can look at the credit card information (I believe one in particular limited me to 5), but the information is still being passed to the Channel Manager and PMS - and I work with all three.

Of course there are certain Payment Gateways which do not require the CVV code to process a transaction. However, many of the hoteliers I work with have Payment Gateways which do.

I'm concerned that retention of this data for such a long period is against PCI-DSS standards, or other legal requirements or industry best practices. I've read answers to one question here on the topic (link below) but the issue is still a bit unclear to me with regards to how this applies for services like Booking Engines.

Storing CVC / CVV / CVV2 until payment is processed

Answer 1

Storage of sensitive authentication data is explicitly not to be stored after authorization. Pre-authorization data can be stored and is outside the realm of the PCI DSS. Individual payment card brands determine the specifics of whether it can be stored, for how long, and what must be done in the process.

The PCI SSC has made it clear that this data should be protected with the same vigor as post-authorization cardholder data like PANs. The different approach to pre-authorization vs. post-authorization is largely due to the diverse and complicated nature of pre-authorization data floating around (your physical card could be considered pre-authorization data, and there are people that literally mail their cards to make payments- although I don't know that anyone intends for cardholders to do so.)

Answer 2

Storing CVV is not allowed:

There are a few things to consider:

1. You assume booking.com is storing CVV
2. You're assuming a CVV is needed to process a transaction.

On 1) - there can be no way to confirm whether booking.com, Expedia are storing unless you work there. They would have to answer to a QSA. Now, as far as the CVV that is stored, that is CVV2 information, it's used for CNP transactions. What I can see a company doing, is perhaps making a cryptographic hash, storing the hash and making a comparison.

On 2) - again, CVV is just an additional mechanism meant to prevent fraud. It it not really needed to process a transaction.

Once a process is authorized, some credit card companies give merchants other identifiers to use for future validation. This can be read/explained via Visa's "Merchant's Best Practice for Recurring Transactions."

Had I to guess how it works:

Consumer --> (CC + CVV2) --> Merchant 
Merchant --> process this --> VISA
VISA --> all is good to go btw here is a summary [additional code] for future reference --> VISA
Merchant --> stores additional code for future reference
Consumer (months later) --> "I want to buy this" --> Merchant
Merchant --> we have data from you, and also from Visa
Merchant --> processed thank you --> Consumer

My best guess on a limited amount of reading, and or caffeine.

Answer 3

It's worth noting the acquirer does not usefully use the CVV unless there is an associated address to check against. The acquirer can disable AVS checking, which means the CVV is ignored at submission.