EMV®*

Contactless Specifications for Payment

Systems

Book A

Architecture and General Requirements

Version 2.6
March 2016

*
EMV is a registered trademark or trademark of EMVCo LLC in the United States and other countries.

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to
the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or
trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

Legal Notice
The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo
neither assumes nor accepts any liability for any errors or omissions contained in these
Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-
INFRINGEMENT, AS TO THESE SPECIFICATIONS.

EMVCo makes no representations or warranties with respect to intellectual property rights of

any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to
determine whether any implementation of the EMV® Specifications may violate, infringe, or
otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other
intellectual property rights of third parties, and thus any person who implements any part of the
EMV® Specifications should consult an intellectual property attorney before any such
implementation.

Without limiting the foregoing, the Specifications may provide for the use of public key
encryption and other technology, which may be the subject matter of patents in several
countries. Any party seeking to implement these Specifications is solely responsible for
determining whether its activities require a license to any such technology, including for patents
on public key encryption technology. EMVCo shall not be liable under any theory for any party’s
infringement of any intellectual property rights in connection with the EMV® Specifications.
EMV Contactless Book A
Architecture & General Requirements v2.6

Contents
1 Scope ....................................................................................................................9
1.1 Audience .......................................................................................................9
1.2 Overview .....................................................................................................11
2 References .........................................................................................................12
2.1 Volumes of the Contactless Specifications .................................................12
2.2 EMV Documents .........................................................................................13
2.3 ISO Standards ............................................................................................13
3 Conventions .......................................................................................................14
3.1 Requirement Numbering .............................................................................14
3.2 Data Element Formats ................................................................................14
4 Terminology .......................................................................................................16
4.1 Card ............................................................................................................16
4.2 Transaction .................................................................................................17
4.3 POS System ...............................................................................................18
4.4 Entry Point ..................................................................................................19
4.5 Kernel .........................................................................................................19
4.6 Outcome .....................................................................................................19
5 POS System Architecture .................................................................................20
5.1 POS System Descriptive Model ..................................................................20
5.2 Terminal and Reader Responsibilities ........................................................22
5.3 Logical Architecture ....................................................................................23
5.4 Operating Modes ........................................................................................24
5.5 POS System Functions ...............................................................................25
5.5.1 Non-interference with Contact Chip Interface .................................25
5.5.2 No Overlapping Transactions..........................................................26
5.5.3 Cancellation ....................................................................................26
5.5.4 Field Management ..........................................................................27
5.5.5 Displaying Amount ..........................................................................27
5.5.6 Transaction Disposition ...................................................................27
5.5.7 Receipts ..........................................................................................28
5.5.8 Cardholder Verification....................................................................28
5.6 POS System Configuration .........................................................................30
5.6.1 POS System Country and Currency Codes ....................................30

Page iii

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted
only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a
registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.6.2 POS System Configuration for Starting a Transaction .................... 31

5.6.3 POS System Configuration for Acceptance Environment ............... 31
5.6.4 POS System Configuration for Type of Transaction ....................... 32
5.6.5 Kernel and Entry Point Configuration Data ..................................... 33
5.7 Transaction Data ........................................................................................34
5.8 Entry Point Processing ...............................................................................37
5.8.1 Starting Conditions ..........................................................................37
5.8.2 Application Selection and Kernel Activation .................................... 39
5.8.3 User Interface Request ...................................................................40
5.9 Kernel Processing .......................................................................................41
5.9.1 User Interface Request ...................................................................41
5.9.2 Processing Data Exchange .............................................................41
5.9.3 CVM Selection and Cardholder Verification .................................... 42
6 Outcomes and Parameters ...............................................................................43
6.1 Outcomes ...................................................................................................43
6.2 Outcome Parameters ..................................................................................48
6.3 Outcome Processing ..................................................................................54
7 User Interaction Overview ................................................................................58
7.1 User Interface Request ...............................................................................59
7.2 Messaging and Status Display ...................................................................61
7.3 Amount Display and Entry ..........................................................................62
8 POS System Requirements ..............................................................................63
9 User Interface Recommendations ....................................................................71
9.1 User Interface Hardware .............................................................................71
9.1.1 Visual Indication ..............................................................................72
9.1.2 Audio Indication ..............................................................................73
9.2 Contactless Transaction Status (User) .......................................................74
9.3 User Interface Guidelines ...........................................................................76
9.3.1 Common User Interface Guidelines ................................................77
9.3.2 Option 1 for Card Read Successfully/Processing Error .................. 79
9.3.3 Option 2 for Card Read Successfully/Processing Error .................. 83
9.4 User Interface Standard Messages ............................................................87
10 Performance Requirements ..............................................................................91
10.1 Card in Field ...............................................................................................91
10.2 Allocation of Tariffs .....................................................................................92

Page iv

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted
only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a
registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

10.3 Transaction Disposition...............................................................................94

10.3.1 Offline ..............................................................................................94
10.3.2 Online ..............................................................................................94
10.4 Reference Cards .........................................................................................95
Annex A Data Elements for the Data Record and Discretionary Data .............96
Annex B Guidance on Outcome and Parameter Setting ..................................97
B.1 Approved ....................................................................................................97
B.2 Approved (with balance) .............................................................................98
B.3 Declined ......................................................................................................99
B.4 Try Another Interface ..................................................................................99
B.5 Online Request .........................................................................................100
B.6 Online Request (for “Two Presentments”) ................................................100
B.7 Online Request (for “Present and Hold”) ..................................................101
B.8 Try Again ..................................................................................................102
B.9 Select Next................................................................................................103
B.10 End Application .........................................................................................103
B.11 End Application (with restart) ....................................................................104
Annex C Glossary ..............................................................................................105

Page v

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted
only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a
registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

Figures
Figure 5-1: POS System Descriptive Model .............................................................21
Figure 5-2: Logical Architecture ................................................................................23
Figure 9-1: Success Tone ........................................................................................73
Figure 9-2: Alert Tone ...............................................................................................73
Figure 10-1: Tariff Allocation for Transaction Timing ................................................92

Page vi

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted
only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a
registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

Tables
Table 5-1: Example Combination Table per Transaction Type ................................32
Table 5-2: Entry Point Configuration Data per Combination.....................................33
Table 5-3: Entry Point Pre-Processing Indicators .....................................................34
Table 5-4: Terminal Transaction Qualifiers...............................................................35
Table 5-5: Example Transaction-specific Data Elements .........................................36
Table 5-6: Type of Transaction .................................................................................36
Table 6-1: Outcomes ................................................................................................44
Table 6-2: Outcome Parameters ..............................................................................49
Table 6-3: First Final Outcome .................................................................................54
Table 6-4: Second Final Outcome (Following an Online Request) ...........................57
Table 7-1: User Interface Request Data ...................................................................59
Table 9-1: Contactless Transaction Status ...............................................................74
Table 9-2: Common User Interface Actions..............................................................77
Table 9-3: User Interface Actions for Option 1 .........................................................79
Table 9-4: User Interface Actions for Option 2 .........................................................83
Table 9-5: User Interface Standard Messages .........................................................87
Table A.1: Kernel Data Record and Discretionary Data Reference ..........................96

Page vii

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted
only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a
registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

