Why is EMV card returning error code 6985 to GET PROCESSING OPTIONS command ?

When communicating with an EMV chip card, the card may reply to a command with error code SW1 SW2 = ’69 85′. In this post, we’ll analyze why this error code may be returned in response to the GET PROCESSING OPTIONS (GPO) command.

The GPO command “initiates the transaction within the ICC, as defined in EMV 4.3 book 3, section ‘6.5.8 GET PROCESSING OPTIONS Command-Response APDUs‘. Status word ‘6985’ is defined as “Command not allowed” (“conditions of use not satisfied”), in EMV 4.3 book 3, section ‘6.3.5 Coding of the Status Bytes. This often happens when the GPO command contains an invalid response to the card Processing Data Options List (PDOL). The PDOL (tag 9F38) is requested by the card in its response to the SELECT AID command. For example, a valid PDOL for an Interac Flash transaction would be : 9F 38 15 9F 59 03 9F 5A 01 9F 02 06 9F 1A 02 5F 2A 02 9F 37 04 9F 58 01 Which is parsed as :

TAG  LEN MEANING                                
9F59 03  Terminal Transaction Information       
9F5A 01  Terminal transaction Type              
9F02 06  amount, authorised                     
9F1A 02  Terminal country code                  
5F2A 02  Transaction currency code              
9F37 04  Unpredictable number                   
9F58 01  Merchant Type Indicator                

In this example, user reports that his Interac Flash card responds with error ’69 85′ to the GPO command. His GPO command is formatted as follow : 80 A8 00 00 15 83 13 00 00 99 00 00 00 00 00 00 00 01 24 01 24 00 00 01 23 00 00 The GPO command structure seems to be valid. Its length matches the one of the data requested by the card in its PDOL. But let’s take a look closer, and compare the PDOL responses values with the ones from a valid(accepted) GPO command :

TAG  LEN MEANING                                REJECTED GPO   ACCEPTED GPO
9F59 03  Terminal Transaction Information       000099         C08000
9F5A 01  Terminal transaction Type              00             00               
9F02 06  amount, authorised                     000000000000   000000001000
9F1A 02  Terminal country code                  0124           0124
5F2A 02  Transaction currency code              0124           0124
9F37 04  Unpredictable number                   00000123       823DDE7A 
9F58 01  Merchant Type Indicator                00             01

You’ll notice that :

  1. The Terminal Transaction Information seems invalid. It should be set according to the reader capabilities, and 99 doesn’t seem very valid.
  2. The amount may not be supported by the card : trying to do a 0$ purchase may not seem legitimate to the card.
  3. The merchant type indicator is invalid. Valid values range from 01 to 05 according to the Interac Flash specification.

Replacing these values with proper ones solved the issue. So, whenever a card responds to the GPO command with 6985, you should start by checking if the PDOL response is valid, both in terms of structure and values, before thinking of more unusual error sources. If you know some other common cases in which GPO may return error code ‘6985’, thanks to let me know in the comments !

