EMV Card reading speeds with ARC35

Tagged: ARC35, Audo Jack, EMV, Speed

Viewing 5 posts - 1 through 5 (of 5 total)

Author

Posts
January 21, 2016 at 8:06 am #54256

Alex
Participant

Hi Guys,

Just a quick question that I thought you or someone on your team would be very suited to answer. When processing / reading EMV data off a card with the ARC35 or any other headphone jack based reader, I am lead to believe that the card needs to be present over the reader for up to 20 seconds as quite a bit of information needs to be exchanged with the card. Apparently the audio jack is a big bottleneck for processing this kind of data.

What experience have you guys found with this? Can you shed any light or advise here? Does the flomio firmware / SDK run into similar bottlenecks with EMV card processing?

January 21, 2016 at 11:07 am #54257

Richard
Keymaster

Hi Alex, the audio jack is a tough interface to exchange data across a high rates. The best we were able to achieve across the FloJack v1 (Kickstarter) was of the order of 100 bytes/sec. So it depends on what amount of data you’re needing to exchange in order to process an EMV transaction. A quick Forum search resulted in ACR35 Timing numbers from another customer.

Because the audio jack is plagued with pour isolation it’s data rates are slow. Bluetooth on the other hand can achieve much faster data rates. That’s why the FloBLE product line is a much more effective user experience with quick scan times when compared to the FloJack.

best,
Richard

January 21, 2016 at 6:50 pm #54258

Alex
Participant

Thanks for your reply Richard.

Based on your understanding of the number of requests and data transferred in order to read EMV data from a Visa/Mastercard, does 20 seconds sound about right?

I had a look at the thread, it’s suggesting 1 second to do a read and a write, surely obtaining card details via EMV protocol would not require 20 reads and 20 writes, or am I mistaken? Do you know approx how many steps are involved in reading a standard Visa/Mastercard?

Cheers,
Alex.

January 21, 2016 at 7:26 pm #54259
Scott
Keymaster
Hi Alex,

20 reads and writes sounds quite high based on my understanding of reading data from EMV cards.

The transaction flow would go as follows:
1) SelectPSE to get the AID (1 SELECT command)
2) SelectADF to get the FCI (1 SELECT command)
3) InitApplicationProcess to get the AIP and AFL (1 GET_PROCESSING_OPTIONS command)
4) ReadApplicationData to get the details of the card (4 or 5 READ RECORD commands)

So with 1 second for each command-response pair, it would take ~7 seconds.

The only caveat is that sometimes step 1 doesn’t return the AID (due to the card having not implementing it) and it is customary to just try many different AIDs which are specific to each Bank/Card type. Note: this is pretty rare.

-Scott
- This reply was modified 8 years, 10 months ago by Scott.
- This reply was modified 8 years, 10 months ago by Scott.
January 21, 2016 at 8:00 pm #54262

Alex
Participant

Hi Scott,

That is very helpful information. Thank you! I guess even if best case scenario was 7 seconds, that is still an excessive amount of time for a customer to have a card present in a POS situation, considering that the standard experience is less than 2 seconds followed by a beep to indicate success.

This will give me something to ponder and another problem to solve. Thanks again.
Author

Posts