Requirements
Requirements – Configurations .................................................................................63
Requirements – Entry of Amount ..............................................................................63
Requirements – New Transaction Preparation and Start .......................................... 64
Requirements – Unpredictable Number ....................................................................65
Requirements – RFU Bits and Bytes .........................................................................65
Requirements – Multiple Interfaces ...........................................................................66
Requirements – Processing Data Exchange Request ..............................................67
Requirements – User Interface Request ...................................................................67
Requirements – Final Outcome Processing ..............................................................68
Requirements – Online Response – Restart .............................................................69
Requirements – End Application – Restart ................................................................70
Requirements – Reader Tariff ...................................................................................93
Requirements – Offline Transaction Disposition........................................................94
Requirements – Online Transaction Disposition........................................................94

Page viii

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted
only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a
registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

1 Scope
With the goal of realising universal acceptance of contactless cards in an international
interchange environment, EMVCo has developed a design for contactless payments that
is compatible with existing payment system solutions, whilst offering the opportunity for
the eventual development of a common EMV contactless acceptance solution.
The design defines a generalised POS System environment that includes:
• reader functionality,
• terminal functionality,
• Entry Point software that performs the initial analysis of a contactless transaction
and invokes appropriate kernel software, and
• several kernels, each of which provides processing appropriate to certain
contactless transactions.
This specification (Book A) describes the overall architecture, plus requirements for
general features not specific to Entry Point or individual kernels. The other specifications
in the suite, listed in section 2.1, describe Entry Point, the kernels, and the
communication protocol.

1.1 Audience
This specification is intended for use by manufacturers of readers and terminals. It may
also be of interest to manufacturers of contactless cards and to financial institution staff
responsible for implementing financial applications in contactless cards.

Page 9

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and
other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

1.2 Overview
This volume includes the following chapters and annexes.
Chapter 1 contains general information that helps the reader understand and use this
specification.
Chapter 2 lists related specifications and standards.
Chapter 3 describes conventions used in this specification.
Chapter 4 defines key terms used throughout the specifications, including card, transaction,
POS System, Entry Point, kernel, and Outcome.
Chapter 5 describes the architecture of the POS System discussed throughout the
specifications.
Chapter 6 describes all Outcomes and associated parameters.
Chapter 7 provides on overview of user interaction.
Chapter 8 defines POS System requirements.
Chapter 9 provides recommendations for the user interface, including the use of visual and
audio indications of the transaction status.
Chapter 10 outlines performance requirements.
Annex A provides an overview of the data elements used in the EMV Contactless
Specifications for Payment Systems.
Annex B provides guidance on Outcome and parameter setting.
Annex C is a glossary of terms and abbreviations used in Book A and Book B of the EMV
Contactless Specifications for Payment Systems.

Page 11

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted
only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a
registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

2 References
The following specifications and standards contain provisions that are referenced in
this specification. The latest version shall apply unless a publication date is explicitly
stated.
If any provision or definition in this specification differs from those in the standards
listed in section 2.3, the provision or definition herein shall take precedence.

2.1 Volumes of the Contactless Specifications

This specification is part of a ten-volume set:
Book A: Architecture and General Requirements
Book B: Entry Point Specification
Book C-1: Kernel 1 Specification
Book C-2: Kernel 2 Specification
Book C-3: Kernel 3 Specification
Book C-4: Kernel 4 Specification
Book C-5: Kernel 5 Specification
Book C-6: Kernel 6 Specification
Book C-7: Kernel 7 Specification
Book D: Contactless Communication Protocol Specification

Page 12

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

2.2 EMV Documents

EMV documents are available on the EMVCo website: http://www.emvco.com/

EMV Integrated Circuit Card Specifications for Payment

Systems, Version 4.3, November 2011, including the following
and all applicable Specification Bulletins:

[EMV 4.3 Book 1] EMV Integrated Circuit Card Specifications for Payment
Systems, Book 1, Application Independent ICC to Terminal
Interface Requirements

[EMV 4.3 Book 2] EMV Integrated Circuit Card Specifications for Payment
Systems, Book 2, Security and Key Management

[EMV 4.3 Book 3] EMV Integrated Circuit Card Specifications for Payment
Systems, Book 3, Application Specification

[EMV 4.3 Book 4] EMV Integrated Circuit Card Specifications for Payment
Systems, Book 4, Cardholder, Attendant, and Acquirer Interface
Requirements

2.3 ISO Standards

ISO 639-1 Codes for the representation of names of languages – Part 1:

Alpha-2 Code.
Note: This standard is updated continuously by ISO.
Additions/changes to ISO 639-1:1988: Codes for the
Representation of Names of Languages are available on:
http://www.loc.gov/standards/iso639-2/php/code_changes.php

ISO 4217 Codes for the representation of currencies and funds.

ISO 14443-3 Identification cards – Contactless integrated circuit(s) cards –

Proximity cards – Part 3: Initialization and anticollision

ISO/IEC 8859 Information Processing – 8-bit Single-Byte Coded Graphic

Character Sets.

Page 13

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

3 Conventions
This specification uses the following conventions.

'0' to '9' and 'A' to 'F' 16 hexadecimal characters

nb, nnb, nnnb, ... Binary values

xx Any value

proprietary Not defined in this specification and/or

outside the scope of this specification

may Denotes an optional feature

shall Denotes a mandatory requirement

should Denotes a recommendation

3.1 Requirement Numbering

Requirements in this specification are uniquely numbered with a four-part numeric
identifier appearing next to each requirement.
A requirement may have different numbers in different versions of the specification.
Hence, all references to a requirement must include the version of the specification
as well as the requirement’s number.

3.2 Data Element Formats

The EMV Contactless Specifications for Payment Systems use the following data
element formats.

a Alphabetic data elements contain a single character per byte. The

permitted characters are alphabetic only (a to z and A to Z, upper and
lower case).
an Alphanumeric data elements contain a single character per byte. The
permitted characters are alphabetic (a to z and A to Z, upper and lower
case) and numeric (0 to 9).

Page 14

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

ans Alphanumeric Special data elements contain a single character per byte.
The permitted characters and their coding are shown in the Common
Character Set table in [EMV 4.3 Book 4], Annex B.
There is one exception: The permitted characters for Application
Preferred Name are the non-control characters defined in the
ISO/IEC 8859 part designated in the Issuer Code Table Index associated
with the Application Preferred Name.
b These data elements consist of either unsigned binary numbers or
bit combinations that are defined elsewhere.
Binary example: The Application Transaction Counter (ATC) is defined as
“b” with a length of two bytes. An ATC value of 19 is stored as
Hex '00 13'.
Bit combination example: Processing Options Data Object List (PDOL) is
defined as “b” with the format shown in [EMV 4.3 Book 3], section 5.4.
cn Compressed numeric data elements consist of two numeric digits (having
values in the range Hex '0'–'9') per byte. These data elements are
left-justified and padded with trailing hexadecimal 'F's.
Example: The Application Primary Account Number (PAN) is defined as
“cn” with a length of up to ten bytes. A value of 1234567890123 may be
stored in the Application PAN as Hex '12 34 56 78 90 12 3F FF' with a
length of 8.
n Numeric data elements consist of two numeric digits (having values in the
range Hex '0'–'9') per byte. These digits are right-justified and padded with
leading hexadecimal zeroes. Other specifications sometimes refer to this
data format as Binary Coded Decimal (“BCD”) or unsigned packed.
Example: Amount, Authorised (Numeric) is defined as “n 12” with a
length of six bytes. A value of 12345 is stored in Amount, Authorised
(Numeric) as Hex '00 00 00 01 23 45'.
var. Variable data elements are variable length and may contain any bit
combination. Additional information on the formats of specific variable
data elements is available elsewhere.

Page 15

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

4 Terminology
The EMV Contactless Specifications for Payment Systems define the processing of a
transaction using a contactless card and processed on a POS System that includes
Entry Point and one or more kernels, with information passed within the POS System
by means of an Outcome. Each of the key terms in that sentence has a particular
meaning in the specifications, as described in the following sections.
4.1 Card ............................................................................................................16
4.2 Transaction .................................................................................................17
4.3 POS System ...............................................................................................18
4.4 Entry Point ..................................................................................................19
4.5 Kernel .........................................................................................................19
4.6 Outcome .....................................................................................................19

4.1 Card
Within these specifications, a card is considered to be any consumer token
supporting contactless payment transactions, whether in the form of a payment chip
card, a key fob, a mobile phone, or another form factor. From the perspective of a
contactless reader, the other form factors communicate and behave the same as a
contactless card that is compliant with Book D. With respect to cardholder
verification, mobile devices may take advantage of the user interface on the handset
to allow cardholder verification of a contactless transaction by means of a
confirmation code entered on the handset.

Page 16

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

4.2 Transaction
Within these specifications, a transaction (unless otherwise specified) is considered
to be one conducted over the contactless interface with a contactless card.
A transaction start is defined differently depending on how it is initiated. It can be
initiated by the merchant, typically by entering the transaction amount. Alternatively, it
can be initiated when a card enters the polling field and responds, indicating its
presence. (Configuration of transaction initiation is described in more detail in
section 5.6.2.)
A transaction continues until the final transaction disposition is indicated to the
cardholder. This may be immediately after the kernel processing for an offline
approval or decline or after reception of the authorisation response if the transaction
is sent online. If further communication with the card is required, then this is a part of
the transaction.
If another interface is requested, then the contactless transaction is concluded and a
new (non-contactless) transaction is considered to start with whichever alternate
interface is selected.

Page 17

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

4.3 POS System

Within these specifications, a POS System is the device that communicates with
contactless cards, processes contactless transactions, and may support other
payment functionalities such as magnetic stripe or contact chip transactions.
The physical architecture can be any of the following:
• Fully integrated terminal: All elements included in a single device.
• Intelligent card reader: The reader handles most of the contactless
transaction processing, passing the results for completion by the terminal.
• Combination of terminal and transparent card reader: The reader provides
communication with the card, whilst kernels and other processes are in the
terminal.
The second and third architectures are representative of adding a contactless reader
to an existing contact terminal that may already be deployed.
The basic functions of the POS System include:
• communication with contactless cards
• application selection and kernel activation
• displaying messages to the cardholder
• displaying messages to the merchant
• accepting merchant data entry of the transaction amount
• cardholder verification (e.g. signature)
• provision of online connections
• provision of data capture for clearing and settlement

Page 18

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

4.4 Entry Point

Within these specifications, Entry Point is software in the POS System that is
responsible for the following:
• performing pre-processing
• discovery and selection of a contactless application that is supported by both
the card and the reader
• activation of the appropriate kernel
• handling of Outcomes returned by the kernel, including passing selected
Outcomes to the reader
Under exception conditions, Entry Point may return an Outcome to the reader as a
result of its own processing.
Detailed information about Entry Point is provided in Book B.

4.5 Kernel
Within these specifications, a kernel is software in the POS System that processes
certain contactless transactions. Entry Point selects a kernel based on the
characteristics of the transaction, the applications supported by both the card and the
reader, and the priority that may be assigned to each application.
Detailed information about the kernels is provided in Books C-n.

4.6 Outcome
An Outcome is the primary instruction from the kernel on how processing should be
continued. A set of parameters with the Outcome allow the kernel to indicate choices,
such as messages to be displayed and whether the kernel wishes to be restarted, for
example, after an online authorisation.
When a kernel provides an Outcome, control is passed back to Entry Point which
handles certain parameters immediately, then either processes the Outcome or
forwards it to the reader as a Final Outcome.
Note: Under exception conditions, Entry Point may not be able to select a kernel and
will directly provide a Final Outcome and pass control back to the reader.
Detailed information about Outcomes is provided in Chapter 6.

Page 19

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5 POS System Architecture

This chapter discusses the architecture of the POS System. The following topics are
included:
5.1 POS System Descriptive Model ..................................................................20
5.2 Terminal and Reader Responsibilities ........................................................ 22
5.3 Logical Architecture ....................................................................................23
5.4 Operating Modes ........................................................................................24
5.5 POS System Functions ...............................................................................25
5.6 POS System Configuration .........................................................................30
5.7 Transaction Data ........................................................................................34
5.8 Entry Point Processing ...............................................................................37
5.9 Kernel Processing .......................................................................................41

5.1 POS System Descriptive Model

To accommodate the broad range of possible architectures discussed in section 4.3
without developing detailed requirements for all the individual elements, EMVCo has
based its design on the descriptive model shown in Figure 5-1. Conceptually this is
along the lines of an intelligent reader device as this is considered to be the most
widespread architecture; however, it is not intended to be prescriptive.

Page 20

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

Figure 5-1: POS System Descriptive Model

POS System

Activate (with Data)

Terminal Reader

Display Display

Data
1 2 3
Exchange
4 5 6
7 8 9
COMMS C 0 E

Final Outcome

The right hand element represents a reader which communicates with the
contactless card and processes the contactless application. It therefore includes the
functionality of Entry Point and the contactless kernels. It would also normally contain
the user interface of cardholder-facing display, visual status indicators (such as lights
or LEDs), and beeper.
The left hand element maps more closely to an EMV contact terminal and includes
the merchant input and display, the online communications interface, plus any
contact or mag-stripe interfaces. Functions such as signature CVM or online PIN
CVM are expected to be acquired the same way as for an EMV contact terminal.
Most of the EMV Contactless Specifications for Payment Systems address the
reader element; this includes the Communication Protocol to a contactless card
(Book D), Entry Point (Book B), and the contactless kernels (Books C-n).

Page 21

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.2 Terminal and Reader Responsibilities

Within the descriptive model the reader is responsible for:
• communication with contactless cards
• application selection and kernel activation
• running the contactless kernel applications
• CVM selection
• creation of a Final Outcome and parameter set
• management of a “no card response” timeout
• management of the contactless field
Whilst the terminal is responsible for:
• provision of data entry (amount) by the merchant
• processing of Final Outcomes, including the handling of authorisation
requests and responses
• cardholder verification (unless delegated to a cardholder device, such as a
mobile phone)
• communication for authorisation messages and clearing records, using
mag-stripe or chip-based data
• transactions on other interfaces (contact and mag-stripe)
• other aspects of transaction processing, including timeouts and cancellations
Depending on the design, the terminal and reader are between them also
responsible for:
• initiation of new transactions, including card removal and the contactless field
state between transactions
• displaying messages to the merchant
• displaying messages and status to the cardholder
• provision of Unpredictable Numbers
• provision of data included in online responses, including Authorisation
Response Code, Issuer Authentication Data, and Issuer Scripts
• indication of “unable to go online”
With respect to performance, the reader will be mostly responsible for the “card in
field” timing and the terminal for the transaction disposition timing. For details see
section 10.

Page 22

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.3 Logical Architecture

Figure 5-2: Logical Architecture

The reader contains Entry Point and a set of kernels, as illustrated in Figure 5-2.
Terminal and reader requirements in Chapter 8 are based on this model but can be
distributed differently between the elements denoted as the terminal and the reader.
Nevertheless, for the overall architecture described here to work successfully with all
merchant/acquirer acceptance environments, the functional requirements of
Chapter 8 must be met.

Page 23

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.4 Operating Modes

A terminal is installed in an acceptance environment that can handle mag-stripe data,
chip data, or both. This information is provided in the Kernel Configuration Data and
in conjunction with the card presented will determine the operating mode of an
individual transaction: mag-stripe mode or EMV mode. Mag-stripe mode transactions
are usually sent online for authorisation, whereas EMV mode transactions may
complete offline in the interest of speed, and can be sent online when the situation
requires it.

Page 24

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.5 POS System Functions

This section discusses the following POS System functions:
5.5.1 Non-interference with Contact Chip Interface ................................. 25
5.5.2 No Overlapping Transactions ......................................................... 26
5.5.3 Cancellation .................................................................................... 26
5.5.4 Field Management .......................................................................... 27
5.5.5 Displaying Amount .......................................................................... 27
5.5.6 Transaction Disposition................................................................... 27
5.5.7 Receipts .......................................................................................... 28
5.5.8 Cardholder Verification ................................................................... 28

5.5.1 Non-interference with Contact Chip Interface

For a POS System capable of accepting transactions over multiple interfaces, all
permitted interfaces should be made available to the merchant/cardholder to perform
a transaction. If the cardholder chooses the contact interface, to prevent interference
between the contact chip and contactless interfaces, the POS System must
power down the contactless interface prior to initiating a contact chip transaction and
keep it powered down for the duration of the transaction.

Page 25

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.5.2 No Overlapping Transactions

The POS System is responsible for ensuring that a new transaction is not started
until the completion of the previous transaction. The completion of a transaction is a
combination of the terminal having a transaction disposition and the physical removal
of the card from the field. In some environments it may be necessary to employ a
removal procedure to ensure that the card has left the field, whereas in others the
physical configuration and the way the transaction completes may be sufficient.
Examples:
In some environments, such as a vending machine where the user has to
physically collect goods from the bottom of the machine, it is unlikely that the card
will be left on the reader or that the next customer will try to make a purchase
before the first customer has moved away. Such a POS System could have
simple logic to manage card removal and initiation of the next transaction.
In other environments, such as access through a gate or turnstile, it may be
important that the POS System checks that a card has been physically removed
and that the next transaction is not initiated until the first customer has made
sufficient progress through the gate. Note that a removal procedure for the card
as defined in Book D, section 9.5, could be started when the kernel indicates the
Card Read Successfully status, 1 as this is the earliest point in a transaction after
which cards can be removed.
Kernels may require a mobile device to be re-presented after entry of a
confirmation code and this may be addressed by means of a restart. Some
kernels may require the POS System to check that the mobile device was
actually removed from the field after the first presentment, possibly by use of the
removal procedure between the Final Outcome and the restart.

5.5.3 Cancellation
Once a transaction has been started, there must be a means to cancel the
transaction in case the user is unable to present a contactless card within a
reasonable amount of time. This may be by means of a timeout or merchants may
have a cancel option. To handle these scenarios, depending on the implementation,
the POS System may attempt to complete the transaction using another interface, or
may terminate the transaction.

1
Status values are discussed in section 9.2.
Page 26

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.5.4 Field Management

Whether the field is on or off between transactions will depend on the acceptance
environment, and the POS System is responsible for ensuring the field condition. For
environments with Autorun “No”, the field is off between transactions; with Autorun
“Yes”, the field is on between transactions. This does not preclude the POS System
from manipulating the field whilst ensuring the transaction is complete. (Autorun is
described in more detail in section 5.6.2.)

Additionally, it is generally recommended for Kernels to always request a field reset

or power-off (depending on factors such as cardholder device formfactor) at the end
of transaction, for example, by setting an appropriate value for the Outcome
Parameter, Field Off Request.

5.5.5 Displaying Amount

In acceptance environments where the Transaction Type and the exact amount are
known before the start, the amount must be indicated to the cardholder, preferably by
means of a terminal/reader display. In some circumstances the amount may be
displayed by labels, such as posted prices on a vending machine. This is typical for
EMV mode environments (with Autorun “No”) where the Transaction Type and
amounts are made known to the reader as the transaction is started.
Other environments may not know the Transaction Type or amount until the
interaction with the card is complete. This is typical for mag-stripe mode
environments (with Autorun “Yes”).

5.5.6 Transaction Disposition

The POS System is responsible for indicating the transaction disposition to the
cardholder. The transaction disposition may be obtained directly from the Outcome
(if Approved or Declined), or it may be necessary that an online authorisation be
completed first. The manner of indication may be via a message, vending of goods,
granting or denying access, or other functions.
An online authorisation will either result in a response with a Response Code and
possible EMV TLV data, or will timeout and be considered as unable to go online.
In EMV mode environments, typical EMV TLV data elements that may be present are
Authorisation Response Code (Tag '8A'), Issuer Authentication Data (Tag '91'), and
Issuer Script Template (Tag '71', '72').

Page 27

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.5.7 Receipts
The POS System may have acceptance rules relating to receipts, specific to location,
environment, and possibly payment system. In such cases, an ‘N/A’ in the Outcome
parameter Receipt indicates that the kernel has no preference and that these rules
should be applied as applicable.

5.5.8 Cardholder Verification

Under certain circumstances when performing a contactless transaction, the POS
System may be required to request Cardholder Verification to ensure that the person
presenting the card is the person to whom the application in the card was issued.
The kernel should be aware of the CVM capabilities of the POS System (e.g. the
capability to print a Signature, or for Online PIN CVM the presence of a PIN entry
device and acquirer online message capabilities).
As described in section 5.9, once the kernel has finished processing the contactless
transaction, an Outcome is indicated by the kernel. For some Outcomes the
Outcome parameters set by the kernel may indicate a request for Cardholder
Verification or indicate that Cardholder Verification has already taken place.
The identified CVMs and corresponding requirements are described below:
Online PIN
The kernel requests that an online transaction includes a PIN.
• The cardholder is prompted for PIN entry.
• The PIN is encrypted and included in the online authorisation request.
• If the timeout function supporting the Removal Timeout has been
requested in the Outcome parameters, then it should be deferred until the
completion of PIN entry.
Confirmation Code Verified
The kernel indicates that the consumer has positively completed a CVM on their
consumer device (e.g. mobile phone). This may be as a result of a single
presentment with the Confirmation Code pre-entered by the cardholder, or it may
be the result of two presentments with a restart and the Confirmation Code being
entered by the cardholder when prompted by the kernel.

Page 28

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

Obtain Signature
The kernel requests that a signature be obtained from the cardholder.
• If the terminal supports signature capture on a transaction receipt, then
the terminal prints a receipt with a signature entry line.
• If the terminal supports signature capture via screen entry, then the
terminal displays the signature screen panel.
• The cardholder is prompted for a signature.
No CVM
The kernel indicates that no cardholder verification is required for this transaction
and no CVM should be requested.
N/A
The kernel indicates no CVM preference.
The POS System may have acceptance rules relating to CVM, specific to
location, environment, and possibly payment system. In such cases, an ‘N/A’
indicates that the kernel has no preference and that these rules should be applied
as applicable.

