10 Responses to “Pre-Authorization Data”


  1. 1 Brian
    June 29, 2012 at 9:50 AM

    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.

    • June 29, 2012 at 11:44 AM

      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.

      • 3 Brian
        July 2, 2012 at 12:57 PM

        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?

      • July 2, 2012 at 6:33 PM

        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.

  2. June 26, 2012 at 11:02 AM

    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

  3. 6 Mark
    October 7, 2011 at 6:27 AM

    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

  4. March 8, 2010 at 5:23 AM

    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.

    • March 12, 2010 at 3:45 PM

      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.

  5. 9 Rafael Rosado, QSA, PA-QSA, CISSP, CISA, GCIH, NSA IAM, NSA IEM
    September 9, 2009 at 6:30 AM

    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


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

September 2009
M T W T F S S
« Aug   Oct »
 123456
78910111213
14151617181920
21222324252627
282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,846 other followers


%d bloggers like this: