Nothing causes more confusion than the discussion of pre-authorization data. To add to the confusion, the PCI DSS is only relevant for post-authorization data. In fact, the PCI SSC has a special working group that is developing the standards for pre-authorization data. And if that is not enough, most people are totally unaware of the concept of pre-authorization data and yet all of us run into it every day.
The first comment I usually get regarding pre-authorization is where do I get the idea that the PCI DSS does not cover pre-authorization data? At the very first PCI Community Meeting, there was a whole hour long session devoted to pre-authorization data. It was at this session that the card brands stated that pre-authorization data was not covered by the PCI DSS. And if you read the PCI DSS, it deals only with the processing, transmission and storage or cardholder data. While all of these activities occur during the pre-authorization phase, if you really read the PCI DSS, all of the language refers to the transaction after it has been authorized. However, the current release of the PA-DSS does address pre-authorization data and its protection.
The most common example of pre-authorization data is at your local gas station or convenience store. When you go to fill up your vehicle and you use a credit card, you swipe your card before you ever pump a drop of fuel. Have you ever wondered what goes on between that card swipe and you complete filling your vehicle?
When you swipe your credit card, the track data is read and a pre-authorization transaction is sent through to the gas station’s processor for some fixed amount, typically the amount is for approximately $75, more if the station is on an Interstate highway. This is done to ensure that your credit card has enough left on its limit to pay for your fill up. Once you complete filling your tank, the pump completes the transaction by submitting the actual cost of the fuel to the processor and the transaction is completed. However, all the while that you were filling your tank with fuel, the station’s computer system has your credit card data until the transaction is completed. Until your transaction is approved or declined, the data is considered pre-authorization data.
Another example of pre-authorization data is when you check into a hotel. When you make your reservation, you provided a credit card for the hotel to guarantee your reservation. Whether through the hotel’s call center, Web site or the location itself, your credit card information is maintained on file so that you can be charged if you fail to cancel the reservation.
When you finally check in, the front desk clerk swipes your card as part of the check in process. Based on the number of nights you are staying and some other guest averages, the hotel again issues a pre-authorization transaction to their processor to make sure your credit card will be able to take care of the likely charges for your stay. All of this is considered pre-authorization. Your credit card information is not cleared from the hotel’s system until you check out. As a result, your credit card data can be in the hotel’s systems from a few weeks or months to even years.
There are other examples, but I think you have the picture. Again, while the PCI DSS currently does not address pre-authorization data, the PCI SSC and the card brands have made it abundantly clear that pre-authorization data is to be protected with the same zeal as post-authorization data. That means encrypting it and restricting access to it. The reason the PCI SSC has not issued any directives regarding pre-authorization data yet is that it is a complicated environment and cannot be dealt with in a simple manner with the same approach working for all occurrences.
So, while pre-authorization data is not covered by the PCI DSS, you must do everything you can to protect it.
PCI Guru 
How anyone can consider themselves a “Guru” and call pre-authorization card data out of scope is an atrocity. Fix your interpretation – it’s wrong. QSAs are required to follow the card from the point of interaction to destruction – there is no exception for pre-authorization data. So if you have customers storing/processing/transmitting cardholder data, even if it’s pre-authorization, it’s in-scope and must be protected in accordance with the DSS.
The PCI DSS is only concerned about the processing, storage and transmission of cardholder data post-authorization. It has been that way since the DSS was introduced and even pre-dates the DSS to the Visa CISP. With v2.0, that was slightly expanded for issuers, but not for pre-authorization data such when an airline or hotelier stores your data for a reservation or a convenience store stores your data while you pump gas.
The card brands have all indicated that pre-authorization data should be protected with the same mechanisms as post-authorization data, but it is not in scope for a PCI assessment. The only reference to pre-authorization data is from the transmission perspective when the transaction is submitted for authorization. Prior to that, the data needs to be protected, but is not in scope. We discuss it with our clients, but we do not include it with their ROC.
Page 7 of the DSS – “PCI DSS Applicability Information” – clearly states that the DSS “applies wherever account data is stored, processed, or transmitted.” I’m pretty sure you mis-placed your period in your first sentence. It should be placed after “cardholder data.” I don’t see the “post-authorization” qualifier anywhere in the DSS. Can you provide a specific reference, rather than a history lesson?
The only reference I can find to support your claim in on page 8 which implicitly claims that the magnetic stripe, CAV2/CVV2/CVC2/CID and the PIN block can be stored prior to authorization. However, someone without a background in the PCI standards would likely be confused about how to interpret the columns ‘Storage Permitted’ and ‘Render Account Data Unreadable’ as they seem to contradict the storage of pre-authorization data.
The bottom line is that pre-authorization data needs to be protected. I have submitted a question to the PCI SSC as even their venerable FAQ does not address the pre-authorization data conundrum. And one would think that if the PCI DSS covered pre-authorization data, they would have explicitly called it out or at least issued an FAQ or Information Supplement on the subject.
I came across your site and found it an excellent resource for PCI questions. This is an older post but hopefully you won’t mind a quesiton here. I would like to know if it is pci compliant to receive a pre-authorization from a web front end application and then transfer this to a fulfillment application that then uses the pre-auth to complete the sale. Of course both the pre-auth and the final transaction take place through the same gateway.
Also, we are passing only the pre-authorization code from the the front end app to the fulfillment app – no other CC information passes.
thanks so much for your help – great blog,
Tom
First off, I have to say this is an amazing resource for anyone attempting to move forward with PCI DSS. Thank you PCI Guru!
I’m doing a SAQ for a tourism company who captures CHD through a website as part of a online reservation system for accommodations (hotels, bed and breakfasts, etc). The CHD transmissions is encrypted and the CHD is stored securely. The accommodation in which the reservation was made has the ability to log in to the web system and access the reservation information (including CHD) to process locally.
So, the tourism company is only a “man in the middle” and only handles preauthorized data. I know there are definitely improvements that must take place and they will.
My question is, is this system out of scope for PCI DSS, with a strong recommendation to following PCI DSS.
Thoughts and comments would be appreciated.
Regards,
Mark
You’ve got it easy in the US as you don’t yet have EMV. This means that all of your authorizations go online.
In Europe, where we have EMV (Chip and PIN), cards can authorize themselves.
The pre-auth SIG within the PCI SSC is all well and good, but is only serving the whims of Visa US and I doubt EMV is going to get much of a say.
So, in the US it’s very easy to delineate between pre- and post-auth environments as you don’t have intelligent credit cards.
In Europe you can’t always take that approach.
EMV can have some different timings regarding when pre-authorization becomes post-authorization, but EMV in and of itself does not effect the concepts of these terms.
I had done some research a while back associated with Pre-Authorization Data storage by digging into the Operating Regulations for Visa and here is what I found:
Source: Visa USA, Inc. Operating Regulations – Volume 1 (Page 292):
5.2.K.16 Store and Forward Transactions
5.2.K.16.a A Merchant or Acquirer must attempt to obtain Authorization for a Store and Forward Transaction as soon as its link to the Single Message System is re-established.
5.2.K.16.b A Store and Forward Transaction that receives a Decline Response to an Authorization Request may be resubmitted if the Decline Response is one of the following:
• Insufficient funds (Response code “51”)
• Exceeds approval amount limit (Response code “61”)
• Exceeds withdrawal frequency limit (Response code “65”)
5.2.K.16.c Transactions resubmitted as specified in Section 5.2.K.16.b:
• Must not contain the PIN or the full contents of any track on the magnetic stripe or equivalent data from the Contactless Payment chip
• May be resubmitted once each day for up to 9 calendar days after the original Transaction Date until an Approval Response is obtained.
Source: Visa USA, Inc. Operating Regulations – Volume 1 (Page 294-295):
5.2.K.11 Preauthorized Transaction Authorization Requests
5.2.K.11.a Except as specified in Section 5.2.K.12, a Preauthorized Transaction that receives a Decline Response may be resubmitted for Authorization up to four times within 16 calendar days from the date of the original Decline Response, in an attempt to receive approval, if the Decline Response is one of the following:
• Authorization declined (Response Code “05”)
• Insufficient funds (Response code “51”)
• Exceeds approval amount limit (Response code “61”)
• Exceeds withdrawal frequency limit (Response code “65”)
5.2.K.11.b If an Approval Response is not received within the time frame specified in Section 5.2.K.11.a, the Merchant must not deposit the Transaction.
Hope this is of some benefit to you or your readers.
Rafael