Page 29

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.6 POS System Configuration

The POS System must have configuration data that defines:
• country and currency codes
• how a transaction is initiated (by terminal action or automatically after
a previous transaction is completed)
• the supported operating modes
• the types of transaction supported
• for each combination of transaction type, application, and kernel, both Kernel
Configuration Data and Entry Point Configuration Data
Details about the various types of configuration data are provided in the following
sections.

5.6.1 POS System Country and Currency Codes

The POS System must be configured with a Terminal Country Code (Tag '9F1A') and
with one or more Transaction Currency Codes (Tag '5F2A'), depending on whether
multiple currencies are supported.

Page 30

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.6.2 POS System Configuration for Starting a Transaction

The POS System must be configured such that a contactless transaction is either
initiated by terminal action or starts automatically after the previous transaction has
completed.
The configuration parameter is Autorun [No, Yes].
Support for the Autorun parameter is optional. If the Autorun parameter is not
supported, then the POS System must function as if the value of Autorun is "No".
If the value of Autorun is “No”, then the transaction start is initiated by the merchant,
typically by entering the amount. If the value of Autorun is “Yes”, then the transaction
start is when a card enters the polling field and responds, indicating its presence.
In general “No” is for environments supporting EMV mode transactions, where the
terminal needs to know the amount before starting a transaction, the field is off
between transactions, and the reader is dependent on and under control of the
terminal. “Yes” is generally for environments supporting mag-stripe mode
transactions, where the field is on between transactions, and the reader does not
depend on the terminal and initiates contactless transactions independently.
Depending on the acceptance environment, the Autorun parameter is not constrained
as above. For example, environments supporting EMV mode transactions with a
fixed amount and field on between transactions could use Autorun “Yes” and
environments supporting mag-stripe mode transactions with manual start and field off
between transactions could use Autorun “No”.

5.6.3 POS System Configuration for Acceptance

Environment
The operating modes supported by a POS System will depend on the acceptance
environment and acceptance rules. Kernels need to know this in order to request the
necessary data elements and execute the applicable processing flow. Therefore
configuration data is provided to the kernel by the POS System indicating the
operating modes that it supports:
• EMV mode
• Mag-stripe mode
• Both EMV mode and mag-stripe mode
This terminology is generic for the purposes of this specification. The actual
configuration parameters will vary per Combination {AID – Kernel ID} and details of
the parameters for each kernel can be found in the corresponding Book C.

Page 31

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.6.4 POS System Configuration for Type of Transaction

The POS System needs to know the types of transaction it supports, from the
following list:
• Purchase
• Purchase with cashback
• Cash Advance (cash withdrawal)
• Refund
In order for a kernel to function correctly, it needs to know about the environment in
which it is installed and what can be expected of Entry Point and the terminal. The
functionality can differ for the type of transaction and between AIDs supported by a
given kernel. In order for Entry Point processing to match kernel expectations, the
reader must be configurable with respect to the kernels and AIDs it supports. For
each type of transaction supported, this list of Combinations {AID – Kernel ID} can be
represented by a table, as indicated by the example in Table 5-1.

Table 5-1: Example Combination Table per Transaction Type

AID1 AID2 … AIDn-1 AIDn

Kernel 1 √

Kernel 2 √

Kernel 3 √ √

Kernel 4 √

Kernel 5 √ √

Kernel 6 √

Kernel 7 √ √

Page 32

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.6.5 Kernel and Entry Point Configuration Data

For each supported combination {AID – Kernel ID }, the reader has:
1. Kernel Configuration Data – For each supported type of transaction, A set of
static data for kernel configuration.
The value of this data is persistent from one transaction to the next and
represents configuration information such as the mode (EMV / mag-stripe),
CVM support, online/offline capabilities, and the RID-specific CA public key
dataset. Updates of the values are exceptional and always occur outside of
transaction processing. Details of the data that must be configured for each
kernel can be found in the corresponding Book C.
Note: Tag values can have different meanings for different kernels.
The appropriate data set will be available to the kernel selected by Entry Point.
2. Entry Point Configuration Data – For each supported type of transaction, A set of
static data for Entry Point processing.
Again, the value of this data is persistent and represents transactional
configuration information, such as contactless limits and CVM limits. Exceptional
updates happen outside of transaction processing.
Table 5-2 defines the available data set for each Combination. All configured data
sets will be available for Entry Point processing. All elements defined in Table 5-2
are optional and may be omitted from a specific instance of a combination.

Table 5-2: Entry Point Configuration Data per Combination

Status Check Support flag, if present

Zero Amount Allowed flag, if present
Reader Contactless Transaction Limit, if present
Reader Contactless Floor Limit, if present
Terminal Floor Limit (Tag '9F1B'), if present
Reader CVM Required Limit, if present
Terminal Transaction Qualifiers, if present
Extended Selection Support flag, if present

Page 33

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.7 Transaction Data

Entry Point uses the data sets described in section 5.6.5 during Pre-Processing to
compute the Entry Point Pre-Processing Indicators for each combination, as defined
in Table 5-3.
The indicators are made available to the kernel selected by Entry Point.
Entry Point temporarily stores the computed indicators to support selection of another
combination for the same transaction or reactivation of a kernel after an Online
Request Outcome.
In addition to the configuration data discussed above, each kernel will need data that
is specific to the transaction. Typical transaction-specific data elements are listed in
Table 5-5.

Table 5-3: Entry Point Pre-Processing Indicators

Status Check Requested

Contactless Application Not Allowed
Zero Amount
Reader CVM Required Limit Exceeded
Reader Contactless Floor Limit Exceeded
Copy of TTQ (if present as part of configuration data);
for definition, see Table 5-4

Page 34

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

Table 5-4: Terminal Transaction Qualifiers

Byte Bit Definition

1 8 1b – Mag-stripe mode supported
0b – Mag-stripe mode not supported
7 RFU (0b)
6 1b – EMV mode supported
0b – EMV mode not supported
5 1b – EMV contact chip supported
0b – EMV contact chip not supported
4 1b – Offline-only reader
0b – Online capable reader
3 1b – Online PIN supported
0b – Online PIN not supported
2 1b – Signature supported
0b – Signature not supported
1 1b – Offline Data Authentication for Online Authorizations
supported
0b – Offline Data Authentication for Online Authorizations not
supported

2 8 1b – Online cryptogram required

0b – Online cryptogram not required
7 1b – CVM required
0b – CVM not required
6 1b – (Contact Chip) Offline PIN supported
0b – (Contact Chip) Offline PIN not supported
5-1 Each bit RFU
3 8 1b – Issuer Update Processing supported
0b – Issuer Update Processing not supported
7 1b – Consumer Device CVM supported
0b – Consumer Device CVM not supported
6-1 Each bit RFU
4 8-1 Each bit RFU

Page 35

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

Table 5-5: Example Transaction-specific Data Elements

Data Element Tag Notes

Transaction Type '9C' See Table 5-6 regarding the
values of these data
Amount, Authorised (Numeric) '9F02' elements.

Amount, Other (Numeric) '9F03'

