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

  • 1
    I suggest removing the word 'legal' and specifying the standard. Otherwise, this question is way off topic here. Nov 19, 2014 at 13:31
  • 2
    How do you know they store the CVV? The CVV is not required to charge a card. Nov 19, 2014 at 13:43
  • 4
    PCI-DSS is not about legality, it's about compliance with rules set forth by the credit card companies for performing transactions. Nov 19, 2014 at 14:03
  • 1
    There is no need to store the CVV or anything else if you're using a proper payment gateway. Century Business Solutions issues a token that can be accessed for future card charges by your company for the account with which it is associated. NO customer card data is stored. Nov 20, 2014 at 3:14
  • 1
    The answer to the question is Yes, if your defining pre-authorized transactions. They have to be protected to the same rigor as the rest of the PCI DSS. I also wanted to point out that from David's comment, that PCI DSS may be a compliance standard, it's a legal requirement to follow for most contracts between merchants and processors. Nov 21, 2014 at 16:06

3 Answers 3


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.)

  • I understand, but this means that booking industry is pretty much unoriented in terms of safe methodologies. Like I said in the post, you can have a CVV stored for a whole year (in advance). And PCI DSS doesn't seem to have an answer for that. Feb 3, 2015 at 21:22
  • 1
    You can store it for however long the card brand allows you to. One year is not the rule (whether that's ideal or unideal for a particular merchant or service provider.) You'll have to ask card brands, issuers, and banks to know how long you're allowed to store it pre-authorization and what other requirements are in effect. The PCI DSS explicitly doesn't have an answer because the PCI DSS doesn't cover pre-authorization data. Feb 4, 2015 at 1:19

Storing CVV is not allowed:

enter image description here

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.

  • edited the question to answer your suppositions Nov 19, 2014 at 15:40
  • 10
    By the way, any kind of cryptographic hash you make out of the CVV has only 1000 options, it's pretty easy to crack. That shouldn't be compliant either. Nov 20, 2014 at 17:09
  • Oh, about the diagram, that's false also: you can provide any false credit card and still get the reservation done. Nov 20, 2014 at 21:00
  • 1
    Please, stop upvoting this answer. I appreciate the link and print-screen (I know them), but the following information is useless for the question. Nov 20, 2014 at 21:05
  • 1
    That screenshot contradicts you somewhat. You say just "storing CVV is not allowed" but the footnote says it "must not be stored after authorization". So storing before authorization is actually not addressed. The PCI page also says "must not be stored after authorization" and further specifies it shouldn't be stored for recurring transactions. By the way for recurring transactions, PCI says CVV is not required.
    – mikato
    May 4, 2020 at 16:19

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .