Readers and terminals operate with smart cards to obtain card information and perform a transaction.
Generally, a reader interfaces with a PC for the majority of its processing requirements. A terminal is a self-contained processing device. Both readers and terminals read and write to smart cards.
This type of reader requires a physical connection to the cards, made by inserting the card into the reader. This is the most common reader type for applications such as ID and Stored Value. The card-to-reader communications is often ISO 7816 T=0 only. This communication has the advantage of direct coupling to the reader and is considered more secure. The other advantage is speed. The typical PTS Protocol Type Selection (ISO7816-3) negotiated speed can be up to 115 kilo baud. This interface enables larger data transport without the overhead of anti-collision and wireless breakdown issues that are a result from the card moving in and out of the reader antenna range.
This type of reader works with a radio frequency that communicates when the card comes close to the reader. Many contactless readers are designed specifically for Payment, Physical Access Control and Transportation applications. The dominant protocol under the ISO 14443 is MIFARE, followed by the EMV standards.
A contact reader is primarily defined by the method of it’s interface to a PC. These methods include RS232 serial ports, USB ports, PCMCIA slots, ExpressCard, Bluetooth, floppy disk slots, parallel ports, infrared IRDA ports and keyboards and keyboard wedge readers. Some readers support more than one type of card such as the tri mode insert readers from MagTek. These readers support magnetic stripe-contact and contactless read operations all in one device.
Reader & Terminal to Card Communication
All cards and readers that follow ISO 7816-3 standards have a standardized set of commands that enable communication for CPU cards.
These commands, called APDUs (Application Protocol Data Units) can be executed at a very low level, or they can be scripted into APIs which enable the user to send commands from an application to a reader.
The reader communicates with the card where the response to the request takes place.
From a technical perspective, the key is the APIs that are chosen. These layers of software can enable effective application communication with smart cards and readers from more than one manufacturer. Most terminal SDKs come with a customized API for that platform. They are typically in some form of C, C++ or C # and will have the header files included. Many smart card readers have specific drivers/APIs for memory cards. For ISO7816 processor cards the PC/SC interface is often employed, but it has limitations. This is especially important if you have both memory and microprocessor cards that can are used in the same system. Some APIs give the software designer the ability to select readers from multiple vendors.
The following are some of the function calls provided for transporting APDUs and their functions:
Proprietary Commands for specific readers and cards
Allow ISO Commands to be passed to cards using standard ISO format
Allow ISO Commands to be sent to cards using a simplified or shortcut format (As in the CardLogix Winplex® API)
The development of PC applications for readers has been simplified by the Personal Computer/Smart Card (PC/SC) standard. This standard is supported by all major operating systems. The problem with the PC/SC method is that it does not support all of the reader functions offered by each manufacturer such as LED control and card latching/locking. When just using the drivers for each reader manufacturer there is no connection the functions of the card.
The better choice is Application Programming Interfaces (API’s) that are part of readily available in Software Design Kits (SDKs) that support specific manufacturer’s card families. Check these kits for a variety of reader manufacture supported. M.O.S. T. and Smart Toolz from CardLogix is a good example of a well rounded Smart Card SDK.
Unlike readers, terminals are more similar to a self contained PC, with most featuring operating systems and development tools. Terminals are often specific to the use case such as Security, health informatics or POS (Point of sale). Connectivity in the terminals is typically via Transmission Control Protocol/Internet Protocol (TCP-IP) or GSM network. Many terminals today feature regular OS’s making deployment easier such as Datastrip with windows CE or Exadigm with Linux.