Specfically, how does an EMV device talk with the card issuer?

Question

When doing an EMV online transaction (ARQC), an EMV device needs to communicate with the issuer (or gateway) to get approval/denial. I am writing POS software and need to support EMV, thus I need to support this interaction. What I can't seem to answer is, is it part of the EMV specification for the EMV device to communicate directly with the issuer, over internet? Or do I need to be looking for some sort of send function in the device's API?

I know this question could be directed at a hardware manufacturer's design, but I have read a few API's for different EMV devices and non of them seem to detail this communication. Most of them have a function to initialize the EMV capabilities (with the transaction amount) and then a callback/event when the transaction is completed. This leads me to believe that all I need to provide is a good internet connection to the device and the magic will happen.

As a followup to that, I see some devices have USB communications (instead of ethernet). These devices (obviously) couldn't talk directly to an outside network. Is it safe to assume these devices are going to do every EMV transaction offline? Or am I missing something?

Answer 1

After much research and headaches, I think I have answered my question. And it is..... Level 2 Kernel. This is the piece that I couldn't find anywhere because (i think) the whole EMV thing is so new in America. As Peter posted in his reply, EMV covers the finer details between the card and device, but only gives suggestions on delivering that data. The Kernel is the "vehicle" by which the Cryptogram (created by the card and device talking) is delivered to the card issuer for approval. Because the Kernel is (usually) a piece of software running on a computer (as a network service for example), it can house both IP communication with the pin pad or monitor a USB port.

From there I realized that I had two choices, first develop my own kernel and go through the whole pinpad integration AND EMV certification (ummm no thank you). Or second, find a company that has already done the certification and pay for use of their solution (yes please).

I found a company named CreditCall offering a product named ChipDNA which is an interface to an existing certified Level 2 Kernel. They have a Microsoft and Java integration. They have already integrated with certain keypads and handle the entire EMV online communication (end to end). They offer a lite version of their API for free, which I created a little console prog for. Worked like a champ! Cut a ton of development time off and a big [certification] cost.

....now I've got to get the accountants to "ok" the ChipDNA cost.

Answer 2

As far as I have come to understand, EMV covers the finer details of the communication between a card and the reader device, then gives the procedure/standards to be followed when delivering that data online. Thus, once you have performed the local processing of the card, you will use whichever means you can find to deliver that info to an online acquirer (assuming its an online transaction) and that communication must fulfill the EMV (and also PCI) security requirements. So Yes, you will need an Internet connection for online transactions. That part, which will "encode" the data according to financial standards and protocols and send it to a specified acquirer/issuer, will need to be created by the developer (you).