EMV v4.3 Book 4 Other Interfaces 20120607062305603-1 PDF
EMV v4.3 Book 4 Other Interfaces 20120607062305603-1 PDF
EMV v4.3 Book 4 Other Interfaces 20120607062305603-1 PDF
Book 4
Cardholder, Attendant, and Acquirer
Interface Requirements
Version 4.3
November 2011
EMV
Book 4
Cardholder, Attendant, and Acquirer
Interface Requirements
Version 4.3
November 2011
EMV is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The
EMV trademark is owned by EMVCo.
Page ii
November 2011
November 2011
Page iii
Contents
Part I - General
1
Scope
1.1
1.2
1.3
1.4
3
3
3
5
5
Normative References
Definitions
11
21
4.1
4.2
4.3
4.4
Abbreviations
Notations
Data Element Format Conventions
Terminology
21
29
31
33
Terminal Types
Terminal Capabilities
Terminal Configurations
Functional Requirements
6.1
Application Independent ICC to Terminal Interface Requirements
6.2
Security and Key Management
6.3
Application Specification
6.3.1
Initiate Application Processing
6.3.2
Offline Data Authentication
6.3.3
Processing Restrictions
6.3.4
Cardholder Verification Processing
6.3.5
Terminal Risk Management
6.3.6
Terminal Action Analysis
6.3.7
Card Action Analysis
6.3.8
Online Processing
6.3.9
Issuer-to-Card Script Processing
6.4
Conditions for Support of Functions
6.5
Other Functional Requirements
November 2011
37
37
38
39
43
43
43
43
44
44
45
45
51
51
52
53
53
54
55
Page v
6.5.1
Amount Entry and Management
6.5.2
Voice Referrals
6.5.3
Transaction Forced Online
6.5.4
Transaction Forced Acceptance
6.5.5
Transaction Sequence Counter
6.5.6
Unpredictable Number
6.6
Card Reading
6.6.1
IC Reader
6.6.2
Exception Handling
6.7
Date Management
6.7.1
Data Authentication
6.7.2
Processing Restrictions
6.7.3
Date Management
7
Physical Characteristics
7.1
Keypad
7.1.1
Command Keys
7.1.2
PIN Pad
7.2
Display
7.3
Memory Protection
7.4
Clock
7.5
Printer
7.6
Magnetic Stripe Reader
55
55
56
56
57
57
57
58
58
59
59
59
59
61
61
62
63
64
64
64
65
65
69
69
70
71
72
72
73
73
73
74
Software Management
77
10
Data Management
79
Page vi
79
80
November 2011
80
81
11.1
11.2
11.3
11.4
12
Language Selection
Standard Messages
Application Selection
Receipt
Acquirer Interface
87
87
88
91
92
93
93
95
97
99
100
101
103
104
106
108
108
109
110
111
111
Part V - Annexes
Annex A
A1
A2
A3
A4
A5
A6
November 2011
115
115
116
118
121
121
122
Page vii
Annex B
123
Annex C
125
Annex D
129
D1
Terminal Usage
D2
Power Supply
D2.1
External Power Supply
D2.2
Battery Requirements
D3
Keypad
D4
Display
D5
Informative References
Annex E
E1
E2
E3
Index
Page viii
Examples of Terminals
Example 1 - POS Terminal or Electronic Cash Register
Example 2 - ATM
Example 3 - Vending Machine
129
129
129
129
130
130
130
133
134
135
136
137
November 2011
Tables
Table 1: Terms Describing Terminal Types
37
Table 2: Setting of CVM Results, TVR bits and TSI bits following CVM
Processing
49
Table 3: Card Action Analysis
52
Table 4: Key Types
61
Table 5: Command Keys
62
Table 6: Command Key Colours
62
Table 7: Application Dependent Data Elements
81
Table 8: Standard Messages
89
Table 9: ICC-specific Authorisation Request Data Elements
95
Table 10: Existing Authorisation Request Data Elements
96
Table 11: ICC-specific Financial Transaction Request Data Elements
97
Table 12: Existing Financial Transaction Request Data Elements
98
Table 13: ICC-specific Authorisation or Financial Transaction Response Data
Elements
99
Table 14: Existing Authorisation or Financial Transaction Response Data
Elements
99
Table 15: ICC-specific Financial Transaction Confirmation Data Elements 100
Table 16: Existing Financial Transaction Confirmation Data Elements
100
Table 17: ICC-specific Batch Data Capture Data Elements
101
Table 18: Existing Batch Data Capture Data Elements
102
Table 19: Existing Reconciliation Data Elements
103
Table 20: ICC-specific Online Advice Data Elements
104
Table 21: Existing Online Advice Data Elements
105
Table 22: ICC-specific Reversal Data Elements
106
Table 23: Existing Reversal Data Elements
107
Annexes
Table 24:
Table 25:
Table 26:
Table 27:
Table 28:
Table 29:
Table 30:
Table 31:
Table 32:
Table 33:
Table 34:
Table 35:
Terminal Type
Terminal Capabilities Byte 1 - Card Data Input Capability
Terminal Capabilities Byte 2 - CVM Capability
Terminal Capabilities Byte 3 - Security Capability
Addl Term. Capabilities Byte 1 - Transaction Type Capability
Addl Term. Capabilities Byte 2 - Transaction Type Capability
Addl Term. Capabilities Byte 3 - Terminal Data Input Capability
Addl Term. Capabilities Byte 4 - Term. Data Output Capability
Addl Term. Capabilities Byte 5 - Term. Data Output Capability
CVM Results
Issuer Script Results
Authorisation Response Codes
115
116
117
117
118
119
119
120
120
121
121
122
123
125
November 2011
Page ix
Page x
134
135
136
November 2011
Figures
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
November 2011
39
40
41
63
70
75
Page xi
Part I
General
November 2011
Page 1
Scope
This document, the Integrated Circuit Card Specifications for Payment Systems Book 4, 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 other documents of the Integrated Circuit Card
Specifications for Payment Systems, all available on http://www.emvco.com:
Book 1 - Application Independent ICC to Terminal Interface Requirements
Book 2 - Security and Key Management
Book 3 - Application Specification
1.2 Structure
Book 4 consists of the following parts:
Part I
General
Part II
General Requirements
Part III
Software Architecture
Part IV
Part V
Annexes
November 2011
Page 3
1 Scope
1.2 Structure
Page 4
November 2011
1 Scope
1.3 Underlying Standards
1.4 Audience
This specification is intended for use by manufacturers of ICCs and terminals,
system designers in payment systems, and financial institution staff responsible
for implementing financial applications in ICCs.
November 2011
Page 5
Normative References
ISO 3166
ISO 4217
ISO/IEC 7811-1
ISO/IEC 7811-3
ISO/IEC 7813
ISO/IEC 7816-1
ISO/IEC 7816-2
ISO/IEC 7816-3
November 2011
Page 7
2 Normative References
ISO/IEC 7816-4
ISO/IEC 7816-5
ISO/IEC 7816-6
ISO 8583:1987
ISO 8583:1993
ISO/IEC 8825-1
ISO/IEC 8859
ISO 9362
ISO 9564-1:2011
ISO/IEC 9796-2:2010
ISO/IEC 9797-1:2011
ISO/IEC 10116
ISO/IEC 10118-3
Page 8
November 2011
2 Normative References
ISO/IEC 10373
ISO 13491-1
ISO 13616
ISO 16609
ISO/IEC 18031
ISO/IEC 18033-3
November 2011
Page 9
Definitions
The following terms are used in one or more books of these specifications.
Accelerated
Revocation
Application
Application
Authentication
Cryptogram
Application
Cryptogram
Authorisation
Request Cryptogram
Authorisation
Response
Cryptogram
Asymmetric
Cryptographic
Technique
Authentication
Block
Byte
8 bits.
November 2011
Page 11
3 Definitions
Card
Certificate
Certification
Authority
Ciphertext
Enciphered information.
Cold Reset
Combined
DDA/Application
Cryptogram
Generation
Command
Compromise
Concatenation
Contact
Cryptogram
Page 12
November 2011
3 Definitions
Cryptographic
Algorithm
Data Integrity
Deactivation
Sequence
Decipherment
Digital Signature
Dynamic Data
Authentication
Embossing
Encipherment
Epilogue Field
Exclusive-OR
Financial
Transaction
Function
November 2011
Page 13
3 Definitions
Guardtime
Hash Function
Hash Result
Inactive
Integrated Circuit
Module
Integrated Circuit(s)
Integrated Circuit(s)
Card
Interface Device
Page 14
November 2011
3 Definitions
Kernel
Key
Key Introduction
Key Replacement
Key Revocation
Key Withdrawal
Keypad
November 2011
Page 15
3 Definitions
Library
Logical Compromise
Magnetic Stripe
Message
Message
Authentication Code
Nibble
Padding
Path
Payment System
Environment
Physical Compromise
PIN Pad
Plaintext
Unenciphered information.
Planned Revocation
Page 16
November 2011
3 Definitions
Potential
Compromise
Private Key
Prologue Field
Public Key
Public Key
Certificate
Response
Script
Secret Key
Signal Amplitude
Signal Perturbations
Socket
November 2011
Page 17
3 Definitions
State H
State L
Static Data
Authentication
Symmetric
Cryptographic
Technique
T=0
T=1
Template
Terminal
Terminate Card
Session
Terminate
Transaction
Page 18
November 2011
3 Definitions
Transaction
Transaction
Certificate
Virtual Machine
Warm Reset
November 2011
Page 19
4.1
Microampere
Micrometre
Microsecond
AAC
AC
Application Cryptogram
ACK
Acknowledgment
ADF
AEF
AFL
AID
Application Identifier
AIP
an
ans
APDU
API
ARC
ARPC
ARQC
ASI
ASN
November 2011
Page 21
ATC
ATM
ATR
Answer to Reset
AUC
BCD
BER
BIC
BGT
Block Guardtime
BWI
BWT
Celsius or Centigrade
CAD
C-APDU
Command APDU
CBC
CCD
CCI
CDA
CDOL
CID
CIN
Input Capacitance
CLA
CLK
Clock
cn
CPU
CRL
CSU
C-TPDU
Command TPDU
Page 22
November 2011
CV
Cryptogram Version
CVM
CVR
CV Rule
CWI
CWT
DAD
DC
Direct Current
DDA
DDF
DDOL
DES
DF
Dedicated File
DIR
Directory
DOL
ECB
EDC
EF
Elementary File
EN
European Norm
etu
Frequency
FC
Format Code
FCI
GND
Ground
GP
Hex
Hexadecimal
HHMMSS
November 2011
Page 23
I/O
Input/Output
IAC
IAD
IBAN
I-block
Information Block
IC
Integrated Circuit
ICC
ICC
IEC
IFD
Interface Device
IFS
IFSC
IFSD
IFSI
IIN
IK
INF
Information Field
INS
IOH
IOL
ISO
IV
KM
Master Key
KS
Session Key
Length
l.s.
Least Significant
Lc
Page 24
November 2011
LCOL
LDD
Le
LEN
Length
Licc
Lr
LRC
Mandatory
Milliohm
m.s.
Most Significant
m/s
mA
Milliampere
MAC
max.
Maximum
MF
Master File
MHz
Megahertz
min.
Minimum
MK
mm
Millimetre
MMDD
Month, Day
MMYY
Month, Year
Newton
NAD
Node Address
NAK
Negative Acknowledgment
nAs
Nanoamperesecond
November 2011
Page 25
NCA
NF
Norme Franaise
NI
NIC
NIST
NPE
ns
Nanosecond
Optional
O/S
Operating System
P1
Parameter 1
P2
Parameter 2
P3
Parameter 3
PAN
PC
Personal Computer
PCA
PCB
PDOL
pF
Picofarad
PI
PIC
PIN
PIX
POS
Point of Service
pos.
Position
PSE
PTS
Page 26
November 2011
R-APDU
Response APDU
R-block
RFU
RID
RSA
RST
Reset
SAD
S-block
Supervisory Block
SCA
SDA
SFI
SHA-1
SI
SIC
SK
SW1
SW2
TAC
TAL
TC
Transaction Certificate
TCK
Check Character
TDOL
tF
TLV
TPDU
tR
TS
Initial Character
November 2011
Page 27
TSI
TTL
TVR
UCOL
UL
Volt
var.
VCC
VCC
Supply Voltage
VIH
VIL
VOH
VOL
VPP
Programming Voltage
VPP
WI
WTX
WWT
YYMM
Year, Month
YYMMDD
Page 28
November 2011
4.2
Notations
16 hexadecimal characters
xx
Any value
A := B
A=B
A B mod n
A mod n
A/n
Y := ALG(K)[X]
X = ALG1(K)[Y]
Y := Sign (SK)[X]
X = Recover(PK)[Y]
C := (A || B)
November 2011
Page 29
Leftmost
Rightmost
H := Hash[MSG]
XY
Page 30
November 2011
4.3
an
ans
cn
November 2011
Page 31
var.
Page 32
Variable data elements are variable length and may contain any bit
combination. Additional information on the formats of specific variable
data elements is available elsewhere.
November 2011
4.4
Terminology
proprietary
shall
should
Denotes a recommendation
November 2011
Page 33
Part II
General Requirements
November 2011
Page 35
5
5.1
Definition
Attended
Unattended
Online only
Offline with
online
capability
Offline only
Operational
control
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).
November 2011
Page 37
The type of terminal shall be indicated in Terminal Type. The coding of Terminal
Type using the three categories is shown in Annex A.
5.2
Terminal Capabilities
Page 38
November 2011
5.3
Terminal Configurations
Terminal
ICC
IFD
Mag. stripe
card
POS Device
C = Cancel
E = Enter
November 2011
Page 39
Merchant Host
POS Device
Figure 2: Example of a Merchant Host
Within this specification a merchant host to which is connected a cluster of POS
devices shall be considered, in its totality, as a terminal regardless of the
distribution of functions between the host and POS devices. (See section 10 for
terminal data management requirements.)
Page 40
November 2011
Cardholder
Terminal
Merchant Host
Public Network
C = Cancel
E = Enter
Acquirer Host
November 2011
Page 41
Functional Requirements
This Book does not replicate the other Books of the Integrated Circuit Card
Specifications for Payment Systems but describes the implementation issues and
the impact of those Books on the terminal.
This section uses standard messages described in section 11.2 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.
November 2011
Page 43
6 Functional Requirements
6.3 Application Specification
6.3.1
When the Processing Options Data Object List (PDOL) includes an amount field
(either Amount, Authorised or Amount, Other), an attended terminal (Terminal
Type = 'x1', 'x2' or 'x3') shall provide the amount at this point in transaction
processing. If the amount is not yet available, the terminal shall obtain the
amount and should display the ENTER AMOUNT message. For any other
terminal type, if the terminal is unable to provide the amount at this point in
transaction processing, the amount field in the data element list shall be filled
with hexadecimal zeroes.
As described in Book 3, if the card returns SW1 SW2 = '6985' in response to the
GET PROCESSING OPTIONS command, indicating that the transaction cannot
be performed with this application, then the terminal should display the NOT
ACCEPTED message and shall return to application selection. The terminal
shall not allow that application to be selected again for this card session as
defined in Book 1.
6.3.2
Page 44
November 2011
6. Functional Requirements
6.3 Application Specification
If the CID bit indicates that the card has returned an ARQC, the terminal
shall complete the transaction processing by performing an immediate
second GENERATE AC command requesting an AAC.
If CDA fails in conjunction with the second GENERATE AC, the terminal
shall decline the transaction
If as part of dynamic signature verification the CID was retrieved from the ICC
Dynamic Data (as recovered from the Signed Dynamic Application Data), then it
is this value that shall be used to determine the cryptogram type. Otherwise the
cleartext CID in the GENERATE AC response shall be used.
Terminals supporting offline cryptography should support Certificate Revocation
Lists (CRLs). If CRLs are supported, the support shall be in accordance with
section 5.1.2 of Book 2.
6.3.3
Processing Restrictions
If the card and terminal Application Version Numbers are different, the terminal
shall attempt to continue processing the transaction. If it is unable to continue,
the terminal shall abort the transaction and should display the NOT
ACCEPTED message.
When processing the Application Usage Control, the terminal must know
whether or not it is an ATM. See Annex A1 for information on identifying an
ATM.
A terminal supporting cashback should not offer cashback facility to the
cardholder if the Application Usage Control does not allow this option.
6.3.4
Recognition of a CVM means the CVM Code is understood by the terminal but
not necessarily supported by the terminal. The terminal shall recognise the
EMV-defined CVM codes in Annex C3 of Book 3 including the CVM codes for 'No
CVM required' and 'Fail CVM processing. The terminal may also recognize
proprietary CVM Codes not defined in Annex C3.
Support for a CVM means the terminal has the hardware and software necessary
to perform the CVM. Support for EMV-defined CVM codes is indicated in the
following manner:
For EMV-defined CVM codes, support is indicated in Terminal Capabilities.
For CVM codes not defined in EMV, support may be known implicitly.
For Combination CVMs, both CVM codes must be supported.
Fail CVM shall always be considered supported.
A CVM can be performed only if it is both recognised and supported.
November 2011
Page 45
6 Functional Requirements
6.3 Application Specification
6.3.4.1
Offline CVM
When the applicable CVM is an offline PIN, the terminal should issue a
GET DATA command to the card to retrieve the PIN Try Counter prior to issuing
either the VERIFY command or GET CHALLENGE command.
If the PIN Try Counter is not retrievable or the GET DATA command is not
supported by the ICC, or 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 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 TVR to 1 (for details on TVR,
see Annex C of Book 3),
shall not display any specific message regarding PINs, and
shall continue cardholder verification processing in accordance with the cards
CVM List.
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 continue
cardholder verification processing in accordance with the cards CVM List. (CVM
Results is described in section 6.3.4.5 and coded according to Annex A4.)
6.3.4.2
Online CVM
When the applicable CVM is an online PIN, the IFD shall not issue a VERIFY
command. Instead, the PIN pad shall encipher the PIN upon entry for
transmission in the authorisation or financial transaction request.
The terminal shall allow a PIN to be entered for online verification even if the
cards PIN Try Limit is exceeded.
The terminal shall set byte 3 of the CVM Results to unknown.
Page 46
November 2011
6.3.4.3
6. Functional Requirements
6.3 Application Specification
If a PIN is required for entry as indicated in the cards CVM List, an attended
terminal with an operational PIN pad may have the capability to bypass PIN
entry before or after several unsuccessful PIN tries. 1 If this occurs, the terminal:
shall set the PIN entry required, PIN pad present, but PIN was not entered
bit in the TVR to 1,
shall not set the PIN Try Limit exceeded bit in the TVR to 1,
shall consider this CVM unsuccessful, and
shall continue cardholder verification processing in accordance with the cards
CVM List.
When PIN entry has been bypassed for one PIN-related CVM, it may be
considered bypassed for any subsequent PIN-related CVM during the current
transaction.
6.3.4.4
Signature (Paper)
When the applicable CVM is signature, the terminal shall set byte 3 of the CVM
Results to unknown. At the end of the transaction, the terminal shall print a
receipt with a line for cardholder signature. (See Annex A2 for requirements for
the terminal to support signature as a CVM.)
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.
November 2011
Page 47
6 Functional Requirements
6.3 Application Specification
6.3.4.5
CVM Results
Page 48
November 2011
6. Functional Requirements
6.3 Application Specification
TVR
Byte 3
TSI
Byte 1
bit 7
'00'
--
'00'
--
0
(Book 3
Section 10.5)
'01'
bit 8 = 1
'01'
bit 8 = 1
'01'
bit 8 = 1
bit 7 = 1
'00' or '40'
(Not recommended for cards.)
'01'
(Book 4
Section 6.3.4.5
and Annex A4)
bit 8 = 1
'01'
bit 8 = 1 2
'1E' or '5E'
(CVM Code for 'Signature')
'00'
(Book 4
Section 6.3.4.4
and Annex A4)
--
Conditions
When the card does not support cardholder verification (AIP
bit 5=0)
When CVM List is not present or the CVM List has no CVM
rules
When no CVM Conditions in CVM List are satisfied
When the terminal does not support any of the CVM Codes
in CVM List where the CVM Condition was satisfied
When the terminal does not recognise any of the CVM
Codes in CVM List (or the code is RFU) where the CVM
Condition was satisfied
When the (last) performed CVM is 'Fail CVM processing'
Byte 1
(CVM Performed)
'3F'
(Book 4 Section 6.3.4.5
and Annex A4)
'3F'
(Book 4 Section 6.3.4.5
and Annex A4)
'3F'
(Book 4 Section 6.3.4.5
and Annex A4)
'3F'
(Book 4 Section 6.3.4.5
and Annex A4)
'3F'
(Book 4 Section 6.3.4.5
and Annex A4)
Byte 2
(CVM Condition)
Byte 3
(CVM Result)
Table 2: Setting of CVM Results, TVR bits and TSI bits following CVM Processing
Errors with PIN related CVMs may also result in the setting of other PIN-related TVR bits.
November 2011
Page 49
Page 49
6 Functional Requirements
6.3 Application Specification
Conditions
TVR
Byte 3
TSI
Byte 1
bit 7
bit 3 = 1
--
'01'
bit 8 = 1
'01'
bit 8 = 12
'00'
--
Byte 1
(CVM Performed)
Byte 2
(CVM Condition)
'02' or '42'
(CVM Code for 'Online PIN')
'1F' or '5F'
(CVM code for 'No CVM Required')
Byte 3
(CVM Result)
'00'
(Book 4
Section 6.3.4.2
and Annex A4)
'02'
(Book 4
Section 6.3.4.5
and Annex A4)
Table 2: Setting of CVM Results, TVR bits and TSI bits following CVM Processing, continued
Page 50
November 2011
6.3.5
6 Functional Requirements
6.3 Application Specification
6.3.6
3 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.
November 2011
Page 51
6 Functional Requirements
6.3 Application Specification
6.3.7
approval
decline
process online
Page 52
November 2011
6.3.8
Online Processing
6.3.9
The terminal shall be able to support one or more Issuer Scripts in each
authorisation or financial transaction response it receives, where the total length
of all Issuer Scripts in the response shall be less than or equal to 128 bytes.
Note: In this case and when only one Issuer Script (tag 71 or 72) is sent, and no Issuer
Script Identifier is used, the maximum length of the Issuer Script Command (tag 86) is
limited to 124 bytes. This implies that the maximum available useful command data (Lc)
is limited to 119 bytes for a Case 3 command.
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 most significant nibble of byte 1 of the Issuer Script Results to Script
processing failed and the least significant 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 most significant nibble of
byte 1 of the Issuer Script Results to Script processing successful and the least
significant nibble to '0'. See Annex A5 for details.
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 the terminal supports advices.
November 2011
Page 53
6 Functional Requirements
6.4 Conditions for Support of Functions
6.4
Page 54
November 2011
6.5
6.5.1
6.5.2
Voice Referrals
November 2011
Page 55
6 Functional Requirements
6.5 Other Functional Requirements
6.5.2.1
6.5.2.2
6.5.3
6.5.4
Page 56
November 2011
6.5.5
6.5.6
Unpredictable Number
6.6
Card Reading
If the terminal does not have 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 prompt for the card to be
inserted into the IC reader such as by displaying the USE CHIP READER
message.
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.
November 2011
Page 57
6 Functional Requirements
6.6 Card Reading
6.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.)
6.6.2
Exception Handling
When an attended terminal attempts and fails to read the ICC but the magnetic
stripe of the card is successfully read, the terminal shall set the POS Entry Mode
Code in the transaction message(s) to Magnetic stripe read, last transaction was
an unsuccessful IC read if the service code on the magnetic stripe indicates that
an IC is present. 5
Payment system rules determine whether fallback to magnetic stripe is allowed
after the failure of an IC-read transaction. This behaviour is outside the scope of
EMV specifications.
5 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.
Page 58
November 2011
6.7
6.7.1
Date Management
Data Authentication
The terminal shall be capable of properly calculating dates associated with data
authentication (certificate expiration dates) for dates before, including, and after
the year 2000.
6.7.2
Processing Restrictions
6.7.3
Date Management
To ensure the accuracy of the data elements Transaction Date (local date) and
Transaction Time (local time), the terminal shall ensure that it is able to
accurately calculate, store, and display date-dependent fields representing the
year 2000 and subsequent years without compromising the integrity of dates or
their use, including calculations for leap years. This requirement applies to
terminals supporting clocks as well as those that update the date and the time
based upon on-line messages.
The terminal should process a 2-digit year (YY) as follows:
YY in the range 0049 inclusive is treated as having the value 20YY
YY in the range 5099 inclusive is treated as having the value 19YY
The same rules shall be used if the terminal converts 2-digit years in format YY
to 4-digit years in format YYYY.
November 2011
Page 59
7 Physical Characteristics
7.1 Keypad
Physical Characteristics
7.1
Keypad
A terminal should have a keypad for the entry of transaction-related data and its
functional operation. The keypad shall support one or more types of keys , as
listed in Table 4.
Numeric
'0' '9'
Command
Function
A keypad 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 keypad. (See Book 2 for security
requirements.)
November 2011
Page 61
7 Physical Characteristics
7.1 Keypad
7.1.1
Command Keys
Command keys are used to control the flow of data entry by the cardholder or
attendant. Table 5 describes the command keys:
Enter
Confirms an action
Cancel
Clear
If the colours green, red, or yellow are used, either for key lettering or the keys
themselves, it is recommended that they be reserved for the command keys
according to Table 6:
Enter
Green
Cancel
Red
Clear
Yellow
Page 62
November 2011
7.1.2
PIN Pad
1
4
7
Cancel
2
5
8
0
3
6
9
Enter
November 2011
Page 63
7 Physical Characteristics
7.2 Display
7.2
Display
7.3
Memory Protection
Software as well as data initialised in the terminal or any part of the terminal,
including cryptographic keys, shall not be erased or altered for the period of time
the software and data are valid.
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.
7.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.
Page 64
November 2011
7.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 11.4).
Cardholder-controlled terminal (Terminal Type = '3x') need not include a printer.
7.6
November 2011
Page 65
7 Physical Characteristics
7.6 Magnetic Stripe Reader
Part III
Software Architecture
November 2011
Page 67
This section is intended to provide insight for terminal manufacturers into the
future direction of the payment system applications and the consequent
requirements for terminal functionality. While terminals without this
functionality may operate satisfactorily in todays environment, changes in that
environment will enhance the longevity of and provide functional advantages to
terminals incorporating the software design principles in this section.
8.1
Environmental Changes
November 2011
Page 69
8.2
Application Libraries
Application A
call X
Application B
X
Application C
call Y
Application D
call X
Common
Subroutines
call X
call Y
Operating
System
Figure 5: Terminal Software
With either the API or the interpreter approach, the terminal should have the
ability to maintain an application library of modules or routines that may be
dynamically incorporated into the processing of a given transaction. Modules in
the application library may be complete application programs, or they may be
subroutines to be called upon at the direction of data within the terminal or the
ICC. In the case of an interpreter capability, these modules will be code, written
in a virtual machine instruction set implemented within the terminal, to be
interpreted by the terminal control program. In the case of the API approach,
modules will be object code written to the specific terminal architecture.
In either case, modules within the application library may be dynamically
invoked either by logic with the terminal application software or under the
direction of referencing data kept within the ICC. The format and specification of
external references are under control of the individual payment systems.
A terminal may contain several libraries, some accessible to all applications and
some restricted to particular applications or payment systems.
Page 70
November 2011
8.3
November 2011
Page 71
8.4
8.4.1
Interpreter
Concept
Page 72
November 2011
8.4.2
Virtual Machine
8.4.3
Kernel
8.4.4
November 2011
Page 73
8.5
Page 74
November 2011
Terminal
Input Device
Plugs
Pl
ug
Operating
System
to
so
ck
Security/Control
et
Socket/Plug identifiers
Applications
Socket
Socket
A
Socket
Socket
Plug
Library
November 2011
Page 75
9 Software Management
8.5 Plugs and Sockets
Software Management
November 2011
Page 77
10 Data Management
10.1 Application Independent Data
10 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.)
Additional data elements may be required for initialisation, such as those
currently used for magnetic stripe processing.
Whenever a data element is initialised or updated, data integrity shall be
assured.
Data elements resident in the terminal shall be under the control of one of the
following parties:
Terminal manufacturer: For example, IFD Serial Number
Acquirer (or its agent): For example, Merchant Category Code
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).
November 2011
Page 79
10 Data Management
10.1 Application Independent Data
10.1.1
The following data elements are application independent and shall be unique to
the terminal (see section 5.3 for different terminal configurations):
IFD Serial Number
Local Date
Local Time
Terminal Country Code
Transaction Sequence Counter
The terminal shall have parameters initialised so that it can identify what
language(s) are supported to process the cards Language Preference (see
section 11.1).
10.1.2
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 for an example):
Additional Terminal Capabilities
Terminal Capabilities
Terminal Type
The terminal shall be constructed in such a way that these data objects cannot be
modified unintentionally or by unauthorised access.
These data objects may be varied on a transaction by transaction basis which
means that for each transaction, the terminal may invoke a different value for
these data objects based on certain characteristics and parameters of the
transaction (selection criteria). Support of this functionality is optional for the
terminal. The implementation of this functionality is left to the discretion of the
terminal manufacturer and is outside the scope of EMV.
Page 80
November 2011
Notes
Acquirer Identifier
Application Identifier (AID)
Application Version Number
Certification Authority Public Key
Certification Authority Public Key
Exponent
Certification Authority Public Key
Modulus
November 2011
Page 81
10 Data Management
10.2 Application Dependent Data
Data Elements
Notes
Terminal Identification
Terminal Risk Management Data
Page 82
November 2011
Note: alternative integrity verification techniques may be used. The integrity of the
stored Certification Authority Public Keys should be verified periodically.
November 2011
Page 83
10 Data Management
10.2 Application Dependent Data
Part IV
Cardholder, Attendant, and
Acquirer Interface
November 2011
Page 85
If a match is found, the language with the highest preference shall be used
for the messages displayed to the cardholder. (The Language Preference
data object is coded so that the language with the highest preference
appears first and the lowest preference appears last.)
If no match is found, the terminal shall allow the cardholder to select their
preferred language if it has a means for allowing such selection. Messages
shall be displayed to the cardholder in the selected language or, if the
terminal has no means of offering language selection to the cardholder, in
the local language.
November 2011
Page 87
If the card does not provide a Language Preference data object, the terminal
shall allow the cardholder to select their preferred language if it has a means
for allowing such selection. Messages shall be displayed to the cardholder in
the selected language or, if the terminal has no means of offering language
selection to the cardholder, in the local language.
Alternatively terminals may support a proprietary language selection process
which is outside the scope of EMV. If such a proprietary language selection
process is used, the EMV language selection process shall not be performed. The
language selected using the proprietary process shall be used throughout the
transaction.
Messages should be displayed to the attendant in the language of the attendants
choice or, if the terminal has no means of offering language selection to the
attendant, in the local language. Messages displayed to the attendant and
cardholder may be displayed in different languages if supported by the terminal.
7 This specification does not imply that the terminal shall support a set of standard
messages in English.
Page 88
November 2011
Message Identifier
Message
Definition
'01'
(AMOUNT)
'02'
(AMOUNT) OK?
'03'
APPROVED
'04'
CALL YOUR
BANK
'05'
CANCEL OR
ENTER
'06'
CARD ERROR
'07'
DECLINED
'08'
ENTER
AMOUNT
'09'
ENTER PIN
November 2011
Page 89
Message Identifier
Message
Definition
'0A'
INCORRECT
PIN
'0B'
INSERT CARD
'0C'
NOT
ACCEPTED
'0D'
PIN OK
'0E'
PLEASE WAIT
'0F'
PROCESSING
ERROR
'10'
REMOVE CARD
'11'
USE CHIP
READER
'12'
USE MAG
STRIPE
'13'
TRY AGAIN
Page 90
November 2011
November 2011
Page 91
11.4 Receipt
Whenever a receipt is provided, it shall contain the AID in addition to the data
required by payment system rules. The AID shall be printed as hexadecimal
characters.
Page 92
November 2011
12 Acquirer Interface
12.1 Message Content
12 Acquirer Interface
12.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 elements 8 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. 9 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 issuer 10 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.
Data requirements may differ depending on terminal operational control, which
is recognised through a specific condition: Present for Terminal Type = xx. For
example, Merchant Identifier is provided only for a merchant-controlled terminal
(Terminal Type = '2x').
An authorisation message shall be used when transactions are batch data
captured. A financial transaction message shall be used when online data
capture is performed by the acquirer. An offline advice shall be conveyed within
batch data capture when supported. An online advice or a reversal message shall
be transmitted real-time, similarly to an authorisation or financial transaction
message.
8 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
TDOL shall be available at the point of transaction.
9
10 These data elements reflect card acceptance conditions and restrictions that rarely
change, such as Application Interchange Profile, Application Usage Control, or Issuer
Action Codes.
November 2011
Page 93
12 Acquirer Interface
12.1 Message Content
Page 94
November 2011
12.1.1
Authorisation Request
Condition
11
CVM Results
IFD Serial Number
Terminal Capabilities
Terminal Type
TVR *
Unpredictable Number*
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.
11
November 2011
Page 95
12 Acquirer Interface
12.1 Message Content
Condition
Acquirer Identifier
Amount, Authorised *
Amount, Other *
Present if in ICC
Application Expiration
Date
Application PAN *
Present if in ICC
Merchant Identifier
Present if in ICC
Transaction Currency
Code *
Transaction Date *
Transaction Time
Transaction Type *
Table 10: Existing Authorisation Request Data Elements
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.
12
Page 96
November 2011
12.1.2
Condition
13
ARQC *
CID
CVM List
CVM Results
IFD Serial Number
Terminal Capabilities
Terminal Type
TVR *
Unpredictable Number *
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.
13
November 2011
Page 97
12 Acquirer Interface
12.1 Message Content
14
Amount, Other *
Application Effective Date
Application Expiration Date
Application PAN *
Application PAN Sequence
Number *
Enciphered PIN Data
Issuer Country Code
Merchant Category Code
Merchant Identifier
POS Entry Mode
Terminal Country Code *
Terminal Identifier
Track 2 Equivalent Data
Transaction Amount *
Transaction Currency Code *
Transaction Date *
Transaction Time
Transaction Type *
Condition
Present for Terminal Type = '1x' or '2x' if
Merchant Identifier or Terminal Identifier does
not implicitly refer to a single acquirer
Present if final transaction amount is different
from authorised amount
Present if cashback used for current transaction
Present if in ICC
Present if not in Track 2 Equivalent Data
Present if not in Track 2 Equivalent Data
Present if in ICC
Present if CVM performed is Enciphered PIN
for online verification.
Present if requested by acquirer
Present for Terminal Type = '2x' if Merchant
Identifier or Terminal Identifier does not
implicitly refer to a single merchant category
Present for Terminal Type = '2x' if Terminal
Identifier does not implicitly refer to a single
merchant
Present if in ICC
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.
14
Page 98
November 2011
12.1.3
Condition
15
Condition
Present for Terminal Type = '1x' or '2x' if in
request message
Amount, Authorised
Authorisation Code
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.
15
November 2011
Page 99
12 Acquirer Interface
12.1 Message Content
12.1.4
Condition
Present if script commands to ICC are
delivered by terminal
TC or AAC
Table 15: ICC-specific Financial Transaction Confirmation Data Elements
Table 16 contains existing data elements necessary for an ICC transaction.
Data Element
Condition
Terminal Identifier
Table 16: Existing Financial Transaction Confirmation Data Elements
Page 100
November 2011
12.1.5
Batch data capture should convey the data elements contained in Table 17 and
Table 18 subject to the specified conditions. Message Type is used to distinguish
between an offline advice and a financial record.
Table 17 contains the new data elements specifically created for an ICC
transaction.
Data Element
Condition
Application Interchange
Profile * 16
Application Transaction
Counter *
Application Usage Control
CID
CVM List
CVM Results
IFD Serial Number
Terminal Capabilities
Terminal Type
TVR *
TC/ARQC or AAC *
Unpredictable Number *
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.
16
November 2011
Page 101
12 Acquirer Interface
12.1 Message Content
Condition
Acquirer Identifier
Amount, Authorised * 17
Amount, Other *
Present if in ICC
Application Expiration
Date
Application PAN *
Application PAN Sequence
Number *
Present if in ICC
Authorisation Code
Authorisation Response
Code
Issuer Country Code
Merchant Identifier
Message Type
POS Entry Mode
Terminal Country Code *
Terminal Identifier
Transaction Amount *
Table 18: Existing Batch Data Capture Data Elements
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.
17
Page 102
November 2011
Data Element
Transaction Currency
Code *
Condition
Present if Merchant Identifier or Terminal
Identifier does not implicitly refer to a single
transaction currency accepted at point of
transaction
Transaction Date *
Transaction Time
Transaction Type *
Table 18: Existing Batch Data Capture Data Elements, continued
12.1.6
Reconciliation
A reconciliation should convey the existing data elements necessary for ICC
transactions and subject to the specified conditions.
Data Element
Acquirer Identifier
Condition
Present for Terminal Type = '1x' or '2x' if
Merchant Identifier or Terminal Identifier does
not implicitly refer to a single acquirer
Terminal Identifier
Transactions Number (per
transaction type)
Transactions Amount (per
transaction type)
Table 19: Existing Reconciliation Data Elements
November 2011
Page 103
12 Acquirer Interface
12.1 Message Content
12.1.7
Online Advice
An online advice should convey the data elements contained in Table 20 and
Table 21 subject to the specified conditions.
Table 20 contains the new data elements specifically created for an ICC
transaction.
Data Element
Condition
Application Interchange
Profile
Application Transaction
Counter
CID
CVM Results
IFD Serial Number
Terminal Capabilities
Terminal Type
TVR
TC or AAC
Unpredictable Number
Page 104
November 2011
Condition
Acquirer Identifier
Amount, Authorised
Present if in ICC
Application PAN
Present if in ICC
Merchant Identifier
Terminal Identifier
Track 2 Equivalent Data
Present if in ICC
Transaction Amount
Transaction Currency Code
Transaction Date
Transaction Time
Transaction Type
Table 21: Existing Online Advice Data Elements
November 2011
Page 105
12 Acquirer Interface
12.1 Message Content
12.1.8
Reversal
A reversal should convey the data elements contained in Table 22 and Table 23
subject to the specified conditions.
Table 22 contains the new data elements specifically created for an ICC
transaction.
Data Element
Condition
Application Interchange
Profile
Application Transaction
Counter
IFD Serial Number
Terminal Capabilities
Terminal Type
TVR
Table 22: ICC-specific Reversal Data Elements
Page 106
November 2011
Condition
Acquirer Identifier
Application PAN
Present if in ICC
Merchant Identifier
Terminal Identifier
Track 2 Equivalent Data
Present if in ICC
Transaction Amount
Transaction Currency Code
Transaction Date
Transaction Time
Transaction Type
Table 23: Existing Reversal Data Elements
November 2011
Page 107
12 Acquirer Interface
12.2 Exception Handling
12.2.1
Unable to Go Online
Page 108
November 2011
12.2.2
Downgraded Authorisation
When the authorisation response received by the terminal does not contain the
Issuer Authentication Data, the terminal shall not execute the EXTERNAL
AUTHENTICATE command and shall set the Issuer authentication was
performed bit in the Transaction Status Information (TSI) to 0, as described in
Book 3. The terminal shall continue processing based on the Authorisation
Response Code returned in the response message as described in section 6.3.6.
Note: If the acquirer or the intermediate network is unable to support ICC messages,
the terminal should send messages compliant with current payment system
specifications. Payment systems will determine compliance requirements for message
content.
November 2011
Page 109
12 Acquirer Interface
12.2 Exception Handling
12.2.3
The authorisation response may not be correctly received by the terminal. The
following incidents may occur:
Response not received or received too late (for example, network failure,
time-out)
Response with invalid format or syntax
Request not received by the authorisation host (for example, network failure)
After repeat(s) 18, if any, of the authorisation request, the terminal shall process
the transaction as being unable to go online. As described in Book 3, the terminal
shall compare the TVR 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:
If the terminal accepts the transaction, it shall set the Authorisation Response
Code to Unable to go online, offline accepted.
If the terminal declines the transaction, it shall set the Authorisation
Response Code to Unable to go online, offline declined.
The result of card risk management performed by the ICC is made known to the
terminal through the return of the CID 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.
Page 110
November 2011
12.2.4
Script Incidents
The Issuer Script may not be correctly processed. The following incidents may
occur:
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.
Script with incorrect format or syntax: The terminal is unable to correctly
parse the Issuer Script(s) into single Script Commands, as specified in Book 3.
If either of these incidents occurs, 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.
Book 3, Annex E gives some examples of TVR and TSI bit setting following script
processing.
12.2.5
Advice Incidents
If the terminal supports advices but is unable to create an advice when requested
by the card in the CID returned in the response to the GENERATE AC command
as described in section 6.3.7, the terminal shall terminate the transaction.
November 2011
Page 111
12 Acquirer Interface
12.2 Exception Handling
Part V
Annexes
November 2011
Page 113
Annex A
12 Acquirer Interface
12.2 Exception Handling
This annex provides the coding for the Terminal Type, Terminal Capabilities,
Additional Terminal Capabilities, CVM Results, Issuer Script Results, and
Authorisation Response Code.
Coding of data (bytes or bits) indicated as RFU shall be '0'.
Neither the terminal nor the card shall check the data indicated as RFU.
A1
Terminal Type
Operational Control Provided By:
Environment
Financial
Institution
Merchant
Online only
11
21
12
22
Offline only
13
23
Online only
14
24
34
15
25
35
Offline only
16
26
36
Cardholder
19
Attended
Unattended
November 2011
Page 115
A2
Terminal Capabilities
b7
b6
b5
b4
b3
b2
b1
Meaning
Magnetic stripe
IC with contacts
RFU
RFU
RFU
RFU
RFU
Page 116
November 2011
b8
b7
b6
b5
b4
b3
b2
b1
Meaning
Signature (paper)
No CVM Required
RFU
RFU
RFU
b7
b6
b5
b4
b3
b2
b1
Meaning
SDA
DDA
Card capture
RFU
CDA
RFU
RFU
RFU
November 2011
Page 117
A3
b7
b6
b5
b4
b3
b2
b1
Meaning
Cash
Goods
Services
Cashback
Inquiry
Transfer
21
Payment
22
Administrative
20
20 For the purpose of this specification, an inquiry is a request for information about one
of the cardholders accounts.
Page 118
November 2011
b8
b7
b6
b5
b4
b3
b2
b1
Meaning
Cash Deposit
RFU
RFU
RFU
RFU
RFU
RFU
RFU
23
b8
b7
b6
b5
b4
b3
b2
b1
Meaning
Numeric keys
Command keys
Function keys
RFU
RFU
RFU
RFU
Table 30: Addl Term. Capabilities Byte 3 - Terminal Data Input Capability
November 2011
Page 119
Meaning
24
b8
b7
b6
b5
b4
b3
b2
b1
Print, attendant
Print, cardholder
Display, attendant
Display, cardholder
RFU
RFU
Code table 10
Code table 9
Table 31: Addl Term. Capabilities Byte 4 - Term. Data Output Capability
The code table number refers to the corresponding part of ISO/IEC 8859.
b8
b7
b6
b5
b4
b3
b2
b1
Meaning
Code table 8
Code table 7
Code table 6
Code table 5
Code table 4
Code table 3
Code table 2
Code table 1
Table 32: Addl Term. Capabilities Byte 5 - Term. Data Output Capability
The code table number refers to the corresponding part of ISO/IEC 8859.
24 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.
Page 120
November 2011
A4
CVM Results
Byte 1
CVM Performed
Byte 2
CVM Condition
Byte 3
CVM Result
A5
Byte 1
Script
Result
Bytes
2-5
Script
Identifier
Bytes 15 are repeated for each Issuer Script processed by the terminal.
November 2011
Page 121
A6
When transmitted to the card, the Authorisation Response Code obtained from
the authorisation response message shall include at least the following:
Online approved
Online declined
Referral (initiated by issuer)
Capture card
In addition, the terminal shall be able to generate and transmit to the card the
new response codes listed in Table 35 when transactions are not authorised
online:
Authorisation Response Code
Value
Offline approved
Y1
Offline declined
Z1
Y3
Z3
25 The cards final decision is reflected in the Cryptogram Information Data and not in the
Authorisation Response Code.
Page 122
November 2011
Annex B
12 Acquirer Interface
12.2 Exception Handling
Table 36 shows the character set common to all parts of ISO/IEC 8859:
b8 0
b7
b6
b5
00
01
02
03
04
05
06
07
b4
b3
b2
b1
00
SP
01
02
03
04
05
06
&
07
08
09
10
11
12
<
13
14
>
15
November 2011
Page 123
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/IEC 8859
that allows the relevant diacritic marks to be displayed.
If the terminal supports Part 1 of ISO/IEC 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/IEC 8859 (the Latin 1 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.
Page 124
November 2011
Annex C
12 Acquirer Interface
12.2 Exception Handling
For the data elements listed in section 12.1, Table 37 illustrates an example of
the relationship between:
the ICC-related data described in Book 3 and the terminal-related data
described in this specification
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.
Tag
ICC Data
Bit
32
Acquiring Institution
Identification Code
4
30
Amount, Transaction
(authorisation)
Amount, Original Transaction
(batch data capture, financial
transaction)
54
Additional Amounts
55
'82'
Application Interchange
Profile
55
'5A'
Application PAN
PAN
23
55
55
November 2011
Page 125
Tag
ICC Data
Bit
'89'
Authorisation Code
38
Authorisation Identification
Response
'8A'
39
Response Code
55
55
55
52
PIN Data
CVM List
55
55
55
55
55
20
55
55
18
Merchant Type
42
22
40
Service Code
'91'
Page 126
November 2011
Tag
ICC Data
Bit
19
43
41
'95'
TVR
55
'57'
35
Track 2 Data
Transaction Amount
Amount, Transaction
49
Transaction Date
13
12
55
'9C'
Transaction Type
November 2011
Page 127
Annex D
D1
12 Acquirer Interface
12.2 Exception Handling
Terminal Usage
D2
D2.1
Power Supply
External Power Supply
The power supply provides the required voltage and current to all components of
the terminal. The power supply should comply with the relevant national safety
regulations.
D2.2
Battery Requirements
November 2011
Page 129
D3
Keypad
To prevent characters printed on the keys of the keypad from becoming illegible
after a while, precautions should be taken so that they:
have wear-resistant lettering
are able to function in normal operating environment including resistance to
soft drink spills, alcohol, detergents, gasoline, etc.
when operated as outdoor terminals, can resist the temperature ranges
commonly encountered
D4
Display
To cater for 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.
D5
Informative References
IEC 950:1991
IEC 801-2:1991
IEC 802-3:1984
IEC 801-4:1988
IEC 68-2-5:1975
Page 130
November 2011
IEC 68-2-6:1982
IEC 68-2-11:1981
IEC 68-2-27:1987
IEC 68-2-32:1975
EN 60-950:1988
EN 41003:1993
UL 1950:1993
NF C 20-010:1992
NF C 98-310:1989
NF C 98-020:1986
26
26
November 2011
Page 131
Annex E
12 Acquirer Interface
12.2 Exception Handling
Examples of Terminals
For informational purposes only, this annex provides some examples of the
physical and functional characteristics of terminals. Each example describes the
setting of Terminal Type, Terminal Capabilities, and Additional Terminal
Capabilities according to the specific terminal characteristics. This annex does
not establish any requirements as such.
November 2011
Page 133
E1
Example 1
Physical:
Keypad
Display
Printer
Yes
IC reader
Yes
Functional:
Language selection
Transaction type
Goods, cashback
SDA, DDA
Yes
Cardholder verification
Card capture
No
Online capable
Yes
Offline capable
Yes
Page 134
November 2011
E2
Example 2 - ATM
Characteristics
Example 2
Physical:
Keypad
Display
Printer
Yes
IC reader
Yes
Functional:
Language selection
Transaction type
SDA
No
Cardholder verification
Online PIN
Card capture
Yes
Online capable
Yes
Offline capable
No
Table 39: Example of ATM
The coding of the terminal-related data for this example is the following:
Terminal Type = '14'
Terminal Capabilities,
November 2011
Page 135
E3
Example 3
Physical:
Keypad
Function keys
Display
No
Printer
No
Yes
IC reader
Yes
Functional:
Language selection
No
Transaction type
Goods
SDA, DDA
Yes
Cardholder verification
No
Card capture
No
Online capable
No
Offline capable
Yes
Table 40: Example of Vending Machine
The coding of the terminal-related data for this example is the following:
Terminal Type = '26'
Terminal Capabilities,
Page 136
November 2011
12 Acquirer Interface
12.2 Exception Handling
Index
A
Abbreviations ........................................................ 21
Acquirer Interface
Exception Handling ........................................ 108
Advice Incidents ........................................ 111
Authorisation Response Incidents ............. 110
Downgraded Authorisation........................ 109
Script Incidents .......................................... 111
Unable to Go Online.................................. 108
Message Content .............................................. 93
Authorisation Request ................................. 95
Authorisation Response ............................... 99
Batch Data Capture.................................... 101
Financial Transaction Confirmation .......... 100
Financial Transaction Request..................... 97
Financial Transaction Response .................. 99
Online Advice............................................ 104
Reconciliation ............................................ 103
Reversal ..................................................... 106
Additional Terminal Capabilities
Terminal Data Input Capability ...................... 119
Terminal Data Output Capability ................... 120
Transaction Type Capability .................. 118, 119
Advice Incidents ................................................. 111
Amount Entry and Management ........................... 55
Application Dependent Data ................................. 81
Application Independent Data ............................... 80
Application Independent ICC to Terminal Interface
Requirements .................................................... 43
Application Selection ............................................ 91
Application Specification ...................................... 43
Authorisation Request ........................................... 95
Authorisation Response ........................................ 99
Authorisation Response Code
Coding ............................................................ 122
Authorisation Response Incidents ....................... 110
B
Batch Data Capture ............................................. 101
Battery Requirements .......................................... 129
D
Data Element Conversion, Example.................... 125
Data Element Format Conventions ....................... 31
Data Elements
Authorisation Request
Existing........................................................ 96
ICC-specific................................................. 95
Batch Data Capture
Existing...................................................... 102
ICC-specific............................................... 101
Financial Transaction Confirmation
Existing...................................................... 100
ICC-specific............................................... 100
Financial Transaction Request
Existing........................................................ 98
ICC-specific................................................. 97
Online Advice
Existing...................................................... 105
ICC-specific............................................... 104
Reconciliation
Existing...................................................... 103
Response
Existing........................................................ 99
ICC-specific................................................. 99
Reversal
Existing...................................................... 107
ICC-specific............................................... 106
Data Elements, Terminal ..................................... 115
Data Management ................................................. 79
Application Dependent Data ............................ 81
Application Independent Data .......................... 80
November 2011
Page 137
E
Example of Data Element Conversion ................ 125
Examples of Terminals ....................................... 133
Exception Handling ...................................... 58, 108
Advice Incidents ............................................ 111
Authorisation Response Incidents.................. 110
Downgraded Authorisation ............................ 109
Script Incidents .............................................. 111
Unable to Go Online ...................................... 108
External Power Supply ....................................... 129
F
Financial Transaction Confirmation ................... 100
Financial Transaction Request .............................. 97
Financial Transaction Response ........................... 99
Functional Requirements ...................................... 43
Amount Entry and Management ...................... 55
Application Independent ICC to Terminal
Interface ...................................................... 43
Application Specification
Data Authentication .................................... 44
Application Specification ................................ 43
Initiate Application Processing ................... 44
Application Specification
Processing Restrictions ............................... 45
Application Specification
Cardholder Verification Processing ............ 45
Application Specification
Cardholder Verification Processing
Offline CVM .......................................... 46
Application Specification
Cardholder Verification Processing
Online CVM........................................... 46
Application Specification
Cardholder Verification Processing
PIN Entry Bypass ................................... 47
Application Specification
Cardholder Verification Processing
Signature (Paper).................................... 47
Application Specification
Cardholder Verification Processing
CVM Results .......................................... 48
Application Specification
Terminal Risk Management ........................ 51
Application Specification
Terminal Action Analysis ........................... 51
Application Specification
Card Action Analysis .................................. 52
Page 138
I
IC Reader .............................................................. 58
Informative References ....................................... 130
Informative Terminal Guidelines........................ 129
Display ........................................................... 130
Keypad ........................................................... 130
Power Supply ................................................. 129
Terminal Usage .............................................. 129
Initiate Application Processing ............................. 44
Issuer-to-Card Script Processing .......................... 53
K
Key Colours .......................................................... 62
Key Types............................................................. 61
Keypad.......................................................... 61, 130
Command Keys ............................................... 62
PIN Pad ............................................................ 63
L
Language Selection............................................... 87
M
Magnetic Stripe Reader ........................................ 65
Memory Protection ............................................... 64
Merchant Host ...................................................... 40
Message Content .................................................. 93
Authorisation Request...................................... 95
Authorisation Response ................................... 99
Batch Data Capture ........................................ 101
November 2011
Index
Referrals ................................................................ 55
Reversal............................................................... 106
Revision Log ......................................................... iii
Scope....................................................................... 3
Script Incidents ................................................... 111
Security and Key Management ............................. 43
Signature (Paper)................................................... 47
Socket/Plug Relationship ...................................... 75
Software Management .......................................... 77
Standard Messages ................................................ 88
Terminal
Capabilities....................................................... 38
Configurations .................................................. 39
Attended ...................................................... 39
Cardholder-Controlled ................................. 41
Merchant Host ............................................. 40
Examples ........................................................ 133
ATM .......................................................... 135
POS Terminal or Electronic Cash Register 134
Vending Machine ...................................... 136
Types ................................................................ 37
Terminal Action Analysis ..................................... 51
Terminal Capabilities
Card Data Input Capability............................. 116
CVM Capability ............................................. 117
Security Capability ......................................... 117
Terminal Data Elements, Coding ........................ 115
Terminal Guidelines, Informative ....................... 129
Terminal Risk Management .................................. 51
Terminal Software Architecture ............................ 69
Application Libraries........................................ 70
Application Program Interface ......................... 71
Environmental Changes ................................... 69
Interpreter
Application Code Portability ....................... 73
Concept........................................................ 72
Kernel .......................................................... 73
Virtual Machine ........................................... 73
Plugs and Sockets ............................................. 74
P
Physical Characteristics ........................................ 61
Clock ................................................................ 64
Display ............................................................. 64
Keypad ............................................................. 61
Command Keys ........................................... 62
PIN Pad ....................................................... 63
Magnetic Stripe Reader .................................... 65
Memory Protection ........................................... 64
Printer ............................................................... 65
PIN Entry Bypass .................................................. 47
PIN Pad ................................................................. 63
Plugs and Sockets.................................................. 74
Power Supply ...................................................... 129
Printer.................................................................... 65
Processing Restrictions ................................... 45, 59
R
Reconciliation ..................................................... 103
References
Informative ..................................................... 130
Normative........................................................... 7
November 2011
Page 139
Page 140
U
Unable to Go Online ........................................... 108
Unpredictable Number.......................................... 57
V
Voice Referrals ..................................................... 55
November 2011