Welcome to a new year. I have had a number of interactions with a variety of people over the previous year and it has become obvious that the concepts of pre-authorization and post-authorization data is not clear to a lot of people. These two concepts are a key part of understanding PCI compliance. I will start with pre-authorization in this post and have a separate post for a discussion of post-authorization.
Pre-Authorization
Where pre-authorization (aka “pre-auth”) typically comes up is when someone asks, “How does [pick your online merchant] store a customer’s payment data and still be PCI compliant?”
Before we get to that question, we need to define what we mean by “pre-authorization”. Pre-authorization is that time when a merchant has a customer’s sensitive authentication data (SAD) or cardholder data (CHD) but has not yet processed it for payment.
For most merchants, that time between collecting the SAD/CHD and processing it is measured in seconds. For card present (CP) transactions, the SAD can be in the form of chip or magnetic stripe data. For card not present (CNP) transactions, it typically includes the cardholder name, primary account number (PAN), expiration data and CVV/CVC/CID. Regardless of transaction type, the data is sent off to either be approved or declined in seconds.
However, there are situations where that does not always happen that quickly. Mail order telephone order (MOTO) and facsimile orders are the most obvious examples that can extend the amount of time between receipt of the CHD and processing by minutes, hours or even days and weeks.
But there are some not necessarily obvious situations where processing delays occur.
My first example of delay is when you go to fill your car with fuel. When you swipe your card to pump the fuel, the system that manages the payment process will pre-authorize the purchase and then temporarily store the SAD until you finish pumping and hang up the hose to complete the transaction. When you complete the transaction at the pump, the system sends through the actual charge and securely deletes your SAD from the system. Depending on the size of your vehicle’s fuel tank and how close to empty you were, the system could have your SAD for quite a few minutes.
Another example is for the hospitality industry. In the hospitality industry, a reservation typically does not cause a charge until a customer checks out even though they are required to have a card on file to hold the reservation. When a customer checks into the property, the hotel’s billing system records the SAD and may also pre-authorize charges, but the actual card transaction is not processed until the customer checks out. As a result, hotels can have SAD on file for the length of a traveler’s stay. In fact, I have encountered SAD in hospitality systems that have been stored for more than a year due to reservations for special occasions such as graduations, birthdays, family reunions and anniversaries.
But getting back to the original question, the example that usually draws the most questions is in regards to when you, as a customer, store your card information with a merchant for future purchases. These entities store your payment information (pre-authorization) in their applications so that you or they can quickly pay for your purchases without constantly re-entering your payment information. These applications are not always part of a payment application, so they may or may not be PA-DSS validated. However, when encountering them, I use the PA-DSS standard to ensure they process, store and transmit the SAD/CHD securely. In addition, as a customer, you should have explicitly approved of the merchant storing your payment data and know how they will use that data.
Last, but not least, another great example of pre-authorization data are eWallet applications such as Google Pay and Apple Pay. eWallets are just an electronic version of a consumer’s physical wallet. eWallets are not regulated by the PCI standards or the card brands nor are they required to be PA-DSS validated. Not that these eWallet applications are not secure, it is just that there is no one independently validating that they are secure. That said, I always instruct developers of eWallet applications (or any pre-authorization applications) to follow the PA-DSS for developing a secure eWallet application.
The most confusion I encounter over pre-authorization data typically occurs regarding SAD/CHD that an organization receives via email or instant messaging. A lot of QSAs get their undies in a bunch over when this happens and point to requirement 4.2 as the reason why this is unacceptable. As a refresher, requirement 4.2 states:
“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).”
The operative word in 4.2 is “send”. Requirement 4.2 says nothing about receiving PANs by these methods. That does not mean that the Council recommends receiving PANs via email, IM or similar methods. It is only recognition of what goes on in the real world. There will always be a small percentage of people that will send their cardholder data insecurely and there is little an organization can do to stop it.
Yes, you can put a data loss prevention (DLP) solution in the middle of all of these messaging technologies and catch the bulk of the offenders. But then what?
I have some clients who have taken this approach and the DLP securely deletes the message and triggers a message back to the sender stating that they do not accept payment card information via this communication channel and then explains all of the appropriate and approved ways a customer can communicate SAD/CHD.
I have other clients that use the DLP but do not delete the message. They explain that in this one instance, they will process the transaction because they are all about the customer experience. They have a process that they follow to handle the message and then securely delete it.
To keep your email, IM and other messaging systems out of scope, the Council has told QSAs that organizations must have a policy in place that says they never encourage customers to use these messaging channels for communicating SAD/CHD and to make sure that organizations have a process to remove the SAD/CHD as soon as possible from those systems. That typically involves the printing of the message, deleting the message from the system(s) and then securely destroying the printed message once the transaction is processed. This is all considered “incidental contact” in the eyes of the Council and the QSA can then consider the system out of scope as long as they can satisfy themselves that the manual process is reliable.
The bottom line is that all of these situations involve pre-authorization data and pre-authorization data can include everything recorded on a card’s track or chip. If a merchant does store the pre-authorization data for the convenience of their customers, they are obligated under the PCI DSS to store it separately, away from post-authorization data and to protect it with the same rigor as post-authorization data, i.e., encrypted, extremely limited access, logging, monitoring, etc.
That is a key point that is often missed. Pre-authorization data must be stored separately and away from any storage of post-authorization data. That means that separate instances of databases need to be used on separate servers. The rationale for this is no different than keeping key encrypting keys (KEK) away from data encrypting keys (DEK). It is to ensure that in the event of a breach of post-authorization data, it does not readily lead to a breach of pre-authorization data. It also allows for more rigorous controls over the pre-authorization data.
One final point regarding pre-authorization data that I made earlier, but it needs to be reiterated. If a merchant intends to store pre-authorization data, I highly recommend that you have a legal agreement in place between your organization and your customers that explains why your organization is retaining this information and the business purpose(s) for which the information will be used. That can be similar to a license agreement that the user either signs or clicks “Okay” online to acknowledge their approval.
In a future post I will discuss the world of post-authorization where the PCI standards were originally focused.
PCI Guru 
Hi – I cannot see text relevant to pre-authorisation data in the NOTE section of 3.4. Am I missing something, Thanks
That is because the card brands make the rules for pre-authorization data.
Most of the discussion here is about storage of SAD but the question of PCI DSS applicability also arises with respect to transmission and processing. I am aware of an outsourced telephone payment services provider whose solution requires the call centre agent to enter the CVC before the call is handed off to the telephone service provider for input of the PAN. The call is dropped entirely from the merchant’s phone system at this point. So the merchant only ever processes CVC not PAN. My reading of PCI DSS says that the merchant’ s environment is still in scope though it’s hard to see the risk.
Yes it is in scope and for the very reason you cite. This is the problem with so called “experts” with no PCI knowledge interpreting the PCI DSS like a legal document and claiming that since it’s not explicitly defined in the PCI DSS, then it’s not enforceable.
Hi PCIGuru,
It’s difficult to combine NOTE in req. 3.4 with storing card data before authorization. REq. 3.4 is more about protecting card data which can be stored in different formats like hash, truncated and encrypted in one table or file. Having all this together it’s possible to reconstruct the real data. weak hash and truncated card number allows to do it nowadays in minutes or seconds.
Storage of card data before authorization or pre-authorization is weak point in PCI and payment brands regulations I think. PCI Card production requirement and PCI DSS req. 3.2 are relevant for issuers. Processes which you in detailed has described (pre-authorization or car fill with fuel are very good examples) are a special payment flows nothing to do with card issuing.
Formally, we can’t find limitation how long card data including sensitive data can be stored BEFORE authorization. Petrol stations can keep it up to a day (me experience), for example. It’s clear that data has to be stored in a secure way like it is described in PCI req. 3.4. But no single word that data which is stored before authorization has to be stored separately from card data which is stored after authorization. The number of data allowed to be stored is different – true. PCI doesn’t prohibit to store in the same database even in the same table records with encrypted PAN and PIN or even TRACK2 (date allowed to be stored before authorization) and encrypted PAN only after authorization is completed. We have the same encryption and the same protection and only key comprise will cause a decryption of card data. So the intent of 3.4 is a little bit different.
I don’t want do say that described situation with storage is a good example – no it’s a bad example of security. Nevertheless, PCI and especially payment brands do not put enough attention to the problematic of card storage before authorization happens, it makes a lot of confusions, especially in travel industry. Actually payment cards started from travel industry and to keep booking or reservation with card data as guarantee before the tickets actually is issued was and is a normal practice, unfortunately.
Many people (including me) and organizations would be happy to see a clear statement from payment brands/PCI about storage of sensitive card data before authorization.
I get your comment. You had to have been at the Community Meetings over the years to understand the how this concept of pre-authorization evolved over the years. The bottom line is that any storing pre-authorization data is required to protect it just like they protect post-authorization data. The only difference is what you can store pre-auth is different.
Thank you for your comment! Fully agree that pre-authorization data must be protected like post-authorization data. And you are right I had never attended Community Meetings to follow this topic directly from the Community, unfortunately.
Unfortunately, the Council shares a lot of information at Community Meetings that never goes into FAQs or other formal communications.
I find it strange that Requirement 3 is very specific on how to protect PAN, but says very little on how stored SAD should be protected. How do you interpret requirements on protecting stored SAD (where it may be stored, i.e. pre-auth or by issuers)?
Issuers get covered in a set of PCI standards specifically for them. The reason pre-auth is confusing is because of the wallet example. The Council nor the brands regulate how a consumer manages their wallet. That is the consumer’s problem. If a consumer decides to give a merchant their card data for purchasing, that is also the consumer’s prerogative. The Council nor the Card Brands want to stop a consumer from having that choice. The only thing the Council and Brands do want is the protection of that SAD if the consumer does choose to allow the merchant to have it.
Hi guru
For this discussion however, there is a posting from SSC on this https://blog.pcisecuritystandards.org/faq-can-cvc-be-stored-for-card-on-file-or-recurring-transactions
In regards to your writing
“But getting back to the original question, the example that usually draws the most questions is in regards to when you, as a customer, store your card information with a merchant for future purchases. These entities store your payment information (pre-authorization) in their applications so that you or they can quickly pay for your purchases without constantly re-entering your payment information”
I believe storing SAD for recurring purchases, or potential future purchases are not allowed under SSC per their note:
“Some service providers offer a concierge-style service, where cardholder details are retained by the provider to facilitate potential future transactions. Retention of card verification codes/values for this purpose is also prohibited under PCI DSS Requirement 3.2.”
Are we talking about the same thing here or its something I misunderstood? Hoping for clarification
These transactions (credential on file, recurring, installment, etc.) are a special class of transactions governed by the Card Brand Rules. This is permitted in certain circumstances and the conditions around their use are tightly controlled and monitored by the acquirer / Brand. The storage, retrieval, and presentation for authorization, chargeback rights and dispute resolution, and cardholder notifications and consent must be observed by the merchant. Merchants who are registered to perform recurring transactions must collect PAN / CVV for the initial transaction and provide the correct ECI and recurring payment indicator. Subsequent transactions need only provide PAN and the correct ECI. So, pre-authorization storage of SAD for recurring need not occur. Card Brands have made revisions to introduce and consolidate requirements for the use of Stored Credentials. The constraints around the use of credential on file are outlined in the Card Brand Rules ( https://www.mastercard.us/content/dam/mccom/global/documents/mastercard-rules.pdf / https://usa.visa.com/dam/VCOM/download/about-visa/visa-rules-public.pdf )
Your article didn’t touch upon Store-and-Forward (SAF) files in POS systems. This constitutes pre-auth storage of SAD, and occurs when the merchant is offline from the acquirer / processor but still wishes to process credit card transactions up to an authorized floor limit. The SAF contains full track data for the length of time the merchant is out of communication. This SAF needs to be protected commensurate with PCI DSS requirements.
Most merchants have gotten away for storing actual PAN/CVV in wallets and have their transaction processor store that information. The merchant then gets a token back that they provide to have the processor on the recurring transaction. Some processors even provide the capability of updating a card’s expiration date and CVV when it changes.
Hi PCI Guru,
In your post you mention:
“Pre-authorization data must be stored separately and away from any storage of post-authorization data. That means that separate instances of databases need to be used on separate servers.”
Can you please point us to the exact page of the PCI DSS where this is stipulated? I’m having hard time finding it.
Thank you for very useful information on this blog.
Requirement 3.4 in the NOTE.
There is nothing secret about chip or magnetic track data and PANs, they cannot be kept secret when they are legitimately possessed over their lifetime (5 years?) by so many independent entities for however short periods, as evidenced by the huge numbers of such data which we know of being breached, and the larger numbers of which we do not know about, in spite of the vast resources invested in trying to safeguard them by means of PCI.
Today, very few merchants store the PAN or even SAD because they no longer come into contact with it as they used to in the past. With the implementations of P2PE/E2EE and tokenization, merchants no longer have access to the data. The big breaches today are coming out of the financial industry who somehow believed that the PCI standards did not apply to them. They are now rapidly playing catch up but are finding that scope minimization is very elusive.
Very interesting read, and i have been battling with QSA’s about this exact fact about pre/post authorization.
However it leads my to a question, regarding the sentence:
> …they are obligated under the PCI DSS to store it separately…
I am curious as to where the requirement to store this seperately is, could you point out the specific requirement ?
Read the NOTE in requirement 3.4. That is where in the PCI DSS it is mentioned. However, there are better references on the subject in the Card Issuance requirements. The whole point is that you do not want to provide anyone a way to break the cryptography or tokenization.