Unpredictable Number '9F37'

Transaction Currency Code '5F2A' Transaction-specific only if

multiple currencies are
supported.

The type of transaction, amount, and cashback amount are known to the terminal
and are mapped as described in Table 5-6.

Table 5-6: Type of Transaction

Type of Transaction Amount, Authorised Amount, Other

Transaction Type (Numeric) (Numeric)
(Tag '9C') (Tag '9F02') (Tag '9F03')
Purchase '00' Purchase amount Zero

Purchase with '00' or '09' Sum of purchase and Cashback amount

cashback cashback amount

Cash Advance '01' Withdrawal amount Zero

Refund '20' Amount to be refunded Zero

Details of the data that must be available for each kernel can be found in the
corresponding Book C. For example, a kernel that supports Online Response may
also require online response data such as Issuer Authentication Data and Issuer
Scripts.
Note: Tag values can have different meanings for different kernels.

Page 36

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.8 Entry Point Processing

Entry Point is responsible for processing the configuration data, the discovery and
selection of a mutually supported contactless application, activation of the
appropriate kernel, and handling of the Outcome when the kernel finishes (including
processing selected Outcome parameters and passing the Outcome to the reader).
Under exception conditions, Entry Point may return an Outcome to the reader as a
result of its own processing.

The mechanism to select an application is designed around the presence of a

Proximity Payment System Environment (PPSE) in the card. This allows Entry Point
to obtain all the available brands and applications with a single command and to
make an immediate choice based on priority and kernel availability.
The use of additional proprietary selection methods is not precluded but is outside of
the scope of this specification. Users of such methods should be aware of the
potential negative impact on performance introduced by any increase in the number
of commands. The method also must deal with the complexity of managing priorities
amongst all available brands and applications.

5.8.1 Starting Conditions

For environments in which the field is normally off, Entry Point will not be started for a
new transaction before the POS system knows that the card has been removed from
the field (e.g. by using a removal procedure) and the normal start conditions (such as
amount entry) have been fulfilled. This is typically the situation for EMV mode
environments.
For environments in which the field is normally on, Entry Point will be started for a
new transaction before the POS system knows that the card has been removed from
the field (e.g. by using a removal procedure). This is typically the situation for
mag-stripe mode environments. It does not however preclude that merchant
interaction might be required to turn on the field, perhaps for power saving in battery
powered devices.

Page 37

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

Entry Point may start at any of several start locations, depending on the environment
and, if it is being restarted within a transaction, depending on the characteristics of
the first Final Outcome.
Start A
Start A is normally used for a new transaction in an EMV mode acceptance
environment where the field is off between transactions and the amount is
variable and determined (e.g. by merchant entry) before the transaction can start.
When starting at Start A, configuration data supplied by the POS System is
processed for each supported Combination to produce the Entry Point
Pre-Processing Indicators.
Start B
Start B is normally used for a new transaction in a mag-stripe mode acceptance
environment where the field is on between transactions and the amount is fixed
or not needed for the contactless processing. When starting at Start B, there is
no Pre-Processing and the Entry Point Pre-Processing Indicators have fixed
values.
Environments with a fixed amount (e.g. a vending machine with identically priced
goods) that may normally have the field off between transactions do not need
Pre-Processing and can use Start B.
Start B can be also used when Entry Point is restarted within a transaction, either
after an online request or if a card is to be re-presented (e.g. mobile device with
confirmation code).
Start C and Start D
Start C is used when Entry Point is restarted within a transaction in order to
attempt a different Combination {AID – Kernel ID}.
Start D is used when Entry Point is restarted within a transaction in order to
process data provided in response to an online request, for risk management
purposes.
When starting at Start C or Start D, Entry Point provides the kernel with the
original Entry Point Pre-Processing Indicators.

Page 38

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.8.2 Application Selection and Kernel Activation

The selection mechanism is designed around the use of a PPSE. For multi-brand
acceptance, this allows Entry Point to obtain all the available brands and applications
with a single command and to make an immediate choice based on priority and
kernel availability.
A PPSE response returned by a card contains one or more File Control Information
(FCI) data elements forming a list of products supported by the card, the kernel they
will run with, and their priority relative to one another.
Entry Point compares the ADF Names and Kernel Identifiers with the transaction type
specific set of Combinations of AIDs and kernels that it supports for the given
transaction type. The result is a list of Combinations, prioritised according to priority
value or (for equal priority matches) by their order in the FCI list. AIDs and ADF
Names can be obtained from the relevant payment system.
Existing cards that are already deployed do not have a Kernel Identifier in the FCI
data; Entry Point reads absence of a Kernel Identifier as ‘existing application’. The
type of existing application is determined from the AID. The current mapping is as
follows:
Kernel 1 for some cards with JCB AIDs and some cards with Visa AIDs
Kernel 2 for MasterCard AIDs
Kernel 3 for Visa AIDs
Kernel 4 for American Express AIDs
Kernel 5 for JCB AIDs
Kernel 6 for Discover AIDs
Kernel 7 for UnionPay AIDs
Exceptions to the above may occur if Entry Point has a specific setting for the linkage
between a product and a kernel.
In the final selection, Entry Point picks the Combination with the highest priority,
sends the SELECT AID command with the AID of this Combination, and hands over
processing to the selected kernel. The Entry Point Pre-Processing Indicators for the
relevant Combination are made available to the selected kernel.
Note that this flexible approach allows for a specific card to include multiple Directory
Entries pointing to the same kernel for different ADF Names, or conversely pointing
to different kernels for the same ADF Name.

Page 39

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.8.3 User Interface Request

During Entry Point processing, if Entry Point wishes to inform the cardholder about
the progress of the transaction, Entry Point may send a User Interface Request and
expects the reader to process this request.
The request will contain a combination of the data listed in Table 7-1 on page 59.

Page 40

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.9 Kernel Processing

Once activated, a kernel continues the dialogue with the card using the necessary
command/response exchanges and might call for a User Interface Request
(e.g. “Remove Card”) from the reader. On completion the kernel provides an
Outcome to Entry Point and the Outcome is processed according to the guidelines in
Chapter 8.

5.9.1 User Interface Request

During kernel processing, if a kernel wishes to inform the cardholder about the
progress of the transaction, the kernel may send a User Interface Request and
expects the reader to process this request.
The request will contain a combination of the data listed in Table 7-1 on page 59.

5.9.2 Processing Data Exchange

Data Exchange provides a flexible communication mechanism between terminal and
kernel. It allows the kernel to send data to and request data from the terminal. Using
the Data Exchange mechanism, the kernel can take the initiative to request a service
from the terminal (e.g. for hot file/exception list checking) and will do so by requesting
a Data Exchange.
If the terminal is able to service the request, it will return a Data Exchange with the
requested data. This mechanism allows the terminal to exercise a level of control on
the kernel – and may influence the kernel’s interaction with the card – by virtue of its
ability to update the current transaction data.
The data or service that is requested is context specific and may vary with the kernel
and the AID currently in use. Implementations must take care that data is exchanged
with the correct kernel while it is active.

Page 41

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

5.9.3 CVM Selection and Cardholder Verification

