Cryptogram Information Data 9F27 returns AAC in second generated AC but approved from host

Question

I am new to EMV and working on a certification of domestic network. Some of the test cards returns AAC while other returns TC when logging 9F27 despite the transaction was approved from host. We suspect that the issue might be root to the tag 91 (Issuer Authentication Data) which is missing in the host response but as we checked the response of those test card where 9F27 returns TC we realized that they also have no tag 91 in it. My question is, is it safe to ignore the card decision and just follow the host response? What could be the other possible reason for such case?

Answer 1

Never ignore decision of a card. Some additional info you need to understand:

1. Type of cryptogram is highly depend on Terminal Action Code (source - Terminal) and Issuer Action code (source - Card). This two values xored and the result is used in kernel to choose cryptogram type.
2. Type of cryptograms:

• AAC - Daniel transaction cryptogram
• ARQC - Online transaction cryptogram
• TC - Offline transaction cryptogram

3. I assume under certification you mean L3 (M-TIP). If yes - read testcase objectives. Some testcase assume that successful condition to pass testcase is failed transaction.
4. It is important to check transaction limits as it's values highly depend on kernel and card decisions to approve transaction.
5. For some transaction type - particularly refund - AAC cryptogram is normal and it's not checked by authorization host.

Answer 2

No, it is not safe to ignore card decision. It is against the mandates of most payment schemes and common sense. It may mean bearing full responsibility for the transaction in case of fraud and no recourse.

Regarding test cards, are you sure they are not meant to simulate exactly the scenario when you should decline and send reversal to these transactions? Please verify with your processor, why you do not receive Issuer Authentication Data - maybe something is simply misconfigured.