Académique Documents
Professionnel Documents
Culture Documents
© 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 viii
3. Definitions x
4. Abbreviations and Notations xii
Annexes
Annex A - Data Elements Table 67
Annex B – Rules for BER-TLV Data Objects 85
B.1 Coding of BER-TLV Data Objects 85
B1.1 Coding of the Tag Field of BER-TLV Data Objects 85
B1.2 Coding of the Length Field of BER-TLV Data Objects 86
B1.3 Coding of the Value Field of Data Objects 87
Annex C - Coding of Data Elements used in the Transaction Processing 89
Annex C.1 - Application Interchange Profile 90
December, 2000 Table of Contents iii
Table of Tables
Table I - 1- Structure of SFI 3
Table I - 2- Most Significant Nibble of the Class Byte 6
Table I - 3- Coding of the Instruction Byte 7
Table I - 4- Coding of Status Bytes SW1 SW2 8
Table I - 5- Allocation of Status Bytes 9
Table I - 6- APPLICATION BLOCK Command Message 11
Table I - 7- APPLICATION UNBLOCK Command Message 12
Table I - 8 - CARD BLOCK Command Message 13
Table I - 9- EXTERNAL AUTHENTICATE Command Message 14
Table I - 10- GENERATE AC Cryptogram Types 15
Table I - 11- GENERATE AC Command Message 15
Table I - 12- GENERATE AC Reference Control Parameter 16
Table I - 13- Format 1 GENERATE AC Response Message Data Field 16
Table I - 14- Coding of Cryptogram Information Data 17
Table I - 15- GET CHALLENGE Command Message 18
Table I - 16- GET DATA Command Message 19
Table I - 17- GET PROCESSING OPTIONS Command Message 20
Table I - 18- Format 1 GET PROCESSING OPTIONS Response Message
Data Field 20
Table I - 19- INTERNAL AUTHENTICATE Command Message 21
Table I - 20- PIN CHANGE/UNBLOCK Command Message 23
Table I - 21- READ RECORD Command Message 24
Table I - 22- READ RECORD Command Reference Control Parameter 24
Table I - 23- READ RECORD Response Message Data Field 24
Table I - 24- VERIFY Command Message 25
Table I - 25- VERIFY Command Qualifier of Reference Data (P2) 25
Table II - 1 - Data Objects Used by the Offline Data Authentication Algorithm 30
Table II - 2 - Mandatory Data Objects 30
Table II - 3 - Data Required for Offline Static Data Authentication 30
Table II - 4 - Data Required for Offline Dynamic Data Authentication 31
Table II - 5 - Data Objects Retrievable by GET DATA Command 31
Table II - 6 - Data Retrievable by GET PROCESSING OPTIONS 32
Table II - 7 - ICC Data Missing Indicator Setting 33
Table A - 1 - Data Elements Dictionary 80
Table A - 2 - Data Elements Tags 83
Table B - 1 - Tag Field Structure (First Byte) BER-TLV 85
Table B - 2 - Tag Field Structure (Subsequent Bytes) BER-TLV 86
Table B - 3 - Primitive BER-TLV Data Object (Data Element) 87
Table B - 4 - Constructed BER-TLV Data Object 87
Table C - 1 - Application Interchange Profile 90
Table C - 2 - Application Usage Control 91
Table C - 3 - CVM Codes 92
Table C - 4 - CVM Condition Codes 93
Table C - 5 - Issuer Code Table Index 94
Table C - 6 - Terminal Verification Results 97
Table C - 7 - Transaction Status Information 98
December, 2000 Table of Contents v
Table of Figures
Figure I-1 - Command APDU Structure 5
Figure I-2 - Response APDU Structure 5
Figure I-3 - Structural Scheme of Status Bytes 8
Figure II- 1 - Transaction Flow Example 35
Figure II- 2 - Use of GENERATE AC Options 38
Figure II- 3 - Use of GENERATE AC with Referrals 39
Figure II- 4 - Random Transaction Selection Example 55
Figure II - 5- Issuer Script Format 63
Figure II - 6- Issuer Script Command Format (Shown with Three Commands) 63
Figure II- 7 - Chip Electronic Commerce System 100
Figure II- 8 - Diagram of Chip Electronic Commerce transaction flow 111
Figure E- 1 - Cardholder System Flow Diagram 133
Figure G - 1 - Cardholder System components 136
Figure G - 2 - Hosted Cardholder System example 140
Figure G - 3 - Thick Client example 142
December, 2000 Scope vii
1. Scope
The Integrated Circuit Card Application Specification for Payment Systems
(hereinafter referred to simply as ‘the Application Specification’) defines the
terminal and integrated circuit card (ICC) procedures necessary to effect a payment
system transaction in an international interchange environment.
In particular it covers:
• Transaction flow (the sequence of events and the commands issued to the card)
• Exception processing
¾Data elements for financial interchange and their mapping onto data objects.
¾Structure and coding of messages between the ICC and the terminal to achieve
application level functions.
The functions described are those necessary to ensure that payment system cards
conforming to this specification can perform the set of common core functions in all
terminals conforming to this specification. Application functions unique to
individual payment systems and those functions not performed in interchange are
not described, but are not precluded.
This specification does not address clearing and settlement or any transactions
where the ICC is not present.
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 - A message sent by the terminal to the ICC that initiates an action and
solicits a response from the ICC.
Issuer Action Code - reflects the issuer’s selected action to be taken based upon
the content of the TVR.
Response - A message returned by the ICC to the terminal after the processing of a
command message received by the ICC.
December, 2000 Definitions xi
Terminal - The device used in conjunction with the ICC at the point of transaction
to perform a financial transaction. It incorporates the interface device and may also
include other components and interfaces such as host communications.
Terminal Action Code - Terminal Action Code(s) (Default, Denial, Online) reflects
the acquirer-selected action to be taken upon the content of the TVR.
xii Abbreviations and Notations December, 2000
AC Application Cryptogram
an Alphanumeric
b Binary
C Celsius or Centigrade
cn Compressed Numeric
DF Dedicated File
DIR Directory
EF Elementary File
hex. Hexadecimal
IC Integrated Circuit
I/O Input/Output
KM Master Key
KS Session Key
LEN Length
M Mandatory
max. Maximum
MF Master File
min. Minimum
n Numeric
O Optional
P1 Parameter 1
P2 Parameter 2
P3 Parameter 3
TC Transaction Certificate
var. Variable
# Number
A ≡ B mod n Integers A and B are congruent modulo the integer n, that is,
there exists an integer d such that
(A - B) = dn
A mod n The reduction of the integer A modulo the integer n, that is, the
unique integer 0 ≤ r < n for which there exists an integer d
such that
A = dn + r
Xx Any value
An item of information is called a data element. A data element is the smallest piece
of information that may be identified by a name, a description of logical content, a
format, and a coding.
Any additional data element transmitted in the response to the SELECT command
(e.g. O/S Manufacturer proprietary data) is placed in the field “FCI Issuer
Discretionary Data” (EMV tag ‘BF0C’).
Upon receipt, the terminal shall parse all the data elements following the rules
described in Annex B. The retrieved value fields of the data elements shall be stored
in the terminal buffer for possible later use in the application.
The terminals shall be capable of correctly interpreting TLV data objects with a
length field coded '00’ as defined in ISO/IEC 7816. This situation can occur, when a
data element is personalised on a card without an actual value field. A data element
with length ‘00’ shall be treated as not present. The data element length indicated
in Annex A, reflects the length of the data elements when actually present on the
card.
2 Data Elements and Files December, 2000
Table A-1 and Table A-2 in Annex A describes the mapping of data elements onto
data objects and the mapping of data objects into templates when applicable.
Records are templates containing one or more primitive and/or constructed data
objects.
The mapping of data objects into records is left to the discretion of the issuer and the
manner in which data elements are to be used is described in Part II of this book.
Annex B defines the tags that are reserved by this specification for EMV, the
payment systems, and issuers. All ICC applications conforming to this specification
shall comply with this coding and allocation scheme in accordance with ISO/IEC
7816-6.
1.3 Files
The data objects contained in data files accessible from the ICC are stored in
records. The file structure and referencing method depend on the purpose of the file.
Structures and referencing methods are described in the following sections. The
layout of the data files accessible from the ICC is left to the discretion of the issuer
except for the directory files described in the following section.
Any ADF or DDF in the card is referenced by its DF name. A DF name for an ADF
corresponds to the AID or contains the AID as the beginning of the DF name. Each
DF name shall be unique within a given card.
SFIs are used for the selection of AEFs. Any AEF within a given application is
referenced by a SFI coded on 5 bits in the range 1 to 30. The coding of the SFI is
described in every command that uses it.
Value Meaning
1-10 Governed by this specification
11-20 Payment system specific
21-30 Issuer specific
A SFI shall be unique within an application. The coding of SFIs within the range 1
to 10 is used to address AEFs governed by this specification.
A DOL is a concatenated list of entries, with each entry representing a single data
element to be included in the constructed field. The format of each entry is a one- or
two-byte tag identifying the desired data object, followed by a one-byte length,
representing the number of bytes the field shall occupy in the command data. Only
tags representing primitive data objects defined in Annex B shall be used in DOLs.
The terminal shall complete the following steps to build the constructed field:
2. Concatenate together all data elements listed in the DOL. The following
rules apply to the creation of this concatenation:
a) If the tag of any data object identified in the DOL is unknown to the
terminal or represents a constructed data object, the terminal shall
provide a data element with the length specified and a value of all
hexadecimal zeroes.
c) If the length specified in the DOL entry is less than the length of the
actual data object, the leftmost bytes of the data element shall be
truncated if the data object has numeric (n) format, or the rightmost
bytes of the data shall be truncated for any other format. If the length
specified is greater than the actual data, the actual data shall be
padded:
• With leading hexadecimal zeroes if the data has numeric format
• With trailing hexadecimal FF’s if the data has compressed
numeric (cn) format,
• With trailing hexadecimal zeroes for any other format (an or ans).
The completed list of data elements shall be concatenated in the sequence in which
the corresponding data objects appear in the DOL.
December, 2000 Commands for Financial Transaction 5
The number of data bytes sent in the command APDU is denoted by Lc (length of
command data field).
The maximum number of data bytes expected in the response APDU is denoted by
length of expected data (Le) . When Le is present and contains the value zero, the
maximum number of available data bytes (up to 256) is expected . When required in
a command message, Le shall always be set to ‘00’.
Hex. Meaning
‘0’ Inter-industry command
‘8’ Proprietary to this specification
Any other Outside the scope of this specification
value
The least significant nibble of the class byte codes secure messaging and logical
channel mechanisms, according to ISO/IEC 7816-4.
Note: Additional INS codes may be assigned in the future in the PSE context using the class ‘8x’. It is
strongly recommended not to define proprietary commands in the class ‘8x’ when they are to be used in
the PSE context, so that collision is avoided.
When present, an APDU response data field consists of a data object or a string of
data objects encapsulated in a template according to Annex B.
SW1 SW2
The following values of SW1 SW2 are described in Book 1, Part I of this specification
as they apply to the TPDU and are not returned to the APDU:
SW1 = ‘6x’ or ‘90’ denotes a normal, warning, or error condition coded according to
ISO/IEC 7816-4.
Other values of SW1 returned by the ICC are not supported by Book1, Part I.
Table I-5 shows the coding of the SW1SW2 status bytes which this specification
requires to be returned in response to specific conditions. The card may generate
December, 2000 Commands for Financial Transaction 9
status bytes not listed in this table for error and warning conditions not specified in
the ICC Application Specification described in Part II of this book.
INTERNAL AUTHENTICATE
PIN CHANGE/UNVBLOCK
APPLICATION UNBLOCK
APPLICATION BLOCK
GET CHALLENGE
READ RECORD
CARD BLOCK
GET DATA
SELECT
VERIFY
SW1 SW2
‘62’ ‘83’ X
‘63’ ‘00’ X
‘63’ ‘Cx’ X
‘69’ ‘83’ X
‘69’ ‘84’ X
‘69’ ‘85’ X X X
‘6A’ ‘81’ X X
‘6A’ ‘82’ X
‘6A’ ‘83’ X
‘6A’ ‘88’ X
To allow for migration and support of new functionality, the IC Card and the
terminal shall not verify the data indicated as RFU.
A card may support more than one logical channel but only the basic logical channel
is supported by this specification. This limits to one the number of concurrent
applications according to this specification.
2.5 Commands
This section describes the following APDU command-response pairs:
• An invalidated application shall return the status bytes ‘Selected file invalidated’
(SW1 SW2 = ‘6283’) in response to a SELECT command.
Code Value
CLA ‘8C’ or ‘84’; coding according to the secure messaging
specified in Book 2 of this specification
INS ‘1E’
P1 ‘00’; all other values are RFU
P2 ‘00’; all other values are RFU
Lc Number of data bytes
Data Message Authentication Code (MAC) data
component; coding according to the secure messaging
specified in Book 2 of this specification
Le Not present
The data field of the command message contains the MAC data component coded
according to the secure messaging format specified in Book 2 of this specification.
Code Value
CLA ‘8C’ or ‘84’; coding according to the secure messaging
specified in Book 2 of this specification
INS ‘18’
P1 ‘00’; all other values are RFU
P2 ‘00’; all other values are RFU
Lc Number of data bytes
Data MAC data component; coding according to the secure
messaging specified in Book 2 of this specification
Le Not present
The data field of the command message contains the MAC data component coded
according to the secure messaging format specified in Book 2 of this specification.
The CARD BLOCK command shall disable all applications in the ICC, including
applications that may be selected implicitly.
Code Value
CLA ‘8C’ or ‘84’; coding according to the secure messaging
specified in Book 2 of this specification
INS ‘16’
P1 ‘00’; all other values are RFU
P2 ‘00’; all other values are RFU
Lc Number of data bytes
Data MAC data component; coding according to the secure
messaging specified in Book 2 of this specification
Le Not present
The data field of the command message contains the MAC data component coded
according to the secure messaging format specified in Book 2 of this specification.
‘9000’ codes a successful execution of the command, independent of whether the card
was already blocked or not.
The response from the ICC consists of returning the processing state of the
command.
Code Value
CLA ‘00’
INS ‘82’
P1 ‘00’
P2 ‘00’
Lc 8-16
Data Issuer Authentication Data
Le Not present
The data field of the command message contains the value field of tag ‘91’ coded as
follows:
Type Meaning
Application Authentication Transaction declined
Cryptogram (AAC)
Application Authorisation Referral Referral requested by the card
(AAR)
Authorisation Request Cryptogram Online authorisation requested
(ARQC)
Transaction Certificate Transaction approved
(TC)
The cryptogram returned by the ICC may differ from that requested in the command
message according to an internal process in the ICC (as described in Part II ).
Code Value
CLA ‘80’
INS ‘AE’
P1 Reference control parameter
(see Table I - 12)
P2 ‘00’
Lc Var.
Data Transaction-related data
Le ‘00’
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 AAC
0 1 TC
1 0 ARQC
1 1 RFU
0 Combined
DDA/AC
generation not
explicitly
requested
1 Combined
DDA/AC
generation
requested
x x x x x RFU
The content of the data field of the command message is coded according to the rules
for the data object list as defined in section 1.4.
The data field of the response message consists of a BER-TLV coded data object.
The coding of the data object shall be according to one of the following two formats.
• Format 1: The data object returned in the response message is a primitive data
object with tag equal to ‘80’. The value field consists of the concatenation without
delimiters (tag and length) of the value fields of the data objects specified in Table
I - 13:
Value Presence
Cryptogram Information Data M
Application Transaction Counter (ATC) M
Application Cryptogram (AC) M
Issuer Application Data O
For both formats, the Cryptogram Information Data returned by the GENERATE
AC response message is coded according to Table I - 14:
b8 b7 b6 b5 b4 b3 b2 B1 Meaning
0 0 AAC
0 1 TC
1 0 ARQC
1 1 AAR
x x Payment System specific
cryptogram
0 No advice required
1 Advice required
x x x Reason/advice/referral code
0 0 0 No information given
0 0 1 Service not allowed
0 1 0 PIN Try Limit exceeded
0 1 1 Issuer authentication failed
x x x Other values RFU
The challenge shall be valid only for the next issued command.
Code Value
CLA ‘00’
INS ‘84’
P1 ‘00’
P2 ‘00’
Lc Not present
Data Not present
Le ’00’
The data field of the response message contains an 8-byte unpredictable number
generated by the ICC.
The GET DATA command is used to retrieve a primitive data object not
encapsulated in a record within the current application.
The usage of the GET DATA command in this specification is limited to the retrieval
of the primitive data objects ATC (tag ‘9F36’), Last Online ATC Register (tag ‘9F13’),
or PIN Try Counter (tag ‘9F17’) defined in Annex A, Table A-1 that are interpreted
by the application in the ICC.
Code Value
CLA ‘80’
INS ‘CA’
P1 P2 ‘9F36’, ‘9F13’, or ‘9F17’
Lc Not present
Data Not present
Le ‘00’
The data field of the response message contains the primitive data object referred to
in P1 P2 of the command message (in other words, including its tag and its length).
The GET PROCESSING OPTIONS command initiates the transaction within the
ICC.
The response from the ICC consists of returning the Application Interchange Profile
(AIP) and the Application File Locator (AFL).
Code Value
CLA ‘80’
INS ‘A8’
P1 ‘00’; all other values are RFU
P2 ‘00’; all other values are RFU
Lc var.
Data Processing Options Data Object List
(PDOL) related data
Le ‘00’
The data field of the command message is a data object coded according to the
Processing Options Data Object List (PDOL) provided by the ICC, as defined in
section 1.4, and is introduced by the tag ‘83’. When the data object list is not
provided by the ICC, the length field of the template is set to zero. Otherwise, the
length field of the template is the total length of the value fields of the data objects
transmitted to the ICC.
The data field of the response message consists of a BER-TLV coded data object.
The coding of the data object shall be according to one of the following two formats.
• Format 1: The data object returned in the response message is a primitive data
object with tag equal to ‘80’. The value field consists of the concatenation without
delimiters (tag and length) of the value fields of the Application Interchange
Profile (AIP) and the Application File Locator (AFL). The coding of the data
object returned in the response message is shown in Table I - 18:
Table I - 18- Format 1 GET PROCESSING OPTIONS Response Message Data Field
The AIP specifies the application functions that are supported by the application in
the ICC and is coded according to Part II of this book.
The AFL consists of the list without delimiters of files and related records that shall
be read according to the ICC Application Specification described in Part II of this
book for the currently selected application.
December, 2000 Commands for Financial Transaction 21
The response from the ICC consists of returning the Signed Dynamic Application
Data to the terminal.
Code Value
CLA ‘00’
INS ‘88’
P1 ‘00’
P2 ‘00’
Lc Length of authentication-related data
Data Authentication-related data
Le ‘00’
The data field of the command message contains the authentication-related data
proprietary to an application. It is coded according to the Dynamic Data
Authentication Data Object List (DDOL) as defined in Book 2 of this specification.
The data field of the response message consists of a BER-TLV coded data object.
The coding of the data object shall be according to one of the following two formats.
22 Commands for Financial Transaction December, 2000
• Format 1: The data object returned in the response message is a primitive data
object with tag equal to ‘80’. The value field consists of the value field of the
Signed Dynamic Application Data as specified in Book 2 of this specification.
• The value of the PIN Try Counter shall be reset to the value of the PIN Try
Limit.
• If requested, the value of the reference PIN shall be set to the new PIN value.
The PIN data transmitted in the command, if present, shall be enciphered for
confidentiality.
Note: The reference PIN, which is stored within the card, is the one that is associated with the
application and which the card uses to check the Transaction PIN Data transmitted within the
VERIFY command.
Code Value
CLA ‘8C’ or ‘84’; coding according to the secure
messaging specified in Book 2 of this
specification
INS ‘24’
P1 ‘00’
P2 ‘00’, ‘01’, or ‘02’
Lc Number of data bytes
Data Enciphered PIN data component, if present,
and MAC data component; coding according to
the secure messaging specified in Book 2 of this
specification
Le Not present
P2: If P2 is equal to ‘00’, the reference PIN is unblocked and the PIN Try Counter
is reset to the PIN Try Limit. There is no PIN update, since the PIN
CHANGE/UNBLOCK command does not contain a new PIN value.
Any other value of P2 allowing PIN unblocking and/or PIN changing is out of
the scope of this specification and shall be described for each payment system
individually.
The data field of the command message contains the PIN data component, if present,
followed by the MAC data component coded according to the secure messaging
format specified in Book 2 of this specification.
Code Value
CLA ‘00’
INS ‘B2’
P1 Record number
P2 Reference control parameter (see
Table I - 22)
Lc Not present
Data Not present
Le ‘00’
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x x SFI
1 0 0 P1 is a record number
The data field of the response message of any successful READ RECORD command
contains the record read. For SFIs in the range 1-10, the record is a BER-TLV
constructed data object as defined in Annex B and coded as shown in Table I - 23:
The response message to READ RECORD for SFIs outside the range 1-10 is outside
the scope of this specification.
The VERIFY command initiates in the ICC the comparison of the Transaction PIN
Data sent in the data field of the command with the reference PIN data associated
with the application. The manner in which the comparison is performed is
proprietary to the application in the ICC.
The VERIFY command applies when the Cardholder Verification Method (CVM)
chosen from the CVM List is an offline PIN, as described in Part II of this book.
Code Value
CLA ‘00’
INS ‘20’
P1 ‘00’
P2 Qualifier of the reference data (see Table I-33)
Lc var.
Data Transaction PIN Data
Le Not present
b8 b7 B6 b5 b4 b3 B2 b1 Meaning
0 0 0 0 0 0 0 0 As defined in ISO/IEC 7816-4 1
1 0 0 0 0 0 0 0 Plaintext PIN, format as defined below
1 0 0 0 0 x x x RFU for this specification
1 0 0 0 1 0 0 0 Enciphered PIN, format as defined in
Book 2
1 0 0 0 1 0 x x RFU for this specification
1 0 0 0 1 1 x x RFU for the individual payment
systems
1 0 0 1 x x x x RFU for the issuer
The processing of the VERIFY command in the ICC will be defined in combination
with the CVM rules as specified in Part II of this book.
where:
Name Value
C Control field Binary 2 (hex. 0010)
N PIN length 4-bit binary number with permissible values of hex.
0100 to hex. 1100
P PIN digit 4-bit field with permissible values of hex. 0000 to
hex. 1001
P/F PIN/filler Determined by PIN length
F Filler 4-bit binary number with value of hex. 1111
The data field of the command message contains the value field of tag ‘99’.
When for the currently selected application the comparison between the Transaction
PIN Data and the reference PIN data performed by the VERIFY command fails, the
ICC shall return SW2 = ‘Cx’, where ‘x’ represents the number of retries still possible.
When the card returns ‘C0’, no more retries are left, and the CVM shall be blocked.
Any subsequent VERIFY command applied in the context of that application shall
then fail with SW1 SW2 = ‘6983’.
Part II
Debit and Credit Application
Specification
December, 2000 Files for Financial Transaction Interchange 29
• All files accessible using the READ RECORD command as defined in the Card
Specification containing data objects defined in the Card Specification shall use
short file identifiers (SFIs) in the range 1 to 10. These files:
− Shall be linear files readable using the READ RECORD command as described
in the Card Specification.
− May contain multiple records. Each record is limited to 254 bytes, including tag
and length.
− Each record shall be coded as a constructed data object. The tag of the
constructed data object shall be ‘70’ indicating a template proprietary to this
specification, and the length field shall contain the total length of the
encapsulated data objects.
− Shall contain only data objects defined in this specification and coded in
accordance with the Basic Encoding Rules - Tag Length Value (BER-TLV)
described in Annex B.
− May have access conditions to be satisfied for updates, but must be readable
unconditionally.
• Files with SFIs in the range 11 to 20 are reserved for proprietary data to be
specified by the individual payment systems.
• Files with SFIs in the range 21 to 30 are reserved for proprietary data to be
specified by the issuer.
• The Application File Locator (AFL) determines the files and records to be used
for processing a transaction. The use of the AFL is described in section 6.2. The
data objects listed in Table II - 1 are used by the offline data authentication
algorithm and, when present, should be located in the first record referenced by
the AFL.2
2This allows the terminal to optionally perform the hashing necessary for data
authentication in parallel with reading and parsing of data for other purposes.
30 Files for Financial Transaction Interchange December, 2000
Tag Value
‘8F’ Certification Authority Public Key Index
‘90’ Issuer Public Key Certificate
Table II - 3 lists the data objects that must be present if the ICC supports offline
static data authentication. Table II - 4 lists the data objects that must be present if
the ICC supports offline dynamic data authentication.3 Offline data authentication
is required to support offline transactions but is optional in cards that support only
online transactions.
Tag Value
‘8F’ Certification Authority Public Key Index
‘90’ Issuer Public Key Certificate
‘93’ Signed Static Application Data
‘92’ Issuer Public Key Remainder
‘9F32’ Issuer Public Key Exponent
3The exception may be that the Issuer Public Key Remainder or the ICC Public Key
Remainder could be absent. This is because if the public key modulus can be
recovered in its entirety from the public key certificate there is no need for a
remainder.
December, 2000 Files for Financial Transaction Interchange 31
Tag Value
‘8F’ Certification Authority Public Key Index
‘90’ Issuer Public Key Certificate
‘92’ Issuer Public Key Remainder
‘9F32’ Issuer Public Key Exponent
‘9F46’ ICC Public Key Certificate
‘9F47’ ICC Public Key Exponent
‘9F48’ ICC Public Key Remainder
‘9F49’ Dynamic Data Authentication Data Object
List (DDOL)4
Of the objects listed here, only the Application Transaction Counter (ATC) is a
mandatory data object, and it can be retrieved by either the GET DATA command or
in the response to a GENERATE APPLICATION CRYPTOGRAM (AC) command.
The terminal retrieves the ATC via the GET DATA command only if the ICC
contains the Lower Consecutive Offline Limit and Upper Consecutive Offline Limit
data objects. If the issuer does not wish terminal velocity checking to be performed
and omits these data objects, the ICC does not need to support the GET DATA
command.
4In case the DDOL is not present in the card, the Default DDOL shall be used in
stead.
32 Files for Financial Transaction Interchange December, 2000
When any mandatory data object is missing, the terminal terminates the
transaction. When an optional data object is required because of the existence of
other data objects or to support functions that must be performed due to the setting
of bits in the Application Interchange Profile, the terminal sets to ‘1’ the ‘ICC data
missing’ indicator in the TVR.
Table II - 7 summarises the conditions under which this bit should be set to ‘1’. If
none of the conditions in Table II- 7 apply, the bit shall be set to ‘0’. The setting of
this bit is in addition to any other actions specified in other sections of this
document.
Issuer Public Key ‘92’ Not present and AIP indicates offline static or
Remainder dynamic data authentication is supported and the
‘length of the Issuer Public Key’, as recovered
from the Issuer Public Key Certificate, indicates
that there was insufficient space for the entire
Issuer’s Public Key in the certificate
Last Online ‘9F13’ Last Online ATC Register is not returned by GET
Application DATA command and both Lower and Upper
Transaction Counter Consecutive Offline Limits are present
(ATC) Register
Signed Static ‘93’ Not present and AIP indicates offline static data
Application Data authentication is supported
ICC Public Key ‘9F46’ Not present and AIP indicates offline dynamic
Certificate data authentication is supported
ICC Public Key ‘9F47’ Not present and AIP indicates offline dynamic
Exponent data authentication is supported
ICC Public Key ‘9F48’ Not present and AIP indicates offline dynamic
Remainder data authentication is supported and the ‘length
of the ICC Public Key’, as recovered from the ICC
Public Key Certificate, indicates that there was
insufficient space for the entire ICC’s Public Key
in the certificate
It is up to the issuer to ensure that data in the card is of the correct format, and no
format checking other than that specifically defined is mandated on the part of the
terminal. However, if in the course of normal processing the terminal recognises
that data is incorrectly formatted (for example, constructed data objects that do not
parse correctly), the terminal shall terminate processing. This rule includes (but is
not limited to):
4 Transaction Flow
The Application Interchange Profile specifies the application functions that are
supported by the card. The terminal shall attempt to execute only those
functions that the ICC supports.
Book 1 describes all functionality outside the application layer, including the
selection of the application. The functions described here begin after application
selection has taken place.
The remainder of this book deals with the terminal-to-ICC dialogue on the level
of the application logical functions. Two transaction flows are described:
• Section 6 Functions used in Transaction Processing.
• Annex D Transaction Processing for Chip Electronic Commerce
5Other actions may be taken by prior agreement but are outside the scope of this
specification.
December, 2000 Transaction Flow 35
Initiate
Application
Read
Application
Data
Processing
Restrictions
Cardholder
Verification
Terminal
Action Analysis
Card Action
Analysis
Online
Online /
Offline Online
Processing &
Decision Issuer
Authentication
Offline
Script
Completion
Processing
The Application Interchange Profile indicates the functions supported in the ICC
according to this specification. Most of the bits in this data object are reserved
for future use (RFU). When a new function is added, a bit in the Application
Interchange Profile will be allocated to indicate support for the new function, and
this specification will be updated to specify the new function and where it fits
into the transaction flow.
Proprietary functions may be added to the terminal and the ICC application as
long as they do not interfere with processing of terminals and ICCs not
implementing the function. For example, offline dynamic data authentication
based on symmetric keys may be added at local option. Such proprietary
functions, while not described in this specification, are not precluded, as long as
the functions specified herein continue to be supported for ICCs not
implementing the proprietary functions.
December, 2000 Generate AC Command Coding 37
The complete transaction flow is not shown in these charts, only the GENERATE
AC commands, responses, and associated decisions.
38 Generate AC Command Coding December, 2000
Earlier
Processing
Online
Terminal Terminal
Terminal
Requests Requests
Requests TC
AAC ARQC
Card
Card Card
responds Reject Refer Online Offline
decision decision
with AAC
Approve Reject
Online Refer
Referral
Completed Processing
No
Online? (see Figure 6)
Authorization
TAC/IAC-
Approve Reject Response
Default
Code
Reject Approve
Terminal
Terminal
requests
requests TC
AAC
Card
Card
returns TC
returns AAC
or AAC
Card initiates
referral processing
External procedures
may take effect.
See payment systems
documentation.
Terminal Terminal
selects Offline supplies Auth.
option Response Code
Online
Approve
Online Auth
Terminal
Response Approve
Requests TC
Code
Reject
Approve
Card Card
returns AAC returns TC
The ICC shall respond to the first GENERATE AC command with any of the
following:
• TC
• ARQC
• AAR
• AAC
The possible responses listed above are in hierarchical order, with a TC being the
highest and an AAC being the lowest. The terminal may request a TC, an
ARQC, or an AAC. If the ICC responds with a cryptogram at a higher level, this
indicates a logic error in the ICC. If this occurs after the first GENERATE AC
command in a transaction, the transaction shall be terminated. If it occurs after
the second GENERATE AC command, all processing for the transaction has been
completed, and the cryptogram returned shall be treated as an AAC.
• If the terminal decides to reject the transaction, it requests an AAC from the
ICC. The ICC shall reply with an AAC.
If the ICC responds with a TC or an AAC, the terminal completes the transaction
offline.
If the ICC responds with an AAR, the terminal either provides an Authorisation
Response Code and proceeds to the completion function or uses the AAR to go
online. See Figure II – 3 for referral processing logic.
42 Generate AC Command Coding December, 2000
If the ICC responds with an ARQC, the terminal attempts to go online, sending
an authorisation request message to the issuer. Included in the authorisation
request message is the ARQC for online card authentication.
Conditions of Execution:
The terminal shall always execute this function.
Sequence of Execution:
This is the first function performed after application selection.
Description:
The terminal sets all bits in the Transaction Status Information (TSI) and the
Terminal Verification Results (TVR) to ‘0’.6
The Processing Options Data Object List (PDOL) is a list of tags and lengths of
terminal-resident data elements needed by the ICC in processing the GET
PROCESSING OPTIONS command. Only data elements identified in the Card
Specification as having the terminal as the source of the data may be referenced
in the PDOL.
If the PDOL does not exist, the GET PROCESSING OPTIONS command uses a
command data field of ‘8300’, indicating that the length of the value field in the
command data is 0.
If the PDOL exists, the terminal extracts the PDOL from the FCI of the ADF and
uses it to create a concatenated list of data elements without tags or lengths.
The rules specified in section 1.4 (see ‘Rules for Processing a Data Object List
(DOL)’) apply to processing of the PDOL. If an amount field (either Amount,
Authorised or Amount, Other) is referenced in the PDOL and 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.
The terminal issues the GET PROCESSING OPTIONS command using either
the command data field of ‘8300’ (if there was no PDOL in the ICC) or a data
object constructed with a tag of ‘83’ and the appropriate length according to
6 There may be some exceptions in the timing for this. For example, these bits
could be set to ‘0’ at the completion of the previous transaction or prior to
application selection of this transaction. The intent here is that the processing
steps as described in the Application Specification presume the bits have been
initialised to ‘0’.
44 Functions Used in Transaction Processing December, 2000
BER-TLV encoding rules and a value field that is the concatenated list of data
elements resulting from processing the PDOL. The card returns either:
• Status SW1 SW2 = ‘6985’ (‘Conditions of use not satisfied’), indicating that
the transaction cannot be performed with this application.
If the status words ‘6985’ are returned, the terminal shall eliminate the current
application from consideration and return to the application selection function to
select another application.
Conditions of Execution:
The terminal shall always execute this function.
Sequence of Execution:
The read application data function is performed immediately following the
initiate application function.
Description:
The terminal shall read the files and records indicated in the Application File
Locator using the READ RECORD command identifying the file by its SFI. If an
error prevents the terminal from reading data from the ICC, the transaction
shall be terminated (see section 4.1).
The AFL is a list identifying the files and records to be used in the processing of a
transaction. The terminal is to read only the records named in the AFL. Each
element of the list corresponds to a file to be read and is structured as follows:
• The first byte codes the SFI in the five most significant bits. The three least
significant bits of the first byte shall be set to zero.
• The second byte codes the first (or only) record number to be read for that SFI.
The second byte shall never be set to zero.
• The third byte codes the last record number to be read for that SFI. Its value
is either greater than or equal to the second byte. When the third byte is
greater than the second byte, all the records ranging from the record number
in the second byte to and including the record number in the third byte shall
December, 2000 Functions Used in Transaction Processing 45
be read for that SFI. When the third byte is equal to the second byte, only the
record number coded in the second byte shall be read for that SFI.
• The fourth byte codes the number of records involved in offline data
authentication starting with the record number coded in the second byte. The
fourth byte may range from zero to the value of the third byte less the value of
the second byte plus 1.
The terminal shall process each entry in the AFL from left to right. A READ
RECORD command as described in section 2.5.11 shall be issued for each record
between the starting record number and the ending record number, inclusively.
Any SW1 SW2 other than ‘9000’ passed to the application layer as a result of
reading any record shall cause the transaction to be terminated. Records
specified in the AFL to be included in offline data authentication shall be
processed as described in section 6.3.
The terminal shall store all recognised data objects read, whether mandatory or
optional, for later use in the transaction processing. Data objects that are not
recognised by the terminal (that is, their tags are unknown by the terminal) shall
not be stored, but records containing such data objects may still participate in
their entirety in offline data authentication, depending upon the coding of the
AFL.
All mandatory data objects shall be present in the card. If any mandatory data
objects are not present, the terminal shall terminate the transaction.
Redundant primitive data objects are not permitted. If the terminal encounters
more than one occurrence of a single primitive data object while reading data
from the ICC, the transaction shall be terminated.
Proprietary data files may or may not conform to this specification. Records in
proprietary files may be represented in the AFL and may participate in offline
data authentication if they are readable without conditions by the READ
RECORD command coded according to the Card Specification. Otherwise, the
reading and processing of proprietary files is beyond the scope of this
specification.
Conditions of Execution:
Availability of data in the ICC to support offline data authentication is optional;
its presence is indicated in the Application Interchange Profile. If both the
terminal and the ICC support offline data authentication, the terminal shall
perform this function. Depending on the capabilities of the card and the
46 Functions Used in Transaction Processing December, 2000
If both of the following are true, the terminal shall perform the Combined
Dynamic Data Authentication/Application Cryptogram Generation as specified in
Book 2:
• The Application Interchange Profile indicates that the card supports the
Combined Dynamic Data Authentication/Application Cryptogram Generation.
If all of the following are true, the terminal shall perform offline dynamic data
authentication as specified in Book 2:
• The Application Interchange Profile indicates that the card supports offline
dynamic data authentication.
• Either the card or terminal (or both) does not support Combined Dynamic
Data Authentication/Application Cryptogram Generation.
If all of the following are true, the terminal shall perform offline static data
authentication as specified in the Card Specification:
• The Application Interchange Profile indicates that the card supports offline
static data authentication.
• Either the card or the terminal (or both) does not support offline dynamic
data authentication
• Either the card or terminal (or both) does not support Combined Dynamic
Data Authentication/Application Cryptogram Generation.
Sequence of Execution:
The terminal shall perform offline data authentication in any order after Read
Application Data but before completion of the terminal action analysis.
Description:
Offline static data authentication authenticates static data put into the card by
the issuer. Offline dynamic data authentication authenticates ICC-resident data,
data from the terminal, and the card itself.
December, 2000 Functions Used in Transaction Processing 47
Input to the authentication process is formed from the records identified by the
AFL, followed by the data elements identified by the optional Static Data
Authentication Tag List (tag ‘9F4A’).
The data from each record to be included in the offline data authentication input
depends upon the SFI of the file from which the record was read.
• For files with SFI in the range 1 to 10, the record tag (‘70’) and the record
length are excluded from the offline data authentication process. All other
data in the data field of the response to the READ RECORD command
(excluding SW1 SW2) is included.
• For files with SFI 11-30, all data in the data field (excluding SW1 SW2) is
included.
The bytes of the record are included in the concatenation in the order in which
they appear in the command response.
After all records identified by the AFL have been processed, the Static Data
Authentication Tag List is processed, if it exists. If the Static Data
Authentication Tag List exists, it shall contain only the tag for the Application
Interchange Profile. The tag must represent the AIP available in the current
application. The value field of the AIP is to be concatenated to the current end of
the input string. The tag and length of the AIP are not included in the
concatenation.
Building of the input list for offline data authentication is considered the first
step in the offline data authentication process. If the input cannot be built
because of a violation of one of the above rules but offline data authentication
should be performed according to the ‘Conditions of Execution’ above, offline data
authentication shall be considered to have been performed and to have failed;
that is, the terminal shall set to ‘1’ the ‘Offline data authentication was
performed’ bit in the TSI and the appropriate ‘Offline static data authentication
failed’ or ‘Offline dynamic authentication failed’ bit shall be set in the TVR.
See Book 2 for additional steps to be performed for offline data authentication. If
offline static data authentication is performed but is unsuccessful, the ‘Offline
static data authentication failed’ bit shall be set to ‘1’ in the TVR, otherwise it
shall be set to ‘0’.
Upon completion of the offline data authentication function, the terminal shall
set to ‘1’ the ‘Offline data authentication was performed’ bit in the TSI.
Conditions of Execution:
The terminal shall always execute this function.
Sequence of Execution:
Functions described here may be performed at any time after Read Application
Data and prior to completion of the terminal action analysis.
Description:
The processing restrictions function is described as comprising the following
compatibility checks:
• If the transaction is being conducted at an ATM, the ‘Valid at ATMs’ bit must
be on in Application Usage Control.
If the Application Usage Control and Issuer Country Code are both present in the
ICC, the terminal shall make the following checks:
• If the Transaction Type indicates that this is a cash transaction and the
Issuer Country Code matches the Terminal Country Code, the ‘Valid for
domestic cash transactions’ bit must be on in Application Usage Control.
• If the Transaction Type indicates that this is a cash transaction and the
Issuer Country Code does not match the Terminal Country Code, the ‘Valid
for international cash transactions’ bit must be on in Application Usage
Control.
• If the Transaction Type indicates a purchase of goods and the Issuer Country
Code matches the Terminal Country Code, the ‘Valid for domestic goods’ bit
must be on in Application Usage Control.
• If the Transaction Type indicates a purchase of goods and the Issuer Country
Code does not match the Terminal Country Code, the ‘Valid for international
goods’ bit must be on in Application Usage Control.
• If the transaction has a cashback amount and the Issuer Country Code
matches the Terminal Country Code, the ‘Domestic cashback allowed’ bit
must be on in Application Usage Control.
• If the transaction has a cashback amount and the Issuer Country Code does
not match the Terminal Country Code, the ‘International cashback allowed’
bit must be on in Application Usage Control.
If any of the above tests fail, the ‘Requested service not allowed for card product’
bit shall be set to ‘1’ in the TVR.
Expiration Date. If it is not, the ‘Expired application’ bit shall be set to ‘1’ in the
TVR.
Conditions of Execution:
Ability of the ICC to support at least one cardholder verification method is
indicated in the Application Interchange Profile. If this bit is set to ‘1’, the
terminal shall use the cardholder verification related data in the ICC to
determine whether one of the issuer-specified cardholder verification methods
(CVMs) shall be executed. This process is described below.
Sequence of Execution:
This function may be performed any time after Read Application Data and before
completion of the terminal action analysis.
Description:
The CVM List (tag ‘8E’) is a composite data object consisting of the following:
2. A second amount field (4 bytes, binary format), referred to as ‘Y’ in the CVM
Condition Codes (see Annex C.3 - Cardholder Verification Rule Format). ‘Y’ is
expressed in Application Currency Code with implicit decimal point. For
example, 123 (hexadecimal ‘7B’) represents £1.23 when the currency code is
‘826’.
If the CVM List is not present in the ICC, the terminal shall terminate
cardholder verification without setting the ‘Cardholder verification was
performed’ bit in the TSI.
If the CVM List is present in the ICC, the terminal shall process each rule in the
order in which it appears in the list according to the following specifications.
Cardholder verification is completed when any one CVM is successfully
performed or when the list is exhausted.
December, 2000 Functions Used in Transaction Processing 51
• The conditions expressed in the second byte of a CVR are not satisfied, or
• The ICC data required by the condition (for example, the Application
Currency Code) is not present, or
• The CVM Condition Code is outside the range of codes understood by the
terminal (which might occur if the terminal application program is at a
different version level than the ICC application),
the terminal shall bypass the rule and proceed to the next. If there are no more
CVRs in the list, cardholder verification has not been successful, and the
terminal shall set the ‘Cardholder verification was not successful’ bit to ‘1’ in the
TVR.
If the conditions expressed in the second byte of a CVR are satisfied, the terminal
shall attempt to perform the CVM if the CVM code is one of those listed in Annex
A or is otherwise understood by the terminal. If the conditions expressed in the
second byte of a CVR are satisfied, but the CVM is not among those listed and is
not understood by the terminal, the terminal shall set the ‘Unrecognised CVM’
bit to ‘1’ in the TVR.
If an offline PIN is the selected CVM as determined by the above process, offline
PIN processing may not be successfully performed for any one of the following
reasons:
• The terminal does not support offline PIN7. In this case, the terminal shall
set to ‘1’ the ‘PIN entry required and PIN pad not present or not working’ bit
in the TVR.
7 This means that the terminal does not support either offline plaintext PIN
verification or offline enciphered PIN verification. If the terminal supports at
least one of these functions, it is considered to support offline PIN for the
purposes of setting the TVR bits.
52 Functions Used in Transaction Processing December, 2000
• The terminal supports offline PIN, but the PIN pad is malfunctioning. In this
case, the terminal shall set to ‘1’ the ‘PIN entry required and PIN pad not
present or not working’ bit in the TVR.
• The terminal bypassed PIN entry at the direction of either the merchant or
the cardholder8. In this case, the ‘PIN entry required, PIN pad present, but
PIN was not entered’ bit shall be set to ‘1’ in the TVR. The terminal shall
consider this CVM unsuccessful, shall not set the CVM Results, and shall
continue cardholder verification processing in accordance with the card’s
CVM List.
• The PIN is blocked upon initial use of the VERIFY command (the ICC returns
SW1 SW2 = ‘6983’ or ‘6984’ in response to the VERIFY command). In this
case, the ‘PIN Try Limit exceeded’ bit shall be set to ‘1’ in the TVR.
The only case in which offline PIN processing is considered successful is when
the ICC returns an SW1 SW2 of ‘9000’ in response to the VERIFY command.
• The terminal does not support online PIN. In this case, the terminal shall set
to ‘1’ the ‘PIN entry required and PIN pad not present or not working’ bit in
the TVR.
• The terminal supports online PIN, but the PIN pad is malfunctioning. In this
case, the terminal shall set to ‘1’ the ‘PIN entry required and PIN pad not
present or not working’ bit in the TVR.
• The terminal bypassed PIN entry at the direction of either the merchant or
the cardholder. In this case, the ‘PIN entry required, PIN pad present, but
PIN was not entered’ bit shall be set to ‘1’ in the TVR.
If the online PIN is successfully entered, the terminal shall set to ‘1’ the ‘Online
PIN entered’ bit in the TVR. In this case, cardholder verification is considered
successful and complete.
Conditions of Execution:
Terminal risk management shall be performed if the ‘Terminal risk management
is supported’ bit is set to ‘1’ in the Application Interchange Profile. Random
transaction selection need not be performed by a terminal with no online
capability. If terminal risk management is not performed, sections 6.6.1 through
6.6.3 do not apply.
Sequence of Execution:
Terminal risk management may be performed at any time after Read Application
Data but before issuing the first GENERATE AC command.
Description:
Terminal risk management consists of:
• Velocity checking
the log is outside the scope of this specification, although to prevent split sales
the number of transactions stored may be quite small.
During terminal risk management floor limit checking, the terminal checks the
transaction log (if available) to determine if there is a log entry with the same
Application PAN, and, optionally, the same Application PAN Sequence Number.
If there are several log entries with the same PAN, the terminal selects the most
recent entry. The terminal adds the Amount, Authorised for the current
transaction to the amount stored in the log for that PAN to determine if the sum
exceeds the Terminal Floor Limit. If the sum is greater than or equal to the
Terminal Floor Limit, the terminal sets the ‘Transaction exceeds floor limit’ bit to
‘1’ in the TVR.
If the terminal does not have a transaction log available or if there is no log entry
with the same PAN, the Amount, Authorised is compared to the appropriate floor
limit. If the amount authorised is equal to or greater than the floor limit, the
‘Transaction exceeds floor limit’ bit is set to ‘1’ in the TVR.
• Target Percentage to be Used for Random Selection (in the range of 0 to 99)
Any transaction with a transaction amount less than the Threshold Value for
Biased Random Selection will be subject to selection at random without further
regard for the value of the transaction. The terminal shall generate a random
number in the range of 1 to 99. If this random number is less than or equal to
the Target Percentage to be Used for Random Selection, the transaction shall be
selected.
0
Biased Floor
Selection Limit
Threshold
If the transaction is selected through the process described in this section, the
‘Transaction selected randomly for online processing’ bit shall be set to ‘1’ in the
TVR.
Transaction Target Percent = ((Maximum Target Percent - Target Percent ) × Interpolation factor )
+ Target Percent
described in this section. If either of these data objects is not present in the ICC
application, the terminal shall skip this section.
The ATC and Last Online ATC Register shall be read from the ICC using GET
DATA commands. If either of the required data objects are not returned by the
ICC in response to the GET DATA command, the terminal shall:
• Set both the ‘Lower consecutive offline limit exceeded’ and the ‘Upper
consecutive offline limit exceeded’ bits to ‘1’ in the TVR.
• Not set the ‘New card’ indicator in the TVR.
If the required data objects are available, the terminal shall compare the
difference between the ATC and the Last Online ATC Register with the Lower
Consecutive Offline Limit to see if the limit has been exceeded. If the difference
is equal to the Lower Consecutive Offline Limit, this means that the limit has not
yet been exceeded. If the limit has been exceeded, the terminal shall set the
‘Lower consecutive offline limit exceeded’ bit to ‘1’ in the TVR and also compare
the difference with the Upper Consecutive Offline Limit to see if the upper limit
has been exceeded. If it has, the terminal shall set the ‘Upper consecutive offline
limit exceeded’ bit to ‘1’ in the TVR.
The terminal shall also check the Last Online ATC Register for a zero value. If it
is zero, the terminal shall set the ‘New card’ bit to ‘1’ in the TVR.
Upon completion of terminal risk management, the terminal shall set to ‘1’ the
‘Terminal risk management was performed’ bit in the TSI.
An offline decision made here is not final. If the terminal asks for a TC from the
ICC, the ICC, as a result of card risk management, may return an ARQC or AAC.
Conditions of Execution:
The terminal action analysis function is always performed.
December, 2000 Functions Used in Transaction Processing 57
Sequence of Execution:
The terminal action analysis function is performed after terminal risk
management and cardholder- and merchant-entered transaction data has been
completed. It shall be performed prior to the first use of the GENERATE AC
command.
The Issuer Action Code - Default and Terminal Action Code - Default processing
described below shall also be performed after online processing is attempted in
the case where the terminal was unable to process the transaction online.
The terminal action analysis function may be executed at several places during a
transaction to eliminate the need for unnecessary processing. If any processing
results in the setting of a bit in the TVR (for example, failure of cardholder
verification), it may be desirable to perform this function immediately to
determine whether the transaction should be rejected offline based upon the
issuer’s parameters in the ICC or the acquirer’s parameters in the terminal.
Recognition of such a decision early in processing may allow the terminal to
avoid prolonging a transaction that will ultimately be rejected. Multiple
executions of this decision process is optional on the part of the terminal.
Description:
The terminal shall make a preliminary decision to reject the transaction,
complete it online, or complete it offline based upon the TVR, issuer action
preferences, and acquirer action preferences according to the method described in
this section.
The ICC contains (optionally) three data elements to reflect the issuer’s selected
action to be taken based upon the content of the TVR. Each of the three data
elements has defaults specified here in case any of these data elements are
absent from the ICC. The three data elements are:
Collectively, these three data objects are termed the Issuer Action Codes. The
purpose of each is described in this section below. The format of each is identical
and mirrors the TVR. Each has one bit corresponding to each bit in the TVR, and
the Issuer Action Code bit specifies an action to be taken if the corresponding bit
in the TVR is set to ‘1’. Thus, the size and format of each of the Issuer Action
Codes is identical to the TVR.
Similarly, the terminal may contain three data elements to reflect the acquirer’s
selected action to be taken based upon the content of the TVR. These data
elements are:
Collectively, these three data objects are termed the Terminal Action Codes. The
purpose of each is described in this section below. The format of each is identical
and mirrors the TVR. Each has one bit corresponding to each bit in the TVR, and
the Terminal Action Code bit specifies an action to be taken if the corresponding
bit in the TVR is set to ‘1’. Thus, the size and format of each of the Terminal
Action Codes is identical to the TVR and to the Issuer Action Codes.
The existence of each of the Terminal Action Codes is optional. In the absence of
any Terminal Action Code, a default value consisting of all bits set to ‘0’ is to be
used in its place. However, it is strongly recommended that as a minimum, the
Terminal Action Code - Online and Terminal Action Code - Default should be
included with the bits corresponding to ‘Offline data authentication was not
performed’, ‘Offline static data authentication failed’, and ‘Offline dynamic data
authentication failed’ set to ‘1’.11
Processing of the action codes is done in pairs, that is, the Issuer Action Code -
Denial is processed together with the Terminal Action Code - Denial, the Issuer
Action Code - Online is processed together with the Terminal Action Code -
Online, and the Issuer Action Code - Default is processed together with the
Terminal Action Code - Default. Processing of the action codes shall be
performed in the order specified here.
If the Issuer Action Code - Denial does not exist, a default value with all bits set
to ‘0’ is to be used. Together, the Issuer Action Code - Denial and the Terminal
Action Code - Denial specify the conditions that cause denial of a transaction
without attempting to go online. If either data object exists, the terminal shall
inspect each bit in the TVR. For each bit in the TVR that has a value of ‘1’, the
terminal shall check the corresponding bits in the Issuer Action Code - Denial
and the Terminal Action Code - Denial. If the corresponding bit in either of the
action codes is set to ‘1’, it indicates that the issuer or the acquirer wishes the
transaction to be rejected offline. In this case, the terminal shall issue a
GENERATE AC command to request from the ICC an AAC. This AAC may be
presented to the issuer to prove card presence during this transaction, but details
of handling a rejected transaction are outside the scope of this specification.
If the Issuer Action Code - Online is not present, a default value with all bits set
to ‘1’ shall be used in its place. Together, the Issuer Action Code - Online and the
Terminal Action Code - Online specify the conditions that cause a transaction to
be completed online. These data objects are meaningful only for terminals
capable of online processing. Offline-only terminals may skip this test and
proceed to checking the Issuer Action Code - Default and Terminal Action Code -
Default, described below. For a terminal capable of online processing, if the
terminal has not already decided to reject the transaction as described above, the
11This protects against a fraudulent card with all the bits in the Issuer Action
Code set to ‘0’. Without this protection, such a card could be created with no
possibility of going online or declining transactions. All transactions would be
approved offline.
December, 2000 Functions Used in Transaction Processing 59
terminal shall inspect each bit in the TVR. For each bit in the TVR that has a
value of ‘1’, the terminal shall check the corresponding bits in both the Issuer
Action Code - Online and the Terminal Action Code - Online. If the bit in either
of the action codes is set to ‘1’, the terminal shall complete transaction processing
online and shall issue a GENERATE AC command requesting an ARQC from the
ICC.
If the Issuer Action Code - Default does not exist, a default value with all bits set
to ‘1’ shall be used in its place. Together, the Issuer Action Code - Default and
the Terminal Action Code - Default specify the conditions that cause the
transaction to be rejected if it might have been approved online but the terminal
is for any reason unable to process the transaction online. The Issuer Action
Code - Default and the Terminal Action Code - Default are used only if the Issuer
Action Code - Online and the Terminal Action Code - Online were not used (for
example, in case of an offline-only terminal) or indicated a desire on the part of
the issuer or the acquirer to process the transaction online but the terminal was
unable to go online. If the terminal has not already rejected the transaction and
the terminal is for any reason unable to process the transaction online, the
terminal shall use this code to determine whether to approve or reject the
transaction offline. If any bit in Issuer Action Code - Default or the Terminal
Action Code - Default and the corresponding bit in the TVR are both set to ‘1’, the
transaction shall be rejected and the terminal shall request an AAC to complete
processing. If no such condition appears, the transaction may be approved
offline, and a GENERATE AC command shall be issued to the ICC requesting a
TC.
Conditions of Execution:
The card online/offline decision is specified by its response to the GENERATE AC
command. Therefore, this section applies to all transactions. Whether the ICC
performs any risk management tests is transparent to the terminal and outside
the scope of this specification.
Sequence of Execution:
The card action analysis process is performed when the terminal issues the
GENERATE AC command for a given transaction.
60 Functions Used in Transaction Processing December, 2000
Description:
The result of risk management performed by the ICC is a decision for one of the
following actions to be taken by the terminal:
• Approve the transaction offline. This option is available to the ICC only if the
terminal has made a preliminary decision to complete the transaction offline,
as described in section 6.7.
• Request a referral.
The decision by the ICC is made known to the terminal by returning a TC, an
ARQC, an AAR, or an AAC to the terminal in response to a GENERATE AC
command, as described in section 2.5.5.
Upon the completion of the card action analysis function, the terminal shall set to
‘1’ the ‘Card risk management was performed’ bit in the TSI.
1. When the Terminal Capabilities Profile is included in the CDOL data, the
ICC considers the transaction eligible for combined DDA/AC generation if
the Combined Dynamic Data Authentication/Application Cryptogram
Generation bit in the Terminal Capabilities Profile is ‘1’ and Combined
DDA/Generate AC bit in the Application Interchange Profile is ‘1’.
2. When the Terminal Capabilities Profile is not included in the CDOL data,
the ICC considers the transaction eligible for combined DDA/AC
generation if Combined DDA/AC Generation Requested bit in the
GENERATE AC command is ‘1’.
December, 2000 Functions Used in Transaction Processing 61
If the transaction is eligible for combined DDA/AC generation and the ICC
response is an offline approval (TC) or an online request (ARQC), the ICC shall
return the GENERATE AC response in a public key envelope as specified in Book
2 Section 6.6.
If b4 of the Cryptogram Information Data is ‘1’, the terminal shall format and
send an advice message. Further information may be found in complementary
payment system documentation and in Book 4.
Conditions of Execution:
Online processing shall be performed if the ICC returns an ARQC in response to
the first GENERATE AC command for the transaction.
Sequence of Execution:
The online processing function is performed when the terminal receives an ARQC
in response to the first GENERATE AC command.
Description:
In general, online processing is the same as today’s online processing of magnetic
stripe transactions and is not described here. This section is limited to the
additional online processing provided in an ICC environment that is not
available in a magnetic stripe environment.
12Actions performed by the acquirer or issuer systems are outside the scope of
this specification. However, an explanation of what is expected to take place at
the issuer may be useful for clarity. The ARQC is a cryptogram generated by the
card from transaction data using an issuer key stored in the card and known at
the issuer authorisation system. The issuer uses this key to authenticate the
ARQC and thereby authenticate the card. This process is termed ‘online card
authentication’ or simply ‘card authentication’.
62 Functions Used in Transaction Processing December, 2000
A script may contain Issuer Script Commands not known to the terminal, but the
terminal shall deliver each command to the ICC individually according to this
specification.
Conditions of Execution:
None.
Sequence of Execution:
Two separate script tags are defined that are available for use by the issuer.
Issuer scripts with tag ‘71’ shall be processed prior to issuing the final
GENERATE AC command. Issuer scripts using tag ‘72’ shall be processed after
issuing the final GENERATE AC command.
Description:
An Issuer Script is a constructed data object (tag ‘71’ or ‘72’) containing
(optionally) a Script Identifier and a sequence of Issuer Script Command APDUs
to be delivered serially to the ICC. The Script Identifier is optional and is not
interpreted by the terminal; it is meaningful only to the issuer. Figure II – 5 and
Figure II - 6 illustrate an Issuer Script containing a Script Identifier and three
commands.
T L T L Script ID Commands
‘71’ or L(∑data, including Script ‘9F18’ ‘04’ Identifier (see Figure II –
‘72’ ID, tags, and lengths) (4 bytes) 6 – Issuer
Script
Command
Format (Shown
with Three
Commands))
T1 L1 V1 T2 L2 V2 T3 L3 V3
‘86’ L(V1) Command ‘86’ L(V2) Command ‘86’ L(V3) Command
• Issuer Script Commands shall be separated using the BER-TLV coding of the
data objects defining the commands (tag ‘86’).
• The terminal shall examine only SW1 in the response APDU and perform one
of the following actions:
If an Issuer Script is processed, the terminal shall set the ‘Script processing was
performed’ bit in the TSI to ‘1’. If an error occurred in processing a script, the
terminal shall set to ‘1’ either the ‘Script processing failed before final
GENERATE AC’ in the TVR if the identifying tag of the failing script was ‘71’ or
the ‘Script processing failed after final GENERATE AC’ in the TVR if the tag was
‘72’.
6.11 Completion
Purpose:
The completion function closes processing of a transaction.
Conditions of Execution:
The terminal always performs this function unless the transaction is terminated
prematurely by error processing.
Sequence of Execution:
The completion function is always the last function in the transaction processing.
(Script processing may be performed after the completion function.)
Description:
The ICC indicates willingness to complete transaction processing by returning
either a TC or an AAC to either the first or second GENERATE AC command
issued by the terminal. If the terminal decides to go online, completion shall be
done when the second GENERATE AC command is issued.
Signed Dynamic Digital signature on critical application parameters for ICC b - ‘9F4B’ NIC
Application Data dynamic data authentication
Signed Static Digital signature on critical application parameters for ICC b ‘70’ or ‘77’ ‘93’ NI
Application Data static data authentication
Static Data List of tags of primitive data objects defined in this ICC -- ‘70’ or ‘77’ ‘9F4A’ var.
Authentication specification whose value fields are to be included in the
Tag List Signed Static or Dynamic Application Data
December, 2000 Annex A – Data Elements Table 77
Service Code n3
When the length defined for the data object is greater than the length of the actual data, the following rules apply:
• A data element in format n is right justified and padded with leading hexadecimal zeroes
• A data element in format cn is left justified and padded with trailing hexadecimal ‘F’s
• A data element in format an is left justified and padded with trailing hexadecimal zeroes
• A data element in format ans is left justified and padded with trailing hexadecimal zeroes
When data is moved from one entity to another (for example, card to terminal), it shall always be passed in order from high order to low
order, regardless of how it is internally stored. The same rule applies when concatenating data.
Note: Data that can occur in template ‘70’ or ‘77’ can never occur in both.
December, 2000 Annex A - Data Elements Table 81
The tags allocated to the data elements are according to Table A-2:
• The tag field (T) consists of one or more consecutive bytes. It codes a class, a type,
and a number (see Table C-1). The tag field of the data objects described in this
specification is coded on one or two bytes.
• The length field (L) consists of one or more consecutive bytes. It codes the length
of the following field. The length field of the data objects described in this
specification is coded on one, two, or three bytes.
• The value field (V) codes the value of the data object. If L = ‘00’, the value field is
not present.
• A primitive data object where the value field contains a data element for financial
transaction interchange.
• A constructed data object where the value field contains one or more primitive or
constructed data objects. The value field of a constructed data object is called a
template.
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 Universal class
0 1 Application class
1 0 Context-specific class
1 1 Private class
0 Primitive data object
1 Constructed data object
1 1 1 1 1 See subsequent bytes
Any other value Tag number
According to ISO/IEC 8825, Table C-2 defines the coding rules of the subsequent
bytes of a BER-TLV tag when tag numbers ≥ 31 are used (that is, bits b5 - b1 of the
first byte equal ‘11111’).
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Another byte follows
0 Last tag byte
Any value > 0 (Part of) tag number
Before, between or after TLV-coded data objects, ‘00’ or ‘FF’ bytes without any
meaning may occur (e.g. due to erased or modified TLV-coded data objects).
The coding of the tag field of a BER-TLV data object is according to the following
rules:
• The following application class templates defined in ISO/IEC 7816 apply: ‘61’ and
‘6F.’
• The following range of application class templates is defined in Part I: ‘70’ to ‘7F’.
The meaning is then specific to the context of an application according to this
specification. Tags ‘78’, ‘79’, ‘7D’, and ‘7E’ are defined in ISO/IEC 7816-6 and are
not used in this specification.
• The application class data objects defined in ISO/IEC 7816 and described in Part
I are used according to the ISO/IEC 7816 definition.
• Context-specific class data objects are defined in the context of this specification
or in the context of the template in which they appear.
• The coding of primitive context-specific class data objects in the ranges ‘80’ to ‘9E’
and ‘9F00’ to ‘9F4F’ is reserved for this specification.
• The coding of primitive context-specific class data objects in the range ‘9F50’ to
‘9F7F’ is reserved for the payment systems.
• The coding of primitive and constructed private class data objects is left to the
discretion of the issuer.
When bit b8 of the most significant byte of the length field is set to 0, the length field
consists of only one byte. Bits b7 to b1 code the number of bytes of the value field.
The length field is within the range 1 to 127.
December, 2000 Annex B – Rules for BER-TLV Data Objects 87
When bit b8 of the most significant byte of the length field is set to 1, the subsequent
bits b7 to b1 of the most significant byte code the number of subsequent bytes in the
length field. The subsequent bytes code an integer representing the number of bytes
in the value field. Two bytes are necessary to express up to 255 bytes in the value
field.
A constructed BER-TLV data object consists of a tag, a length, and a value field
composed of one or more BER-TLV data objects. A record in an AEF governed by
this specification is a constructed BER-TLV data object. A constructed data object is
structured according to Table B-4:
This annex provides the coding for specific data elements used to control the
transaction flow in the terminal or to record the status of processing for the
transaction. In the tables, a ‘1’ means that if that bit has the value ‘1’, the
corresponding ‘Meaning’ applies. An ‘x’ means that the bit does not apply.
Data (bytes or bits) indicated as RFU shall be set to ‘0’.
90 Annex C – Coding of Data Elements December, 2000
Byte 1 (Leftmost):
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 x x x x x x x RFU
x 1 x x x x x x Offline static data authentication is supported
x x 1 x x x x x Offline dynamic data authentication is
supported
x x x 1 x x x x Cardholder verification is supported
x x x x 1 x x x Terminal risk management is to be performed
x x x x x 1 x x Issuer authentication is supported14
x x x x x x 1 x Combined DDA – GENERATE AC supported
x x x x x x x 0 RFU
Byte 2 (Rightmost):
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
When this bit is set to ‘1’, Issuer Authentication using the EXTERNAL
14
Byte 2 (Rightmost):
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Domestic cashback allowed
x 1 x x x x x x International cashback allowed
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
Value Meaning
‘00’ Always
‘01’ If cash or cashback
‘02’ If not cash or cashback
‘03’ If terminal supports the CVM15
‘04’ - ‘05’ RFU
‘06’ If transaction is in the application
currency16 and is under X value
‘07’ If transaction is in the application
currency and is over X value
‘08’ If transaction is in the application
currency and is under Y value
‘09’ If transaction is in the application
currency and is over Y value
‘0A’ - ‘7F’ RFU
‘80’ - ‘FF’ Reserved for use by individual payment
systems
15 In the case of offline PIN CVM, this means ‘If offline PIN pad present’. In the case
of online PIN CVM, this means ‘If online PIN pad present’.
16 That is, Transaction Currency Code = Application Currency Code.
94 Annex C – Coding of Data Elements December, 2000
Value Refers to
‘01’ Part 1 of ISO 8859
‘02’ Part 2 of ISO 8859
‘03’ Part 3 of ISO 8859
‘04’ Part 4 of ISO 8859
‘05’ Part 5 of ISO 8859
‘06’ Part 6 of ISO 8859
‘07’ Part 7 of ISO 8859
‘08’ Part 8 of ISO 8859
‘09’ Part 9 of ISO 8859
‘10’ Part 10 of ISO 8859
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x ICC and terminal have different application
versions
x 1 x x x x x x Expired application
x x 1 x x x x x Application not yet effective
x x x 1 x x x x Requested service not allowed for card product
x x x x 1 x x x New card
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
Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Cardholder verification was not successful
x 1 x x x x x x Unrecognised CVM
x x 1 x x x x x PIN Try Limit exceeded
x x x 1 x x x x PIN entry required and PIN pad not present or
not working
x x x x 1 x x x PIN entry required, PIN pad present, but PIN
was not entered
x x x x x 1 x x Online PIN entered
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Transaction exceeds floor limit
x 1 x x x x x x Lower consecutive offline limit exceeded
x x 1 x x x x x Upper consecutive offline limit exceeded
x x x 1 x x x x Transaction selected randomly for online
processing
x x x x 1 x x x Merchant forced transaction online
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
December, 2000 Annex C – Coding of Data Elements 97
Byte 5 (Rightmost):
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Default TDOL used
x 1 x x x x x x Issuer authentication was unsuccessful
x x 1 x x x x x Script processing failed before final
GENERATE AC
x x x 1 x x x x Script processing failed after final GENERATE
AC
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
Byte 1 (Leftmost):
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x Offline data authentication was performed
x 1 x x x x x x Cardholder verification was performed
x x 1 x x x x x Card risk management was performed
x x x 1 x x x x Issuer authentication was performed
x x x x 1 x x x Terminal risk management was performed
x x x x x 1 x x Script processing was performed
x x x x x x 0 x RFU
x x x x x x x 0 RFU
Byte 2 (Rightmost):
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
The Payment Gateway is responsible for reformatting the SET message (along with
additional IC Card related data) and transmitting an authorisation request to the
issuer. The manner in which the Payment Gateway reformats, transmits and
receives messages to and from the issuer is dependent on Payment Systems
requirements. These requirements are outside the scope of this document.
The Transaction Processing for Chip Electronic Commerce defines the use of an
integrated chip card (IC Card) application to conduct a credit or debit transaction in
an electronic commerce environment using SET 1.0 compliant software.
It leverages the EMV functions described in section 6 with the Secure Electronic
Transaction™ (SET) Specification (a secure protocol for which credit and debit
products may be used to conduct electronic commerce), to provide the foundation for
secure, portable, cost–effective, IC Card based transactions over the Internet
• SET Common Chip Extension: Extends the SET protocol to support the
transport of IC Card related data.
• Online PIN extension Extends the SET protocol to support the
online transport of a cardholders’ PIN.
• Confidentiality of information
• Integrity of data
• Interoperability
The Transaction Processing for Chip Electronic Commerce extends the SET
Specification by supporting two key features native to EMV IC Card applications:
Payment System
Issuer Acquirer
IC Card
Cardholder
Cardholder System
The Transaction Processing for Chip Electronic Commerce does not require any
modification to EMV–compliant IC Cards.
During application selection, an issuer may supplement the EMV defined branding
mechanisms, i.e. the display of an Application Label or Preferred Name, by showing
its cardholder a visual image of its brand. More information is provided in Annex E
Issuer URL for Electronic Commerce.
To do this, an issuer should store an additional data element, the Issuer URL, in the
File Control Information of its Application Definition File. If used, the format,
template, tag, and length to be applied to this data element are as follows:
This section describes the additional requirements imposed upon the Cardholder
System by this specification. Since there are many possible ways in which a
Cardholder System can be configured, this description treats the component as if it
were a black box.
The physical requirements that the EMV capable Interface Device (IFD) must meet
are prescribed by Book 1.
The physical characteristics that the Cardholder System and the PIN entry device
must possess to process a cardholder’s PIN are defined by individual Payment
System rules.
The Cardholder System must be aware of its PIN processing and interface device
capabilities.
The Cardholder System shall perform the following functions, which are detailed in
Section D.2, Transaction Processing:
104 Annex D –Transaction Processing for Chip E-Commerce December, 2000
Due to the special nature of the electronic commerce environment, the following
EMV defined functions are not executed:
D.1.2.2 Commands
Part II of Book 1 and Part I of this book prescribe the coding conventions and
structuring of command and response APDUs.
The Cardholder System shall be able to decode all responses generated by cards,
which respond to commands as prescribed by Part I of this book.
This section defines the Data Elements resident at the Cardholder System and their
values.
For more information regarding other EMV related Data Elements and their
sources, see Table D-9.
Amount Other
Amount Other encodes a cashback amount. Since there is no cashback in the
purchase transaction, the Data Element shall be defined as:
BrandID—AID Table
The BrandID—AID Table contains a mapping from each SET brandID to its
corresponding Application Identifiers (AIDs).
The Cardholder System should have a mechanism to update its BrandID-AID Table.
The Cardholder System’s BrandID—AID table shall include the AIDs defined in the
Payment System Specifications.
Terminal Type
The Terminal Type specifies the terminal’s environment, its communications
capabilities and its operational control. To indicate that it is an “unattended, online,
controlled by cardholder” device, the Data Element shall be defined as:
Transaction Type
The Transaction Type specifies the type of financial transactions the Cardholder
System performs. To indicate that the transaction is a purchase of goods or service,
the Data Element shall be defined as:
The values to be ascribed to bits that are static are indicated below. Bits whose
values are to be dynamically set, will be set by the Cardholder System during the
course of the transaction, as prescribed later in this specification. The coding of this
Data Element is as follows:
This section describes the SET Message Extensions that the Cardholder System
shall support in order to conduct an EMV transaction.
The Cardholder System must be able to support the following message extensions as
prescribed by the SET Common Chip Extension and SET Online PIN Extension.
• commonChip Created by the Cardholder System and placed in the
PReq message; this extension carries the cryptogram
and related data required by the acquirer to format a
Payment System’s authorisation request.
• acqCardExtensions Created by the Payment Gateway and placed within
the AcqCardMsgData field of the PRes message; this
extension carries Issuer Authentication and Issuer
Script data.
• onlinePIN Created by the Cardholder System and placed in the
PReq message; this extension identifies the presence
in the RSA/OAEP block of PIN data entered by the
cardholder.
The Transaction Processing for Chip Electronic Commerce does not require any
modification to Merchant Servers.
December, 2000 Annex D – Transaction Processing for Chip E-Commerce 109
The Payment Gateway must be able to process the following message extensions as
prescribed by the SET Common Chip Extension.
The Payment Gateway shall be able to process the following message extensions as
prescribed by the SET Online PIN Extension.
Organisation
This section illustrates the EMV functions and SET messages processed to conduct a
purchase transaction.
December, 2000 Annex D – Transaction Processing for Chip E-Commerce 111
Card Selection
Application Selection
Application Initiation
Read Application
Cardholder Verification
Capture Request
Capture Response
This section describes the phases of the purchase transaction in the order in which
they occur.
The Merchant Server invokes the Cardholder System and informs it of the payment
brands it accepts.
112 Annex D - Transaction Processing for Chip E-Commerce December, 2000
Card Selection
The cardholder presents to the Cardholder System the payment card to be
used for the purchase.
Application Selection
The Cardholder System selects an application from the card, with input from
the cardholder if necessary.
Application Initiation
The Cardholder System initiates the card application to determine whether it
and the card agree about how the transaction should be processed.
Read Application
The Cardholder System reads the application data.
Cardholder Verification
The Cardholder System retrieves information from the cardholder that may
verify their identity and either presents it to the card or transmits to the
issuer for verification
Purchase Request
The Cardholder System requests a purchase and provides the Merchant
Server with the data that it, the Payment Gateway and the issuer need to
respond to the request.
Authorisation Request
The Merchant Server sends the Payment Gateway the information that it
needs to verify the authenticity of the cardholder and to create a Payment
System’s authorisation request message.
Note: SET allows a merchant to return a PRes message to the Cardholder
System before authorisation processing.
Authorisation Response
The Payment Gateway sends the Merchant Server a message that indicates
whether the transaction has been authorised or declined by the issuer.
December, 2000 Annex D – Transaction Processing for Chip E-Commerce 113
Purchase Response
The Merchant Server informs the Cardholder System of the status of the
transaction sometime after it has received the Cardholder System’s Purchase
Request.
Capture Request
The Merchant Server may request that the Payment Gateway capture the
transaction after it has received the Payment Gateway’s Authorisation
Response.
Capture Response
The Payment Gateway notifies that Merchant Server of the status of its
request for capture.
D.2.2.1 Card Selection: Describes how the Cardholder indicates which payment
card to use for the purchase.
D.2.2.2 Application Selection: Describes how the Cardholder System, with
input from the cardholder, selects a card application to participate in the
transaction.
D.2.2.3 Application Initiation: Describes how the Cardholder System initiates
the card application.
D.2.2.4 Read Application Data: Describes how the Cardholder System reads the
card application’s records.
D.2.2.5 Cardholder Verification: Describes how the Cardholder System verifies
the identity of the cardholder.
D.2.2.6 Terminal Action Analysis: Describes how the IC Card application
generates an Application Cryptogram.
D.2.2.7 Issuer Script Processing and Completion: Describes how the
Cardholder System ends its involvement with the processing of the
transaction.
114 Annex D - Transaction Processing for Chip E-Commerce December, 2000
Purpose
Card selection is the phase of transaction processing in which the cardholder
indicates which payment card should be used for the purchase. This phase
supplements the SET defined account selection process.
Conditions of execution
The Cardholder System shall always perform Card Selection.
Process description
The Cardholder System shall integrate the execution of Card Selection with the
execution of account selection. In doing so, the following requirements shall be met:
• All brands accepted by the Merchant Server shall be displayed.
• The Cardholder shall be offered all available payment options.
• Once a chip card has been selected, the Cardholder System shall request that the
Cardholder not remove the card until prompted to do so.
Introduction
Application Selection is the transaction-processing phase in which the Cardholder
System selects the application from the IC Card.
Conditions of execution
This phase is mandatory.
Process description
The Cardholder System shall perform Application Selection as prescribed by Part II
of Book 1
If no mutually supported applications are found, the Cardholder System shall either:
• Prompt the Cardholder to confirm the correct card has been inserted, and if so,
update the Brand—AID table. Otherwise request the Cardholder to remove the
card and return to the Card Selection phase. If after an update, a mutually
supported application cannot be found, the Cardholder System shall request that
the Cardholder remove the card and return to the Card Selection phase.
Purpose
Application Initiation is the transaction-processing phase during which the IC Card
and the Cardholder System learn the details of the transaction and make an
informed decision as to whether they wish to participate.
Conditions of execution
This phase is mandatory.
Process description
The Cardholder System shall initiate the application as prescribed by Section 6.1..
It shall assume the role of the “terminal” described therein.
Purpose
Read Application Data is the transaction processing phase in which the Cardholder
System reads the files and records of the card application.
Conditions of execution
This phase is mandatory.
Process description
The Cardholder System shall read the application data as prescribed section 6.2. It
shall assume the role of the “terminal” described therein.
Purpose
Cardholder Verification is the transaction-processing phase in which the Cardholder
System retrieves information from the Cardholder that may verify their identity and
either presents it to the card or transmits it to the issuer for verification.
116 Annex D - Transaction Processing for Chip E-Commerce December, 2000
Conditions of execution
The Cardholder System shall perform Cardholder Verification if bit 5 of byte 1 of the
Application Interchange Profile is set to ‘1’.
Process Description
The Cardholder System shall perform the Cardholder Verification process as
prescribed by section 6.5, assuming the role of the “terminal” described therein, with
the following exceptions:
1 Determining Whether to Prompt for Off–line PIN Entry. When the method
of Cardholder Verification requested by the card (as indicated by it’s CVRs)
requires that the Cardholder provide his/her PIN for off–line verification by
the card, the Cardholder System shall determine whether there is a
mechanism for transport of the cryptogram to the issuer for authentication.
If transport of the cryptogram is not available, the Cardholder System shall
not prompt for off–line PIN entry, but shall attempt to process the next
CVR. Cardholder applications shall support the following method and may
support others. The Cardholder System shall search for the presence of the
commonChip OID in the extension to Payment Gateway Certificate. If this
OID is present, transport of the cryptogram is available.
2 Determining Whether to Prompt for Online PIN Entry. When the method of
Cardholder Verification requested by the card (as indicated by it’s CVRs)
requires that the Cardholder provide his/her PIN for online verification by
the issuer, the Cardholder System shall determine whether the Payment
Gateway supports issuer verification of an online PIN. To do this, the
Cardholder System shall search for the presence of the id–set–PIN–Any–
Source OID in the extension to Payment Gateway Certificate. If this OID is
available, the Cardholder System shall prompt for PIN entry. If this OID is
not available, the Cardholder System shall not prompt for PIN entry, but
shall attempt to process the next CVR.
Purpose
Terminal Action Analysis is the phase of transaction processing in which the
Cardholder System requests an online authorisation of the transaction. In response,
the card determines whether to decline the transaction off–line or to request an
online authorisation.
December, 2000 Annex D – Transaction Processing for Chip E-Commerce 117
Conditions of execution
This phase is mandatory if the Payment Gateway supports the commonChip
extension.
Process description
The Cardholder System shall perform Terminal Action Analysis as in section 6.7.
The Cardholder System shall assume the role of the “terminal” described therein
and behave just like that terminal with the following exceptions:
Before transmitting it to the card in the data field of the GENERATE AC command,
the Cardholder System shall convert some of the source data referenced above as
follows:
Purpose
Issuer Script Processing and Completion is the transaction-processing phase in
which the Cardholder System terminates the involvement of the Cardholder and the
IC Card with the transaction.
Conditions of executions
This phase is mandatory.
Process description
The Cardholder System shall perform Issuer Script Processing and Completion
according to the following conditions:
the value ‘Z3’ to the Authorisation Response Code (tag ‘8A’) (Inform the
Cardholder that it is now permissible to remove the card from the IFD).
3. The PRes message has been processed and the AuthCode does not indicate
orderReceived, noReply, piAuthMismatch or systemError.
D.2.7.1 SET Initiation: describes the SET Initiation Message used to invoke the
Cardholder System.
D.2.7.2 Purchase Initialization Request & Response: describes the PInitReq and
PInitRes messages, which support initialization of the SET protocol.
D.2.7.3 Purchase Request & Response: describes the PReq and PRes messages,
which constitute the purchase transaction between the Cardholder
System and Merchant.
December, 2000 Annex D – Transaction Processing for Chip E-Commerce 121
Purpose
SET Initiation is the phase of a purchase transaction during which the Merchant
Server invokes the Cardholder System and informs it of the transaction details and
accepted payment brands.
Conditions of use
The Merchant Server shall initiate every SET purchase transaction.
Note: In order to provide the complete functionality of this specification, the URL in
the SET–Brand header line in the SET Initiation message must reference a
directory that contains the brandDat.mim file. When the merchant manages this
directory, the Merchant Server shall retrieve the file from a directory managed by
the brand and copy the file to its local directory. See Appendix 1 for more details.
Purpose
Purchase Initialization is the phase of a purchase transaction during which:
1. The Merchant Server obtains the information that it needs to understand the
context of the transaction.
2. The Cardholder System obtains the information that it needs to create a
purchase request, as well as authenticate the Merchant Server and Payment
Gateway.
Conditions of use
The Cardholder System shall initialize every purchase transaction.
Rules
The mechanism that SET provides for purchase initialisation is the PInitReq and
PInitRes messages.
The Cardholder System shall create the PInitReq message as prescribed below.
The Merchant Server shall process PInitReq and create PInitRes as prescribed by
SET.
The Cardholder System shall process PInitRes as prescribed by SET.
122 Annex D - Transaction Processing for Chip E-Commerce December, 2000
Completing PInitReq
The Cardholder System shall create PInitReq as prescribed by SET, with the
following exceptions:
Step Action
1 Obtain the IC Card specific data inputs to PInitReq from the
card application.
2 Convert the data objects obtained from the card to SET formats.
Note: Cardholder Systems designed for use in a private environment (a home PC for
example) may provide an option to use a Cardholder–selected language rather than
the IC Card’s language.
Processing PInitRes
The Cardholder System shall process the PInitRes as prescribed by SET with the
following addition.
Purpose
Purchase Request is the transaction-processing phase in which the Cardholder
System requests the actual purchase from the merchant. Purchase Response is the
transaction-processing phase in which the Merchant Server informs the Cardholder
System of the status of the Purchase Request.
Conditions of use
The Cardholder System shall transmit the Purchase Request (PReq) message after
initializing each purchase transaction. The Merchant Server may transmit the
Purchase Response (PRes) message anytime after it receives the Purchase Request
Message, even before it sends an Authorisation Request to the Payment Gateway.
Rules
The mechanism that SET provides for purchase request is the PReq and PRes
messages.
The Cardholder System shall create the PReq message as follows:
If the Cardholder Verification Method selected was Online PIN, the Cardholder
System shall create and append the onlinePIN extension to the PReq message as
prescribed in the SET Online PIN Extension.
The Merchant Server shall process the PReq and create a PRes as prescribed by
SET.
The Cardholder System shall process the PRes as prescribed by SET.
124 Annex D - Transaction Processing for Chip E-Commerce December, 2000
Completing PReq
The Cardholder System shall create the PReq as prescribed by SET, making the
following changes to the manner in which the Payment Instructions are created:
Step Action
1 Obtain the IC Card specific data inputs to the Payment
Instructions (PI).
2 Convert the data objects obtained from card to SET required
formats.
When required, the Cardholder System shall append the commonChip extension to
the PIHead portion of the PReq message. It shall code this extension as prescribed
by SET Common Chip Extension. The EMVData field of the extension must include
the Data Elements listed in the table below, when available for the transaction.
The data that appears in the EMV data field can be in any order but must be TLV
encoded and bit–wise identical to the fields presented to the IC Card. The
Cardholder System shall obtain these Data Elements from the source identified in
the last column of the table.
126 Annex D - Transaction Processing for Chip E-Commerce December, 2000
D.2.4.1 Authorisation Request & Response: describes the AuthReq and AuthRes
messages, which support the authorisation stage of the payment
transaction.
D.2.4.2 Capture Request & Response: describes the CapReq and CapRes
messages, which support the capture stage of the purchase transaction.
December, 2000 Annex D – Transaction Processing for Chip E-Commerce 127
Purpose
Authorisation Request is the phase in which the Merchant Server requests an
authorisation for the Cardholder’s intended purchase.
Authorisation Response is the phase in which the Payment Gateway informs the
Merchant Server whether the purchase has been approved or declined by the issuer.
It also provides the merchant with the data necessary to request the capture of the
transaction.
Conditions of execution
The Merchant Server shall transmit the Authorisation Request (AuthReq) message
after it receives a valid purchase request from the Cardholder System. The
Payment Gateway shall transmit the Authorisation Response (AuthRes) message
after it has received an authorisation response.
Rules
The Merchant Server shall create the AuthReq as prescribed by SET.
The Payment Gateway shall process AuthReq and may create AuthRes as prescribed
below.
The Merchant Server shall process AuthRes as prescribed by SET.
Completing AuthRes
The Payment Gateway shall create AuthRes as prescribed by SET with the following
exception:
To be able to provide this additional data, the Merchant Server must have received
it from the Payment Gateway in one of two fields of the AuthRes message. If the
Payment Gateway wishes to enable the Merchant Server to decrypt the emvData, to
capture outside of SET for example, the Payment Gateway must transmit it as an
extension to the AuthResPayload field of AuthRes. If not, the Payment Gateway
may transmit it via the TokenOpaque field of the Capture Token.
Purpose
Capture Request is the phase of transaction processing in which the merchant
requests clearing, i.e., financial payment, for one or more previously authorized
transactions. Capture response is the phase of transaction processing in which the
Payment Gateway notifies the Merchant Server of the status of its capture request.
Conditions of execution
The means by which the Merchant Server captures transactions and the times at
which it does so may vary. For example, a merchant may delay the clearing of a
transaction and when clearing the transaction, the merchant may clear it out–of–
band to SET.
Rules
The contents of the EMVData field of the commonChip extension should be included
in Payment System messages related to the original authorisation request (e.g.,
subsequent authorisation requests/reversals needed to process split and recurring
payments, and clearing messages in general.) Exactly how this data ultimately
reaches the clearing and settlement system depends upon the processing
relationships and capabilities of the Merchant Server, Payment Gateway, merchant
back office, and the acquirer’s system.
130 Annex D - Transaction Processing for Chip E-Commerce December, 2000
The issuer Uniform Resource Locator (URL), located in the ADF, points to the
location of (a) brand or financial institution logo(s) that the Cardholder System may
retrieve for display to the Cardholder during the transaction.
The structure of the Issuer URL is illustrated below. It consists of two parts, the
Issuer’s server, which is identified by its Scheme and Authority, and an
ApplicationID:
URL <Scheme>://<Authority><ApplicationID>
Scheme Example: http://
Authority Example: www.bankname.com/
ApplicationID Examples: Brand–xCreditClassic, or a reference number.
In order to retrieve the logo to be displayed, the Cardholder System shall generate
the Issuer URL as follows:
The graphic formats for the logo are defined in Appendix F of the SET 1.0
Specification.
For more information regarding URL, see IETF RFC 1738 “Uniform Resource
Locator (URL).”
132 Annex E – Issuer URL for Electronic Commerce December, 2000
Introduction
This appendix illustrates the flow of the Cardholder System’s processing steps.
No
Is
Application
SET Initiation Message Card Selection Application Selection Selection
successful
Yes
Purchase Initialization Purchase Initialization Read Application Application Initiation
Response Request
Is
Is commonChip
No Online PIN No
extension
requested supported
Yes Yes
Is Is
Is Is onlinePIN
No onlinePIN No Yes Yes
Off-line PIN Online PIN extension Cardholder Verification
extension
requested requested supported
supported
Yes Yes
Generate onlinePIN
Cardholder Verification Cardholder Verification No No extension
Is the
Application
Cryptogram Yes
an AAC
No
Generate commonChip
extension
Is a
Cardholder No
Certificate
available
Yes
PReqDualSigned PReqUnSigned
Purchase Response
G.1 Overview
Introduction
This specification defines the integration of EMV card technology and SET electronic
commerce technology. In it, the communication between the card and the merchant
is managed by a system called the Cardholder System. Before the development of
Chip Electronic Commerce, a SET Cardholder System was usually a software
application stored on a PC that acted as a helper to a Web browser. This application
is commonly referred to as a SET “wallet”.
It is offered by the EMVCo working group as an aid to the ongoing SET Technical
Advisory Group efforts to define the technical requirements for server based wallets.
The EMV Cardholder System is any combination of hardware and software that
allows a cardholder to conduct an EMV compliant SET payment with a merchant’s
system. It is an abstract term covering any number of logical components that reside
on a single physical device, or are distributed across any number of connected
devices.
136 Annex G - Cardholder System Implementations December, 2000
The EMV Cardholder System can be divided into seven functional components and a
internal communication protocol defining the interaction of each component. The
components are:
• Cardholder interface
• Cardholder database
• SET message manager
• SET private key manager
• EMV message manager
• IC Card Interface device
• PIN entry device (optional)
• Internal communication protocol
Components
Overall guideline
The Cardholder System, being the sum of the components, must minimize the risk of
limited or systemic compromise. The specific security requirements must be
appropriate for the implementation of the system as a whole. For example, the risks
and therefore the security requirements for a classic SET application on a personal
computer will be less than those for a server based Cardholder System designed to
serve hundreds of cardholders.
December, 2000 Annex G - Cardholder System Implementations 137
The Cardholder interface and device is responsible for the system’s input/output
(such as keyboard, screen, and graphic user interface) allowing the Cardholder to
interact with the system.
The Cardholder interface and device must protect the Cardholder’s input, as well as
the display or output of system information in accordance with industry best
practice.
Cardholder database
The Cardholder database is responsible for the management of all Cardholder data,
both payment data and non–payment data, such as a telephone number. Some
configurations may store this data; others might hold it only for the duration of a
transaction
Cardholder data must be processed and stored in a manner that secures the
confidentiality and integrity of sensitive data (both personal and payment related,
such as PAN, PANSecret and Expiry) from external and internal attacks.
The SET Private Key Manager, in conjunction with the SET Message Manager,
must process certificate request and purchase request signing operations in a
manner that assures the security of the private key.
EMV manager
The EMV manager is responsible for the EMV message interaction between an EMV
Device and Card.
The EMV Manager must, at a minimum, support the EMV Commands, and ChipEC
protocols defined in the Chip Electronic Commerce Specification.
The PIN entry device must comply with applicable Payment System requirements
and industry best practices.
Organisation
Annex G includes the following sample implementations:
Component allocation
This implementation allocates the Cardholder System components as follows:
Component Location
Cardholder interface Client
Cardholder database Server
SET message manager Server
SET private key manager Server
EMV manager Client
EMV device Client
PIN entry device (optional) Client
Internal communication protocol Shared
Step Description
1 The SET Merchant Server sends a standard SET Initiation message.
2 The Chip enabled Cardholder Client forwards the wake–up message to the
Cardholder Server requesting that it complete a standard SET transaction. The
Cardholder uses a cryptogram as a key to access the server.
3 The Cardholder Server having received the Client request message, validates the
& cryptogram by contacting the issuer through an out of band mechanism, and if
4 successful, uses the information in the wakeup message to conduct a SET
transaction on the Cardholder’s behalf.
Depending on the server’s capabilities, a certificate and/or a cryptogram may be
used in the Purchase Request.
5 Upon the completion of the transaction, the Cardholder Server sends a purchase
response message to the Cardholder Client informing it of the transaction
results.
140 Annex G - Cardholder System Implementations December, 2000
Cardholder Server
Purchase
Request
+cryptogram
Purchase
Response
SET
Cardholder SET Initiation (Wake-up) Merchant
Client Server
EMV
This example implementation explores hosting the majority of the SET Cardholder
System functions on the Cardholder Client, while the server provides a specialized
service to the client. The example below describes a server that manages the
certificate request and signing processes for a PReqDualsigned transaction. Note, in
this example the certificate and private key are not stored on the Cardholder Client.
Component allocation
This implementation allocates the Cardholder System components as follows:
Component Location
Cardholder interface Client
Cardholder database Client
SET message manager Client
SET private key manager Server
EMV manager Client
EMV device Client
PIN entry device (optional) Client
Internal communication protocol Shared
Step Description
1 The SET Merchant Server sends a standard SET Initiation
message.
2 The Cardholder Client sends a standard SET Purchase
Initialization Request message indicating which payment brand
is being used and receives a standard response from the
merchant.
142 Annex G - Cardholder System Implementations December, 2000
Cardholder Server
Signing
Request
+cryptogram Signing
Response
+Certificate
SET Initiation (Wake-up)
Cardholder SET
ChipSET
SET PInitReq/Res Mercant
Merchant
Client
PReq/Res (DualSigned) Server
EMV