Technical Blog

Welcome to the ID TECH Products technical blog

Home  > Technical Blog

Kas Thomas
Posted: 30 Jan 2019

In Part I of this series, we talked about how chip-card transactions differ from magstripe. We saw that there's a considerable amount of back-and-forth communication between the reader and the card. But (good news!) we also saw that a lot of that communication is handled automatically -- which is to say, out of the control of the payment-app developer -- by the reader's EMV kernel. In Part II, we talked a bit about the various tags (or TLV data) that you can expect to get back during an EMV transaction, and what some of them mean. We also mentioned that...

Kas Thomas
Posted: 17 Dec 2018

In Part I of this post, we talked a bit about EMV transactions and how they're structured. We saw that: Unlike MSR (magstripe) transactions, an EMV transaction occurs in multiple stages. Most of the back-and-forth talk between the chip card and the reader happens at the kernel level, outside the control of application logic. Transaction results are returned in TLVs ("tags"). A cryptogram (a unique 8-byte piece of data produced by the card, using a private key known only to the card) is produced before the Completion stage of the transaction; and a second cryptogram is produced after the call...

Kas Thomas
Posted: 4 Sep 2018

ID TECH makes and markets a wide variety of payment devices, almost all of which, nowadays, are compatible with "chip cards" (or "smart cards"). Payments made with a chip card are generically referred to as "contact EMV," or sometimes just "EMV." (EMV, of course, stands for Europay, MasterCard, and Visa; the card-brand consortium.) In industry terms, an EMV transaction is one that conforms to the requirements of the four-volume EMV Integrated Circuit Card Specifications for Payment Systems (available from https://www.emvco.com/). Wrapping your head around this spec takes time. At four volumes, it's a pretty extensive specification. ID TECH tries to make...

Kas Thomas
Posted: 27 Jul 2018

Self-service or "unattended" credit card transactions are increasingly popular, not just at ATMs and gas pumps, but in a bewildering variety of other settings: pay-at-the-table terminals in restaurants,  tap-and-go public transit, airport kiosks, parking meters, vending machines, rental stations of all kinds, etc. Driven (in part) by technologies like Apple Pay and Google Pay, "self-service" has become one of the fastest growing segments of the payment industry as a whole. But note well, to succeed in unattended payments means more than just transplanting countertop credit-card acceptance technology to a kiosk enclosure. Think about it — unattended payment devices typically operate:...

Kas Thomas
Posted: 27 Jun 2018

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,...

Kas Thomas
Posted: 25 May 2018

When selecting a card reader, or before starting a Level 3 EMV certification, it's important to know what kind of EMV terminal you will be supporting. The EMV Specs define fifteen different terminal types, depending on whether the payment environment is attended (such as in traditional retail) or unattended (e.g., a self-service kiosk), and whether the terminal goes online or stays offline, plus other factors. The terminal types defined by EMV are shown in the table below, which is taken from Annex A of EMV Book 4: ID TECH offers a wide variety of EMV-ready card readers, but not all...

Kas Thomas
Posted: 26 Apr 2018

One of the nice things about choosing a credit card reader made by ID TECH is that integration of the device into a POS or payment-app environment can happen quickly and painlessly via a single Software Development Kit, which we call the Universal SDK. It's "universal" in that it exposes a common API across all supported ID TECH products, and works the same way regardless of environment. Having said that, it's important to recognize that ID TECH's Universal SDK comes in several flavors, depending on what kind of operating system you intend to deploy the device into, and the specific...

Kas Thomas
Posted: 26 Mar 2018

ID TECH makes available a number of excellent free utilities for anyone involved in developing payment apps using our products. In recent posts, I talked about Parsomatic, our free data parser (implemented as a web form), and UDemo, the Universal SDK test app that works with all of our non-legacy products (implemented in C# for Windows). I'd be remiss if I didn't also encourage you to try our Encrypt/Decrypt Tool, which you can load in your browser by clicking this link. The Encrypt/Decrypt Tool is a powerful, self-contained single-page HTML app with a native JavaScript implementation of AES encryption, Triple...

Kas Thomas
Posted: 21 Feb 2018

Payment-app developers who need to fast-track the integration of ID TECH card readers into their POS (or other) systems can make headway quickly by taking advantage of ID TECH's Universal SDK. The SDK provides libraries (and a common API) for manipulating all of ID TECH's current-production card readers, including chip-card (EMV), magstripe (MSR), and contactless readers, in a number of languages (such as C# for Windows, Java for Android, Swift for iOS, and C for Linux). You don't actually need to install the SDK, however, to run the associated demo program, a standalone app that we call the Universal Demo,...