Integrated Circuit Card Specifications For Payment Systems: Cardholder, Attendant, and Acquirer Interface Requirements
Integrated Circuit Card Specifications For Payment Systems: Cardholder, Attendant, and Acquirer Interface Requirements
Integrated Circuit Card Specifications For Payment Systems: Cardholder, Attendant, and Acquirer Interface Requirements
Book 4
Cardholder, Attendant, and Acquirer
Interface Requirements
Version 4.0
December, 2000
© 2000 EMVCo, LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV 2000 Specifications
(“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement
between the user and EMVCo found at <http://www.emvco.com/specifications.cfm>.
These Materials and all of the content contained herein are provided "AS IS" "WHERE IS" and "WITH
ALL FAULTS" and EMVCo neither assumes nor accepts any liability for any errors or omissions
contained in these materials. EMVCO MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY
KIND, EXPRESS OR IMPLIED, WITH RESPECT TO THE MATERIALS AND INFORMATION
CONTAINED HEREIN. EMVCO SPECIFICALLY DISCLAIMS ALL REPRESENTATIONS AND
WARRANTIES, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY
QUALITY, AND FITNESS FOR A PARTICULAR PURPOSE.
EMVCo makes no representation or warranty with respect to intellectual property rights of any third
parties in or in relation to the Materials. EMVCo undertakes no responsibility of any kind to determine
whether any particular physical implementation of any part of these Materials may violate, infringe, or
otherwise use the patents, copyrights, trademarks, trade secrets, know-how, and/or other intellectual
property rights of third parties, and thus any person who implements any part of these Materials should
consult an intellectual property attorney before any such implementation. WITHOUT LIMITATION,
EMVCO SPECIFICALLY DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES WITH RESPECT
TO INTELLECTUAL PROPERTY SUBSISTING IN OR RELATING TO THESE MATERIALS OR ANY
PART THEREOF, INCLUDING BUT NOT LIMITED TO ANY AND ALL IMPLIED WARRANTIES OF
TITLE, NON-INFRINGEMENT OR SUITABILITY FOR ANY PURPOSE (WHETHER OR NOT EMVCO
HAS BEEN ADVISED, HAS REASON TO KNOW, OR IS OTHERWISE IN FACT AWARE OF ANY
INFORMATION).
Without limitiation to the foregoing, the Materials provide for the use of public key encryption
technology, which is the subject matter of patents in several countries. Any party seeking to implement
these Materials is solely responsible for determining whether their activities require a license to any
technology including, but not limited to, patents on public key encryption technology. EMVCo shall not
be liable under any theory for any party's infringement of any intellectual property rights.
December, 2000 Table of Contents i
Table of Contents
1. Scope vii
2. Normative References ix
3. Definitions x
4. Abbreviations, Notations and Terminology xii
Annexes
Annex A - Coding of Terminal Data Elements 63
A1. Terminal Type 63
A2. Terminal Capabilities 65
A3. Additional Terminal Capabilities 68
A4. CVM Results 73
A5. Issuer Script Results 73
A6. Authorisation Response Code 74
Annex B - Common Character Set 75
Annex C - Example of Data Element Conversion 77
Annex D - Informative Terminal Guidelines 81
D1. Terminal Usage 81
December, 2000 Table of Contents iii
Table of Figures
Table of Tables
1. Scope
The Cardholder, Attendant, and Acquirer Interface Requirements for Payment
Systems defines the mandatory, recommended, and optional terminal
requirements necessary to support the acceptance of integrated circuit cards
(ICCs) in accordance with the Application Independent ICC to Terminal Interface
Requirements (Book 1), the Security and Key Management (Book 2) and the
Application Specification (Book 3). Application-specific terminal requirements
unique to individual payment systems and those functions not required to
support interchange are not covered in this specification.
• Cardholder interface
• Acquirer interface
requirements for those features and functions that are applicable according to
the particular operating environment of the terminal.
2. Normative References
The following standards contain provisions that are referenced in this
specification:
3. Definitions
The following terms are used in this specification:
Application - The application protocol between the card and the terminal and
its related set of data.
Byte - 8 bits.
Command - Message sent by the terminal to the ICC that initiates an action
and solicits a response from the ICC.
0+0=0
0+1=1
1+0=1
1+1=0
Integrated Circuit(s) Cards - Card into which one or more integrated circuits
are inserted to perform processing and memory functions.
Interface Device - That part of a terminal into which the ICC is inserted,
including such mechanical and electrical devices that may be considered part of
it.
PIN Pad - Arrangement of numeric and command keys to be used for personal
identification number (PIN) entry.
Response - Message returned by the ICC to the terminal after the processing of
a command message received by the ICC.
Terminal - Device used in conjunction with the ICC at the point of transaction
to perform a financial transaction. The terminal incorporates the interface
device and may also include other components and interfaces such as host
communications.
AC Application Cryptogram
EN European Norm
IC Integrated Circuit
I/O Input/Output
NF Norme Française
PC Personal Computer
pos. Position
TC Transaction Certificate
Within this specification, online reflects online communication to acquirer (or its
agent). The acquirer is assumed to be capable of communicating to the issuer (or
its agent).
Online only - The transaction can only be completed online in real time, such as
transmitting an authorisation message.
Offline only - The transaction can only be completed offline by the terminal.
Operational control - The entity responsible for the operation of the terminal.
This does not necessarily equate to the actual owner of the terminal.
• Card data input capability - Indicates all the methods supported by the
terminal for entering the information from the card into the terminal.
4 Terminal Types and Capabilities December, 2000
Terminal
1 2 3
4 5 6
ICC 7 8 9
C 0 E
IFD
POS Device
C = ‘Cancel’
Mag. stripe E = ‘Enter’
card
Merchant Host
POS Device
1 2 3 Merchant Host
4 5 6
Public Network
7 8 9
C 0 E
Cardholder
Terminal
C = ‘Cancel’
E = ‘Enter’
Acquirer Host
2. Functional Requirements
This specification does not replicate Book 1 Application Independent ICC to
Terminal Interface Requirements, Book 2 Security and Key Management and
Book 3 Application Specification but describes the implementation issues and
the impact of these parts on the terminal.
This section uses standard messages described in section 7.2, of this specification
to illustrate the appropriate message displays for the transaction events
described below.
The usage of Authorisation Response Code, CVM Results, and Issuer Script
Results is specified in this section. See Annex A for additional information on
coding.
Sections 2.3.1 to 2.3.9 expand upon the terminal functions described in the
Application Specification.
When processing the Application Usage Control, the terminal must know
whether or not it is an ATM. See Annex A, Terminal Type, for information on
identifying an ATM.
If the PIN Try Counter is not retrievable or the GET DATA command is not
supported by the ICC, the terminal shall prompt for PIN entry.
If the value of the PIN Try Counter is zero, indicating no remaining PIN tries,
the terminal should not allow offline PIN entry. The terminal shall set the ‘PIN
Try Limit exceeded’ bit in the Terminal Verification Results to ‘1’. The terminal
shall not display any specific message regarding PINs, shall not set the CVM
Results, and shall continue cardholder verification processing in accordance with
the card’s CVM List.
If the value of the PIN Try Counter is not zero, indicating remaining PIN tries,
the terminal shall prompt for PIN entry such as by displaying the message
‘Enter PIN’.
If offline PIN verification by the ICC is successful, the terminal shall set byte 3
of the CVM Results to ‘successful’. Otherwise, the terminal shall not set the
10 Functional Requirements December, 2000
The terminal shall allow a PIN to be entered for online verification even if the
card’s PIN Try Limit is exceeded.
The terminal shall set bytes 1 and 2 of the CVM Results with the Method Code
and Condition Code of the last CVM performed.
If the last CVM performed was not considered successful (byte 3 of the CVM
Results is not set to ‘successful’ or ‘unknown’), the terminal shall set byte 3 of the
CVM Results to ‘failed’.
If no CVM was performed (no CVM List present or no CVM conditions satisfied),
the terminal shall set byte 1 of the CVM Results to ‘No CVM performed’.
1 This prevents a genuine cardholder who does not remember the PIN from having to
keep entering incorrect PINs until the PIN is blocked in order to continue with the
transaction.
December, 2000 Functional Requirements 11
When the terminal has an exception file listing cards and associated
applications, the terminal shall check the presence of the application selected
(identified by data such as the Application Primary Account Number (PAN) and
the Application PAN Sequence Number) in the exception file.
If a match is found in the exception file, the terminal shall set the ‘Card appears
in exception file’ bit in the Terminal Verification Results to ‘1’.
• If the terminal decides to accept the transaction offline, it shall set the
Authorisation Response Code to ‘Offline approved’.2
• If the terminal decides to decline the transaction offline, it shall set the
Authorisation Response Code to ‘Offline declined’.
• If the terminal decides to transmit the transaction online, it shall not set a
value for the Authorisation Response Code nor change the value for the
Authorisation Response Code returned in the response message.
• If the card indicates an approval, the terminal should display the ‘Approved’
message and shall complete the transaction.
• If the card indicates a decline, the terminal should display the ‘Declined’
message and shall decline the transaction.
2 This does not mean that the transaction will be approved. The card makes the final
decision and returns it to the terminal in its response to the first GENERATE AC
command.
12 Functional Requirements December, 2000
• When an advice is requested by the card and advices are supported by the
terminal acquirer interface protocol:
• If the card indicates ‘Service not allowed’, the terminal should display the
‘Not Accepted’ message and shall terminate the transaction.
− If the card has return a TC as indicated in the CID bit, the terminal shall
decline the transaction.
− If the card has return an ARQC as indicated in the CID bit, the terminal
shall complete the transaction processing by performing immediately a
second Generate_AC requesting for an AAC.
The result of card risk management performed by the ICC is made known to the
terminal through the return of the Cryptogram Information Data indicating
either a transaction certificate (TC) for an approval or an application
authentication cryptogram (AAC) for a decline.
When online data capture is performed by the acquirer, the terminal shall send a
reversal message if the final decision of the card is to decline a transaction for
which the Authorisation Response Code is ‘Online approved’.
December, 2000 Functional Requirements 13
The terminal shall be able to recognise the tag for the Issuer Script transmitted
in the response message. If the tag is ‘71’, the terminal shall process the script
before issuing the second GENERATE AC command. If the tag is ‘72’, the
terminal shall process the script after issuing the second GENERATE AC
command.
For each Issuer Script processed, the terminal shall report the Script Identifier
(when present) with its result in the Issuer Script Results. If an error code was
returned by the card for one of the single Script Commands, the terminal shall
set the first nibble of byte 1 of the Issuer Script Results to ‘Script processing
failed’ and the second nibble with the sequence number of the Script Command
in the order it appears in the Issuer Script. If no error code was returned by the
card, the terminal shall set the first nibble of byte 1 of the Issuer Script Results
to ‘Script processing successful’ and the second nibble to ‘0’.
The terminal shall transmit the Issuer Script Results in the batch data capture
message (financial record or offline advice), the financial transaction
confirmation message, or the reversal message. If no message is created for the
transaction (such as a decline), the terminal shall create an advice to transmit
the Issuer Script Results, if terminal supports advices.
An online-only terminal need not support all of the terminal risk management
functions. In this case, the acquirer (or its agent) should process the transaction
instead of the terminal according to Book 3 Application Specification. In other
words, the acquirer should perform the remaining terminal risk management
functions. Individual payment systems will define rules for this case.
14 Functional Requirements December, 2000
When the amounts are entered through the use of a key pad, the terminal should
allow the amount to be displayed during entry. The attendant or cardholder
should be able to either correct the amounts entered prior to authorisation and
proceed with the transaction or cancel the transaction if the amount was entered
incorrectly.
The cardholder should be able to validate the original or corrected amount when
the transaction amount is known before authorisation. If PIN entry occurs
immediately after the amounts are entered, PIN entry can act as the validation
of the amount (see Book 2 Security and Key Management). If PIN entry does not
occur immediately after the amounts are entered, the terminal should display
the ‘(Amount) OK?’ message for the cardholder to validate the amount fields.
If the authorisation takes place before the final transaction amount is known (for
example, petrol at fuel dispenser, amount before tip at restaurant), the Amount,
Authorised data object represents the estimated transaction amount and the
Transaction Amount data object represents the final transaction amount as
known at the end of the transaction.
The cardholder may have the ability to separately enter or identify a cashback
amount prior to authorisation if the terminal supports cashback and the card’s
Application Usage Control indicates that cashback is allowed for the transaction.
When cashback is allowed, the cashback amount shall be transmitted in the
Amount, Other data object. The amounts transmitted in Amount, Authorised
and Transaction Amount shall include both the purchase amount and cashback
amount (if present).
When passed to the ICC as part of the command data, the Amount, Authorised
and Amount, Other shall be expressed with implicit decimal point (for example,
‘123’ represents £1.23 when the currency code is ‘826’).
As a result of the referral process or override, the terminal shall set the
Authorisation Response Code to ‘Approved (after card-initiated referral)’ if
approved or ‘Declined (after card-initiated referral)’ if not. The terminal shall
bypass the issuance of the EXTERNAL AUTHENTICATE command and issue
the second GENERATE AC command requesting either a TC for an approval or
an AAC for a decline.
If the transaction is forced online (by the terminal or the attendant), the
terminal shall not set the Authorisation Response Code and shall transmit an
authorisation or financial transaction request message using the Application
Authorisation Referral (AAR) as an Authorisation Request Cryptogram (ARQC).
The terminal shall continue normal online processing of the transaction (see
section 2.3.8).
The terminal shall not modify the Authorisation Response Code. The terminal
shall issue the second GENERATE AC command requesting either a TC for an
approval or an AAC for a decline. If the Issuer Authentication Data is present
in the authorisation response message, the terminal may issue the EXTERNAL
AUTHENTICATE command either before or after the referral data is manually
entered.
16 Functional Requirements December, 2000
The initial value of this counter is one. When the Transaction Sequence Counter
reaches its maximum value, it shall be reset to one. A value of zero is not
allowed. (See Book 3 Application Specification for details on this data element.)
and AARs.3 (See Book 3 Application Specification for details on this data
element.)
If the terminal has a combined IC and magnetic stripe reader, when the
magnetic stripe of the card is read and the service code begins with a ‘2’ or a ‘6’
indicating that an IC is present, the terminal shall process the transaction using
the IC.
2.6.1 IC Reader
The IFD should have a pictogram near the card slot indicating how to insert the
card into the IC reader.
As soon as the card is inserted into the reader, the message ‘Please Wait’ should
be displayed to reassure the cardholder or attendant that the transaction is
being processed so that the card is not removed prematurely.
When the card is inserted into the IFD, the card should be accessible to the
cardholder at all times during the transaction. When the card is not accessible
at all times or when the terminal has a ‘tight grip’ to hold the card, there should
be a mechanism, for example, a button, to recall or release the card in case of
terminal malfunction, even if there is a power failure. For an unattended
terminal with card capture capability, where captured cards remain in the
secure housing of the terminal (such as for an ATM), the card release function is
not required.
When the card is inserted into the IFD, the cardholder or attendant should not
be able to accidentally dislodge the card from the reader.
If the card is removed from the terminal prior to completion of the transaction,
the terminal should abort the transaction and should ensure that neither the
card nor the terminal is damaged. The message ‘Processing Error’ should be
displayed. (For additional requirements on abnormal termination of transaction
processing, see Book 3 Application Specification.)
current application cryptogram and the previous exclusive-OR result, which is stored in
the terminal.
18 Functional Requirements December, 2000
an unsuccessful IC read’ if the service code on the magnetic stripe indicates that
an IC is present.4
The same rules shall be used if the terminal converts 2-digit years in format YY
to 4-digit years in format YYYY.
4 This does not imply that the terminal shall support this ISO 8583:1987 data element.
An issuer or an acquirer may define an equivalent data element. The specific code will be
set by individual payment systems.
December, 2000 Physical Characteristics 19
3. Physical Characteristics
Physical characteristics vary depending on the intended usage of the terminal,
the environment at the point of transaction (including its security), and the
terminal configuration.
A key pad may consist of a single key, such as a function key that could be a
button on a vending machine to indicate selection of an application or to indicate
that a receipt is to be printed.
A touch screen is considered to be a key pad (see Book 2 Security and Key
Management for security requirements).
The following colours, if used, shall be reserved for the command keys, either for
the lettering or for the keys themselves:
Enter Green
Cancel Red
Clear Yellow
20 Physical Characteristics December, 2000
When the command keys are horizontally arranged, the ‘Cancel’ and ‘Enter’ keys
should be located on the bottom row of the key pad, and ‘Cancel’ should be the
furthest key left and ‘Enter’ should be the furthest key right. When the
command keys are vertically arranged, ‘Cancel’ should be the uppermost key and
‘Enter’ the lowest key.
If the terminal supports PIN entry, a separate key pad may be present for PIN
entry or the same key pad may be used for both PIN entry and entry of other
transaction-related data. The PIN pad shall comprise the numeric and ‘Enter’
and ‘Cancel’ command keys. If necessary, the command key for ‘Clear’ may also
be present.
The numeric layout of the PIN pad shall comply with ISO 9564 as shown in
Figure 4, except for cardholder-controlled terminals such as personal computers
(PCs), where the keyboard may contain a numeric key pad in a different format
for PIN entry. An example of the placement of the ‘Cancel’ and ‘Enter’ keys on
the bottom row is shown in Figure 4.
1 2 3
4 5 6
7 8 9
Cancel 0 Enter
The key for ‘5’ should have a tactile identifier (for example, a notch or raised dot)
to indicate to those whose sight is impaired that this is the central key from
which all others may be deduced.
3.2 Display
A display is used to help the cardholder or attendant monitor transaction flow
and data entry, validate transaction-related data, and select options.
An attended terminal shall have a display for the attendant and may have an
additional display for the cardholder, such as when a PIN pad is present. In
order that different information may be displayed and different languages used
December, 2000 Physical Characteristics 21
When the terminal supports batch data capture, the captured transactions and
advices stored in the terminal shall not be erased or altered until the next
reconciliation with the acquiring system.
3.4 Clock
Offline-only terminals and offline terminals with online capability shall have a
clock with the local date and time.
The date is used for checking certificate expiration dates for data authentication
and/or offline PIN encipherment as well as application expiration/effective dates
for processing restrictions. The time may be used for assuring transaction
identification uniqueness as well as for input to the application cryptogram
algorithm.
3.5 Printer
A terminal should have a printer for receipt printing. If present, the printer
shall be able to print at least 20 alphanumeric characters per line (see section
7.4 of this specification).
The magnetic stripe reader shall be able to read the full track 1 and/or track 2
and process according to the payment system rules.
Part II
Software Architecture
December, 2000 Terminal Software Architecture 25
The ICC replaces this environment with cards that may have multiple diverse
applications, with significantly larger amounts of data representing a large
number of options that must be interpreted by the terminal. The typical
terminal will support multiple applications, with varying degrees of similarity.
Applications may be modified annually, presenting additional challenges to
software migration in the terminal. New applications will almost certainly be
added during the life of a terminal. There will be a need to add applications
efficiently and without risk to existing applications. Modification or addition of
applications should be done in such a way that unaffected applications need not
be re-certified. Code should be reusable and sharable with adequate security
controls to accomplish such migration with efficiency and integrity.
At the level of this specification, the payment systems view two alternative
software architectures as providing the capabilities required. These two
alternatives are called the ‘Application Program Interface (API)’ and the
‘Interpreter’ approaches.
26 Terminal Software Architecture December, 2000
Subroutines
data within the terminal or the ICC. In the case of an
Common
interpreter capability, these modules will be code, “call Y”
written in a virtual machine instruction set
implemented within the terminal, to be interpreted by
Application D
the terminal control program. In the case of the API
approach, modules will be object code written to the “call X”
The API takes the form of a library of functions that can be used by all
applications stored in the terminal. The functions in the library may be
dynamically linked into the application programs that use them.
• Each application program in the terminal does not need to include the same
code to implement standardised functionality. The implementation of only
one copy of code in each terminal to perform this functionality is very efficient
in terminal memory.
• Certification of new terminal application programs will take place against the
standardised and approved API function library for a particular terminal and
does not require the re-certification of existing terminal applications
programs (as would be the case with a single terminal program). The
verification of firewalls between application programs is considerably eased
by this architecture.
While a single library of functions is used to construct the API, the library
contains functions in two broad classes:
Functions in the library may use other functions within the library. For
example, static data authentication may use a terminal hardware function to
read data from an application on the card.
Functions in the library may be written using either terminal dependent object
code or a more general virtual machine instruction set.
4.4 Interpreter
4.4.1 Concept
The purpose of this section is to describe the general architecture underlying an
interpreter implementation and give a brief overview of how it relates to the
future environment for payment system applications.
Use of ICC technology necessitates altering the firmware in all terminals that
accept ICCs. To facilitate this transition, an interpreter may be implemented as
a software system that is compact, efficient, and easy to maintain and enhance
for future payment system needs. The name arises from the capability of a
terminal to contain central processing unit (CPU)-independent application
programs and plugs that can be interpreted during a transaction to determine
the terminal’s behaviour.
• One version of the terminal software kernel across multiple processor and
terminal types. Therefore, only one certification and validation is needed for
software libraries, terminal programs, and payment applications on the set of
terminal types supported using a common interpreter/virtual machine.
The virtual machine accesses memory in two areas: code space and data space.
All code accesses are internal to the virtual machine only and are not available
to programs; the memory fetch and store operators access data space only.
Translated program code only exists in code space. No terminal software
(libraries or other functions external to the kernel) can make any assumptions
regarding the nature or content of code space or attempt to modify code space in
any way. This restriction, plus the complete absence of a symbol table, adds
significantly to program security.
4.4.3 Kernel
A kernel contains all functions whose implementation depends upon a particular
platform (CPU and operating system). It includes a selected set of commands,
plus a number of specialised functions, such as terminal I/O support and
program loader/interpreter support.
The kernel for each particular CPU type is written to make that processor
emulate the virtual machine. The virtual machine concept makes a high degree
December, 2000 Terminal Software Architecture 29
Plugs are executable code, written in the machine language or virtual machine
instruction set supported by the terminal, that may be inserted at points defined
by sockets to enhance the default terminal logic. Plugs may already exist in the
terminal to be invoked under control of data in the ICC and logic in the terminal.
Plugs may also come from an input device (such as the ICC or a host system
connected to the terminal), but only if agreed by the payment system, issuer,
acquirer, and merchant. Special care may be required for ICC plugs if they can
modify a socket’s behaviour or be placed in the program flow prior to successful
card authentication.
The proposed terminal architecture does not propose that ICCs contain entire
applications but only plugs that enhance existing terminal applications.
Socket Socket
A B C D
Socket Socket
Plug
Library
5. Software Management
A means of software upgrade shall be supported wherever this is not in conflict
with national legal restrictions. The software upgrade may be facilitated from a
remote site over a network or locally.
• Verify the identity of the party loading the software, since only software
issued by the terminal manufacturer, owner, or a third party approved by the
owner or acquirer can be loaded in the terminal.
When both tests are successful, the terminal shall notify the party loading the
software whether the load was successfully performed or not.
To facilitate ICC application upgrade from one version to another, the terminal
should be able to support at least two versions of the ICC application, as
identified by the terminal’s Application Version Numbers.
32 Data Management December, 2000
6. Data Management
The data elements listed in this section shall be initialised in the terminal or
obtainable at the time of a transaction (definitions for these data are in Book 3
Application Specification). There may be additional data elements required for
initialisation, such as those currently used for magnetic stripe processing.
Data elements resident in the terminal shall be under the control of one of the
following parties:
• Merchant: For example, Local Date and Local Time (these may be controlled
by either the merchant or acquirer)
The terminal should be constructed in such a way that the data which is under
control of the acquirer is only initialised and updated by the acquirer (or its
agent).
• Local Date
• Local Time
The following data elements are application independent and may be specific to
each device constituting the terminal, such as a host concentrating a cluster of
devices (see Figure 2 in Part I of this specification for an example):
• Terminal Capabilities
• Terminal Type
The terminal shall have parameters initialised so that it can identify what
language(s) are supported to process the card’s Language Preference (see section
7.1 of this specification).
• Acquirer Identifier
• Default Transaction Certificate Data Object List (TDOL) (If not present, a
default TDOL with no data objects in the list shall be assumed)
• Merchant Identifier
• PIN Pad Secret Keys (required if the PIN pad and IC reader are not an
integrated tamper-evident device or if the terminal supports enciphering
PINs for online verification)7
• Terminal Identification
The terminal shall provide the necessary logical key slots to handle the active
and future replacement Certification Authority Public Keys necessary for data
authentication and/or offline PIN encipherment. Each logical key slot shall
contain the following data: RID, Certification Authority Public Key Index,
Certification Authority Public Key.
8 According to Book 3 the Application Specification, the default value consists of all bits
set to ‘0’, although ‘Data authentication was not performed’, ‘Static data authentication
failed’, and ‘Dynamic data authentication failed’ bits are strongly recommended to be set
to ‘1’ in the Terminal Action Code - Default and Terminal Action Code - Online.
December, 2000 Data Management 35
When the Certification Authority Public Key is loaded to the terminal, the
terminal shall verify the Certification Authority Public Key Check Sum to detect
a key entry or transmission error. The method for calculating this check sum is
by the terminal-supported Secure Hash Algorithm. If the verification process
fails, the terminal shall not accept the Certification Authority Public Key and, if
operator action is needed, the terminal shall display an error message. After the
Certification Authority Public Key is successfully loaded, the terminal should
store the Certification Authority Public Key Check Sum.
ISO 8859 consists of several parts, each part specifying a set of up to 191
characters coded by means of a single 8-bit byte. Each part is intended for use
for a group of languages. All parts of ISO 8859 contain a common set of 95
characters, coded between ‘20’ (hexadecimal) and ‘7E’ (hexadecimal) as shown in
Annex B. This common character set allows the terminal to display Application
Label(s) and messages in multiple languages using Latin characters without
using diacritic marks (see example in Annex B).
If a match is found, the language with the highest preference shall be used in the
messages displayed to the cardholder. Language Preference is coded so that the
language with the highest preference appears first and the lowest preference
appears last.
If no match is found and the terminal supports more than one language, the
terminal shall allow the cardholder to select the preferred language at the
beginning of the transaction. The messages shall be displayed to the cardholder
in the selected language.
If no match is found or the terminal supports only one language, the terminal
shall display messages in that language.
‘01’ - (AMOUNT)
‘03’ - APPROVED
Indicates to the cardholder and attendant that the transaction has been
approved.
When used with the ‘Enter PIN’ message, instructs the cardholder to validate
PIN entry by pressing the ‘Enter’ key or to cancel PIN entry by pressing the
‘Cancel’ key.
9 This specification does not imply that the terminal shall support a set of standard
messages in English.
December, 2000 Cardholder and Attendant Interface 41
‘07’ - DECLINED
Indicates to the cardholder and attendant that the online or offline authorisation
has not been approved.
Invites the cardholder to enter the PIN for the first and subsequent PIN tries.
An asterisk is displayed for each digit of the PIN entered.
Indicates that the PIN entered by the cardholder does not match the reference
PIN.
Instructs to insert the ICC into the IFD. Correct insertion should be noted by
displaying the message ‘Please Wait’ to reassure the cardholder or attendant
that the transaction is being processed.
Indicates to the cardholder and attendant that the application is not supported
or there is a restriction on the use of the application, for example, the card has
expired.
‘0D’ - PIN OK
Displayed to the cardholder or attendant when the card is removed before the
processing of a transaction is complete or when the transaction is aborted
because of a power failure, or the system or terminal has malfunctioned, such as
communication errors or time-outs.
42 Cardholder and Attendant Interface December, 2000
Instructs to insert ICC into the magnetic stripe reader of the terminal after IC
reading fails, when the IC and magnetic stripe readers are not combined.
A terminal supporting more than one application should offer the cardholder the
ability to select an application or confirm the selection proposed by the terminal.
Applications supported by both the ICC and the terminal shall be presented to
the cardholder in priority sequence according to the card’s Application Priority
Indicator, if present, with the highest priority listed first.
• The Application Preferred Name(s), if present and if the Issuer Code Table
Index indicating the part of ISO 8859 to use is present and supported by the
terminal (as indicated in Additional Terminal Capabilities).
A terminal not offering the cardholder the ability to select or confirm a selection
shall determine those applications supported by both the card and the terminal
that may be selected without confirmation of the cardholder according to
Application Priority Indicator, if present. The terminal shall select the
application with the highest priority from those.
If the card returns SW1 SW2 other than ‘9000’ in response to the SELECT
command indicating that the transaction cannot be performed with the selected
application:
December, 2000 Cardholder and Attendant Interface 43
If no application can be selected, the terminal should display the ‘Not Accepted’
message and shall terminate the transaction.
The application used for the transaction shall be identified on the transaction
receipt by the partial Application PAN (or the full PAN, if allowed by payment
system rules) and the AID.
7.4 Receipt
Whenever a receipt is provided, it shall contain the AID in addition to the data
required by payment system rules.10 The AID shall be printed as hexadecimal
characters.
10 The receipt may contain the partial Application PAN (or full if allowed).
44 Acquirer Interface December, 2000
8. Acquirer Interface
8.1 Message Content
Messages typically flow from the terminal to the acquirer and from the acquirer
to the issuer. Message content may vary from one link to another, with data
being added to enrich the message at the acquirer. To enrich the message, the
acquirer stores static point of transaction data elements11 based on the Merchant
Identifier and/or the Terminal Identifier. These data elements are implicitly
referred to by the Merchant/Terminal Identifier(s) and therefore may be absent
in terminal to acquirer messages.12 In the following sections, this implicit
relationship is indicated by a specific condition: ‘Present if the
Merchant/Terminal Identifier(s) do not implicitly refer to the (data element)’.
Message content may also vary due to data requested by the acquirer but not the
issuer, such as for transaction capture or audit. The ICC stored data elements
are implicitly known by the issuer13 based on the AID and/or PAN and therefore
may be absent in acquirer to issuer messages. In the following sections, this
implicit relationship is indicated by a specific condition: ‘Present if requested by
the acquirer’.
11 These data elements indicate point of transaction acceptance characteristics that rarely
change, such as Merchant Category Code, Acquirer Identifier, or Terminal Country Code.
At a minimum, all data listed in the Card Risk Management Data Object Lists and the
12
13 These data elements reflect card acceptance conditions and restrictions that rarely
Data elements marked with an asterisk are the minimum set of data elements to
be supported in authorisation request and response messages, as well as clearing
messages, for ICC transactions.
Table 1 contains the new data elements specifically created for an ICC
transaction.
Application Interchange
Profile *
Application Transaction
Counter *
ARQC *
Cryptogram Information
Data *
CVM Results
IFD Serial Number Present if Terminal Identifier does not implicitly refer to IFD
Serial Number
Terminal Capabilities
Terminal Type
Terminal Verification
Results *
Acquirer Identifier Present for Terminal Type = ‘1x’ or ‘2x’ if Merchant Identifier
or Terminal Identifier does not implicitly refer to a single
acquirer
Amount, Authorised *
Enciphered PIN Data Present if CVM performed is ‘enciphered PIN for online
verification’
Merchant Category Code Present for Terminal Type = ‘2x’ if Merchant Identifier or
Terminal Identifier does not implicitly refer to a single
merchant category
Merchant Identifier Present for Terminal Type = ‘2x’ if Terminal Identifier does not
implicitly refer to a single merchant
Terminal Identifier
Transaction Currency
Code *
Transaction Date *
Transaction Type *
Table 3 contains the new data elements created specifically for an ICC
transaction.
ARQC *
Cryptogram Information
Data *
CVM List Present if requested by acquirer
CVM Results
IFD Serial Number Present if Terminal Identifier does not implicitly refer to IFD
Serial Number
Issuer Action Code - Present if requested by acquirer
Default
Issuer Action Code - Present if requested by acquirer
Denial
Issuer Action Code - Present if requested by acquirer
Online
Issuer Application Data * Present if provided by ICC in GENERATE AC command
response
Terminal Capabilities
Terminal Type
Terminal Verification
Results *
Unpredictable Number * Present if input to application cryptogram calculation
Acquirer Identifier Present for Terminal Type = ‘1x’ or ‘2x’ if Merchant Identifier
or Terminal Identifier does not implicitly refer to a single
acquirer
Enciphered PIN Data Present if CVM performed is ‘Enciphered PIN for online
verification’.
Merchant Category Code Present for Terminal Type = ‘2x’ if Merchant Identifier or
Terminal Identifier does not implicitly refer to a single
merchant category
Merchant Identifier Present for Terminal Type = ‘2x’ if Terminal Identifier does not
implicitly refer to a single merchant
Terminal Identifier
Transaction Amount *
Transaction Currency
Code *
Transaction Date *
Transaction Type *
December, 2000 Acquirer Interface 49
Table 5 contains the new data elements specifically created for an ICC
transaction.
• Issuer Script
Template 1
• Issuer Script
Template 2
Acquirer Identifier Present for Terminal Type = ‘1x’ or ‘2x’ if in request message
Amount, Authorised
Authorisation Response
Code
Terminal Identifier
Transaction Date
Transaction Time
Table 7 contains the new data elements specifically created for an ICC
transaction.
Issuer Script Results Present if script commands to ICC are delivered by terminal
TC or AAC
Terminal Identifier
Table 9 contains the new data elements specifically created for an ICC
transaction.
Application Interchange
Profile *
Application Transaction
Counter *
Application Usage Present if requested by acquirer
Control
Cryptogram Information
Data *
CVM List Present if requested by acquirer
CVM Results
IFD Serial Number Present if Terminal Identifier does not implicitly refer to IFD
Serial Number
Issuer Action Code - Present if requested by acquirer
Default
Issuer Action Code - Present if requested by acquirer
Denial
Issuer Action Code - Present if requested by acquirer
Online
Issuer Application Data * Present if provided by ICC in GENERATE AC command
response
Issuer Script Results Present if script commands to ICC are delivered by terminal
Terminal Capabilities
Terminal Type
Terminal Verification
Results *
TC/ARQC or AAC * ARQC may be used as TC substitute
Unpredictable Number * Present if input to application cryptogram calculation
Acquirer Identifier Present if for Terminal Type = ‘1x’ or ‘2x’ Merchant Identifier
or Terminal Identifier does not implicitly refer to a single
acquirer
Application Expiration
Date
Application PAN *
Authorisation Response
Code
Merchant Category Code Present for Terminal Type = ‘2x’ if Merchant Identifier or
Terminal Identifier does not implicitly refer to a single
merchant category
Merchant Identifier Present for Terminal Type = ‘2x’ if Terminal Identifier does not
implicitly refer to a single merchant
Message Type
Terminal Identifier
Transaction Amount *
Transaction Date *
Transaction Time
Transaction Type *
8.1.6 Reconciliation
A reconciliation should convey the existing data elements necessary for ICC
transactions and subject to the specified conditions.
Acquirer Identifier Present for Terminal Type = ‘1x’ or ‘2x’ if Merchant Identifier
or Terminal Identifier does not implicitly refer to a single
acquirer
Amount, Net
Reconciliation
Merchant Identifier Present for Terminal Type = ‘2x’ if Terminal Identifier
implicitly does not refer to a single merchant
Reconciliation Currency Present if Merchant Identifier or Terminal Identifier does not
Code implicitly refer to a single transaction currency accepted at
point of transaction
Terminal Identifier
Transactions Number
(per transaction type)
Transactions Amount
(per transaction type)
Table 12 contains the new data elements specifically created for an ICC
transaction.
Application Interchange
Profile
Application Transaction
Counter
Cryptogram Information
Data
CVM Results
IFD Serial Number Present if Terminal Identifier does not implicitly refer to IFD
Serial Number
Issuer Script Results Present if script commands to ICC are delivered by terminal
Terminal Capabilities
Terminal Type
Terminal Verification
Results
TC or AAC
Acquirer Identifier Present for Terminal Type = ‘1x’ or ‘2x’ if Merchant Identifier
or Terminal Identifier does not implicitly refer to a single
acquirer
Amount, Authorised Present if final transaction amount is different from
authorised amount
Application Effective Present if in ICC
Date
Application Expiration Present if not in Track 2 Equivalent Data
Date
Application PAN Present if not in Track 2 Equivalent Data
Application PAN Present if in ICC
Sequence Number
Authorisation Response
Code
Merchant Category Code Present for Terminal Type = ‘2x’ if Merchant Identifier or
Terminal Identifier does not implicitly refer to a single
merchant category
Merchant Identifier Present for Terminal Type = ‘2x’ if Terminal Identifier does not
implicitly refer to a single merchant
POS Entry Mode
Terminal Country Code Present if Terminal Identifier or IFD Serial Number does not
implicitly refer to a single terminal country
Terminal Identifier
Track 2 Equivalent Data Present if in ICC
Transaction Amount
Transaction Date
Transaction Time Present if Terminal Type = ‘x2’, ‘x3’, ‘x5, or ‘x6’
Transaction Type
8.1.8 Reversal
A reversal should convey the data elements contained in Table 14 and Table 15
subject to the specified conditions.
Table 14 contains the new data elements specifically created for an ICC
transaction.
Application Interchange
Profile
Application Transaction
Counter
IFD Serial Number Present if Terminal Identifier does not implicitly refer to IFD
Serial Number
Issuer Script Results Present if script commands to ICC are delivered by terminal
Terminal Capabilities
Terminal Type
Terminal Verification
Results
Acquirer Identifier Present for Terminal Type = ‘1x’ or ‘2x’ if Merchant Identifier
or Terminal Identifier does not implicitly refer to a single
acquirer
Application Expiration Present if not in Track 2 Equivalent Data
Date
Application PAN Present if not in Track 2 Equivalent Data
Application PAN Present if in ICC
Sequence Number
Authorisation Response
Code
Merchant Category Code Present for Terminal Type = ‘2x’ if Merchant Identifier or
Terminal Identifier does not implicitly refer to a single
merchant category
Merchant Identifier Present for Terminal Type = ‘2x’ if Terminal Identifier does not
implicitly refer to a single merchant
Original Data Elements Present if available at terminal
POS Entry Mode
Terminal Country Code Present if Terminal Identifier or IFD Serial Number does not
implicitly refer to a single terminal country
Terminal Identifier
Track 2 Equivalent Data Present if in ICC
Transaction Amount
Transaction Date
Transaction Time Present if Terminal Type = ‘x2’, ‘x3’, ‘x5, or ‘x6’
Transaction Type
• Card action analysis via its response to the first GENERATE AC command:
Cryptogram Information Data indicates ARQC returned (see Book 3
Application Specification.)
The result of card risk management performed by the ICC is made known to the
terminal through the return of the Cryptogram Information Data indicating
either a TC for an approval or an AAC for a decline.
• Response not received or received too late (for example, network failure,
time-out)
• Request not received by the authorisation host (for example, network failure)
After repeat(s) of the authorisation request, the terminal shall process the
transaction as being unable to go online. As described in Book 3 Application
Specification, the terminal shall compare the Terminal Verification Results with
both Terminal Action Code - Default and Issuer Action Code - Default to
determine whether to accept or decline the transaction offline and shall issue the
second GENERATE AC command to the ICC indicating its decision:
The result of card risk management performed by the ICC is made known to the
terminal through the return of the Cryptogram Information Data indicating
either a TC for an approval or an AAC for a decline.
When online data capture is performed by the acquirer, the terminal shall send a
reversal message regardless of the final decision on the transaction (to ensure
that if the authorisation host received a request and sent a response, the
transaction is cancelled). If the transaction is finally approved offline (TC
returned by the ICC), the terminal shall create a financial record to be forwarded
to the acquirer.
• Script length error: The response message contains one (or more) Issuer
Script(s) whose cumulative total length is larger than the script length
supported by the network or terminal.
60 Acquirer Interface December, 2000
If either of these incidents occur, the terminal shall terminate the processing of
the Issuer Script in which the incident occurred, shall read if possible the Script
Identifier (when present) and shall report it as not performed in the Issuer
Script Results of the financial transaction confirmation or batch data capture
message. The terminal shall continue processing any subsequent Issuer Script.
Neither the terminal nor the card shall check the data indicated as RFU.
Attended
Online only 11 21 --
Offline only 13 23 --
Unattended
Online only 14 24 34
Offline only 16 26 36
Terminal Types ‘14’, ‘15’, and ‘16’ with cash disbursement capability (Additional
Terminal Capabilities, byte 1, ‘cash’ bit = ‘1’) are considered to be ATMs. All
other Terminal Types are not considered to be ATMs.
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x 1 x x x x x x Magnetic stripe
x x 1 x x x x x IC with contacts
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x 1 x x x x x Signature (paper)
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x 1 x x x x x x Dynamic data
authentication
x x 1 x x x x x Card capture
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Cash
x 1 x x x x x x Goods
x x 1 x x x x x Services
x x x 1 x x x x Cashback
x x x x 1 x x x Inquiry15
x x x x x 1 x x Transfer16
x x x x x x 1 x Payment17
x x x x x x x 1 Administrative
15 For the purpose of this specification, an inquiry is a request for information about one
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 x x x x x x x RFU
x 0 x x x x x x RFU
x x 0 x x x x x RFU
x x x 0 x x x x RFU
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Numeric keys
x x 1 x x x x x Command keys
x x x 1 x x x x Function keys
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 0 x RFU
x x x x x x x 0 RFU
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Print, attendant
x 1 x x x x x x Print, cardholder
x x 1 x x x x x Display, attendant
x x x 1 x x x x Display, cardholder
x x x x 0 x x x RFU
x x x x x 0 x x RFU
x x x x x x 1 x Code table 10
x x x x x x x 1 Code table 9
The code table number refers to the corresponding part of ISO 8859.
18 If the terminal is attended (Terminal Type = ‘x1’, ‘x2’, or ‘x3’) and there is only one
printer, the ‘Print, attendant’ bit shall be set to ‘1’ and the ‘Print, cardholder’ bit shall be
set to ‘0’.
If the terminal is attended and there is only one display, the ‘Display, attendant’ bit shall
be set to ‘1’ and the ‘Display, cardholder’ bit shall be set to ‘0’.
If the terminal is unattended (Terminal Type = ‘x4’, ‘x5’, or ‘x6’), the ‘Print, attendant’ and
‘Display, attendant’ bits shall be set to ‘0’.
72 Annex A -Coding of Terminal Data Elements December, 2000
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Code table 8
x 1 x x x x x x Code table 7
x x 1 x x x x x Code table 6
x x x 1 x x x x Code table 5
x x x x 1 x x x Code table 4
x x x x x 1 x x Code table 3
x x x x x x 1 x Code table 2
x x x x x x x 1 Code table 1
Last CVM of the CVM List actually performed by the terminal: One-byte
CVM Code of the CVM List as defined in Book 3 Application Specification
(‘3F’ if no CVM is performed)
Bytes 1-5 are repeated for each Issuer Script processed by the terminal.
74 Annex A -Coding of Terminal Data Elements December, 2000
• Online approved
• Online declined
• Capture card
In addition, the terminal shall be able to generate and transmit to the card the
following new response codes when transactions are not authorised online:
Offline approved Y1
Offline declined Z1
The terminal shall never modify the Authorisation Response Code returned in
the response message19.
19 The card’s final decision is reflected in the Cryptogram Information Data and not in the
b8 0 0 0 0 0 0 0 0
b7 0 0 0 0 1 1 1 1
b6 0 0 1 1 0 0 1 1
b5 0 1 0 1 0 1 0 1
b4 b3 b2 b1 00 01 02 03 04 05 06 07
0 0 0 0 00 SP 0 @ P ‘ p
0 0 0 1 01 ! 1 A Q a q
0 0 1 0 02 “ 2 B R b r
0 0 1 1 03 # 3 C S c s
0 1 0 0 04 $ 4 D T d t
0 1 0 1 05 % 5 E U e u
0 1 1 0 06 & 6 F V f v
0 1 1 1 07 ‘ 7 G W g w
1 0 0 0 08 ( 8 H X h x
1 0 0 1 09 ) 9 I Y i y
1 0 1 0 10 * : J Z j z
1 0 1 1 11 + ; K [ k {
1 1 0 0 12 , < L \ l |
1 1 0 1 13 - = M ] m }
1 1 1 0 14 . > N ^ n ~
1 1 1 1 15 / ? O _ o
The following is an example of the use of the common character set to display the
‘Approved’ message in French without supporting the part of ISO 8859 that allows the
relevant diacritic marks to be displayed.
76 Annex B - Common Character Set December, 2000
If the terminal supports Part 1 of ISO 8859 (the Latin 1 alphabet) and supports the
display of the standard messages in French, when a card indicates in its Language
Preference that French is the preferred language, the terminal can display the
‘Approved’ message as ‘Accepté’, using the appropriate diacritic marks.
If the terminal does not support Part 1 of ISO 8859 (the Latin alphabet) but supports
Part 8 (the Hebrew alphabet), the terminal is still able to support the display of the
standard messages in French by using the common character set. When a card
indicates in its Language Preference that French is the preferred language, the
terminal can display the ‘Approved’ message as ‘Accepte’, without the use of diacritic
marks. The cardholder should be able to comprehend the message.
December, 2000 Annex C - Example of Data Element Conversion 77
• The data transmitted in messages as defined in ISO 8583:1987 and bit 55 from ISO
8583:1993
This does not imply that ISO 8583 is required as the message standard.
30 Amount, Original
Transaction (batch data
capture, financial
transaction)
43 CAD Acceptor
Name/Location (if
terminal/acquirer countries
are different)
The guidelines have been documented in industry standards established in Europe and
the United States (see Annex D5 for informative references).
For portable terminals, the battery caters for the support of the necessary terminal
functions (see the Application Independent ICC to Terminal Interface Requirements –
Book 1 for power/current requirements).
• When operated as outdoor terminals, can resist the temperature ranges commonly
encountered.
82 Annex D - Informative Terminal Guidelines December, 2000
D4. Display
To cater for the visually disabled people, characters on the display are visible in all
lighting conditions (bright overhead or dim diffuse light) and the size of the characters
is large enough to be read from a distance of 1 meter.
Physical:
IC reader Yes
Functional:
Card capture No
The coding of the Terminal-Related Data for this example is the following:
Physical:
IC reader Yes
Functional:
Offline capable No
The coding of the Terminal-Related Data for this example is the following:
December 2000 Annex E - Examples of Terminals 87
Physical:
Display No
Printer No
IC reader Yes
Functional:
Language selection No
Cardholder verification No
Card capture No
Online capable No
The coding of the Terminal-Related Data for this example is the following: