Technical Blog

Welcome to the ID TECH Products technical blog

Home  > Technical Blog

ID TECH Admin
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, or UDemo (for short). You can get the UDemo (standalone version for Windows) by going here. We recommend that all of our developer-customers become familiar with the UDemo app, because it illustrates (in detail) what the raw requests and responses (to and from the device) look like, allows you to...

ID TECH Admin
Posted: 29 Jan 2018

Integrating a payment peripheral into a POS app (or other payment app) can be challenging, even under the best of circumstances. It helps to have good documentation. It helps even more to have good tools. ID TECH offers a number of free tools to make the integration process easier. One of our most popular tools, Parsomatic, is hosted on this site (go here). Another tool that gets heavy use not only by customers but by ID TECH’s internal support staff is our Encrypt/Decrypt Tool (go here). We also have a Windows-based (.NET) utility, which works with all current-production (and some older) ID TECH products, that we call UDemo (or the Universal SDK Demo). It’s available, with many other demos and utilities, on our downloads page. If you’re starting to do an integration, or you’re new to EMV and need a quick tag-lookup utility that can also parse arbitrary blocks of...

Here at ID TECH, we get a lot of technical questions about the payments business. People are sometime confused about Payment Card Industry requirements. For example, we get questions like: “Can you help me by providing a PCI DSS Certificate for these devices?” or “I don’t see X product on the PCI website, is it P2PE certified?”   These are common questions, yet these kinds of questions are sometimes motivated by faulty assumptions. If the assumption is that non-PCI-certified devices are inherently less secure than PCI-certified devices, that’s simply not the case. ID TECH can supply PCI PTS SRED certified hardware (such as the SREDKey pictured at right; or the Augusta S, Spectrum Pro, SecuRED, VP8800, or others), but our non-SRED devices are still highly secure devices that can be used for most payment solutions being developed for the market. PCI DSS is a systems solution requiring certification of all aspects of a payment system, not just the hardware device(s)....

ID TECH Admin
Posted: 05 Oct 2017

Many of ID TECH’s customers are interested in point-to-point encryption (P2PE), and as part of their quest to achieve compliance with PCI’s stringent P2PE rules, customers often consider SRED (Secure Reading and Exchange of Data) payment devices. Such devices not only encrypt data at the point of capture (as all of ID TECH’s devices are capable of doing) but also incorporate tamper detection, automatic data zeroization in the event of tamper, and other specialized security features. Chief among the “other specialized security features” is something known as MAC authentication of commands. In cryptography, a message authentication code (MAC) is a short code used to allow the receiver of a message to authenticate the message—in other words, confirm that the message came from a trusted sender. The MAC value protects both a message’s data integrity as well as its authenticity, by combining the message with a secret known to both the sender and the receiver. The message is sent in the clear, but...

ID TECH Admin
Posted: 05 Sep 2017

Checksums of various kinds are commonly used in data communication protocols to allow the recipient of a message to determine, quickly and easily, whether the data is likely to have been corrupted in transit. If you add all the bytes of a message together, and find (neglecting overflow) that the sum is 96, then you tack that number onto the message before sending it, the recipient can repeat your summation on the first N – 1 bytes of the message, and compare the result to the final byte to see if it’s 96. If so, the recipient can infer that the message probably (arguably) wasn’t altered in transit. You’ll find a wide array of checksum techniques in common use. Three of the most popular ones are the conventional checksum, LRC (longitudinal redundancy check), and CRC (cyclic redundancy check). The latter isn’t really a checksum in the usual sense, but is an example of a one-way hash that...