3

I'm using Java code and Android NFC capabilities to communicate with contactless payment cards.

I have code which works with a bunch of Visa and MasterCards but I have run into an issue with a specific subcategory of Visa card.

Here are the steps I have taken and the issues I encountered:

  • I identify the application using PPSE
  • SELECT the application AID (A0000000031010) The File Control Info includes a PDOL which I construct
  • Send a GET PROCESSING OPTIONS

At this point I get a 6984 return code which - as far as I can see - translates to PIN Try Limit exceeded but I have not been able to see that this is a legitimate response from a GPO.

Nor would I expect to have seen this given there's been no auth attempt, and it's a contactless transaction. Does this suggest that the card has been invalidated elsewhere ?

I should note that the code I'm writing is performing minimal steps required to access Track2 data from the card, it is not trying to recreate the full EMV kernel processing.

Thanks

Dave Durbin
  • 3,562
  • 23
  • 33

3 Answers3

3

As the EMV application has a Visa AID, I would assume that it's built for contactless kernel 3. The kernel 3 specification defines that if a card returns the status code 6984 in response to the GET PROCESSING OPTIONS command, the reader should use another interface (e.g. EMV contact interface) to communicate with the card.

Michael Roland
  • 39,663
  • 10
  • 99
  • 206
  • Thanks Michael, I went back to the Kernel 3 spec and found this in a flowchart. I guess the next question(s) are: why would the card do this (it's a brand new card though it's been used for chip & pin transactions successfully) and how do I make it *not* do this (if at all possible) ? The transaction is for $1 so I don't think it's exceeded any particular threshold. – Dave Durbin May 27 '14 at 21:25
  • @DaveDurbin If the card had been used for chip & PIN (EMV over contact interface) before, I have no idea why the card would reject contactless use. My initial thought was that you have to perform one initial contact transaction to activate the card's contactless capabilities. That's for instance the case with Austrian Maestro cards when they are sent to customers to prevent contactless use while they are sent by mail. What parameters did you provide in the GPO command? – Michael Roland May 28 '14 at 04:25
  • Thanks again, your reply forced me to recheck my GPO parameters (which I thought I'd checked several times) only to discover that I was not passing the terminal country code correctly and consequently the response to the PDOL was short. I was phased by 6984 rather than 6985 which I've seen previously when stuffing up GPO. – Dave Durbin May 30 '14 at 08:15
3

I ran into the same problem you mentioned above. In my case, it's Visa Blink card.

=> 80 A8 00 00 02 83 02 00
<= 67 00
=> 80 A8 00 00 04 83 02 00 00 00
<= 69 84

I figured out that the card doesn't like short GPO command (even though the short command works fine with Mastercard). So solution is using long GPO command.

1/ Use longer GPO command with no country code:

80A8000023832180000000000000000000000000000000000000000000000000000000000000000000

2/ Use better GPO command with passing country code: 

80A80000238321A0000000000000000001000000000000084000000000000840070203008017337000

In either case (passing country code or not), it works.

Trung
  • 1,655
  • 2
  • 18
  • 26
1

I had similar issue to this one just 2 days ago. I was working on VISA contactless card that client uses, I would also get 6984 from GPO but my issue was resolved by simply sending specific country and currency code to the card.

I find it very annoying that you will get "try another interface", which basically means contact or magnet-stripe (which does work) and you have no way to get a hint that you are sending wrong currency and country code to the card for contactless. Or at least that is how it looked from my point of view.

Janko Acimovic
  • 11
  • 1