Most smartcard schemes involve some elements of the scheme shown in the diagram below. Very few require all of them. Click on the relevant part of the diagram for a description

The Smartcard Reader. This is arguably the most important component in the system, as it is the real-time performance of this device which directly impacts on the card user. Using our off-the-shelf hardware, we can develop scheme-specific functionality for the reader which can greatly improve the speed and efficiency of the entire system. We can also remove or reduce the reliance on a local PC from the mission-critical card reading sub-system, and enhance the security of the transaction data using end-to-end cryptography.

The Smartcard Reader PC or host system PC. It is often necessary for the smartcard reader to interface directly to a PC, to integrate the smartcard transaction into an existing back-office system. This PC is usually provided for the benefit of the operator, and requires a user-friendly and non-technical interface for smartcard operations, as well as acting as a concentrator and comms controller for transactional and control data to / from the Scheme Server .

The Smartcard Scheme server. In all applications where transaction data is required to be stored and analysed, it is necessary to develop a Transaction Server. Where the transactions have any form of monetary value (eg, epurse or loyalty points), it is also necessary to secure the transaction data using a proven cryptography system. This part of the system will usually also control the cardholder database and store ancillary data such as the hot-list and action-list.

The Administration System. This may exist on one or many PCs, and is used to provide an administration interface to the Scheme Server.  This part of the system will control access to the cardholder database and ancillary data such as the hot-list and action-list. Transaction data can also be mined to provide management reports.

The Clearing and Settlement System. This system supplies the card readers with the authority to add value to smartcards, and analyses the transaction data produced when cards are used in value-related operations. The output from this part of the system is used to provide an analysis of the monetary value of the card transactions, often with a view to reimbursing retailers or other scheme operators. It is vital that this part of the system should be secure, and that there is no possibility of transaction data being invented, amended or deleted by a third party.

The Card Production System. Whether cards are to be produced in-house or by a subcontractor, it is necessary for a system to exist which can define precisely the nature of every card required, and can log this information for future analysis. When production is in-house, the system creates print queues and drives the printer/programmer devices. When an external source is used, it is vital that this source feeds back production information, so that the exact status of every card is known to the scheme administrator.

Host Device. This is often a component which pre-dates the smartcard project, or provides necessary functionality for non-smartcard use. Examples include bus ticketing machines, vending machines, parking meters, turnstiles systems, library systems and electronic door entry controllers. These legacy devices are often not designed to be part of a smartcard scheme, and it can be necessary to interface the smartcard reader directly to these devices in a manner which emulates a supported component.

For more information, contact us at enquiries@cjstechnology.com or see the contacts page.