9 thoughts on “Why is EMV card returning error code 6985 to GET PROCESSING OPTIONS command ?

  1. Dion

    I get the same response 6985 with CDOL1:
    [9f02]Amount, Authorised (Numeric)=000000000100
    [9f03]Amount, Other (Numeric)=000000000100
    [9f1a]Terminal Country Code=0104
    [95]Terminal Verification Results (TVR)=8000080000
    [5f2a]Transaction Currency Code=0104
    [9a]Transaction Date=140806
    [9c]Transaction Type=00
    [9f37]Unpredictable Number=00000010
    [9f35]Terminal Type=24
    [9f45]Data Authentication Code=0000
    [9f4c]ICC Dynamic Number=0000000000000000
    [9f34]Cardholder Verification (CVM) Results=1e0300
    Could you show me what was wrong

    Reply
    1. Nicolas Riousset Post author

      Hi Dion,

      without the full EMV dialog, it’s dfficult to troubleshoot the issue. For example, I don’t know when you sent your GENERATE AC command, or if your TLV list properly matches the CDOL1 requirements.
      However, the TVR tag value (80 00 08 00 00) may give some hints. TVR = 80 00 08 00 00. According to EMV 4.3 Book 3, section “C5 Terminal Verification Results”, it means :
      byte 1, bit 8 = 1 means “Offline data authentication was not performed”
      byte 3, bit 4 = 1 means “PIN entry required and PIN pad not present or not working”

      Could it be that your card rejects the transaction because no PIN verification was done before ?

      Reply
  2. knock

    Hi Nicolas,
    I want at first to thank you for this precious articles. This website has really helped me understanding how emv works.
    However I still can’t understand the 69 85 issue. I think that my APDU is will formated but I still have this response with some visa cards.
    Could you give a shot ?
    Thanks in advance

    6F : FCI Template (M).
    84 : DF Name (M).
    value : A0 00 00 00 03 10 10 (7 bytes).
    A5 : FCI Proprietary Template (M).
    50 : Application Label (O).
    value : 56 69 73 61 20 43 72 65 64 69 74 (11 bytes).
    87 : Application Priority Indicator (O).
    value : 01 (1 bytes).
    9F38 : PDOL (O).
    value : 9F 66 04 9F 02 06 9F 37 04 5F 2A 02 (12 bytes).
    5F2D : Language Preference (O).
    value : 65 6E (2 bytes).
    9F11 : Issuer Code Table Index (O).
    9F12 : Application Preferred Name (O).
    BF0C : FCI Issuer Discretionary Data (O).
    9F6E : Third Party Data (O).
    Sending GPO : 0x80 0xA8 0x00 0x00 0x12 0x83 0x10 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 0x00 0xE4 0xEC 0x9E 0x52 0x00 0x36 0x00
    Response to GPO: 69 85

    Reply
    1. Nicolas Riousset Post author

      Hi Knock,

      It seems that your GPO is invalid.
      Through the returned PDOL, the card requests the following info :
      – 9F 66 04 // Terminal Transaction Qualifier (Visa)
      – 9F 02 06 // Amount authorized
      – 9F 37 04 // unpredictable number
      – 5F 2A 02 // transaction currency code

      In your GPO, the corresponding values are :
      – TTQ : 0x83 0x10 0x80 0x00
      – Amount authorized : 0x00 0x00 0x00 0x00 0x00 0x00
      – Unpredictable number: 0x20 0x00 0xE4 0xEC
      – Currency code : 0x9E 0x52
      – an unknown value, not requested in the PDOL : 0x00 0x36

      – A 0$ transaction is unsual, and may be rejected by the card.
      – Your currency code is also unknown . I would expect one of the values listed here http://www.nationsonline.org/oneworld/currencies.htm. For example, 01 24 for Canadian Dollar.
      – The TTQ also seems invalid. As defined in Annex A Kernel 3 Data Elements of EMV Contactless 2.5 Book C-3 (https://www.emvco.com/download_agreement.aspx?id=1091). Byte 1 indicates that magstripe mode is enabled, but no EMV contact or contactless, which is inconsistent with an EMV transaction.
      – I have no idea how the unrequested value will be processed by the card. It may be ignored since it’s at the end of the list.

      I stopped working in the EMV domain a couple of years ago, so I may be wrong. Still, I hope this will help.

      Good luck.

      Reply
  3. Yury Ledentsov

    Hi Nicolas,
    very helpful site but i receive 6985 for a very strange reason.
    look at
    6F File Control Information (FCI) Template
    84 Dedicated File (DF) Name A0000000041010
    A5 File Control Information (FCI) Proprietary Template
    50 Application Label M A S T E R C A R D
    87 Application Priority Indicator 01
    5F2D Language Preference r u e n
    BF0C File Control Information (FCI) Issuer Discretionary Data
    9F4D Log Entry 0B0A
    9F6E third party data 064300003030000207083373257005372226
    There no PDOL, so
    generated GPO: 80A8000002830000
    Response to GPO: 69 85

    Reply
      1. Nicolas Riousset Post author

        Hi Yury,

        You’re right, this looks like a faulty applet.
        No PDOL is a correct situation, according to EMV Contactless Book for Kernel 2 :
        “The data field of the command message is the Command Template with tag ’83’ and with a value field coded according to the PDOL provided by the Card in the response to the SELECT command.If the PDOLis not provided by the Card, the length field of the template is set to zero.”

        Your GPO seems valid, your data field template is 83, and both length before and after it are correct.

        Sorry, but I don’t see what could be wrong.

        Good luck

        Reply
  4. Sol

    Hi Nicolas,

    Firstly thanks for the post. It’s been helpful in guiding my research into this subject. Much like Knock wrote above, I followed your guidance to the letter but i’m still having an issue with the 69 85 issue. Could you kindly check out my log below and perhaps point out where i’m gong wrong please ?

    Send: 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
    Received: 6F 20 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 0E BF 0C 0B 61 09 4F 07 A0 00 00 00 03 10 10 90 00
    Send: 00 A4 04 00 07 A0 00 00 00 03 10 10 00
    Received: 6F 4A 84 07 A0 00 00 00 03 10 10 A5 3F 50 10 56 49 53 41 20 44 45 42 49 54 20 20 20 20 20 20 87 01 02 9F 38 18 9F 66 04 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 5F 2D 02 65 6E BF 0C 07 BF 63 04 DF 20 01 80 90 00
    Send: 80 A8 00 00 15 83 13 32 20 40 00 00 00 00 00 30 00 00 00 00 00 30 08 26 00 00 00 00 00 08 26 16 10 20 00 33 8F 50 78 00
    Received: 69 85

    I decoded my PDOL to:

    9F66 04 – TTQ Terminal Transaction Qualifier -> 32 20 40 00
    9F02 06 – Amount Authorized -> 00 00 00 00 00 30
    9F03 06 – Other Amount -> 00 00 00 00 00 30
    9F1A 02 – Terminal Country Code -> 08 26
    95 05 – Terminal Verification Results – 00 00 00 00 00
    5F2A 02 – Transaction Currency Code -> 08 26
    9A 03 – Transaction Date -> 16 10 20
    9C 01 – Transaction Type -> 00
    9F37 04 – Unpredictable Number -> 33 8F 50 78

    Thanks in Advance ! and thanks again for the content so far

    Reply
    1. Nicolas Riousset Post author

      Hi Sol,

      Check the length of your GPO command. The header 80 A8 00 00 15 indicates a 21 (0x15 ) bytes data length, while the payload is indeed 34 bytes long.
      That would be a first step to solve your problem. This point aside, I’m not seeing anything wrong in the GPO content.

      Let me know if it works,

      Nicolas

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *