-1

We are having issues with the MTIP 06 test cases, and they are all responding like this example. APDU Validations as follows:
Passed: In Read Record PAN is correct (5A)
Passed: In First GEN AC, Tag 9F02 Amount Authorized is correct
All of the rest of the steps fail:
The Card responds to Second GEN AC with TC
The first issuer script command is sent after Second GEN AC
The card responds to the first issuer script with SW=9000
The second issuer script command is sent after second GEN AC
The card responds to the second issuer script with SW=9000
The third issuer script command is sent after second GEN AC
The card responds to the third issuer script with SW=9000
The fourth issuer script command is sent after second GEN AC
The card responds to the fourth issuer script with SW=9000

Terminal Type: 25 <br/>
9F33: 6098C8<br/>
9F40: FF00F0A001<br/>
9F39: 05<br/>
TAC DF0F (Online): FE50B8F800<br/>
TAC DF0D (Default): FE50B8A000<br/><br/>

Logs are here: https://pastebin.com/LsK3sgap

Any help would be appreciated.

acodingguy
  • 1
  • 1

1 Answers1

0

It's a bit low on the details, to be honest.

Your log says you have card power off after first cryptogram generation, so nothing that happens in the terminal-card interaction after transaction went online actually could happen. Your application may close the reader way too early.

Michal Gluchowski
  • 1,197
  • 8
  • 16
  • Thank you Michal, unfortunately I work with the device at a higher level and the issues we are having apparently has to do with the configuration, which is usually completed by someone else. On top of that, the UL tool, is reading the interaction between the card and the reader, and never had to go down to this level to understand what is going on.
    The driver software has passed certifications before, but in this case, self-certifying and trying to figure out what is going on with the whole response to AC and then the failure of the script responses.     – acodingguy Aug 24 '22 at 19:46
  • Unfortunately, it is impossible to say what is wrong. Looking at timestamp difference (around ~100 ms between command response and next command) I'd assume IFD is not directly accessible to the EMV kernel - it may be remote or accessible through some more complex integration layer. The point where the communication stops is usually a decision point where authorization logic is implemented. Please check that: 1. Authorization request and responses are performed and handled 2. Kernel receives authorization result with EMV data. – Michal Gluchowski Aug 25 '22 at 05:59
  • figured it out. There was an issue with the IssuerScripts, and they were failing causing the cascade, Thanks for your assistance Michal! – acodingguy Aug 26 '22 at 15:34