During kernel processing, the kernel will determine from the acceptance environment
and issuer settings in the card whether a cardholder verification is needed for the
transaction. Methods that may be supported are online PIN and signature – offline
PIN is not suitable due to the “card in field” timing issues.
In some markets it may be that contactless transactions are designated as without
cardholder verification, but only for transaction amounts below a certain limit,
whereas other markets, perhaps with an online PIN infrastructure in place, may allow
any amount for contactless transactions, with online PIN above a certain threshold.
The use of mobile devices allows for the entry of Consumer Device CVM on the
handset as a CVM.
More information on cardholder verification processing can be found in section 5.5.8.

Page 42

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

6 Outcomes and Parameters

An Outcome is the primary instruction from the kernel or Entry Point on how
processing should be continued. The parameters allow the kernel to indicate choices,
such as messages to be displayed and whether the kernel wishes to be restarted
after an online authorisation.
When a kernel provides an Outcome, control is passed back to Entry Point which
handles certain parameters immediately, then either processes the Outcome or
forwards it to the reader as a Final Outcome.

6.1 Outcomes
The following Outcomes are defined:
• Select Next
• Try Again
• Approved
• Declined
• Online Request
• Try Another Interface
• End Application
Table 6-1 describes the Outcomes and indicates the responsibilities of the kernel,
Entry Point, and the reader or terminal for each.

Page 43

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.1 Outcomes

Table 6-1: Outcomes

Outcome Description Kernel Entry Point Reader/ Terminal

Select Next The kernel has determined that the selected Creates Outcome, Processes Outcome No processing
Combination is unsuitable and the next passes to Entry
Combination (if any) should be tried. Point

Try Again The kernel wishes that a card be presented

again; this may be a result of an error, such as
tearing, that could resolve if the transaction is
attempted again. It is one way a kernel may
handle a mobile device that requires a
confirmation code to be entered.

Page 44
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the
user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.1 Outcomes

Outcome Description Kernel Entry Point Reader/ Terminal

Approved The kernel is satisfied that the transaction is Creates Outcome, • Processes Processes the Final
acceptable with the selected contactless card passes to Entry selected Outcome Outcome
application and wants the transaction to be Point parameters
approved. This is the expected Outcome for a • Passes Outcome
successful offline transaction. This might also to reader as a
occur following reactivation of a kernel after an Final Outcome
online response.

Declined The kernel has found that the transaction is not

acceptable with the selected contactless card
application and wants the transaction to be
declined. This might also occur following
reactivation of a kernel after an online response.

Online The transaction requires an online authorisation

Request to determine the approved or declined status. If
the kernel wishes to be restarted when the
response has been received (e.g. to receive
issuer update data), then this is indicated in the
parameters.

Page 45
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the
user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.1 Outcomes

Outcome Description Kernel Entry Point Reader/ Terminal

Try Another Either of the following: May create Either of the following: Processes the Final
Interface • The kernel is unable to complete the Outcome and pass • Receives Outcome Outcome
transaction with the selected contactless card it to Entry Point from kernel,
application, but knows from the configuration processes selected
data that another interface (e.g. contact or Outcome
magnetic-stripe) is available. The kernel parameters, and
could indicate a preference for the alternate passes Outcome
interface. to reader as a
• Entry Point was unable to identify a Final Outcome
contactless card application that could • Under exception
complete the transaction and returns control conditions, creates
to the POS System, which might attempt a Outcome and
different interface. passes it to reader

Page 46
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the
user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.1 Outcomes

Outcome Description Kernel Entry Point Reader/ Terminal

End Any of the following:
Application • The kernel has completed processing and
requires no further action.
• The kernel wished to restart after the card
has been removed. It is one way a kernel
may handle a mobile device that requires a
confirmation code to be entered.
• The kernel experienced an application error,
such as missing data, that will not resolve if
the transaction is attempted again with the
same selected contactless card application.
• Entry Point was unable to identify a
contactless card application that could
complete the transaction with the current card
and wants the POS System to direct the
cardholder to present another card.

Page 47
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the
user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.2 Outcome Parameters

6.2 Outcome Parameters

Each Outcome has a list of mandatory parameters:
• Start
• Online Response Data
• CVM
• UI Request on Outcome Present
• UI Request on Restart Present
• Data Record Present
• Discretionary Data Present
• Alternate Interface Preference
• Receipt
• Field Off Request
• Removal Timeout
The parameters indicate the kernel’s expectations of Entry Point, the reader, and the
terminal (or Entry Point’s expectations of the reader and the terminal). These include
user interface needs, and if and where Entry Point processing should be restarted,
for example, after an online authorisation. It is expected that kernels will be
configured such that they will only make requests that are supported by the
environment.
Note: The precise format for the Outcome Parameters may differ on a kernel to
kernel basis. It is also advised that future kernel developers should follow the same
format from one of the existing kernels.
The Outcome Parameters are defined in Table 6-2.

Page 48
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.2 Outcome Parameters

Table 6-2: Outcome Parameters

Outcome Parameter Description Values Meaning of Value

Start Indicates whether Entry Point should
be restarted after the Outcome has B Restart Entry Point from Protocol Activation. If the
been processed, and which Entry same card is present, the same kernel will be
Point start location should be used. selected.
Typically used in conjunction with an • Used by Online Request for “two presentments”.
online request and allows for issuer • Used by End Application to confirm card
risk management via a variety of removal before restart.
approaches, such as a “second
• Used by Try Again, which is processed by Entry
presentment” or “present and hold”.
Point.
It may also be used to allow card
removal to be confirmed, before a
kernel is restarted. C Restart Entry Point from Combination Selection.
Currently only used by Select Next processed
internally by Entry Point.
D Restart Entry Point from Kernel Activation. The same
kernel will be selected. There will be no removal
procedure and the field will stay on. Used by Online
Request for “present and hold”.
N/A Do not restart Entry Point.

Page 49
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the
user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.2 Outcome Parameters

Outcome Parameter Description Values Meaning of Value

Online Response Conditions whether the kernel should EMV Data The kernel restart should occur only if the EMV TLV
Data be restarted based on the presence data Tag '91', '71', and/or '72' is present in the online
of data in the online response. response. (If the kernel wishes to be restarted only
for issuer risk management, but no issuer update
data is returned, then there is no point in restarting
the kernel.)
Any The kernel restart should occur regardless of the
presence of any online response data. Used, for
example, for “present and hold”.
N/A Not applicable.

Page 50
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the
user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.2 Outcome Parameters

Outcome Parameter Description Values Meaning of Value

CVM The kernel may request cardholder Online PIN The kernel requests that an online transaction
verification or may indicate that CVM includes a PIN (having determined that online PIN is
has already occurred. supported).
Confirmation The kernel indicates that the consumer has
Code Verified successfully completed a CVM on their consumer
device (e.g. confirmation code entry on a mobile
phone).
Obtain The kernel requests that a signature be obtained
Signature from the cardholder. The terminal may print a receipt
with a signature entry line, or the terminal may have
other means, such as electronic signature capture.
No CVM The kernel indicates that no cardholder verification is
required for this transaction.
N/A The kernel indicates no CVM preference. A CVM
may or may not be required as a result of
acceptance rules applied by the POS System.
UI Request on Either the kernel or Entry Point may Yes The User Interface Request defined in section 7.1
Outcome Present include a User Interface Request to No may be used to indicate a message/status to be
be acted upon as the outcome is presented to the cardholder.
processed.

Page 51
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the
user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.2 Outcome Parameters

Outcome Parameter Description Values Meaning of Value

