18

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

Community
  • 1
Andras Gyomrey
  • 821
  • 3
  • 9
  • 17
  • 1
    I suggest removing the word 'legal' and specifying the standard. Otherwise, this question is way off topic here. – David Houde Nov 19 '14 at 13:31
  • 2
    How do you know they store the CVV? The CVV is not required to charge a card. – John Downey Nov 19 '14 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. – Lucas Kauffman Nov 19 '14 at 14:03
  • edited the question to answer your suppositions – Andras Gyomrey Nov 19 '14 at 15:41
  • 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. – Fiasco Labs Nov 20 '14 at 03:14
  • That's fantastic, and also true. But doesn't help me out here. I'm trying to respond to the question "Are these actors (pms, channel manager, ids) compliant with PCI-DDS?" – Andras Gyomrey Nov 20 '14 at 12:12
  • 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. – Shane Andrie Nov 21 '14 at 16:06
  • Thank you Shane. What I still don't get is for example Booking.com: the don't do any preauthorization and hold that data for the hotel. I'm certain of this situation. Could we still say the're compliant? – Andras Gyomrey Nov 21 '14 at 17:55
  • I can speak about booking.com as I have previous experience. They used to fax full card details of a booking direct to the hotel. This would include card number, expiry and CVV2. This would then be used by the actual hotel receiving the booking, so yes it could be stored for a year, but not necessarily by booking.com, obviously in breach of PCI. It seems they have moved over to storing the CVV2 at booking.com and a hotel now has to request a one time password to their email account to login to the booking.com system top retrieve the CVV2 code. I am unsure of the effect this would have on PCI C – Kurtis Brown Nov 19 '14 at 13:48
  • @AndrasGyomrey The implemetation of booking.com as you describe it is very problematic. The CVV should be checked immediately after entering, and not stored after that. Some (virtual) card issuers use a rotating CVV, which generates a new CVV every five minutes, and invalidates the old CVV. – Peter Bruins Feb 27 '20 at 12:44

3 Answers3

18

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.

Fiasco Labs
  • 1,557
  • 10
  • 12
munkeyoto
  • 8,682
  • 16
  • 31
  • edited the question to answer your suppositions – Andras Gyomrey Nov 19 '14 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. – Andras Gyomrey Nov 20 '14 at 17:09
  • Oh, about the diagram, that's false also: you can provide any false credit card and still get the reservation done. – Andras Gyomrey Nov 20 '14 at 21:00
  • Please, stop upvoting this answer. I appreciate the link and print-screen (I know them), but the following information is useless for the question. – Andras Gyomrey Nov 20 '14 at 21:05
  • @AndrasGyomrey a keyed hash (AKA peppered hash), especially HMAC, would be much harder to crack (assuming the key/pepper isn't stolen of course). – Ohad Schneider Aug 12 '17 at 11:08
  • How do merchants due with subscriptions or recurring charges if they don't save CVV? – Boon Jan 02 '20 at 20:46
  • 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 04 '20 at 16:19
8

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

Hamhot Ptonel
  • 136
  • 1
  • 4
  • 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. – Andras Gyomrey Feb 03 '15 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. – Hamhot Ptonel Feb 04 '15 at 01:19
2

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.

Mike
  • 21
  • 1