In previous posts, I’ve mentioned ID TECH’s patent-pending Augusta chip-card reader, which can run an EMV transaction in as little as 2 seconds using built-in “faster EMV” support (often called Quick Chip). What makes Augusta unique (and patent-pending) isn’t just the ability to do Quick Chip transactions. The patent-pending part has to do with the fact that these transactions can be done with a USB device operating in keyboard mode. That means: You simply dip your card, and character data (representing the TLVs needed for an EMV transaction) come streaming out of the device automatically, suitable for direct consumption by, say, a browser-based virtual terminal app. No special drivers needed.

To integrate Augusta into a payment app, you don’t need any special software to “interrogate” the card reader. The reader simply outputs data automatically, upon card insertion. This mode of operation is already familiar to many users of magstripe readers (“card swipers”), where simply swiping a card causes data to flow straight into a web form. Augusta brings that same capability to payment app integrators who need to support EMV (chip card transactions). ID TECH is the only company with EMV-ready products that do this.

And now, this same capability (Quick Chip EMV in keyboard mode) is available not just in Augusta but in other ID TECH card readers, such as the 3-in-1 ViVOpay VP3300 (which can handle MSR, chip cards, and/or contactless/NFC transactions, including Apple Pay, Android Pay, Mifare, and others).

Normally, in an environment where chip cards are presented, the payment app needs to have fine control over the reader’s behavior, so that (for example) if a customer swipes a chip card instead of using the chip, the app can deny the swipe until a dip has been tried 3 times. Usually, this kind of logic (detect the MSR swipe; determine if there’s a chip on the card; deny the swipe if a chip exists; allow a swipe only after a chip dip is unsuccessful) requires a lot of back-and-forth communication between the payment app and the card reader. How is that possible if the card reader is a “keyboard device ” that outputs data automatically?

In ID TECH’s readers, fallback behavior can be controlled via configuration settings. At setup time, the integrator will specify the desired behaviors by sending the reader various TLVs (tag-length-value triplets) as “terminal settings,” in USB-HID mode. Once the reader has been configured, it can be set to keyboard mode (in a sort of “set it and forget it” manner). From that point on, fallback behaviors are automatic.

For example: You can configure the reader to check for the presence of a chip on a card using tag DFEF62. If you supply a value of 01 in this tag, the reader will automatically check the service code in the card’s track data when it’s swiped, to see if a chip exists on the card. (And it will deny any swipe attempt until the chip has been tried first.)

If you want to control the number of times the cardholder should be required to try using the chip, you can do so using tag DFEF7D. Supply a value of 03 in the TLV (DFEF7D0103) to tell the reader you intend to make cardholders try their chip a minimum of 3 times before they’re allowed to fall back to swiping.

If you want to capture detailed error codes as part of a fallback session, configure the reader with tag DFEF65 using a value of 01. The value ’01’ says to turn on detailed error reporting. Detailed error codes will appear, with each card insertion, in tag DFEF61. The two-byte error codes you might see include the following:

Code	Definition
F2 20	Insert ICC again (counter limit not reached yet)
F2 21	No matching AID; okay to fall back to MSR
F2 22	Counter limit reached

 

For a complete listing of status codes and error codes, consult the Appendices in the ID TECH Tag Reference Guide, which you can download free (and without registration) at the ID TECH Knowledge Base.

One more configuration tag you should know about is DFEF7E. Using this tag, you can specify exactly which two-byte error codes should trigger fallback behavior. (You can supply up to 32 two-byte error codes as the Value of this TLV.)

This kind of in-depth configurability eliminates the need for considerable runtime “business logic” in payment apps and makes integration of an EMV reader into a POS environment much quicker and easier than it otherwise would be. It’s one way in which ID TECH goes the extra distance to make developers’ lives easier.

Have questions about EMV? Quick Chip? USB keyboard mode? Give our experts a call: 1-800-984-1010. We’re here to help!