UI Request on The kernel may include a User Yes The kernel can use a User Interface Request as
Restart Present Interface Request to be processed No defined in section 7.1 to indicate a message/status
if Entry Point is restarted. to be presented to the cardholder as Entry Point is
restarted.
The two UI Requests can be used as a pair, for
example to provide advice before and instruction
after online processing.
Data Record Present Depending on the transaction Yes The data provided may be full chip data, or reduced
outcome, the kernel will make No data appropriate to a specific kernel. An overview is
available data records appropriate to found in Annex A and details are specified in
the implementation for clearing Books C-n.
and/or authorisation.
Discretionary Data The kernel indicates whether it has Yes The use of kernel discretionary data provided in
Present made available discretionary data No association with an Outcome is not addressed in this
(e.g. balance, cardholder name). specification.
Alternate Interface The kernel indicates a preference for Contact Chip Indicates the kernel’s preference, if any.
Preference an alternate interface if the Mag-stripe
contactless interface cannot be used.
N/A

Page 52
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the
user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.2 Outcome Parameters

Outcome Parameter Description Values Meaning of Value

Receipt The kernel indicates whether a Yes Provide a receipt.
receipt is to be provided.
N/A The kernel has no preference. A receipt may or may
not be required as a result of acceptance rules
applied by the POS System.
Note: If the value of the CVM parameter is ‘Obtain
Signature’, then the terminal may choose to obtain it
by means of a receipt with signature entry line,
regardless of the value of this parameter.
Field Off Request The kernel indicates whether to hold time value Any value (including zero) indicates that the field is
turn off the field (without card to be turned off. The hold time is in units of 100ms.
removal procedure). The hold time
N/A No change to the field is requested.
will delay the processing of the next
change to the field until it has
elapsed.
Removal Timeout The kernel indicates whether a time value For an Online Request Outcome, the kernel may
timeout function should be started instruct the terminal to start a timeout function and, if
with the time specified. the timeout occurs, to prompt the user to remove the
card. When the online response is received (or if the
terminal was unable to go online), the result of the
timeout will be available to the kernel when it is
restarted.
The parameter value indicates the time setting for
the timeout function, in units of 100ms.
The default is zero (no timer).

Page 53
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the
user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV Contactless Book A
Architecture & General Requirements v2.6

6.3 Outcome Processing

In order to complete the transaction and arrive at the correct start for the following
new transaction, the POS System must process each kind of Outcome as described
below. The requirements listed are allocated to the reader and terminal according to
the architectural overview described in Chapter 5, but the separation between the
two may differ between implementations and it is not important which entity performs
the actions, provided that the overall POS System fulfils all the requirements.
Table 6-3 describes POS System processing for a first Final Outcome. Table 6-4
describes POS System processing for a second Final Outcome; that is, one that
follows an Online Request Outcome.

Table 6-3: First Final Outcome

First Final POS System Processing

Outcome
Approved • The terminal considers the transaction disposition as
“approved”.
• The terminal advises the cardholder of the transaction
outcome.
• If a cardholder receipt is required, the terminal prints it or provides it
electronically (e.g. email).
• The terminal captures CVM signature or online PIN if requested.
• The terminal prepares a clearing record using the data record
provided with the Outcome.
• Once the above steps are complete, the POS System
continues processing at ‘Requirements – New Transaction
Preparation and Start’ on page 64.
Declined • The terminal considers the transaction disposition as
“declined”.
• The terminal advises the cardholder of the transaction
outcome.
• Once complete, continue with ‘Requirements – New
Transaction Preparation and Start’ on page 64.

Page 54

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.3 Outcome Processing

First Final POS System Processing

Outcome
Online • The POS System advises the cardholder that an online
Request transaction is in progress. An initial message to the
cardholder might have been displayed as a result of the
kernel including a User Interface Request with the Outcome.
If a PIN CVM is required, then the message directs the
cardholder to enter the PIN.
• The terminal initiates an online authorisation request, using
the data record provided with the Outcome. If the CVM is
online PIN, then the terminal processes and submits the
encrypted online PIN.
• The terminal receives the online response or might determine
that the request was unable to go online.
• If the Start parameter was any value other than ‘N/A’, then:
• The terminal makes available the transaction disposition
in the online response together with all of the EMV TLV
data elements present.
• The reader reactivates Entry Point by continuing with
‘Requirements – Online Response – Restart’ on page 69.
• The terminal determines the transaction disposition, based on
the online response indication (with Unable To Go Online a
decline).
• The terminal advises the cardholder of the transaction
outcome.
• If a cardholder receipt is required, the terminal prints it or provides it
electronically (e.g. email).
• The terminal captures CVM signature or online PIN if requested.
• The terminal prepares a clearing record if transaction
disposition is “approved”.
• Once complete, continue with ‘Requirements – New
Transaction Preparation and Start’ on page 64.

Page 55
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.3 Outcome Processing

First Final POS System Processing

Outcome
Try Another • The terminal allows the transaction to be attempted on
Interface another interface – contact chip or mag-stripe according to its
capabilities. If a preference is indicated in the Outcome, then
(depending on payment system rules) this might need to be
taken into account.
• The POS System advises the cardholder that another
interface might be used. An initial message to the cardholder
might have been displayed as a result of including a User
Interface Request with the Outcome.
• The terminal processes the transaction using the other
interface and might use the ADF Name provided with the
Outcome to seek to select the same application if the chip
interface is used. Cardholder communication will be as per
the normal processing for a chip or mag-stripe interface.
• Once complete, continue with ‘Requirements – New
Transaction Preparation and Start’ on page 64.
End If the Start parameter is ‘N/A’, then:
Application
• The terminal determines the transaction disposition as
“terminated”.
• The POS System advises the cardholder of the situation.
• The terminal continues according to its environment and
acceptance rules. This might allow further transaction
attempts by the cardholder, or might require a complete
restart.
• Once complete, continue with ‘Requirements – New
Transaction Preparation and Start’ on page 64.
Else the POS System confirms card removal before restarting
Entry Point as indicated by the Start parameter.

Page 56
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.
EMV Contactless Book A 6 Outcomes and Parameters
Architecture & General Requirements v2.6 6.3 Outcome Processing

Table 6-4: Second Final Outcome (Following an Online Request)

Second Final POS System Processing

Outcome
Approved • The terminal determines the transaction disposition as
“approved”.
• The POS System advises the cardholder of the transaction
outcome.
• If a cardholder receipt is required, the terminal prints it or provides it
electronically (e.g. email).
• The terminal captures CVM signature if requested.
• The terminal prepares a clearing record.
• Once complete, continue with ‘Requirements – New
Transaction Preparation and Start’ on page 64.
Declined • The terminal determines the transaction disposition as
“declined”. (This overrules an “approved” in the online
response).
• The POS System advises the cardholder of the transaction
outcome.
• Once complete, continue with ‘Requirements – New
Transaction Preparation and Start’ on page 64.
Online Not applicable.
Request
Try Another Not applicable.
Interface
End • The terminal determines the transaction disposition according
Application to the online response indication.
• The POS System advises the cardholder of the situation.
• The terminal continues according to its environment and
acceptance rules.
• Once complete, continue with ‘Requirements – New
Transaction Preparation and Start’ on page 64.

Page 57
© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is
permitted only pursuant to the applicable agreement between the user and EMVCo found at
www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States
and other countries.