RuPay Chip Terminal Implementation Requirements Guide - v1.1

RuPay CHIP – Terminal
Implementation
Requirements Guide
Version – V1.1
Date: March 21, 2013

Confidential RuPay CHIP-Acquiring Requirements Guide Page 1 of 117
*** This Page is Left Blank ***

TABLE OF CONTENTS
1 Introduction ......................................................................................................................... 9
1.1 Audience ................................................................................................................................. 9
1.2 Scope of the Document .......................................................................................................... 9
1.3 Document Organization .......................................................................................................... 9
1.3.1 Naming Conventions ....................................................................................................... 9
1.3.2 Acronyms ...................................................................................................................... 10
1.3.3 Reference Materials ...................................................................................................... 11
2 RuPay Chip Card Program ................................................................................................... 12
3 Payment Transaction Overview........................................................................................... 13
4 Message types supported for RuPay ................................................................................... 14
5 Data Elements pertaining to RuPay Chip Transaction ........................................................... 15
5.1 DE#22 – PoS Entry Code........................................................................................................ 15
5.2 DE#23 – Card Sequence Number .......................................................................................... 15
5.3 DE#35 – Track 2 Data Element .............................................................................................. 16
5.4 DE#39 – Response Data ........................................................................................................ 16
5.5 DE#55 – Chip Data................................................................................................................. 17
5.6 DE#61 – PoS Data Code......................................................................................................... 23
6 RuPay Chip EMV Transaction Cycle @ Point of Sale (PoS) ..................................................... 24
6.1 Step 1: Application Selection ................................................................................................ 25
6.1.1 Terminal Data Elements and other Relevant Terms ..................................................... 26
6.1.2 Technical Processing ..................................................................................................... 28
6.1.3 Commands .................................................................................................................... 30
6.1.4 RuPay Implementation Requirements .......................................................................... 30
6.2 Step 2: Initiate Application Processing ................................................................................. 31
6.2.1 Terminal Data Elements and other Relevant Terms ..................................................... 32
6.2.3 Commands .................................................................................................................... 34
6.3 Step 3: Read Application Data .............................................................................................. 34
6.3.1 Terminal Data Elements and Other Relevant Terms .................................................... 35

6.3.3 Commands .................................................................................................................... 36
6.4 Step 4: Offline Data Authentication ...................................................................................... 36
6.4.3 Commands .................................................................................................................... 44
6.5 Step 5: Processing Restrictions ............................................................................................. 45
6.5.3 Commands .................................................................................................................... 48
6.6 Step 6: Cardholder Verification............................................................................................. 48
6.6.3 Commands .................................................................................................................... 56
6.7 Step 7: Terminal Risk Management ...................................................................................... 57
6.7.2 Commands .................................................................................................................... 62
6.8 Step 8: First Terminal Action Analysis ................................................................................... 62
6.8.2 Commands .................................................................................................................... 66
6.9 Step 9: First Card Action Analysis.......................................................................................... 68
6.9.3 Commands .................................................................................................................... 71

6.10 Step 10: Online Processing.................................................................................................... 71
6.10.3 Commands .................................................................................................................... 75
6.11 Step 11: Second Terminal Action Analysis ............................................................................ 75
6.11.3 Commands .................................................................................................................... 80
6.12 Step 12: Second Card Action Analysis ................................................................................... 80
6.12.3 Commands .................................................................................................................... 82
6.13 Step 13: Transaction Completion.......................................................................................... 82
6.13.3 Commands .................................................................................................................... 84
6.14 Step 14: Issuer to Card Script Processing .............................................................................. 84
6.14.3 Commands .................................................................................................................... 87
6.14.5 Conclusion of Processing .............................................................................................. 87
6.14.6 Chip Card Deactivation and Removal............................................................................ 88
6.15 Summary of Terminal Functionality Requirements .............................................................. 88
7 Device Requirements .......................................................................................................... 90
7.1 Basic Requirements............................................................................................................... 90
7.1.1 Terminal Types .............................................................................................................. 90
7.1.2 Approval Requirements ................................................................................................ 91
7.1.3 Terminal Capabilities..................................................................................................... 91

7.1.4 Additional Terminal Capabilities ................................................................................... 92
7.1.5 Migration of Existing Terminals .................................................................................... 94
7.1.6 New Terminal Requirements ........................................................................................ 94
8 Operating / Functional Requirements ................................................................................. 95
8.1 Generic Requirements .......................................................................................................... 95
8.2 Other Requirements ............................................................................................................. 95
8.3 Command Set ........................................................................................................................ 96
8.4 Fall back to Magnetic Stripe Processing................................................................................ 96
8.5 Refund Transaction Processing at Terminal ......................................................................... 97
8.6 Application Status ................................................................................................................. 97
8.7 Service Code Validation ........................................................................................................ 97
8.8 Displayable Messages on Terminal ....................................................................................... 98
8.9 Premature Card Removal ...................................................................................................... 98
8.10 Terminal Receipt Printing...................................................................................................... 99
8.11 Chip Related Reversal ......................................................................................................... 102
9 Acquirer System Interface ................................................................................................. 103
10 Terminal Testing and Certification..................................................................................... 104
ANNEXURE A ........................................................................................................................... 105
Terminal Parameters for Rupay Chip (Sample) .......................................................................... 105
Annexure B .............................................................................................................................. 108
Terminal Configuration Recommendations ............................................................................... 108
Annexure C .............................................................................................................................. 110
Terminal Certification Form (Sample) ....................................................................................... 110
Annexure D ............................................................................................................................. 112
Certification Authority Public Keys Set I .................................................................................... 112
Test Key Set ..................................................................................................................................... 112
Annexure E .............................................................................................................................. 114
Certification Authority Public Keys Set II ................................................................................... 114
Test Key Set ..................................................................................................................................... 114
Annexure F .............................................................................................................................. 116
Certification Authority Public Keys Set III .................................................................................. 116
Test Key Set ..................................................................................................................................... 116

LIST OF TABLES
Table 1 POS Entry Code......................................................................................................................... 15

Table 2 Chip Decline Codes ................................................................................................................... 17
Table 3 Chip Reversal Decline Codes .................................................................................................... 17
Table 4 DE#55 - Chip Data Contents ..................................................................................................... 18
Table 5 DE#61 – PoS Data Code: Subfield 1 .......................................................................................... 23
Table 8 - Application Selection Terminal Data Elements ...................................................................... 26
Table 9 - Relevant Terms Introduced During Application Selection ..................................................... 27
Table 10 RuPay supported AIDs ............................................................................................................ 30
Table 11 - Initiate Application Processing Terminal Data Elements ..................................................... 32
Table 12 - Relevant Terms Introduced During Initiate Application Processing .................................... 33
Table 13 - Offline Data Authentication Terminal Data Elements ......................................................... 40
Table 14 - Relevant Terms Introduced During Offline Data Authentication ........................................ 41
Table 15 - Processing Restrictions Terminal Data Elements ................................................................. 47
Table 16 - Relevant Terms Introduced During Processing Restrictions ................................................ 47
Table 17 - Cardholder Verification Terminal Data Elements ................................................................ 52
Table 18 - Relevant terms introduced during Cardholder Verification ................................................ 53
Table 19 - Terminal Risk Management Terminal Data Elements .......................................................... 59
Table 20 - Relevant Terms Introduced During Terminal Risk Management ......................................... 60
Table 21 - First Terminal Action Analysis Terminal Data Elements ...................................................... 64
Table 22 - Terminal Cryptogram Request Matrix.................................................................................. 65
Table 23 - NPCI recommended TAC values ........................................................................................... 67
Table 24 - Relevant Terms Introduced During First Card Action Analysis ............................................ 70
Table 25 - Chip Card Cryptogram Response Matrix .............................................................................. 71
Table 26 - Online Processing Terminal Data Elements ......................................................................... 73
Table 27 - Relevant Terms Introduced During Online Processing ........................................................ 73
Table 28 - Second Terminal Action Analysis Terminal Data Elements .................................................. 78
Table 29 - Relevant Terms Introduced During Second Terminal Action Analysis ................................. 78
Table 30 - Scenarios and Terminal Processing in Second Terminal Action Analysis ............................. 79
Table 31 - Transaction Completion Terminal Data Elements ............................................................... 83
Table 32 - Issuer to Card Script Processing Terminal Data Elements ................................................... 86
Table 33 - List of Issuer Script Commands ............................................................................................ 87
Table 34 Terminal Functionality Requirement ..................................................................................... 88
Table 35 Terminal Types ....................................................................................................................... 90
Table 36 Terminal Capabilities - Byte 1: Card Data Input Capability .................................................... 91
Table 37 Terminal Capabilities - Byte 2: CVM Capability ...................................................................... 91
Table 38 Terminal Capabilities - Byte 3: Security Capability ................................................................. 92
Table 39 Additional Terminal Capabilities - Byte 1: Transaction Type Capability ................................ 92

Table 40 Additional Terminal Capabilities - Byte 2: Transaction Type Capability ................................ 93
Table 41 Additional Terminal Capabilities - Byte 3: Terminal Data Input Capability ............................ 93
Table 42 Additional Terminal Capabilities - Byte 4: Terminal Data Output Capability ......................... 93
Table 43 Additional Terminal Capabilities - Byte 5: Terminal Data Output Capability ......................... 94
Table 44 Other Requirements ............................................................................................................... 95
Table 45 EMV Command Set Supported............................................................................................... 96
Table 46 Displayable Messages on Terminal ........................................................................................ 98
Table 47 Recommended Data for Receipt Printing .............................................................................. 99
LIST OF FIGURES
Figure 1 - Payment Transaction Overview ........................................................................................... 13

Figure 2 - EMV Transaction Flow @ Terminal....................................................................................... 24
Figure 3 - Process for Application Selection (Part 1 of 2: Building the Candidate list) ......................... 25
Figure 4 - Process flow for Application Selection (Part 2 of 2: Final Selection) .................................... 26
Figure 5 - Process flow for Initiate Application processing ................................................................... 32
Figure 6 - Process flow for Read Application Data ................................................................................ 35
Figure 7 - Process flow for Offline Data Authentication (Part 1 of 3: Process Overview) .................... 37
Figure 8 - Process flow for Offline Data Authentication (Part 2 of 3: SDA) .......................................... 38
Figure 9 - Process flow for Offline Data Authentication (Part 3 of 3: DDA) .......................................... 39
Figure 10 - Process flow for Processing Restrictions ............................................................................ 46
Figure 11 - Process flow for Cardholder Verification (Part 1 of 2: CVM List Processing) ..................... 50
Figure 12 - Process flow for Cardholder Verification (Part 2 of 2: PIN Processing) .............................. 51
Figure 13 - Process flow for Terminal Risk Management ..................................................................... 58
Figure 14 - Process flow First Terminal Action Analysis........................................................................ 63
Figure 15 - Process flow for First Card Action Analysis ......................................................................... 69
Figure 16 - Process flow for Online Processing ..................................................................................... 72
Figure 17 - Process flow for Second Terminal Action Analysis ............................................................. 77
Figure 18 - Process flow for Second Card Action Analysis .................................................................... 81
Figure 19 - Process flow for Transaction Completion (Part 1 of 2: Completion after first GENERATE AC
Response) .............................................................................................................................................. 82
Figure 20 - Process flow for Transaction Completion (Part 2 of 2: Completion after Second GENERATE
AC Response) ........................................................................................................................................ 83
Figure 21 - Process flow for Issuer to Card Script Processing ............................................................... 85
Figure 22 - Magstripe Txn Receipt ...................................................................................................... 100
Figure 23 - Chip Txn Receipt with PIN ................................................................................................. 101
Figure 24 - Chip Txn Receipt with Signature ....................................................................................... 102

1 Introduction
This NPCI RuPay Chip Terminal Implementation Requirements Guide (this “Guide”) has been
created to assist Acquirers for upgrading of their acquiring systems from RuPay magnetic
stripe to Chip Card transactions in accordance with the RuPay chip card specifications. RuPay is
compliant with EMV™ specifications version 4.2. EMV™ is a trademark owned by EMVCo LLC.
1.1 Audience
This Guide is primarily intended for Acquirers, terminal manufacturers and vendors,
3rd party processors, and / or other entities responsible for implementing the NPCI
RuPay Chip Card program on the Acquiring side.
1.2 Scope of the Document

The RuPay specifications have been designed to enable an Acquirer to support chip
acceptance at their terminals. Implementation of these services shall require the
support of vendors that have the necessary RuPay implementation expertise and is
outside the scope of this document.
NPCI documents to be used for the development and implementation of Chip Card
products and services are referenced throughout this Guide. Under no
circumstances, should this present Guide be considered to be a replacement for or
an amendment of the information and specifications provided herein by reference.
While implementation, acquirer must refer this guide in conjunction with the RuPay
- Online Switching Interface Specification.
1.3 Document Organization

This Guide is organized using the data conventions and section structure described
in the following subsections.
1.3.1 Naming Conventions

Capitalized terms used in this Guide shall have the meanings assigned to them in the
Acronyms and Glossary included as section 1.3.2 unless another definition is clearly
indicated. The following naming conventions are adopted throughout this Guide:
 National Payments Corporation of India is referenced as NPCI

 A card that is compliant with the RuPay specifications is referenced as a “RuPay
Chip Card" or Chip Card
 A terminal that is compliant with the RuPay specifications is referenced as a
“RuPay Chip Card Terminal” or "Terminal"
 A transaction that is compliant with the RuPay specifications is referenced as a
“RuPay Chip Transaction” or "Transaction"

1.3.2 Acronyms
Acronym Description
AAC Application Authentication Cryptogram

AC Application Cryptogram
ADF Application Definition File
AFL Application File Locator
AID Application Identifier
AIP Application Interchange Profile
API Application Priority Indicator
ARC Authorization Response Code
ARPC Application Response Cryptogram
ARQC Application Request Cryptogram
ASI Application Selection Indicator
ATC Application Transaction Counter
ATM Automated Teller Machine
AUC Application Usage Control
CA Certification Authority
Combined DDA/Application Cryptogram
CDA
Generation
CDOL Card risk management Data Object List
CID Cryptogram Information Data
CVD Card Verification Data
CVM Cardholder Verification Method
CVR Card Verification Results
DDA Dynamic Data Authentication
DDF Directory Definition File
DDOL Dynamic Data Object List
DF Directory File
EMV Europay Master Visa
FCI File Control Information
IAC Issuer Action Codes
IAD Issuer Application Data
IC Integrated Circuit
ICC Integrated Circuit Card
Card Verification Data for Integrated Chip
iCVD
Cards
IFD Interface Device
LOATC Last Online Application Transaction Counter
LCOL Lower Consecutive Offline Limit
ODA Offline Data Authentication

PAN Primary Application Number
PC Personal Computer
PCI Payment Card Industry
PDOL Processing Data Object List
PED Pin Entry Device
PIN Personal Identification Number
PIX Proprietary Identifier Extension
PK Public Keys
PoS Point of Sale
PSE Payment System Environment
RFU Reserved for Future Use
RID Registered Application Provider Identifier
RSA Rivest, Shamir & Adleman
SDA Static Data Authentication
TAC Terminal Action Codes
TC Transaction Certificate
TLV Tag Length Value
TSI Transaction Status Information
TVR Terminal Verification Results
UCOL Upper Consecutive Offline Limit
1.3.3 Reference Materials

1. RuPay PoS Switching Interface Specification
2. RuPay Global Clearing and Settlement Technical Message Specification
3. RuPay Chip Certification Guide
4. RuPay Key Management Guide
5. EMV4.2 Book 1 – ICC to Terminal Interface
6. EMV 4.2 Book 2 – Security and Key Management
7. EMV4.2 Book 3 – Application Specification
8. EMV4.2 Book 4 – Other Interfaces
9. www.emvco.com

2 RuPay Chip Card Program
RuPay Chip program enables secured transactions between Chip Cards, Terminals, Issuers, and
Acquirers. NPCI has developed this comprehensive program to support all members that are
migrating from magnetic stripe to Chip Card Transactions & includes:
• Network support for RuPay Chip Card Transactions
• RuPay requirements for Chip Cards and Terminals
• Acquirer and Issuer planning and implementation guides
• Certificate Authority requirements and processes
• Testing and certification requirements

3 Payment Transaction Overview
The figure below presents a typical transaction flow of a payment card.
Figure 1 - Payment Transaction Overview
1. The cardholder swipes his card on the Point of Sale machine at the merchant outlet
2. The PoS creates a financial transaction message and forwards the same to the Acquirer Host
system
3. The Acquirer system, after performing the validation tests identifies if the transaction is On-
Us i.e. if the card is issued by the Acquirer itself. If yes, then the transaction is authenticated
and authorized by the Acquiring Bank Authorization Host itself
4. If the transaction is Off-Us i.e. the card belongs to some other issuer, the Acquirer forwards
the transaction to NPCI which in turn will route the request to the Issuer
5. The Issuer will then authorize the transaction and send back the response to NPCI
6. NPCI will then route the transaction response back to the Acquirer which in turn will forward
the same to the PoS terminal
7. The merchant and the cardholder will be informed about the status of the transaction –
Approved or Declined – by the message displayed in the PoS Screen

4 Message types supported for RuPay
The message types supported for RuPay are as below –
1. Authorization message
2. Financial message
3. Reversal message
4. Network management message
The detailed specifications of these message formats are available in RuPay PoS Switching
Interface Specification manual

5 Data Elements pertaining to RuPay Chip Transaction
The data elements indicating a chip transaction and / or containing chip information, required to be
present in a financial message will be as follows –
5.1 DE#22 – PoS Entry Code

Type n3
Format Fixed
Description Contains a 3 digit code indicating the method used to enter

the account number
Requirement In case of Chip, the first two digits should indicate the usage of
chip with either of the following values depending upon the
condition given
When POS Entry Mode is chip, all data for the transaction
must be fetched from the Chip. The device shall use the Track
2 Equivalent Data from the chip instead of reading the same
form magnetic strip
Table 1 POS Entry Code
Digits 1 & 2 Condition
05 ICC used
95 ICC with Unreliable CVD. This condition may

arise if either terminal or Acquirer have issues
in capturing/ processing the CVD value correctly
80 Fall back from chip to magnetic stripe
5.2 DE#23 – Card Sequence Number

Type n3
Format Fixed
Description Card Sequence Number is used by the issuer to distinguish

between multiple cards associated with the same account
number. It is also used in case of re-issuing cards to keep a
track of the cards issued to an individual

Requirement This field is mandatory to be present in case of a chip
transaction. The value of this field will be as defined by the
issuer and will be present in the EMV Tag 5F34. The acquirer
needs to populate DE#23 from this EMV Tag. The acquirer
shall ensure to left pad the value in tag 5F34 with zero to form
the three digits Card Sequence Number. In case, this field is
absent in the request message (chip), the NPCI will decline
the transaction
5.3 DE#35 – Track 2 Data Element

DE 35 shall contain the data elements of Track 2 according to ISO/IEC 7813,
excluding start sentinel, end sentinel, and Longitudinal Redundancy Check (LRC), as
follows:
 Primary Account Number (PAN)
 Field Separator
 Expiration Date (YYMM)
 Service Code
 Discretionary Data
For RuPay Chip Card Transactions (POS Entry Capability = 05 or 95), this field shall
contain the Track 2 equivalent data read from the Chip Card (EMV tag ‘57’) and EMV
tag 57 will not be carried in DE 55.
5.4 DE#39 – Response Data

Type an 2
Format Fixed
Description The issuer indicates its decision for a transaction through

this field
Requirement The terminal will receive information about issuer declines

on chip transaction through this field only. However,
Acquirer may require populating this field in case of Chip
transaction reversals.
Response Codes present in the response in case of Chip transactions declined by the
Issuer are as below –

Table 2 Chip Decline Codes
Response Meaning Action to be taken

Code by the Terminal
E3 ARQC Validation failed by Issuer D
E4 Transaction Declined by Issuer D

basis TVR Validation
E5 Transaction Declined by Issuer D

basis CVR Validation
Response Codes to be populated by the Acquirer in case of Reversal of an Issuer

approved Chip Transaction are as below –
Table 3 Chip Reversal Decline Codes
Response Meaning Action to be taken

Code
E1 AAC Generated by the Chip Card Reverse the transaction
E2 Terminal does not receive final Reverse the transaction

application cryptogram from the Chip
5.5 DE#55 – Chip Data

Type b…255
Format LLLVar
Description This field contains the relevant chip information required for
processing the chip transaction. The information is present
as EMV Tags encoded in Tag-Length-Value (TLV) format
Requirement Table below shows the minimum required data in DE 55

transmitted from the Terminal to the Acquirer for online
chip transactions. Other data may be required by NPCI as
the need arises.
Online authorization requests must conform to Section

12.1.1 of EMV4.2 Book4 – Other Interfaces

Table 4 DE#55 - Chip Data Contents*
0100 / 0200
0110 / 0210
0120 / 0220
0130 / 0230
EMV
Format
Length
0420
0430
# Tag Name Usage
Tag
9F02
1. Amount 6 n 12 M - M - M - Authorized
Authorized amount of the
transaction
(excluding
adjustments)
9F03
2. Amount 6 n 12 C - C - C - Mandatory if cash
Other over (cash back)
transaction OR if
input to
application
cryptogram
(ARQC/TC/AAC)
calculation.
9F26
3. Application 8 b M - M - M - Cryptogram
Cryptogram returned by the
ICC in response of
the GENERATE AC
command
9F06
4. Application 5-16 b O - O - O - Identifies the
Identifier application as
(AID) – described in
Terminal ISO/IEC 7816-5
82
5. Application 2 b M - M - M - Indicates the
Interchange capabilities of the
Profile (AIP) card to support
specific functions
in the application
9F36
6. Application 2 b M - M - M - Counter
Transaction maintained by the
Counter application in the
(ATC) ICC (incrementing
the ATC is

0100 / 0200
0110 / 0210
0120 / 0220
0130 / 0230
EMV
Format
Length
0420
0430
# Tag Name Usage
Tag
managed by the
ICC)
9F07
7. Application 2 b O - O - O - Indicates issuer‘s
Usage specified
Control restrictions on the
geographic usage
and services
allowed for the
application
9F27
8. Cryptogram 1 b M - M - M - Indicates the type
Information of cryptogram and
Data (CID) the actions to be
performed by the
terminal
9F34
9. CVM Results 3 b O - O - O - Indicates the
results of the last
CVM performed
84
10. Dedicated 5-16 b O - O - O - Identifies the
File Name name of the DF as
described in
ISO/IEC 7816-4
9F1E
11. Interface 8 an 8 O - O - O - Unique and
Device (IFD) permanent serial
Serial number assigned
Number to the IFD by the
manufacturer
9F10
12. Issuer Var. b M - M - M - Contains
Application up proprietary
Data (IAD) to application data
32 for transmission to
the issuer in an
online transaction

0100 / 0200
0110 / 0210
0120 / 0220
0130 / 0230
EMV
Format
Length
0420
0430
# Tag Name Usage
Tag
91
13. Issuer 8-16 b - C - - - - Data sent back to
Authenticati the ICC as
on Data response data for
online issuer
authentication.
Mandatory for
online successful
transactions OR if
any script/s are
sent to the card by
the issuer
9F5B
14. Issuer Script Var. b - - C - C - Present if scripts
Results Up were sent by
to issuer in original
25 response
71
15. Issuer Script Var. b - C - - - - Contains
Template 1 up proprietary issuer
to data for
127 transmission to
the ICC before
issuing the second
GENERATE AC
command. Present
if sent by Issuer
72
16. Issuer Script Var. b - C - - - - Contains
Template 2 up proprietary issuer
to data for
127 transmission to
the ICC after
completion of the
second GENERATE
AC command.
Present if sent by
Issuer

0100 / 0200
0110 / 0210
0120 / 0220
0130 / 0230
EMV
Format
Length
0420
0430
# Tag Name Usage
Tag
9F09
17. Terminal 2 b O - O - O - Version number
Application assigned for the
Version application
Number
9F33
18. Terminal 3 b M - M - M - Indicates the
Capabilities capabilities of the
terminal, like card
data input
method, CVMs,
security functions
etc..
9F1A
19. Terminal 2 n3 M - M - M - Indicates the
Country country of the
Code terminal,
represented
according to ISO
3166
9F35
20. Terminal 1 n2 O - O - O - Indicates the
Type environment of
the terminal, its
communications
capability, and its
operational
control
95
21. Terminal 5 b M - M - M - Status of the
Verification different functions
Results (TVR) as seen from the
terminal
5F2A
22. Transaction 2 n3 M - M - M - Indicates the
Currency currency code of
Code the transaction
according to ISO
4217

0100 / 0200
0110 / 0210
0120 / 0220
0130 / 0230
EMV
Format
Length
0420
0430
# Tag Name Usage
Tag
9A
23. Transaction 3 n6 M - M - M - Local date that the
Date YYM transaction was
MD authorized
D
9F41
24. Transaction 2-4 n 4- O - O - O - Counter
Sequence 8 maintained by the
Counter terminal that is
incremented by
one for each
transaction
9C
25. Transaction 1 n2 M - M - M - Indicates the type
Type of financial
transaction,
represented by the
first two digits of
the ISO 8583:1987
Processing Code.
9F37
26. Unpredictabl 4 b M - M - M - Random number
e Number generated by
terminal for each
transaction.
4F
27. ICC Vari B O - O - O - ADF name (AID)
Application able returned by ICC, as
ID (…1 read from
6) directory file, in
template 61
* In case of any difference between the above table as presented in this manual and in the RuPay-
online switching interface specification, the table presented in RuPay- online switching interface
specification will take precedence.

5.6 DE#61 – PoS Data Code
Type ans…999
Format LLLVar
Description This determines the data input capability
Requirement In case of Chip, the subfields 1, 7 and 9 of this field can have
a combination of either of the following values depending
upon the condition given
Table 5 DE#61 – PoS Data Code: Subfield 1

Card Data Input Capability
2 ICC Capability
4 Magnetic Stripe & ICC Capability

Card Data Input Mode
3 Online Chip
4 Offline Chip

Cardholder Authentication Capability
1 ICC

6 RuPay Chip EMV Transaction Cycle @ Point of Sale (PoS)
A smartcard, unlike a magnetic stripe card, has the capability to process transaction using the
application loaded on the embedded Chip on the card. Terminal uses this chip to carry out a
transaction. The card needs to be inserted in the reader and needs to be there until the
transaction is complete. During the transaction, a series of checks and tests are run between the
card and the terminal to verify the authenticity of each other. The entire process of a Chip Card
transaction comprises of mainly fourteen steps which can be described briefly as below –
Figure 2 - EMV Transaction Flow @ Terminal

6.1 Step 1: Application Selection
In this step, the terminal checks for the available applications on the card and builds
the candidate list from the ones common to both the terminal and the card. The
final application to be invoked, for the transaction completion, is based upon the
card application parameters set by issuer.
Figure 3 - Process for Application Selection (Part 1 of 2: Building the Candidate list)

Figure 4 - Process flow for Application Selection (Part 2 of 2: Final Selection)
6.1.1 Terminal Data Elements and other Relevant Terms

The data elements that originate in the terminal during Application Selection are
listed below
Table 8 - Application Selection Terminal Data Elements
DATA ACRONYM DEFINITION

ELEMENT
Application AID Identifies the application as described in ISO/IEC 7816-5.
Identifier The AID is made up of the Registered Application
Provider Identifier (RID) and the Proprietary Identifier
Extension (PIX).
The terminal holds a list of all of the AIDs that it
supports.

Application ASI For an application in the Integrated Circuit Card (ICC) to
Selection be supported by an application in the terminal, the ASI
Indicator indicates whether the associated AID in the terminal
must match the AID in the chip card exactly, including
the length of the AID, or only up to the length of the AID
in the terminal.
There is only one ASI per AID supported by the terminal.
A list of other relevant terms that are introduced during Application Selection is
provided below. These terms relate to EMV functionality and chip card processing.
Table 9 - Relevant Terms Introduced During Application Selection
TERM ACRONYM DEFINITION

Application ADF A file that contains information specific to an application
Definition File on the chip card.
Application Mnemonic associated with the AID according to ISO/IEC
Label 7816-5. Used in application selection.
Application Preferred mnemonic associated with the AID.
Preferred
Name
Application API Indicates the priority of a given application or group of
Priority applications in a directory.
Indicator
Candidate List A list of ICC applications that are supported by the
terminal.
Cardholder A process in Application Selection where a cardholder is
Confirmation asked to confirm the application that the terminal has
chosen for use in the current transaction.
Cardholder A process in Application Selection where the terminal
Selection requests that the cardholder chose the application that
will be used for the current transaction. Cardholder
Selection is executed either by the terminal displaying a
complete list of the available applications or by
displaying them one at a time.
Directory DDF A file within the Payment System Directory that defines
Definition File the structure beneath it.
File Control FCI The information that is returned to the terminal in
Information response to a SELECT command.
Payment A directory that contains entries for DDFs and ADFs on
System the chip card.
Directory The Payment System Directory has a primary DDF used
by the terminal to select the PSE of “1.PAY.SYS.DDF01”.

Payment PSE The set of logical conditions established within the ICC
System when a payment system application has been selected,
Environment or when a DDF used for payment system application
purposes has been selected.
Processing PDOL Contains a list of terminal resident data objects (tags
Data Object and lengths) needed by the card application in
List processing the GET PROCESSING OPTIONS command.
6.1.2 Technical Processing

A partial review of the technical processing steps for Application Selection is
provided to aid the reader’s understanding of this specification. For a full description
of Application Selection processing, refer to Section 12 of EMV 4.2 Book 1 ICC to
Terminal Interface and Section 11.3 of EMV 4.2 Book 4 Other Interfaces
There are two parts of the Application Selection process:
Part I: Building the Candidate List – Creation of a list of mutually supported
applications.
Part II: Final Selection – Selection of the application that will be used for the
transaction.
6.1.2.1 Building the Candidate List

The terminal builds the candidate list by using either the Directory Method
or the List of Application Identifiers Method (List of AIDs Method). As per
EMV, support of the Directory Method is optional for both the chip card and
the terminal, while support of the List of AIDs Method is mandatory.
To build the candidate list, the terminal must access application data from
the chip card. The process for obtaining this data depends on the
capabilities of the chip card and terminal.
DIRECTORY METHOD:
 The chip card has a Payment System Environment (PSE) application
which contains list of all the payment applications supported by the
card. For more details and examples on this, see Annex C of EMV 4.2
Book 1ICC to Terminal Interface
 The terminal issues a SELECT command for the PSE, and then issues the
READ RECORD command to obtain each record in the Payment System
Directory. It may have to repeat this process if any of the records
contain additional DDFs
 If the PSE is blocked or if there were no applications added to the
candidate list, the terminal then attempts to build the candidate list via
the List of AIDs Method

LIST OF AIDs METHOD:
 The chip card stores data for each application individually.
 The terminal individually issues a SELECT command for each AID on its
list.
In both the Directory Method and List of AIDs Method, the terminal receives
the chip card’s response, which includes information about the chip card’s
applications via either the ADF directory entry or the File Control
Information (FCI). This information includes the AID, the Application Label,
and the Application Priority Indicator (API), as well as other optional data
such as the Processing Data Objects List (PDOL) and the Application
Preferred Name.
The terminal adds an AID to candidate list for which successful response is
received from the card to the SELECT command issued by the terminal. The
application is added to the candidate list when either the AID provided by
the chip card is an exact match to the AID in the terminal, or when the AID in
the terminal matches the initial bytes of the chip card’s AID and the
Application Selection Indicator (ASI) in the terminal for that AID indicates
that partial matching is allowed.
If the card is blocked or if certain conditions are not met, the transaction can
be terminated during this transaction step. See EMV 4.2 Book 1ICC to
Terminal Interface for a full description of these conditions.
6.1.2.2 Final Selection

In final selection, the application that will be used for the transaction is
identified.
The process used depends on how many applications have been placed on
the candidate list and on the capabilities of the terminal.
 If there is only one application on the candidate list, the terminal will
automatically select that application. Then, based on card and terminal
functionality, it may also require the cardholder to confirm the selected
application.
 If there are multiple applications on the candidate list, the terminal will
either automatically choose the application to be used, or allow the
cardholder to select the application. The terminal uses the application
priority indicator (API) to determine the priority of these applications.
o If the terminal supports Cardholder Selection, it displays the
applications in the Candidate List in priority order and allows the
cardholder to choose the application they wish to use.
o If the terminal does not support Cardholder Selection, it
automatically selects the application with the highest priority. Then,

based on card and terminal functionality, it may also require the
cardholder to confirm the selected application.
When a terminal displays an application to a cardholder, the terminal uses
either the Application Label or the Application Preferred Name obtained
from the chip card in its display.
The terminal issues a final SELECT command for the chosen application and
moves to Step 2: Initiate Application Processing. If the cardholder does not
approve any application, the transaction is terminated.
6.1.3 Commands
 SELECT
This command is used by the terminal in both phases of Application Selection.
During the first phase “Building the Candidate List,” it is used to: (1) select the
Payment System Directory, (2) select additional DDFs, or (3) select the AID.
During the second phase “Final Selection”, the SELECT command is used to
select the AID.
This command must be performed as described in Section 11 of EMV 4.2 Book1
ICC to Terminal Interface
 READ RECORD
This command is used by the terminal to read the Payment System Directory or
other DDF records. This command must be performed as described in Section 11
of EMV 4.2 Book1 ICC to Terminal Interface
6.1.4 RuPay Implementation Requirements

 The terminal must perform Application Selection as defined in Section 12 of
EMV 4.2 Book1 ICC to Terminal Interface and Section 11.3 of EMV 4.2 Book4
Other Interfaces
 The terminal must support the List of AIDs Method for building a candidate list
 If an Application Preferred Name is present and supported, the terminal must
display the Application Preferred Name to the cardholder instead of the
Application Label when a name is displayed
 The terminal must have the ASI set for each RuPay supported AID to allow
partial AID matching
 The terminal must have the RuPay supported AIDs loaded, as detailed in the
table below
Table 10 RuPay supported AIDs
AID Application
Version Number
A0000005241010 0064
A0000001523010 0001
A0000000651010 0200

 RuPay implementation requires that the terminal provides support for
Application Selection Indicator (ASI) to ensure Partial Selection for all the
supported AIDs
 RuPay requires that the terminal configures and refers to the Application Priority
Indicator for application selection in case of RuPay Chip Card transactions
6.2 Step 2: Initiate Application Processing

In this step, the terminal initiates the transaction with the Chip. Further during the
processing of this command terminal establishes the following:
 Provides to the ICC the terminal-related information about the transaction

(e.g. PDOL Data)
 Obtains from the ICC the parameters which indicate to the terminal the
capability of cards e.g. Application Interchange Profile (AIP) and a list of files
(Application File Locator (AFL)) that contain the ICC data to be read by the
terminal and further used in processing of the transaction

Figure 5 - Process flow for Initiate Application processing
6.2.1 Terminal Data Elements and other Relevant Terms

The data elements that originate in the terminal during Application Selection are
listed below
Table 11 - Initiate Application Processing Terminal Data Elements
DATA ELEMENT ACRONYM DEFINITION
Data Elements Actual PDOL data elements are defined by issuer.

Requested by the Typical data elements included are:
Processing Data
Object List Additional Terminal Capabilities
Amount Authorized

Merchant Category Code
Terminal Capabilities
Terminal Country Code
Terminal Type
Transaction Currency Code
Transaction Date
Transaction Type
Terminal TVR Status of the different functions as seen from the

Verification terminal.
Results
Transaction TSI Indicates the functions performed in a transaction.

Status
Information
A list of other relevant terms that are introduced during Application Selection is
Table 12 - Relevant Terms Introduced During Initiate Application Processing
Application File AFL A list identifying the files and records to be used in
Locator the processing of a transaction.
Application AIP Indicates the capabilities of the card to support

Interchange specific functions in the application.
Profile
Processing Data PDOL Contains a list of terminal resident data objects

Object List (tags and lengths) needed by the card application in
processing the GET PROCESSING OPTIONS
command.

This section provides an overview of the technical processing steps involved during
the execution of Initiate Application Processing command. For a full description of
Initiate Application Processing, refer to Section 10.1 of EMV 4.2 Book 3 Application
Specification and Section 6.3.1 of EMV 4.2 Book 4 Other Interfaces.

The terminal starts Initiate Application Processing by setting all of the bits in the TVR
and in the TSI to 0. The TVR and the TSI are a group of indicators that the terminal
uses to track the results of its processing, so they are set to 0 before being
populated in the subsequent transaction steps.
If a PDOL was present in the FCI data of the selected application, the terminal also
constructs the PDOL data as described in Section 5.4 of EMV 4.2 book 3 Application
Specification.
The terminal then sends the GET PROCESSING OPTIONS command to the chip card.
If requested, the PDOL data is included with the GET PROCESSING OPTIONS
command. If the requested PDOL data included an amount field that the terminal is
unable to provide at this stage in the transaction, the relevant amount field is
populated with hexadecimal zeros.
In response to the GET PROCESSING OPTIONS command, the chip card returns the
AIP and AFL to the terminal. If the chip card returns an error, the terminal returns to
Step 1: Application Selection and the application is removed from the candidate list.
Otherwise, the transaction moves to Step 3: Read Application Data.
6.2.3 Commands
 GET PROCESSING OPTIONS
This command is used by the terminal to inform the chip card that transaction
processing is starting, and to provide any data requested in the PDOL. This
command must be performed as described in Section 6.5 of EMV 4.2 Book 3
Application Specification.

 The terminal must perform Initiate Application Processing as defined in Section
10.1 of EMV 4.2 Book3 Application Specification and Section 6.3.1 of EMV 4.2
Book4 Other Interfaces
6.3 Step 3: Read Application Data

In this step, the terminal requests and reads the required data from the chip, as
indicated in AFL which is read during initiate application processing, necessary for it
to process the transaction further.

Figure 6 - Process flow for Read Application Data
6.3.1 Terminal Data Elements and Other Relevant Terms

There are no terminal data elements or other relevant terms introduced in this step.

This section provides an overview of the technical processing steps involved during
the execution of Read Application Data command & is provided to aid the reader’s
understanding of this specification. For a full description of Read Application Data,
refer to Section 10.2 of EMV 4.2 Book 3 Application Specification.
During Read Application Data, the terminal accesses the records as per the record
details in the AFL received during Initiate Application Processing by issuing a series
of READ RECORD commands. If the chip card responds with the requested data, the

terminal stores all recognized data elements for later usage and moves to Step 4:
Offline Data Authentication.
A data object returned by the chip card that is not recognized by the terminal is not
stored, and should not cause the terminal to become unstable or lock up. However,
the transaction is terminated if the chip card responds with an error or if either of
the following conditions occurs:
 If there is more than one occurrence of a single primitive data object
 If any of the mandatory data elements are not received
See Section 7.5 of EMV 4.2 Book 3 Application Specification for more details.
6.3.3 Commands
 READ RECORD
This command is used by the terminal to read the records indicated by the AFL.
This command must be performed as described in Section 6.5 of EMV 4.2 Book 3
Application Specification

 The terminal must perform Read Application Data as defined in Section 10.2 of
EMV 4.2 Book3 Application Specification
6.4 Step 4: Offline Data Authentication

In this transaction step, the terminal uses information obtained during Read
Application Data to ensure that the chip card/ data has not been altered since its
personalization, and that the data on the chip card was created by the authentic
issuer. This validation is performed using PKI algorithm.
This algorithm involves creation of key pairs (public & private) using a mathematical
formation which links the generated key pair with each other. A key is a binary value
that is used as part of an algorithm to encrypt or decrypt data. The three types of
Rivest, Shamir & Adleman (RSA) key pairs used during this process are the Certificate
Authority Keys (CA), the Issuer Keys, and the ICC Keys. The CA key pairs are created
by scheme. The public key components of the generated key pairs are stored in the
terminal. The Issuer Public Keys and the ICC Public Keys are generated by the issuer
and placed on the chip card during personalization.
The three types of offline data authentication are Static Data Authentication (SDA),
Dynamic Data Authentication (DDA) and Combined Dynamic Data Authentication /
Application Cryptogram Generation (CDA). The method performed depends on the
capabilities of the chip card and terminal.
The results of Offline Data Authentication are stored in the TVR for use later in the
transaction.

RuPay Chip Terminal
Terminal examines AIP to determine the

authentication method that the chip card
supports
Terminal compares its supported method to those

supported by Chip Card, and chooses the highest
mutually supported method
SDA DDA CDA No method identified
Offline Data Authentication is not

Terminal Performs SDA Terminal Performs DDA Terminal recovers the keys
performed. Terminal sets the relevant
(see figure 8 for details) (see figure 9 for details) required to perform CDA
TVR/ TSI bit as per EMV
Yes
Were the keys
successfully
recovered?
No
CDA fails so that the terminal SETS the

relevant TVR and TSI bits as per EMV
Transaction
moves to
processing
restriction
Figure 7 - Process flow for Offline Data Authentication (Part 1 of 3: Process Overview)

RuPay Chip Terminal
Terminal recovers the keys needed to

perform SDA
Were the keys Yes Terminal uses the keys to

successfully validate the chip card’s
recovered? static signature
No
Was the static Yes SDA is completed

signature successfully so the terminal
validated sets the relevant TVR/ TSI
successfully? bits as per EMV
No
SDA fails so that the

terminal sets the TVR and
TSI bits as per EMV
Transaction
moves to
processing
restriction
Figure 8 - Process flow for Offline Data Authentication (Part 2 of 3: SDA)

RuPay Chip Card RuPay Chip Terminal
Terminal recovers the keys needed

to perform DDA
Yes Were the keys

successfully
recovered?
Did the card No

Yes provide a Dynamic
Data Auth. Object
List (DDOL)? DDA fails, terminal sets the relevant
TVR and TSI bits as per EMV
No
Terminal sends INTERNAL
AUTHENTICATE command Terminal uses default DDOL
Card returns dynamic

signature to the terminal
Terminal uses the keys to
validate the signature
Was the Yes DDA is completed successfully

signature
validated so the terminal sets the
successfully? relevant TSI bit as per EMV
No
Transaction
DDA Fails so the terminal
moves to
sets the relevant TVR and
processing
TSI bit as per EMV
restriction
Figure 9 - Process flow for Offline Data Authentication (Part 3 of 3: DDA)

The data elements that originate in the terminal during Offline Data Authentication
are listed below.
Table 13 - Offline Data Authentication Terminal Data Elements

Data Elements See DDOL Definition in Table 8. DDOL terminal data
Requested by the elements must include:
Dynamic Data
Authentication Unpredictable Number
Data Object List
Default Dynamic DDOL to be used for constructing the INTERNAL

Data AUTHENTICATE command if the DDOL in the card is
Authentication not present.
Data Object List
Scheme CA PK That key of the scheme/CA asymmetric key pair that

Certificate can be made public.
Authority Public
Key Consists of:
CA PK Exponent – Value of the exponent part of the

Certification Authority Public Key.
CA PK Modulus – Value of the modulus part of the

CA PK Index CA PKI Identifies the scheme Certificate Authority’s Public

Key/Private Key pair used in Offline, Static Data
Authentication (SDA), Dynamic Data Authentication
(DDA), Combined Data Authentication (CDA) &
Offline Enciphered PIN.
Registered RID Part of AID that is unique to an application provider

Application and assigned according to ISO/IEC 7816-5.
Provider
Identifier
Terminal Indicates the card data input, Cardholder Verification

Capabilities Method (CVM), and security capabilities of the
terminal.

Results
Transaction TSI Indicates the functions performed in a Transaction.

Status
Information
A list of other relevant terms that are introduced during Offline Data Authentication is
Table 14 - Relevant Terms Introduced During Offline Data Authentication
Combined Dynamic CDA A form of offline dynamic data authentication.

Data Authentication /
Application
Cryptogram
Generation
Dynamic Data DDA A form of offline dynamic data authentication.

Authentication
Dynamic Data DDOL List of data objects (tag and length) to be

Authentication Data passed to the ICC in the INTERNAL
Object List AUTHENTICATE command to perform Standard
Dynamic Data Offline Authentication.
ICC Public Key Consists of:
ICC Public Key Exponent- Used for the

verification of the Signed Dynamic Application
Data.
ICC Public Key Remainder - Remaining digits of

the ICC Public Key Modulus.
ICC Public Key ICC Public Key certified by the issuer.

Certificate
Issuer Public Key Consists of:
Issuer Public Key Exponent - Used for the

verification of the Signed Static Application Data

and the ICC Public Key Certificate.
Issuer Public Key Remainder – Remaining digits

of the Issuer Public Key Modulus.
Issuer Public Key Issuer Public Key certified by the scheme

Certificate Certificate Authority (CA) for use in Offline,
SDA, DDA, and CDA with Offline Enciphered PIN
supported.
Key A key is a binary value that is used as part of an

algorithm to encrypt or decrypt data.
Rivest, Shamir & RSA A reversible algorithm for encipherment and

Adleman digital signature generation.
Signed Dynamic Dynamic digital signature generated by the card

Authentication Data on critical application parameters for DDA or
CDA and validated by the terminal.
Signed Static Static digital signature generated by the issuer

Authentication Data on critical application parameters for SDA,
personalized in the card application and
validated by the terminal.
Static Data SDA Offline Static Data Authentication.

Authentication

An overview of the technical processing steps for Offline Data Authentication is
provided in this section to aid the reader’s understanding of this specification. For a
full description of Offline Data Authentication, refer to Sections 5-6 of EMV 4.2 Book
2 Security and Key Management and Section 10.3 of EMV 4.2 Book 3 Application
Specification.
If a terminal does not support Offline Data Authentication, it sets the relevant TVR /
TSI bits as per EMV and moves to Step 5: Processing Restrictions.
The terminal examines the AIP obtained during Initiate Application Processing to
identify the types of Offline Data Authentication that the chip card supports. The
terminal then compares the methods in the AIP to the methods that it supports. The
terminal chooses the highest mutually supported method. CDA has the highest
priority, followed by DDA and lowest being the SDA. If the chip card does not
support Offline Data Authentication, or if data required for Offline Data

Authentication is missing, the terminal sets the relevant TVR/ TSI bits as per EMV
and moves to Step 5: Processing Restrictions.
6.4.2.1 Static Data Authentication – SDA

A chip card is personalized with Signed Static Authentication Data when it is
issued. In SDA, the terminal validates this static signature. The chip card is
not involved in this transaction step directly, because the chip card data
used for SDA was obtained during Read Application Data. If SDA is
performed, the terminal executes the following actions:
 Reads the Registered Application Provider Identifier (RID) and the CA

PKI from the chip card data
 Identifies which of its stored CA PKs should be used
 Uses the CA PK to recover the Issuer Public Key from the Issuer Public
Key Certificate
 Uses the Issuer Public Key to validate the static signature
 Sets the relevant TVR and TSI bits as per EMV and moves to Step 5:
Processing Restrictions
6.4.2.2 Dynamic Data Authentication – DDA

In DDA, the terminal validates the signed dynamic authentication data, a
dynamic signature created by the chip card for the transaction. If DDA is
performed, the terminal executes the following actions:
 Reads the RID and the CA PKI from the chip card data
Key Certificate
 Uses the Issuer Public Key to recover the ICC Public Key from the ICC
Public Key Certificate
 Issues an INTERNAL AUTHENTICATE command to the chip card to obtain
the dynamic signature, the signed dynamic authentication data
o The INTERNAL AUTHENTICATE command also includes the data
requested by the chip card during Read Application Data in the
DDOL
o If the chip card did not contain a DDOL, the terminal’s default
DDOL is used
o The DDOL must include the Unpredictable Number. If it does
not, DDA fails
 Receives the dynamic signature from the chip card and validates it with
the ICC Public Key
 Sets the relevant TVR and TSI bits as per EMV and moves to Step 5:

6.4.2.3 Combined DDA / AC Generation – CDA
In CDA, as in DDA, the terminal validates a dynamic signature that the chip
card creates for each transaction. Unlike DDA, the dynamic signature
generated by the chip card is processed in conjunction with the generation
of the Application Cryptogram (AC) later in the transaction.
If CDA is performed, the terminal’s only activity during Offline Data

Authentication is to recover the keys that will be used to validate the
dynamic signature. To do this, the terminal
 Reads the RID and the CA PKI from the chip card data
Key Certificate
 Uses the Issuer Public Key to recover the ICC Public Key from the ICC
Public Key Certificate
 If any step fails, the terminal sets the relevant TVR and TSI bits as per
EMV and no further CDA processing is performed
 If the keys are recovered successfully, the remainder of CDA is
performed starting in Section 6.8, Step 8: First Terminal Action Analysis.
The terminal then moves to Step 5: Processing Restrictions
6.4.3 Commands
 INTERNAL AUTHENTICATE
This command is used by the terminal to request the chip card to generate the
signed dynamic authentication data. The command includes the data elements
that are detailed in the DDOL, which must include the Unpredictable Number.
This command must be performed as described in Section 6.5 of EMV 4.2 Book3

 The terminal must perform Offline Data Authentication as defined in Section 5
and 6 of EMV4.2 Book2 Security and Key Management, Section 10.3 of
EMV4.2 Book3 Application Specification and Section 6.3.2 of EMV4.2 Book4
Other Interfaces
 Certification Authority Public Keys for all the RuPay supported AIDs should be
loaded in the terminals
 It is required that terminals should have 6 slots for CA PKs per AID supported by
RuPay as per list of supported AIDs and their associated Data Elements
 Terminals that are capable of DDA must store a Terminal Default DDOL, which
must include the Unpredictable Number (Tag 9F37). This shall be used as default
DDOL during DDA processing, if DDOL cannot be retrieved from the IC Card

6.5 Step 5: Processing Restrictions
The terminal, in this step checks for any validations and / or restrictions on the
transaction to be carried out as per the processing rules set forth by the acquirer by
means of different parameters like effective date/ expiry date checking, certification
expiry / revocation / validity checking, geographic restrictions etc.
The results of Processing Restrictions are stored in the TVR for use later in the
transaction. The chip card is not directly involved in this step.

RuPay Chip Terminal
Terminal compares the chip card and

terminal application version numbers
Are the Yes

Application Terminal sets the relevant
Version numbers TVR bit as per EMV
different?
No
Terminal compares
transaction to AUC rules
Yes
Are there any Terminal sets the relevant
restrictions? TVR bit as per EMV
No
Terminal compares the

transaction date to Application
expiration date
Yes
Is the Chip Terminal sets the relevant
Card expired? TVR bit as per EMV
No Transaction
moves to
Cardholder
verification
Figure 10 - Process flow for Processing Restrictions

The data elements that originate in the terminal during Processing Restrictions are
listed below
Table 15 - Processing Restrictions Terminal Data Elements
Application Version number assigned by the scheme to the

Version Number application.
Terminal Country Indicates the country of the terminal, represented

Code according to ISO 3166.
Transaction Type Indicates the type of financial transaction,

represented by the first two digits of the ISO
8583:1987 Processing Code.
Transaction Date Local date that the transaction was authorized.

Results
A list of other relevant terms that are introduced during Processing Restrictions is
Table 16 - Relevant Terms Introduced During Processing Restrictions
Application Date from which the application may be used.

Effective Date
Application Date after which application is no longer valid.

Expiration Date
Application AUC Indicates issuer‘s specified restrictions on the

Usage Control geographic usage and services allowed for the
application.
Issuer Country Indicates the country of the issuer according to ISO

Code 3166. The terminal uses this data with AUC to check
geographic restrictions.

An overview of the technical processing steps for Processing Restrictions is provided
here in this section to aid the reader’s understanding of this specification. For a full
description of Processing Restrictions, refer to Section 10.4 of EMV 4.2 Book3
In Processing Restrictions, the terminal executes four transaction-specific checks

against data obtained from the chip card during Read Application Data. The relevant
TVR/ TSI bits are set as per EMV to indicate the result of this process.
 Application Version Number - The terminal compares the application version

numbers with the one read from the chip card
 Application Usage Control (AUC) - The terminal compares rules set by the issuer
in the AUC with the relevant transaction data to determine:
o Whether the application has restrictions on usage at an ATM
o Whether the application has location-based restrictions based on the
Terminal and Issuer Country Codes and the Transaction Type
o Whether cash back is allowed (if the transaction has a cash back
amount)
 Application Effective Date - The terminal compares the transaction date to the
Application Effective Date
 Application Expiration Date - The terminal compares the transaction date to the
Application Expiration Date
Upon completion of these checks, the terminal moves to Step 6: Cardholder

Verification.
6.5.3 Commands
There are no commands used in this transaction step.

 The terminal must perform Processing Restrictions as defined in Section 10.4 of
EMV 4.2 Book3 Application Specification and Section 6.3.3 of EMV 4.2-4 Other
Interfaces
 Terminals supporting RuPay Chip must store Application Version Numbers as
listed in Section 6.1.4 Table 8
6.6 Step 6: Cardholder Verification

Once the processing restrictions have been determined, the terminal moves to
verify the cardholder by initiating the cardholder verification method as indicated by
the CVM list read by the terminal from the card e.g. offline PIN, online PIN and / or
signature.

The cardholder verification process is considered complete either when a CVM is
successfully performed, or when the full list of CVMs in the chip card is exhausted.
The results of Cardholder Verification are stored in the TVR & in CVM results (Tag
9F34) for use later in the transaction.

RuPay Chip Terminal
Terminal checks the AIP to

determine whether cardholder
verification supported
Should cardholder Yes

verification be
skipped?
No
Terminal reviews the first CVM in the

chip card’s list
Is the CVM
Terminal reviews the next supported and
Yes Terminal performs CVM (See
CVM on the chip card’s list allowed for this separate flow for PIN processing)
transaction?
No
Was CVM Yes The terminal sets the relevant TVR/TSI
processing
bits as per EMV
successful?
No
Are there any Yes Does the CVM list CVM processing fails so that the Transaction moves
Yes No
CVM left in the allow processing terminal sets the relevant TVR and to processing
CVM list? of another CVM? TSI bit as per EMV restriction
No
Figure 11 - Process flow for Cardholder Verification (Part 1 of 2: CVM List Processing)
Figure 12 - Process flow for Cardholder Verification (Part 2 of 2: PIN Processing)

The data elements that originate in the terminal during Cardholder Verification are
listed below.
Table 17 - Cardholder Verification Terminal Data Elements
Amount, Authorized amount of the transaction (excluding

Authorized adjustments).
Certification CA PK That key of the CA asymmetric key pair that can be

Authority Public made public.
Key
Consists of:
CA PK Exponent – Value of the exponent part of the

CA PK Modulus – Value of modulus part of the

Certification Authority Public Key
CA PK Index CA PKI Identifies the Certificate Authority’s Public Key/Private

Key Pair used in Offline, SDA, DDA, and CDA, with
Offline Enciphered PIN supported.
Cardholder CVM Results Indicates the results of the final CVM performed.
Verification
Method Results
Enciphered PIN Transaction PIN enciphered at the PIN pad for online
Data (if online verification or for offline verification if the PIN pad
PIN is supported) and terminal are not a single integrated device.
Registered RID Part of AID that is unique to an application provider

Application and assigned according to ISO/IEC 7816-5.
Provider
Identifier
Terminal Indicates the card data input, CVM, and security

Capabilities capabilities of the terminal.

Results

Transaction Indicates the currency code of the transaction
Currency Code according to ISO 4217.
Transaction PIN Data entered by the cardholder for the purpose of the
Data PIN verification.

Status
Information
List of other relevant terms that are introduced during Cardholder Verification is provided
below. These terms relate to EMV functionality and chip card processing.
Table 18 - Relevant terms introduced during Cardholder Verification
Application Indicates the currency in which the account is

Currency Code managed according to ISO 4217.
Cardholder CVM Method used to ensure that the person presenting the
Verification ICC is the person to whom the card was issued.
Method
CVM Condition CVM list component that details the circumstance

Code under which the specific CVM is performed.
CVM List Identifies a prioritized list of methods of verification of

the cardholder supported by the application.
ICC PIN Consists of:

Encipherment
Public Key ICC PIN Encipherment Public Key Exponent - Used for
PIN encipherment when the ICC PIN Encipherment
Public Key is used.
ICC PIN Encipherment Public Key Remainder -

Remaining digits of the ICC PIN Encipherment Public
Key Modulus.
ICC PIN ICC PIN Encipherment Public Key certified by the

Encipherment issuer.
Public Key
Certificate

PIN Try Counter Global counter indicating the number of PIN tries
remaining.

An overview of the technical processing steps for Cardholder Verification is provided
here to aid the reader’s understanding of this specification. For a full description of
Cardholder Verification, refer to Section 10.5 of EMV 4.2 Book3 Application
Specification and Section 6.3 of EMV 4.2 Book4 Other Interfaces
The terminal begins by checking the AIP to determine whether the application
supports Cardholder Verification. If supported, there are 2 parts to the process:
Part I: Determining which CVM to perform – The terminal determines which CVM
to use
Part II: Performing the CVM – The terminal performs the CVM and stores the results
6.6.2.1 Part I: Determining which CVM to perform

The terminal processes the CVMs in the order in which they are detailed in
the CVM List. This order may vary by card. The CVMs supported for RuPay
chip include:
 Online PIN
 Offline plaintext and / or enciphered PIN
 Signature
 Combined offline PIN and signature
 No CVM required
The terminal first examines the CVM list to determine which CVM to use for
the transaction. Each entry on the list contains the type of CVM, a condition
code indicating when the CVM is to be performed (e.g., “Always” or “If
Cash”), and a flag indicating whether another CVM may be attempted if the
CVM fails. In some cases, terminal or card data elements may also be
utilized in combination with the condition code to determine whether the
CVM is allowable for the transaction, e.g., Amount, Authorized or
Application Currency Code. See Annex C of EMV 4.2 Book3 Application
Specification for the CVM Condition Codes.
The terminal reviews each CVM starting with its condition code. If it
determines that a CVM is recognized and, by comparing it to the Terminal
Capabilities, supported, it moves to Part II: Performing the CVM. If the
terminal encounters a CVM that is not recognized, it sets the relevant TVR
bits as per EMV and then checks whether it can try a different CVM.

If the terminal has not identified a CVM by the end of the list, it sets the
relevant TVR and TSI bits as per EMV. The terminal then moves to Step 7:
Terminal Risk Management.
6.6.2.2 Performing the CVM

CVM processing is reviewed below. The outcome of this processing is stored
in the terminal CVM Results. In all cases, if the attempted CVM fails, the
terminal determines whether it is allowed to perform an alternate CVM. If it
is allowed, the terminal returns to Part I: Determining Which CVM to
Perform. If it is not allowed, the terminal sets the relevant TVR, TSI, and
CVM Results bits as per EMV and moves to Step 7: Terminal Risk
Management.
6.6.2.2.1 Online PIN

The terminal starts by requesting the cardholder to enter the PIN.
 If a PIN is entered, it is stored as Enciphered PIN Data for later

use and the terminal sets the relevant TVR and TSI bits as per
EMV. The terminal moves to Step 7: Terminal Risk Management
 If the PIN pad is malfunctioning or if PIN entry is bypassed,
Online PIN processing fails, so the terminal sets the relevant TVR
and TSI bits per EMV
6.6.2.2.2 Offline PIN – Plaintext and Enciphered

The terminal starts by issuing a GET DATA command to the terminal
for the PIN Try Counter. If the PIN Try Counter is more than 0, or is
not returned, the terminal prompts for PIN entry
 If the PIN Try Counter indicates that no PIN try attempts are left,
Offline PIN has failed so the terminal sets the relevant TVR and
TSI bits as per EMV
 If the PIN pad is malfunctioning or if PIN entry is bypassed,
Offline PIN processing has failed so the terminal sets the
relevant TVR and TSI bits as per EMV
The cardholder enters the PIN, which is stored as the Transaction

PIN Data until needed.
 If plaintext offline PIN, the terminal continues to the next step

 If enciphered offline PIN, the terminal uses the RID and the CA
PKI to identify which CA PK to use. This CA PK is used to recover
the Issuer Public Key, which is used to recover the ICC PIN
Encipherment Public Key
o The terminal issues a GET CHALLENGE command to the
chip card for an Unpredictable Number

o The terminal uses the ICC PIN Encipherment Public Key
and the Unpredictable Number to encipher the PIN and
continues to the next step
The terminal sends a VERIFY command to the chip card with the
Transaction PIN Data, including a parameter that indicates whether
the PIN was enciphered.
 If the chip card response indicates that the PIN was verified, the
terminal sets the relevant TSI bits as per EMV and moves to Step
7: Terminal Risk Management
 If the chip card response indicates that the PIN validation has
failed and the PIN try limit is not zero, the terminal returns to
the PIN entry prompt to allow the cardholder another
opportunity to enter the PIN. If the value of the remaining PIN
Try Counter returned by the chip card is 1, the terminal may
display a message to indicate that there is only one PIN Try
remaining
 If the chip card response indicates that the PIN try limit was
exceeded, Offline PIN has failed so the terminal sets the relevant
TVR and TSI bits per EMV
 If the chip card responds in any other way, the terminal
terminates the transaction
6.6.2.2.3 Signature
If signature is chosen as the CVM, and the terminal supports
signature, the process is considered successful and cardholder
verification is complete. The terminal sets itself to print a signature
line on the receipt during post-transaction processing and sets the
relevant TVR/ TSI bits as per EMV. The terminal then moves to Step
7: Terminal Risk Management.
6.6.2.2.4 Combined Offline PIN and Signature

The terminal must complete the processes for both of the CVMs.
The terminal then sets the relevant TVR and TSI bits as per EMV and
moves to Step 7: Terminal Risk Management.
6.6.2.2.5 No CVM Required

The terminal sets the relevant TVR/ TSI bits as per EMV and moves
to Step 7: Terminal Risk Management.
6.6.3 Commands
 GET DATA

The terminal uses this command to request the PIN Try Counter from the chip card.
This command must be performed as described in Section 6.5 of EMV 4.2 Book3
 GET CHALLENGE
This command is used by the terminal to obtain an Unpredictable Number from the
chip card for use in the PIN encipherment process. This command must be
performed as described in Section 6.5 of EMV 4.2 Book3 Application Specification.
 VERIFY
This command is used by the terminal during offline PIN verification to compare the
PIN entered by the cardholder to the reference PIN from the chip card. This
command must be performed as described in Section 6.5 of EMV 4.2 Book3

 The terminal must perform Cardholder Verification as defined in Section 10.5 of
EMV4.2 Book3 Application Specification and Section 6.3.4 of EMV4.2 Book4
Other Interfaces
 ATMs must be configured to support Online PIN as the only Cardholder
Verification Method (CVM). All other CVMs including Offline PIN (plaintext and
enciphered) are not permitted for ATMs
 Attended Terminals should support Online PIN, signature CVM at a minimum for
RuPay Transactions
 The terminal must support the GET DATA command for the PIN Try Counter
 Terminals accepting PIN must comply with PCI PED
 In addition, consult NPCI in regard to any other Terminals (including ATMs), as
CVM support may be required under certain conditions / functions supported
by the Terminal. The Acquirer may add other methods not defined in EMV such
as biometrics authentication, but must consult NPCI in this case
 PIN Bypass – PIN bypass is a manual override of the PIN CVM process. This is
used when a PIN is selected as the CVM, but the merchant wants to offer the
cardholder the ability to sign instead. Although allowing PIN Bypass aids in
simplifying the magnetic stripe to chip migration; since NPCI mandates PIN
based transactions, the merchant should not be allowed to bypass PIN
6.7 Step 7: Terminal Risk Management

In this transaction step, the terminal completes several checks to confirm that
transaction processing is occurring within risk limits set by the payment brand,
acquirer, and the issuer. The results of Terminal Risk Management are stored in the
TVR for use later in the transaction

Chip card terminal
Terminal checks the AIP to determine if

Terminal Risk Management is to be
performed
Is Terminal Risk Yes

Terminal compares the transaction amount to the
Management to be Terminal Floor Limit
performed?
No Yes
Is transaction amount greater Terminal sets the relevant TVR bits
than the floor limit? as per EMV
No
Terminal determines whether the transaction

will be randomly selected to go online
Has the transaction been Yes Terminal sets the relevant TVR bits
randomly selected? as per EMV
No
Terminal uses chip card data to identify the

allowable number of offline transactions
Has the chip card exceeded Yes Terminal sets the relevant TVR bits
the allowable number? as per EMV
No
Yes
Terminal sets the relevant TVR bits
Is the chip card new?
as per EMV
No
Yes
Is the PAN on an exception Terminal sets the relevant TVR bits
file? as per EMV
No
Yes
Did the merchant force the Terminal sets the relevant TVR bits
transaction online? as per EMV
No
Terminal Risk Management is completed so the

terminal sets the relevant TSI bit as per EMV
Transaction moves to
Terminal Action Analysis
Figure 13 - Process flow for Terminal Risk Management

The terminal uses the results of these tests in the next step. The data elements that
originate in the terminal during Terminal Risk Management are listed below
Table 19 - Terminal Risk Management Terminal Data Elements
Amount, Authorized amount of the transaction (excluding

Authorized adjustments).
Maximum Target Value used in terminal risk management for

Percentage to be Random Transaction Selection.
Used for Biased
Random
Selection
Random Number A unique number between 0-99 that is generated

(internally by the terminal for each transaction where
generated) Random Transaction Selection is used.
Target Value used in terminal risk management for

Percentage to be Random Transaction Selection.
Used for Random
Selection
Terminal Floor Indicates the Floor Limit in the terminal in

Limit conjunction with the AID.

Results
Threshold Value Value used in terminal risk management for

for Biased Random Transaction Selection.
Random
Selection
Transaction Log A log of approved transactions stored in the

terminal consisting of the Application Primary
Account Number (PAN), transaction amount, and
possibly the Application PAN Sequence Number
and transaction date.
Transaction Value created by the terminal for use in Terminal

Target Risk Management for Random Transaction

Percentage Selection.

Status
Information
A list of other relevant terms that are introduced during Terminal Risk Management
is provided below.
Table 20 - Relevant Terms Introduced During Terminal Risk Management
Application ATC Global counter maintained by the card application

Transaction in the ICC.
Counter
Exception File (if A list of card numbers stored in the terminal that
supported by the have been identified by the issuer to be either sent
terminal) online or declined if a transaction is attempted.
Last Online LOATC ATC value of the last transaction that went online.
Application
Transaction
Counter
Lower LCOL RuPay chip card application proprietary data

Consecutive element specifying the maximum number of offline
Offline Limit transactions allowed for the transaction profile
before a transaction is forced to go online.
Random A process performed by the terminal to randomly

Transaction select transactions to be sent online.
Selection
Upper UCOL RuPay chip card application proprietary data

Consecutive element specifying the maximum number of offline
Offline Limit transactions allowed for the transaction profile
before a transaction is declined after an online
transaction is unable to be performed.

An overview of the technical processing steps for Terminal Risk Management is
provided here to aid the reader’s understanding of this specification. For a full
description of Terminal Risk Management, refer to Section 10.6 of EMV 4.2 Book3
Application Specification and Section 6.3 of EMV 4.2 Book4 Other Interfaces
The terminal begins by checking the AIP to determine whether Terminal Risk
Management is to be performed. In Terminal Risk Management, the terminal
performs a series of checks, including Terminal Floor Limit, Random Transaction
Selection, Velocity Checking, New Card Check, Exception File Checking, and/or
Transaction Forced Online, few of which are described in the following subsections.
6.7.1.1 Terminal Floor Limit

Floor Limits are set within the terminal as a mechanism to combat fraud. A
Floor Limit is an amount that, if met or exceeded, triggers a transaction to
be sent online for approval. During a transaction, if the terminal determines
that the amount of transaction is greater than or equal to the Terminal Floor
Limit, it sets the relevant TVR bits as per EMV.
Terminals may also have the capability to hold a transaction log to prevent
split sales. This log contains a transaction history that includes the
Application PAN, the transaction amount, and optionally the Application
PAN Sequence Number and the transaction date. During a transaction, the
terminal compares the chip card being used with the log. If the terminal
identifies a match, it adds the most recent transaction amount in the log
with the current transaction amount and compares this total amount to the
Floor Limit. If the total amount of the transactions is greater than, or equal
to, the Floor Limit, the terminal sets the relevant TVR bits per EMV.
Floor Limits are used in multiple payment environments, i.e., magnetic

stripe, chip card, and contactless chip card. Therefore, terminals may have
the capability to store multiple Floor Limits for each type of technology to
enable maximization of risk management capabilities.
NPCI recommends that terminals that are capable of storing multiple Floor
Limits, store a separate Floor Limit for magnetic stripe and for chip card
transactions, as well as for domestic and international transactions.
Since current RuPay implementation mandates that all RuPay Transactions

must be sent online for authorization, the Acquirer shall ensure that the
terminal floor limits are set to Rupees Zero (INR 0) for RuPay magnetic
stripe as well as RuPay Chip card transactions.

6.7.1.2 Exception File Checking
If the terminal has an Exception File, the Application PAN and Application
PAN Sequence Number are checked against the Exception File. If a match is
found, the terminal sets the relevant TVR bits as per EMV.
Upon completion of these checks, the terminal sets the relevant TSI bit as
per EMV and moves to Step 8: First Terminal Action Analysis.
6.7.2 Commands
 GET DATA
This command is used by the terminal to request both the ATC and the LOATC
from the chip card. This command must be performed as described in Section
6.5 of EMV 4.2 Book3 Application Specification.

 Terminal Risk Management functions must conform to Part III, Section 10.6 of
EMV4.2 Book3 Application Specification and Part II, Section 6.3.5 of EMV4.2
 Terminals are required to store Terminal Floor Limits as defined in the relevant
operating regulations, policies, and agreements
 Terminals that support both offline and online transactions must support
Random Transaction Selection
6.8 Step 8: First Terminal Action Analysis

In this step, the terminal analyses the results of the tests performed during Terminal
Risk arrangement and accordingly requests the card for AAC, TC or ARQC.
In First Terminal Action Analysis, the terminal recommends an approach for

processing the remainder of the transaction by comparing the bits set in the TVR
during offline processing against rules placed in the terminal by the payment brand
and in the chip card by the issuer. These rules govern the level of risk acceptable for
various transaction conditions.
Up to this point in the transaction, all processing was completed offline. Moving
forward, data is generated that may be sent to the issuer during authorization or
clearing. A security element called a cryptogram is used to secure this data and to
provide validation that the chip card involved is genuine.
This step results in a request for the chip card to decline, send online, or approve the
transaction.

RuPay Chip Terminal
Terminal checks Issuer and

Payment Brand decline rules
Should the Yes Terminal requests an offline

transaction be decline
declined offline?
No Yes
Is the Terminal
Yes Terminal checks Issuer and Should the
transaction be
offline only? Payment Brand default rules
declined offline?
No No
Terminal requests an offline

Yes approval
Is the Terminal
online capable?
No
Terminal checks the Issuer and

payment brand online rules
Should the Yes

Terminal requests an online
transaction be sent authorization
Online?
No
Terminal requests an offline

approval
Terminal sends a GENERATE AC

command indicating the card
Yes Is CDA being
should produce a dynamic performed?
signature
No
Terminal sends a GENERATE AC

command
Transaction moves
to first card action
analysis
Figure 14 - Process flow First Terminal Action Analysis

The data elements that originate in the terminal during First Terminal Action
Analysis are listed below.
Table 21 - First Terminal Action Analysis Terminal Data Elements
Application AC Cryptogram computed by the RuPay chip card

Cryptogram application and returned to the terminal in the
response of the GENERATE AC command (i.e., TC,
ARQC, AAC).
Application AAC An Application Cryptogram generated by the card

Authentication when declining a transaction.
Cryptogram
Authorization ARQC An Application Cryptogram generated by the card

Request when requesting online authorization.
Cryptogram
Card Risk CDOL1 A list of the tags and lengths of data elements that
Management must be passed to the ICC in the first GENERATE AC
Data Object List 1 command.
Issuer Action IACs IAC Default

Codes
Specifies the issuer‘s conditions that cause a
transaction to be rejected if it might have been
approved online, but the terminal is unable to
process the transaction online.
IAC Denial
Specifies the issuer‘s conditions that cause the

decline of a transaction without attempt to go online.
IAC Online
Specifies the issuer‘s conditions that cause a

transaction to be transmitted online.
Transaction TC An Application Cryptogram generated by the card

Certificate when accepting a transaction.

An overview of the technical processing steps for First Terminal Action Analysis is
description of First Terminal Action Analysis, refer to Section 10.7 of EMV 4.2 Book3
Application Specification and Section 6.3 EMV 4.2 Book4 Other Interfaces
First Terminal Action Analysis consists of two parts:
 Part I: TVR Comparison – The terminal determines the type of cryptogram it will
request
 Part II: Requesting a Cryptogram – The terminal requests a cryptogram from the
chip card
6.8.1.1 TVR Comparison

The terminal determines its initial recommendation for transaction
processing by using the IACs, TACs, and TVR. The IACs and TACs hold settings
that correspond to a list of transaction processing conditions (i.e., e.g. how
the transaction should progress if SDA fails). In these settings, a bit is set to 1
if the condition is true.
In the TVR comparison, the terminal reviews each condition to determine if

there are any matches between the TVR bits and either the TAC or IAC bits
(or both) for that condition. If there is a match, the terminal must take
action. There are three sets of IACs and TACs:
 Denial: Indicates when the transaction should be declined offline

 Online: Indicates when the transaction should be sent online to the
issuer
 Default: Indicates when a transaction should be declined if a terminal
can’t go online
The usage of the IACs and TACs depends on the capabilities of the terminal.
Online-only terminals may optionally skip the default IAC and TAC check and
instead request an immediate offline decline. In all cases, when the terminal
completes the TVR comparison, it moves to Part II: Requesting a
Cryptogram.
6.8.1.2 Requesting a Cryptogram

Once the terminal has identified a recommendation, it issues the first
GENERATE AC command for this recommendation.
Table 22 - Terminal Cryptogram Request Matrix
TERMINAL RECOMMENDATION TYPE OF CRYPTOGRAM REQUESTED
Decline the transaction offline Application Authentication Cryptogram (AAC)

Request an online approval Authorization Request Cryptogram (ARQC)
Approve the transaction offline Transaction Certificate (TC)
The terminal also includes the data detailed in the CDOL1 in the first
GENERATE AC command. Once the first GENERATE AC command has been
sent, the transaction moves to Step 9: First Card Action Analysis.
6.8.1.3 CDA
If the terminal selected CDA during Offline Data Authentication, it now
determines whether to request a dynamic signature in the first GENERATE
AC command.
 If the terminal is recommending that the chip card decline the

transaction offline, it does not move ahead with further CDA processing.
 If the terminal is recommending the chip card approve the transaction
offline, the terminal includes the request for the dynamic signature.
 If the terminal is recommending the chip card request an online
approval, the terminal can either request the dynamic signature at this
point or wait until the second GENERATE AC command during Second
Terminal Action Analysis.
o If the terminal does not request the dynamic signature, it sets
the relevant TVR bits as per EMV.
6.8.2 Commands
 GENERATE APPLICATION CRYPTOGRAM
This command is used by the terminal to request a cryptogram from the chip
card. There are two times during transaction execution when this command may
be issued:
o During Step 8: First Terminal Action Analysis, the first GENERATE AC

command is issued by the terminal. The command requests that the
chip card create a specific cryptogram based on the terminal’s initial
recommendation for transaction processing.
o During Step 11: Second Terminal Action Analysis (if performed), the
second GENERATE AC command is issued by the terminal. The command
requests that the chip card create a specific cryptogram based on the
terminal’s final recommendation for transaction processing.
This command must be performed as described in Section 6.5 and Section 9 of EMV
4.2 book3 Application Specification.

 Terminal Action Analysis must conform to Section 10.7 of EMV4.2 Book3
 NPCI recommends the following configuration for Terminal Action Code.
Table 23 - NPCI recommended TAC values
DESCRIPTION 00 10 00 00 00 FF FF FF FF FF FF FF FF FF FF
BYTE BIT DENIAL ONLINE DEFAULT
Offline data authentication
1 was not performed 0 1 1
SDA failed 0 1 1
ICC data missing 0 1 1
Card appears on Terminal
exception file 0 1 1
DDA failed 0 1 1
CDA failed 0 1 1
RFU 0 1 1
RFU 0 1 1
ICC and Terminal have
2 different application versions 0 1 1
Expired application 0 1 1
Application not yet effective 0 1 1
Requested service not
allowed for card product 1 1 1
New card 0 1 1
RFU 0 1 1
RFU 0 1 1
RFU 0 1 1
Cardholder Verification was
3 not successful 0 1 1
Unrecognized Card
Verification Method (CVM) 0 1 1
PIN Try Limit exceeded 0 1 1
PIN entry required but PIN
pad not present or not
working 0 1 1
PIN entry required, PIN pad
present but PIN not entered 0 1 1
Online PIN entered 0 1 1
RFU 0 1 1
RFU 0 1 1
Transaction exceeds floor
4 limit 0 1 1
Lower consecutive offline
limit exceeded 0 1 1
Upper consecutive offline
limit exceeded 0 1 1

Transaction selected
randomly for online
processing 0 1 1
Merchant forced Transaction
online 0 1 1
RFU 0 1 1
RFU 0 1 1
RFU 0 1 1
5 Default TDOL used 0 1 1
Issuer authentication was
unsuccessful 0 1 1
Script processing failed before
final GENERATE AC 0 1 1
Script processing failed after
final GENERATE AC 0 1 1
RFU 0 1 1
RFU 0 1 1
RFU 0 1 1
RFU 0 1 1
6.9 Step 9: First Card Action Analysis

The Chip Card receives the terminal’s recommendation on how to proceed with the
transaction and then carries out its own set of validations. Based on the risk
management performed by the chip itself, the chip decides whether the transaction
has to be accepted offline, declined offline or to be sent online for issuer
authorization and accordingly responds back with the corresponding cryptogram.

RuPay Chip Card
Chip card receives GENERATE AC

command from the terminal
Chip card performs internal risk

management
Chip card generates cryptogram

and related data
Was CDA
Yes Chip card generates dynamic
requested? signature
No
Chip card returns cryptogram

and relevant data to terminal
Transaction
moves to
online
processing
Figure 15 - Process flow for First Card Action Analysis

There are no data elements originating from the terminal during First Card Action
Analysis. However, a list of other relevant terms that are introduced during First
Terminal Action Analysis is provided below. These terms relate to EMV functionality
and chip card processing.
Table 24 - Relevant Terms Introduced During First Card Action Analysis
Cryptogram CID Indicates the type of cryptogram (TC, ARQC, or AAC)

Information Data returned by the card and the actions to be
performed by the terminal.
Card Verification CVR RuPay chip card application proprietary data

Results element used to inform the issuer about exception
conditions that occurred during the current and
previous transactions. It is transmitted to the
terminal in Issuer Application Data.
Issuer Application IAD Contains proprietary application data to be

Data transmitted to the issuer in an online transaction (in
the authorization request) and after transaction
completion in the clearing record.

An overview of the technical processing steps for First Card Action Analysis is
description of First Card Action Analysis, refer to Section 10.8 of EMV 4.2 Book3
Application Specification and Section 6.3.7 of EMV 4.2 Book4 Other Interfaces.
When the chip card receives the first GENERATE AC command, it performs internal
risk management to determine how it will respond to the terminal’s request. The
chip card tracks the results of its risk management processing in the Card
Verification Results (CVR).
Based on its risk management, the chip card can choose to overrule the terminal’s
recommendation in certain scenarios. However, the chip card cannot lessen the
severity of the terminal’s recommendation. For example, the chip card cannot
respond with an online approval if the terminal has recommended declining the
transaction offline.
The acceptable responses by the chip card to the first GENERATE AC command are
detailed below

Table 25 - Chip Card Cryptogram Response Matrix
TERMINAL RECOMMENDS POSSIBLE CHIP CARD RESPONSES
Decline the transaction offline (AAC) Decline the transaction offline (AAC)
Decline the transaction offline (AAC)

Request an online approval (ARQC)
Request an online approval (ARQC)
Decline the transaction offline (AAC)
Approve the transaction offline (TC) Request an online approval (ARQC)
Approve the transaction offline (TC)
When the chip card determines its response, it sends the appropriate cryptogram
along with the Cryptogram Information Data (CID), Issuer Application Data (IAD), and
the ATC. If CDA was requested and the chip card response is not an offline decline,
the chip card also generates and returns the dynamic signature. The transaction
then moves to Step 10: Online Processing.
More details on the response format options and specific data included can be
found in Section 6.5 of EMV 4.2 Book3 Application Specification.
6.9.3 Commands
There are no commands used in this transaction step.

 First Card Action Analysis must be performed as specified in Section 10.8 of EMV
4.2 Book3 Application Specification, and Section 6.3.7 of EMV 4.2 Book4 Other
Interfaces
 There are no terminal-specific requirements for this transaction step
6.10 Step 10: Online Processing

If the decision from Chip after first card action analysis is to send the transaction
online, the terminal constructs the financial transaction request and forwards it to
the issuer for authorization. The issuer then responds back with the authorization
response

RuPay Chip Card RuPay Chip Terminal RuPay Issuer
Terminal resolves response to

first GENERATE AC command
Did the chip card

Yes
return AAC?
No
Yes Terminal uses the ICC public
key to validate the dynamic
Was CDA signature
requested in the
first GENERATE AC?
No Yes Was the dynamic

signature
validated?
No
The relevant TVR bit is SET as
per EMV
Transaction
moves to 2nd
Terminal Action
Analysis
Did the chip
Yes
card return a
TC?
Transaction
No moves to
Transaction
Terminal generates the authorization Completion
message and sends to the issuer
Yes
Was the Issuer processes authorization
transaction sent and sends response message
Online
successfully?
Was the
No authorization Yes
response message
downgraded?
Transaction
moves to 2nd
Terminal Action No
Analysis
Chip card validates cryptogram Transaction sends EXTERNAL Yes Does the AIP
and sends response AUTHENTICATE command indicate that issuer
authentication is
supported?
Transaction
Issuer Authentication is No moves to 2nd
complete so the terminal sets Terminal Action
the relevant TSI bit as per EMV Analysis
Confidential RuPay
Figure CHIP-Acquiring
16 - Process flowRequirements Guide
for Online Processing Page 72 of 117
The data elements that originate in the terminal during Online Processing are listed
below.
Table 26 - Online Processing Terminal Data Elements
Terminal Verification TVR Status of the different functions as seen from the
Results terminal.
Transaction Status TSI Indicates the functions performed in a transaction.

Information
Note: See Section 12.1 of EMV 4.2 Book4 Other Interfaces for a list of EMV data elements
that are included in the authorization message and refer the RuPay PoS Switching Interface
specifications for more details.
A list of other relevant terms that are introduced during Online Processing is provided
below. These terms relate to EMV functionality and chip card processing.
Table 27 - Relevant Terms Introduced During Online Processing
Authorization ARPC A cryptogram generated by the issuer in response to

Response an Authorization Request Cryptogram.
Cryptogram
Issuer Used in order to verify that the authorization response

Authentication was, in fact, generated by the issuer host.
Issuer Data sent from the issuer or its proxy to the ICC for
Authentication online Issuer Authentication.
Data
Issuer Scripts A command or a string of commands transmitted by

the issuer to the terminal for the purpose of being sent
serially to the ICC as commands.
A check value present within the track 2-equivalent

data on the chip that differs from the number encoded
Card Verification iCVD within the magnetic stripe
Data for Integrated
Chip Cards

An overview of the technical processing steps for Online Processing is provided here
to aid the reader’s understanding of this specification. For a full description of
Online Processing, refer to Section 10.9 of EMV 4.2 Book3 Application Specification.
Online Processing starts when the terminal receives the chip card’s response to the
first GENERATE AC command. The terminal examines the response to determine the
type of processing to perform.
If CDA was requested and the chip card returns a dynamic signature in the response,
the terminal uses the ICC Public Key recovered during Offline Data Authentication to
validate the signature. If this fails, the terminal sets the relevant bit in the TVR and
stops Online Processing and moves to Step 11: Second Terminal Action Analysis.
The terminal then examines the type of cryptogram that was returned by the chip
card. If the chip card returned either a TC or an AAC, the terminal moves to Step 13:
Transaction Completion. If the chip card returned an ARQC, the terminal creates an
authorization request message that includes the ARQC and the data used to create
it. This message is then sent to the issuer.
In addition to the inclusion of the data elements that are created as a part of an
EMV transaction, other fields in the authorization request message are populated
with data from the chip card ( e.g., track 2 data, expiry date, Application PAN, etc.).
The track 2 data on the chip may not be an exact match to the track 2 data on the
card itself if the issuer is using a Card Verification Data for Integrated Chip Cards
(iCVD).
When the issuer receives the authorization request, the ARQC is validated and then
an authorization response message is sent to the terminal that includes the Issuer
Authentication Data and any Issuer Scripts. Upon receiving the authorization
response, the terminal determines whether it needs to perform Issuer
Authentication as described in Section 6.10.2.1 of this document.
If the terminal was unable to go online, or if it received a downgraded authorization

response with no Issuer Authentication Data, it moves to Step 11: Second Terminal
Action Analysis.
6.10.2.1 Issuer Authentication

When the terminal receives the Issuer Authentication Data, it examines the
AIP to determine whether to perform Issuer Authentication at this point in
the transaction or whether the chip card will perform it along with the
second GENERATE AC command.
If the AIP indicates that the chip card supports Issuer Authentication, the
terminal performs it as described below. If Issuer Authentication is not
supported, the terminal moves to Step 11: Second Terminal Action Analysis.

To perform Issuer Authentication, the terminal creates an EXTERNAL
AUTHENTICATE command, including the Issuer Authentication Data, which is
sent to the chip card. Upon receipt of the command, the chip card validates
the Authorization Response Cryptogram (ARPC) that is part of the Issuer
Authentication Data and responds to the terminal. The terminal sets the
relevant TVR and TSI bits per EMV and moves to Step 11: Second Terminal
Action Analysis.
6.10.3 Commands
 EXTERNAL AUTHENTICATE
The EXTERNAL AUTHENTICATE command is used when Issuer Authentication Data is

received in the authorization response message, and when the chip card’s AIP
indicates support for Issuer Authentication. The Issuer Authentication Data shall be
sent with the EXTERNAL AUTHENTICATE command to the chip card. This command
must be performed as described in Section 6.5 of EMV 4.2 Book3 Application
Specification.

 Online Processing must be performed as described in Section 10.9 of EMV 4.2
Book3 Application Specification
 The online authorization request message must include the minimum chip card-
related data elements detailed in Section 12.1 of EMV 4.2 Book4 Other
Interfaces, as well as the data outlined in the applicable RuPay PoS Switching
Interface Specification
 The terminal should transmit all data encoded on magnetic stripe without any
modification or alteration for magnetic stripe fall-back transactions
 Online capable terminals must support Issuer Authentication and EXTERNAL
AUTHENTICATE command. Issuer authentication could be performed either
using independent EXTERNAL AUTHENTICATE command or could be part of the
generate AC command as indicated by the AIP read from the card. In any case
terminal must support both the options
6.11 Step 11: Second Terminal Action Analysis

If the transaction was requested by the card to be sent online for processing, the
terminal attempts to do so. Basis the outcome of terminals’ attempt to go online,
terminal performs risk analysis for the second time. This is regardless of the fact that
whether the transaction was able to go online or not.
Second Terminal Action Analysis is not part of every transaction. It only occurs in
transactions where the chip card has previously requested that the transaction be
sent online for authorization.
In this transaction step, the terminal makes a second recommendation on how the
transaction should be completed. This recommendation is based on either the

issuer’s response to the authorization request, or on the issuer and payment brand
rules stored in the IACs and TACs.
This step results in the terminal requesting the chip card either to decline or to
approve the transaction.

RuPay Chip Terminal
Terminal reviews the result of

Online processing
Does the ARC

Was the terminal Yes indicate
Yes Terminal creates second
Terminal includes CDA
able to go GENERATE AC command
transaction request if required
Online? requesting a TC
approval?
No No
Terminal checks TVR against

the IAC and TAC default rules
Yes Terminal creates second

Did any bits
GENERATE AC command
match?
requesting an AAC
No
Terminal creates a second

GENERATE AC command
requesting a TC
Transaction
Terminal includes CDA moves to second
request if required card action
analysis
Figure 17 - Process flow for Second Terminal Action Analysis

The data elements that originate in the terminal during Second Terminal Action
Analysis are listed below.
Table 28 - Second Terminal Action Analysis Terminal Data Elements
Authorization ARC Code that defines the disposition of a

Response Code message.
Data Elements See CDOL2 Definition in Table 29.

Requested by the Card Actual CDOL2 data elements are
Risk Management defined by issuer. Typical data
Data Object List 2 elements included are:
 ARC
 Issuer Authentication Data
 TVR
 Unpredictable Number
Terminal Action Codes TAC Default Specifies the conditions that cause a
– Default transaction to be rejected if it might
have been approved online, but the
terminal is unable to process the
transaction online.
Terminal Verification TVR Status of the different functions as

Results seen from the terminal.
A list of other relevant terms that are introduced during Second Terminal Action
Analysis is provided below. These terms relate to EMV functionality and chip card
processing.
Table 29 - Relevant Terms Introduced During Second Terminal Action Analysis
Card Risk CDOL2 A list of the tags and lengths of data elements that
Management Data must be passed to the ICC in the second GENERATE
Object List 2 AC command.

An overview of the technical processing steps for Second Terminal Action Analysis is
description of Second Terminal Action Analysis, refer to Sections 9 and 10.11 of EMV
4.2 Book3 Application Specification.
The terminal can enter Second Terminal Action Analysis from several points
depending on the processing that occurred in Step 10: Online Processing. The
scenarios and the terminal processing that occurs are detailed in the following table.
Table 30 - Scenarios and Terminal Processing in Second Terminal Action Analysis
SCENARIO PROCESSING PERFORMED BY THE TERMINAL
CDA validation failed The terminal creates a second GENERATE AC

command requesting an AAC from the chip card.
Terminal was unable to go online The terminal compares the TVR to the IAC and TAC
default values; the terminal then creates a second
GENERATE AC command.
 If there were any matches, the terminal

requests an AAC
 If there were no matches, the terminal requests
a TC
o If the terminal is requesting a TC, and
CDA is being performed, the terminal
can include a request for the dynamic
signature
Note: Online-only terminals may optionally skip the

default IAC and TAC check and instead request an
immediate offline decline.
Authorization response message The terminal examines the ARC received in the
received authorization response message, and creates a
second GENERATE AC command that requests
either an AAC or a TC.
If the terminal is requesting a TC, and CDA is being

performed, the terminal can include a request for
the dynamic signature.

In all cases, the second GENERATE AC command also includes the data elements
identified in the CDOL2. Once the second GENERATE AC command has been created,
the terminal sends it to the chip card and moves to Step 12: Second Card Action
Analysis.
6.11.3 Commands
 GENERATE APPLICATION CRYPTOGRAM
This command is used by the terminal to request a cryptogram from the chip
card. There are two times during transaction execution when this command may
be issued:
o During Step 8: First Terminal Action Analysis, the first GENERATE AC

command is issued by the terminal. The command requests that the
chip card create a specific cryptogram based on the terminal’s initial
recommendation for transaction processing
o During Step 11: Second Terminal Action Analysis (if performed), the
second GENERATE AC command is issued by the terminal. The command
requests that the chip card create a specific cryptogram based on the
terminal’s final recommendation for transaction processing
This command must be performed as described in Section 6.5 and Section 9 of

EMV 4.2 Book3 Application Specification

 Second Terminal Action Analysis must be performed as described in Sections 9
and 10.11 of EMV 4.2 Book3 Application Specification
6.12 Step 12: Second Card Action Analysis

In Second Card Action Analysis, the chip card receives the terminal’s
recommendation for processing transaction completion. The chip card then
completes its own risk management to determine whether to accept or overrule the
terminal’s request. The terminal has no direct involvement in this step.
Second Card Action Analysis results in the chip card responding to the terminal with
a cryptogram that reflects the chip card’s final decision on whether the transaction
should be approved or declined.

RuPay Chip Terminal
Terminal reviews the chip card’s

response to the second GENERATE
AC
Did the terminal

Yes
receive an AAC?
Terminal declines the

No transaction
Was CDA
Yes Terminal attempts to Did the terminal Yes Relevant TVR and TSI bits are
validate the dynamic fail to validate the
requested? set as per EMV
signature signature?
No No
Terminal approves the transaction
Figure 18 - Process flow for Second Card Action Analysis

There are no data elements originating from the terminal during Second Card Action
Analysis. No additional relevant terms are introduced.

An overview of the technical processing steps for Second Card Action Analysis is
description of Second Card Action Analysis, refer to Sections 9 and 10.11 of EMV 4.2
Book3 Application Specification.
When the chip card receives the second GENERATE AC command, it performs a final
round of risk management to determine how to respond to the terminal’s request.
 If the terminal has requested that the transaction be declined, the chip card can
only respond with a decline
 If the terminal requested that the transaction be approved, the chip card can
respond with either an approval or a decline response based on upon the results
of its internal risk management

 If the terminal requested that the chip card perform CDA along with cryptogram
generation, the chip card creates the dynamic signature only when responding
with an approval. The cryptogram and dynamic signature are sent back to the
terminal in response to the second GENERATE AC command and the terminal
moves to Step 13: Transaction Completion
6.12.3 Commands
There are no terminal commands used in this transaction step.

 Second Card Action Analysis must be performed as specified in Sections 9 and
10.11 of EMV 4.2 Book3 Application Specification
 There are no terminal-specific requirements for this transaction step
6.13 Step 13: Transaction Completion

Transaction Completion is performed by the terminal during every transaction
unless a transaction is prematurely terminated. The step that precedes Transaction
Completion varies based on the processing for the particular transaction.
RuPay Chip Terminal

response to first GENERATE AC
Did the terminal

Yes Terminal declines the
receive an AAC? transaction
No
Terminal approves the

transaction
Figure 19 - Process flow for Transaction Completion (Part 1 of 2: Completion after first
GENERATE AC Response)

RuPay Chip Terminal

response to the second
GENERATE AC
Did the terminal

Yes
receive an AAC?
Terminal declines the

No transaction
Was CDA
Yes Terminal attempts to Did the terminal Yes Relevant TVR and TSI
validate the dynamic fail to validate the
requested? bits are set as per EMV
signature signature?
No No
Terminal approves the

transaction
Figure 20 - Process flow for Transaction Completion (Part 2 of 2: Completion after Second GENERATE AC Response)

The data elements that originate in the terminal during Transaction Completion are
listed below
Table 31 - Transaction Completion Terminal Data Elements

Results

Status
Information
There are no additional relevant terms introduced in Transaction Completion.

An overview of the technical processing steps for Transaction Completion is
description of Transaction Completion, refer to Section 10.11 of EMV 4.2 Book3
Application Specification and Sections 6.5.4 and 11.4 of EMV 4.2 Book4 Other
Interfaces.
Transaction Completion occurs when the terminal receives either a TC or AAC in

response to either the first or the second GENERATE AC commands.
6.13.3 Commands
There are no terminal commands used in this transaction step.

 Transaction Completion must be performed as specified in Section 10.11 of EMV
4.2 Book3 Application Specification and Sections 6.5.4 and 11.4 of EMV 4.2
6.14 Step 14: Issuer to Card Script Processing

In this transaction step, the terminal sends any issuer scripts received in the
authorization response message to the chip card.
When an authorization request message is sent to an issuer, the issuer has an

opportunity to send updates to the chip card by including issuer scripts in the
response message. If received, these issuer scripts are sent to the chip card by the
terminal. This step results in issuer scripts being processed by the chip card.

RuPay Chip Card RuPay Chip Terminal
Terminal examines the issuer

script
Terminal sends script Yes

Are there any
Chip card processes command to chip card
tag ‘71’script
script before the second
commands?
GENERATE AC
Did the card Yes Are there any Yes No

return a normal more script
or warning commands in tag
status? ‘71’ script?
No
No
Issuer script processing
fails so the terminal sets
the relevant TSI bits as
per EMV
Terminal sends script Yes Are there any

Chip card processes command to chip card
tag ‘72’ script
script after the second
commands?
GENERATE AC
Did the card Yes Are there any No

return a normal more script Yes
or warning commands in tag
status? ‘72’ script?
No
No
Issuer script processing

Issuer script processing is
fails so the terminal sets
completed so the
the relevant TSI bits as
terminal sets the relevant
per EMV
TSI bit as per EMV
Figure 21 - Process flow for Issuer to Card Script Processing

The data elements that originate in the terminal during Issuer to Card Script
Processing are listed below.
Table 32 - Issuer to Card Script Processing Terminal Data Elements
Issuer Script Indicates the result of the terminal script

Results processing.

Results

Status
Information
There are no additional relevant terms introduced in Issuer to Card Script

Processing.

An overview of the technical processing steps for Issuer to Card Script Processing is
description of Issuer to Card Script Processing, refer to Section 10.10 of EMV 4.2
Book3 Application Specification and Section 6.3.9 of EMV 4.2 Book4 Other
Interfaces
If issuer scripts are included in the authorization response, the terminal starts by
examining the type of script returned and then sends the script to the chip card.
Terminal can send the Issuer scripts to the chip card at two points during an EMV
transaction:
 Before the second GENERATE AC command (tag ‘71’).

 After the second GENERATE AC command (tag ‘72’).
The terminal formats the data received into the command format and sends the
script command to the chip card for processing. If there are multiple script
commands within a script sent in the authorization response, the terminal processes
the script commands in the order in which the issuer placed them in the
authorization message.

The terminal processes all scripts unless the chip card indicates an issue. If issuer
script processing fails, the terminal sets the relevant TVR bits as per EMV. Once
issuer script processing is complete, the terminal sets the relevant TSI bits as per
EMV. The results are stored in the Issuer Script Results.
6.14.3 Commands
Below table provides the list of script commands supported by RuPay
Table 33 - List of Issuer Script Commands
ISSUER SCRIPT COMMANDS

APPLICATION BLOCK All issuer script commands must be passed by the
APPLICATION UNBLOCK terminal to the chip card.
CARD BLOCK
PIN CHANGE/ UNBLOCK Issuer script commands may be updated or changed
PUT DATA after the release of this document. The terminal must
UPDATE RECORD pass issuer scripts even if they are not recognized.
The processing of Issuer Script commands must

conform to Section 6 of EMV4.2 Book3 – Application
Specification

 Issuer to Script Processing must be completed as described in Section 10.10 of
EMV 4.2 Book3 Application Specification and Section 6.3.9 of EMV 4.2 Book4
Other Interfaces
 For Issuer Scripts commands Terminals must support both the tags i.e. tag ‘71’
and Tag ‘72’. However an authorization response shall only have either one of
them
 Terminals must process all issuer scripts, whether the scripts are recognized by it
or not
 It is recommended that the Acquirer stores the Transaction Certificate for all
transactions, as it may be required during dispute resolution
6.14.5 Conclusion of Processing

 When printing a receipt, the terminal must be fully compliant to Section 11.4 of
EMV 4.2-4 Other Interfaces, as well as the relevant operating regulations,
policies, and agreements
 The terminal shall not display any message to the card holder indicating that the
transaction is concluded until all issuer script processing is completed
 RuPay recommends the presence of certain RuPay Chip related data to be
printed on the receipt upon a successful transaction. Please refer to Section 8.9
Terminal Receipt Printing in this document for more details

6.14.6 Chip Card Deactivation and Removal
The terminal must be fully compliant to Section 6.1.5 of EMV 4.2 Book1 ICC to
Terminal Interface
6.15 Summary of Terminal Functionality Requirements

The following table provides the RuPay Chip terminal functionality requirements for
each step in a chip card transaction.
Table 34 Terminal Functionality Requirement
Functionality by Transaction Step Terminal Requirement

Step 1: Application Selection Mandatory
 List of AIDs Method  Mandatory
 Directory Method  Optional
Step 2: Initiate Application Processing Mandatory

Step 3: Read Application Data Mandatory
Step 4: Offline Data Authentication Conditional
 SDA  Conditional (Mandatory for offline capable
terminals or if DDA supported by the terminal)
 DDA  Conditional (Mandatory if CDA supported by
the terminal)
 CDA  Optional
Step 5: Processing Restrictions Mandatory
 Application Version Number  Optional
 Application Usage Control (AUC)  Mandatory
 Effective Date Checking  Mandatory
 Expiration Date Checking  Mandatory
Step 6: Cardholder Verification Mandatory
 No CVM  Optional
 Signature  Conditional – Mandatory for signature based
cards and wherever configured as fall-back
CVM
 Online PIN  Mandatory for PIN Based Cards where CVM
indicates ONLINE PIN
 Offline PIN (Plaintext / Enciphered)  Optional
Step 7: Terminal Risk Management Conditional
 Random Transaction Selection  Conditional (if offline and online capable)
Terminal Floor Limit
 Exception File (if supported by the  Conditional (if online capable)
terminal)
 New Card Check  Optional
 Transaction Forced Online  Optional
 Transaction Log  Optional
 Velocity Checking  Optional
Step 8: First Terminal Action Analysis Mandatory
Step 9: First Card Action Analysis N/A – Chip card functionality

Step 10: Online Processing Mandatory
 Online Capability  Mandatory for Online Terminals
 Issuer Authentication  Conditional (if online capable)
Step 11: Second Terminal Action Analysis Conditional (if online capable)
Step 12: Second Card Action Analysis N/A – Chip card functionality
Step 13: Transaction Completion Mandatory
Step 14: Issuer to Card Script Processing Conditional (if online capable)

7 Device Requirements
7.1 Basic Requirements
7.1.1 Terminal Types
Terminal types are defined as below
Table 35 Terminal Types
No Terminal Type Definition
1 Attended online-only Online-only Terminals operated by an attendant at

Terminal merchants. EMV-compliant.
2 Attended offline Terminal Offline Terminals with online capability operated by

with online capability an attendant at merchants. EMV-compliant.
3 Attended offline-only Offline-only Terminals operated by an attendant at

Terminal merchants. EMV-compliant.
4 Unattended online-only Online-only Terminals not operated by an attendant,

Terminal controlled by merchants. EMV-compliant.
5 Unattended offline Offline Terminals with online capability not operated

Terminal with online by an attendant, controlled by merchants.
capability EMV-compliant.
6 Unattended offline-only Offline-only Terminals not operated by an attendant,

Terminal controlled by merchants. EMV-compliant.
7 Online-only ATM Online-only Terminals (ATMs) with cash dispensing

capability not operated by an attendant, controlled
by financial institutions. EMV-compliant.

7.1.2 Approval Requirements
Chip Card Terminals shall meet the following requirements to guarantee
interoperability and correctly process Chip Card Transactions:
 The Terminal shall be approved and listed on the Level 1 and Level 2 approved
lists available on the EMVCo website at www.emvco.com
 The Terminal along with the acquirer Host Interface shall be compliant with
NPCI requirements and must have successfully passed NPCI end-to-end
certification testing
 Terminals shall be certified to the PCI PED security requirements
 Terminals shall be certified for PA/ PCI DSS standards as well
Acquirers should also consider choosing a Terminal that supports a Terminal

Management System to manage Terminal parameters and download software from
a remote location
7.1.3 Terminal Capabilities

Terminal shall personalize this element to indicate the capabilities of the terminal.
Following tables displays some sample values that may apply however the final
configuration will be decided by the terminal vendor as per the terminals actual
capabilities
Table 36 Terminal Capabilities - Byte 1: Card Data Input Capability
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x X x x x x x Manual key entry
x 1 X x x x x x Magnetic stripe
x x 1 x x x x x IC with contacts
x x X 0 x x x x RFU
x x X x 0 x x x RFU
x x X x x 0 x x RFU
x x X x x x 0 x RFU
x x X x x x x 0 RFU
Table 37 Terminal Capabilities - Byte 2: CVM Capability
Plaintext PIN for ICC
1 x X x x x x x
verification
Enciphered PIN for
x 1 X x x x x x
online verification
x x 1 x x x x x Signature (Paper)
Enciphered PIN for
x x X 1 x x x x
offline Verification
x x X x 0 x x x No CVM Required
x x X x x 0 x x RFU
x x X x x x 0 x RFU
x x X x x x x 0 RFU

If the terminal supports a CVM of signature, the terminal shall be an attended
terminal and shall support a printer (Additional Terminal Capabilities, byte 4, ‘Print,
attendant’ bit = ‘1’)
Table 38 Terminal Capabilities - Byte 3: Security Capability
1 x X x x x x x SDA
x 1 X x x x x x DDA
x x 0 x x x x x Card Capture
x x X 0 x x x x RFU
x x X x 1 x x x CDA
x x X x x 0 x x RFU
x x X x x x 0 x RFU
x x X x x x x 0 RFU
7.1.4 Additional Terminal Capabilities

NPCI recommends the following configuration for Additional Terminal Capabilities.
However, the final configuration shall be decided by the Acquirer
Table 39 Additional Terminal Capabilities - Byte 1: Transaction Type Capability
1 x x X x x x x Cash
x 1 x X x x x x Goods
x x 1 X x x x x Services
x x x 1 x x x x Cash back
1
x x x X 0 x x x Inquiry
2
x x x X x 0 x x Transfer
3
x x x X x x 0 x Payment
x x x X x x x 0 Administrative
Note:
1
For the purpose of this specification, an inquiry is a request for information about one of
the cardholder’s accounts
2
For the purpose of this specification, a transfer is a movement of funds by a cardholder
from one of its accounts to another of the cardholder’s accounts, both of which are held by
the same financial institution
3
For the purpose of this specification, a payment is a movement of funds from a cardholder
account to another party, for example, a utility bill payment

Table 40 Additional Terminal Capabilities - Byte 2: Transaction Type Capability
4
0 x x X x x x x Cash Deposit
x 0 x X x x x x RFU
x x 0 X x x x x RFU
x x x 0 x x x x RFU
x x x X 0 x x x RFU
x x x X x 0 x x RFU
x x x X x x 0 x RFU
x x x X x x x 0 RFU
Note:
4
A cash deposit is considered to be a transaction at an attended or unattended terminal
where cardholder deposits cash into a bank account related to an application on the card
used
Table 41 Additional Terminal Capabilities - Byte 3: Terminal Data Input Capability
1 x x X x x x x Numeric keys
Alphabetic and special
x 1 x X x x x x
characters keys
x x 1 X x x x x Command keys
x x x 1 x x x x Function keys
x x x X 0 x x x RFU
x x x X x 0 x x RFU
x x x X x x 0 x RFU
x x x X x x x 0 RFU
Table 42 Additional Terminal Capabilities - Byte 4: Terminal Data Output Capability
b8 b7 b6 b5 b4 b3 b2 b1 Meaning5
1 x x X x x x x Print, attendant
x 0 x X x x x x Print, cardholder
x x 1 X x x x x Display, attendant
x x x 0 x x x x Display, cardholder
x x x X 0 x x x RFU
x x x X x 0 x x RFU
x x x X x x 0 x Code table 10
x x x X x x x 0 Code table 9
Note:
The code table number refers to the corresponding part of ISO/IEC 8859
5
If the terminal is attended (Terminal Type = ‘x1’, ‘x2’, or ‘x3’) and there is only one printer,
the ‘Print, attendant’ bit shall be set to ‘1’ and the ‘Print, cardholder’ bit shall be set to ‘0’. If
the terminal is attended and there is only one display, the ‘Display, attendant’ bit shall be set

to ‘1’ and the ‘Display, cardholder’ bit shall be set to ‘0’. If the terminal is unattended
(Terminal Type = ‘x4’, ‘x5’, or ‘x6’), the ‘Print, attendant’ and ‘Display, attendant’ bits shall be
set to ‘0’"
Table 43 Additional Terminal Capabilities - Byte 5: Terminal Data Output Capability
0 x x X x x x x Code table 8
x 0 x X x x x x Code table 7
x x 0 X x x x x Code table 6
x x x 0 x x x x Code table 5
x x x X 0 x x x Code table 4
x x x X x 0 x x Code table 3
x x x X x x 0 x Code table 2
x x x X x x x 1 Code table 1
Note:
The code table number refers to the corresponding part of ISO/IEC 8859
7.1.5 Migration of Existing Terminals

Changes to POS Terminals are executed by Terminal vendors or system integrators.
POS Terminals that already have Chip Card capabilities may need the following
changes to be implemented to accept Chip Cards:
 Modify the Terminal payment application to handle RuPay Chip Card

Transactions
 Modify the Terminal Acquirer interface to handle RuPay Chip Data Elements for
authorization and batch data capture
 Load RuPay Chip parameters including NPCI’s Public Keys and supporting data
7.1.6 New Terminal Requirements

POS Terminals that do not already have Chip Card capabilities may need the
following changes to be implemented to accept RuPay Chip Cards:
 Select an approved Chip Card reader from the list included on www.emvco.com
 Install the Chip Card reader into the unattended POS Terminal and modify its
payment processing software as follows:
o Modify the Terminal payment application to handle Chip Card
Transactions
o Modify the Terminal Acquirer interface to handle RuPay Chip Data
Elements for authorization and batch data capture.
 Load Terminal parameters

8 Operating / Functional Requirements
8.1 Generic Requirements

Additional requirements for card readers and printers are defined below.
1. IC Card readers must conform to the definitions in Section 6.6 of
EMV4.2 Book4 Other Interfaces.
2. These are the additional requirements for card readers including magnetic
stripe readers
a. If the Terminal successfully performs a transaction using the IC chip, it
sets the POS Entry Mode to ‘05X’
b. If the Terminal initiates an IC transaction but cannot retrieve IC Card
information (except for the situation described in the item (c)), the
Terminal may initiate a magnetic stripe transaction and shall set the
POS Entry Mode to ‘80X’ indicating that fall-back was performed
c. If the Terminal detects that the IC Card or the IC Card application is
blocked during Application Selection, the Terminal shall not initiate a
transaction using the blocked IC Chip Card/ application. Furthermore,
using magnetic stripe to process the transaction in this case is also not
allowed
d. If no AID matched during Application Selection, the Terminal shall
display a message suggesting the operator or cardholder to perform a
fall back as magnetic stripe transaction with POS Entry Mode equal to
‘80X’ .
3. Cancellation at any time while processing a transaction
4. Accept a PAN up to 19 digits
8.2 Other Requirements
Table 44 Other Requirements
Terminal Country Code 0356

Terminal Currency Code 0356
Terminal Currency 02
Exponent
Dynamic Data Object List NPCI mandates the presence of DDOL with setting
(including the and usage conforming to Section 6.5 of EMV4.2
Unpredictable Number) Book2 – Security and Key Management and Section
(DDOL) 5.4 of EMV4.2 Book3 – Application Specification
Minimum of Unpredictable Number (Tag 0x9F37)

must be present as part of DDOL list and shall be used
as default DDOL If DDOL cannot be retrieved from the

IC Card
8.3 Command Set

The following table outlines the RuPay requirements for terminal support of
commands. All commands marked as mandatory must be supported by terminals
compliant to RuPay. All commands listed as conditional must be supported if the
listed condition is true. All issuer script commands must be passed by the terminal to
the chip card.
Table 45 EMV Command Set Supported
COMMAND TERMINAL REQUIREMENT
GENERATE APPLICATION CRYPTOGRAM
GET DATA
GET PROCESSING OPTIONS Mandatory
READ RECORD
SELECT
EXTERNAL AUTHENTICATE Conditional – If online capable
GET CHALLENGE Conditional – If offline enciphered PIN is

supported
INTERNAL AUTHENTICATE Conditional – If DDA is supported
8.4 Fall back to Magnetic Stripe Processing

When a Chip Card is presented at a RuPay Chip enabled terminal, the transaction
should be completed as a Chip Card Transaction. If the transaction cannot be
completed in this manner, the transaction shall “fall back” to a magnetic stripe
transaction and must be submitted to the Issuer for authorization.
 The Chip Card transaction may not be completed for reasons like –
o The Chip Card and the Terminal fail to reach completion of the transaction
due to technical problem. Here completion of transaction means the final
decision (approval or decline) taken by the Chip and communicated
successfully to the terminal. Transaction completion does not include script
processing i.e. if due to any reasons, the terminal is not able to process the
scripts sent by the Issuer after the Chip has communicated its decision to
the terminal, the terminal will not raise a fall back.
 If the transaction cannot be completed as a Chip Card Transaction, a fall back to
magnetic stripe transaction shall be allowed

 If Chip Fall back procedures are used to obtain an Authorization Response, the
Chip Card Transaction is treated as a standard Card Transaction
 Fall back transactions must go online for authorization
 Fall back transactions must be indicated in the financial request transaction by
setting DE 22 (POS Entry Mode) to ‘80X’
8.5 Refund Transaction Processing at Terminal

A refund transaction is carried out when the cardholder returns goods to a merchant
and is expected to be credited with its value. Refunds can be for full or partial
amount of the original transaction.
Refund processing in case of RuPay Chip Card will be carried out in a manner similar
to that in RuPay Magstripe Card; however, the refund request message will contain
the chip data of the card.
The steps for carrying out Refund Transaction will be as below –
1. The terminal performs Application Selection. The same application invoked

during the original purchase transaction is selected
2. The terminal initiates application processing by fetching the available PDOL and
providing the card with the data required in the PDOL
3. The ICC responds back with the Application Interchange Profile and the AFL
based on which the terminal issues READ RECORD command, requesting the
required data.
4. After completion of READ RECORD commands, terminal terminates the
interaction with the chip
5. The terminal populates all the data required for generating refund record for the
clearing file, logs the activity and generates receipt indicating successful refund
transaction processing
6. The ISO message for refund is piggy backed with the next online transaction /
before batch close
8.6 Application Status

An IC Card application may be blocked; a status in which no transaction can be
performed. If the IC Card application status was normal when initiating the
transaction, the Terminal should complete the current transaction even if it detects
that the application has been blocked during processing. The Terminal shall not start
a transaction using the application which is already blocked
8.7 Service Code Validation

When a magnetic stripe transaction is attempted at a Terminal that has been
upgraded to support Chip Cards, service code checking should occur before the
transaction is initiated. If the service code indicates that the card is chip capable
(values 2XX for international or 6XX for domestic Chip Cards valid only within the
country of issuance), the Terminal should not allow the transaction to be performed

via the magnetic stripe. Instead, the Terminal should prompt for the Chip Card to be
inserted into the Chip Card reader. If the transaction being performed is a fall back
transaction, the Terminal should not perform service code checking
8.8 Displayable Messages on Terminal

Several new Terminal display messages are required as a result of the introduction
of Chip Card processing. While NPCI does not mandate the exact messages to be
displayed on Terminals, the sample messages included in Table 17 below are
recommended
Table 46 Displayable Messages on Terminal
Condition Message
Magnetic stripe transaction attempted by a card INSERT CARD or USE CHIP READER
with a service code that indicates it is chip capable
Fall back transaction PLEASE SWIPE CARD or USE
MAGSTRIPE
The card has restrictions preventing the current NOT ACCEPTED
transaction from being processed
The PIN Try Counter indicates that the Cardholder LAST PIN TRY
has only one PIN attempt remaining
The PIN that the Cardholder entered was incorrect INCORRECT PIN
After an incorrect PIN has been entered, the RE-ENTER PIN
Cardholder is asked to enter the PIN again
Transaction is concluded and Chip Card removal is REMOVE CARD
allowed
8.9 Premature Card Removal

In a Chip Card Transaction, the Chip Card must remain in the Terminal for the full
duration of the Transaction. The Chip Card should only be removed after the
Terminal displays a prompt indicating that this action is allowed (e.g., “REMOVE
CARD”).
If a Chip Card is removed prior to the card’s completion of its final cryptogram
generation (at either the end of the first or second card action analysis), the
Transaction must be terminated. If the Chip Card is removed after its final
cryptogram generation, but before Issuer script processing, the Transaction is
considered complete.
If a Transaction is terminated due to a premature card removal or is reject by the

card during final completion processing (response to 2nd generate AC = AAC), and
an online authorization was obtained & the transaction was approved by the issuer,
NPCI requires that a reversal be sent for this transaction

8.10 Terminal Receipt Printing
The table below lists down the data required, for RuPay Chip Card, to be printed on
a transaction receipt as per RuPay specifications –
Table 47 Recommended Data for Receipt Printing
Data Condition
AID Mandatory
Approval Code Mandatory
Date of Charge Mandatory
Establishment Name and / or Number
Mandatory
(Merchant Details)
Total Amount (Including currency if other
Mandatory
than the local currency)
Truncated Account Number (PAN) Mandatory
Transaction Certificate (TC) Optional
Conditional – Required if signature is used as the
mechanism for cardholder verification, in other
Cardholder Signature
cases, the decision to print this data is at
Acquirer’s discretion
Application Preferred Name or Application
Optional
Label
Expiration Date Optional
Indicator showing that chip was used for
Optional
the transaction
TVR Optional
TSI Optional
PIN Verification Status to be printed for
successfully verified PIN; recommend value
as below Conditional if PIN is used as the mechanism for
cardholder verification
- PIN Verified OK
Below detailed are some conditional samples that might be a useful reference for the Acquirer /
terminal vendor –
Magstripe Only Transaction
ABC Bank
XYZ Merchant
Mumbai
Date 01-09-2012 Time 16:59:24

MID 123456789123456 TID 11223344
Batch Num 000012 Invoice Num 000111
Sale
Card Num 1234XXXXXXXX3456 Swipe

Card Type RuPay
Appr Code 121212 RRN 123412341234
AMOUNT Rs. 505.00
Sign ____________________________
Disclaimer for Customer
Merchant / Customer Copy
Figure 22 - Magstripe Txn Receipt

Chip Transaction + Successful PIN Verification
ABC Bank
XYZ Merchant
Mumbai
Date 01-09-2012 Time 16:59:24

MID 123456789123456 TID 11223344
Batch Num 000012 Invoice Num 000111
Sale
AID A0000005241010
Card Num 1234XXXXXXXX3456 CHIP
Card Type RuPay
Appr Code 121212 RRN 123412341234
AMOUNT Rs. 505.00
Transaction Certificate 1A2B3C4D5E6F7A89
PIN Verified OK
Figure 23 - Chip Txn Receipt with PIN

Chip Transaction + Signature used as the method for Cardholder Verification
ABC Bank
XYZ Merchant
Mumbai
Date 01-09-2012 Time 16:59:24

MID 123456789123456 TID 11223344
Batch
Num 000012 Invoice Num 000111
Sale
AID: A0000005241010
Card Num 1234XXXXXXXX3456 CHIP
Card Type RuPay
Appr Code 121212 RRN 123412341234
AMOUNT Rs. 505.00
Sign ____________________________
Figure 24 - Chip Txn Receipt with Signature
8.11 Chip Related Reversal

A reversal notifies the Issuer that a Transaction is being cancelled after a successful
online authorization, and ensures that a clearing message is not created for the
Transaction.
For a Chip Card Transaction, a reversal is performed in the same way as for a
magnetic stripe transaction.
When the Chip Card performs its final analysis after an online approved
authorization is received, in certain scenarios it can still decline the Transaction.
When the Chip Card declines the Transaction at this point, the Terminal should
generate a reversal message

9 Acquirer System Interface
The Terminal must ensure that all the required data pertaining to a RuPay Chip transaction should
be passed on to the acquiring switch to which it is connected. While the format and the content of
the RuPay Chip related fields will be as per the specifications laid down by NPCI, the communication
protocol and message format of the overall transaction data exchanged between the Terminal and
the Acquiring Switch will be proprietary to the Acquirer

10 Terminal Testing and Certification
It is important to note that in order for a RuPay transaction to occur, a terminal must have RuPay
specific parameters and data elements loaded and must be certified to process RuPay
transactions.
For more details, please refer to RuPay Chip Certification Guide.
Note: The Acquirer shall get in touch with NPCI for latest test tools and test cases.

ANNEXURE A
Terminal Parameters for Rupay Chip (Sample)
Below are the sample values for Terminal Parameters. Please ask your NPCI representative to
provide the latest copy of Terminal Parameters.
CONDITIONS / PRE- SOURCE OF

REQUISITES / CONFIGURAT
PARAMETER POSSIBLE VALUES RECOMMENDATION ION
Application Selection
AID / Application
Version Number
A0000005241010 /
0064
A0000001523010 /
All supported Application 0001
Identifier (AID) and supporting A0000000651010 /
Application version numbers 0200 NPCI
Application Selection Indicator 1. Full Match Both Methods should Acquirer /

(ASI) 2. Partial Match be supported NPCI
1. Cardholder
Selection
2. Cardholder
Confirmation
3. Application
Final Selection Method Priority NPCI
Offline Data Authentication
It is recommended that
terminals should have
6 slots for CA PKs per
AID and their
associated Data
CA Public Keys 6 keys Elements NPCI

As per BIN Range
type (for PIN based
PIN Bypass Option cards - not allowed) Acquirer
Terminal Risk Management - Supported
The floor limits for chip

transactions may be
different from the
magstripe floor limits
but for this
implementation it is
required to have both
the floor limits set to
Terminal Floor Limits 0 zero(0) Acquirer
Required only when

Offline Transactions
Random Transaction Selection - NA - are supported Acquirer
Maximum Target Percentage for

Biased Random
Selection - NA -
Target Percentage for Random

Selection - NA -
Threshold Value for Biased

Random Selection - NA -
Velocity Checking - NA - Acquirer
Exception File Optional Acquirer
Transaction Forced Online - NA - Acquirer
First Terminal Action Analysis
The merchants should

Please refer to 'TERMINAL not be allowed to Acquirer /
ACTION CODES' change these values NPCI

Fallback Allowed to
Fallback Allowed YES Magstripe + PIN only
Other Requirements
As configured for
Terminal Country Code 0356 domestic magstripe Acquirer
As configured for
Terminal Currency Code 0356 domestic magstripe Acquirer
Terminal Currency Exponent 02 Acquirer
Default Terminal Data Object List

(TDOL) - NA - Not Required Acquirer
Default Dynamic Data Object List

(including the Unpredictable Mentioned tag is
Number) (DDOL) 9F3704 Minimum Required Acquirer

Annexure B
Terminal Configuration Recommendations
CONDITIONS / SOURCE OF
PARAMETER POSSIBLE VALUES PRE-REQUISITES CONFIGURATION
Compliance
1. Support up to 19
digits
2. Sending the PAN
intact in
Authorization and
PAN Length Clearing Messages Terminal Vendor
Displayable Messages on Terminal
Magnetic stripe transaction
attempted by a card with a
service code that indicates it is chip INSERT CARD or USE Acquirer /
capable CHIP READER Scheme Provider
PLEASE SWIPE CARD Acquirer /
Fallback transaction or USE MAGSTRIPE Scheme Provider
The card has restrictions preventing
the current Acquirer /
transaction from being processed NOT ACCEPTED Scheme Provider
The PIN Try Counter indicates that For OFFLINE PIN
the Cardholder has verifications Acquirer /
only one PIN attempt remaining LAST PIN TRY only Scheme Provider
The PIN that the Cardholder entered Acquirer /
was incorrect INCORRECT PIN Scheme Provider
After an incorrect PIN has been
entered, the
Cardholder is asked to enter the PIN Acquirer /
again RE-ENTER PIN Scheme Provider
Acquirer /
The (offline) PIN entered was correct PIN OK Scheme Provider
Transaction is concluded and Chip
Card removal is Acquirer /
allowed REMOVE CARD Scheme Provider
Other Support Requirements
Acquirer /
Purchase with Debit and Credit Cards - NA - Mandatory Terminal Vendor
Cancellation at any time while Acquirer /
processing a transaction - NA - Mandatory Terminal Vendor
Support T=0 and T=1 protocols (for Acquirer /
Contact based EMV CHIP Cards) - NA - Mandatory Terminal Vendor

Capability to store up to six
Certification Authority (CA) Public
Keys (PKs) and their associated Data Acquirer /
Elements - NA - Mandatory Terminal Vendor
Transmit all data encoded on
magnetic stripe without any
modification or alteration for Acquirer /
magnetic stripe transactions - NA - Mandatory Terminal Vendor
Acquirer /
Support Terminal floor limits - NA - Mandatory Terminal Vendor
Support the minimum Chip Card
related Data, as per RuPay
Specifications, Elements for Acquirer /
authorization and batch data capture - NA - Mandatory Terminal Vendor
Acquirer /
Support transaction receipt printing - NA - Mandatory Terminal Vendor

Annexure C
Terminal Certification Form (Sample)
Below is a sample values for Terminal Certification Form. Please ask your NPCI representative to
provide the latest copy of Terminal Certification Form.
TERMINAL CERTIFICATION FORM

Date
Implementation ID#
ACQUIRER DETAILS
Acquirer ID
Institution Details
Acquirer Name
Address
Contact Number
Fax
Contact Point Details
Contact Person Name
Address
Contact Number
Fax
Email Id
TERMINAL DETAILS
Manufacturer Company Name
Make / Model / Serial No.
Certification Details
EMVCo Level 1 Approval Number
Kernel Manufacturer Company Name
EMVCo Level 2 Approval Number
Proprietary Application Name & Version
TERMINAL CAPABILITIES
Terminal Type
Data Authentication Supported
Static Data Authentication Yes / No
Dynamic Data Authentication Yes / No
Combined Data Authentication Yes / No
Cardholder Verification Methods (CVM)
Supported
Online Enciphered PIN Verification Supported Yes / No
Offline Enciphered PIN Verification Supported Yes / No
Offline Plaintext PIN Verification Supported Yes / No
Signature Supported Yes / No

No CVM Supported Yes / No
Other
Terminal Floor Limit
Terminal Country Code
Transaction Currency Code
Random Transaction Selection
Maximum Target Percentage for Biased Random
Selection
Target Percentage for Random Selection
Threshold Value for Biased Random Selection
Velocity Checking Supported
Exception File
Bypass PIN Entry Supported
Magstripe Fallback
TERMINAL CONFIGURATIONS
Application Identifier (AID)
Set '0064' for AID = A0 00 00 05 24 10 10
Set '0001' for AID = A0 00 00 01 52 30 10
Application Version Number Set '0200' for AID = A0 00 00 00 65 10 10
CA Public Keys Refer Worksheet(s) CA PKs
TAC - Denial Set '00 10 00 00 00'
TAC - Online Set 'FF FF FF FF FF'
TAC - Default Set 'FF FF FF FF FF'
Default DDOL Set Unpredictable Number '9F3704'

Annexure D
Certification Authority Public Keys Set I
RID: A0 00 00 01 52
Note
Hash Value or the check value is calculated on the concatenation of all parts of the CA Public Key
(RID, CA Public Key Index, CA Public Key Modulus, CA Public Key Exponent) using SHA-1
Test Key Set

CA PK Index 5A
EDD8252468A705614B4D07DE3211B30031AEDB6D33A4315F2CFF7C97DB918993
C2DC02E79E2FF8A2683D5BBD0F614BC9AB360A448283EF8B9CF6731D71D6BE93
9B7C5D0B0452D660CF24C21C47CAC8E26948C8EED8E3D00C016828D642816E65
Modulus 8DC2CFC61E7E7D7740633BEFE34107C1FB55DEA7FAAEA2B25E85BED948893D07
Exponent 03
Hash Algorithm
Indicator 01 (SHA-1)
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value CC9585E8E637191C10FCECB32B5AE1B9D410B52D
CA PK Index 5B
D3F45D065D4D900F68B2129AFA38F549AB9AE4619E5545814E468F382049A0B97
76620DA60D62537F0705A2C926DBEAD4CA7CB43F0F0DD809584E9F7EFBDA3778
747BC9E25C5606526FAB5E491646D4DD28278691C25956C8FED5E452F2442E25E
DC6B0C1AA4B2E9EC4AD9B25A1B836295B823EDDC5EB6E1E0A3F41B28DB8C3B7
Modulus E3E9B5979CD7E079EF024095A1D19DD
Exponent 03
Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value 4DC5C6CAB6AE96974D9DC8B2435E21F526BC7A60
CA PK Index 5C
833F275FCF5CA4CB6F1BF880E54DCFEB721A316692CAFEB28B698CAECAFA2B2D2
AD8517B1EFB59DDEFC39F9C3B33DDEE40E7A63C03E90A4DD261BC0F28B42EA6E
7A1F307178E2D63FA1649155C3A5F926B4C7D7C258BCA98EF90C7F4117C205E8E
32C45D10E3D494059D2F2933891B979CE4A831B301B0550CDAE9B67064B31D8B
481B85A5B046BE8FFA7BDB58DC0D7032525297F26FF619AF7F15BCEC0C92BCDC
Modulus BC4FB207D115AA65CD04C1CF982191
Exponent 03

Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value 60154098CBBA350F5F486CA31083D1FC474E31F8
CA PK Index 5D
AD938EA9888E5155F8CD272749172B3A8C504C17460EFA0BED7CBC5FD32C4A80
FD810312281B5A35562800CDC325358A9639C501A537B7AE43DF263E6D232B81
1ACDB6DDE979D55D6C911173483993A423A0A5B1E1A70237885A241B8EEBB557
1E2D32B41F9CC5514DF83F0D69270E109AF1422F985A52CCE04F3DF269B795155
A68AD2D6B660DDCD759F0A5DA7B64104D22C2771ECE7A5FFD40C774E441379D
1132FAF04CDF55B9504C6DCE9F61776D81C7C45F19B9EFB3749AC7D486A5AD2E
781FA9D082FB2677665B99FA5F1553135A1FD2A2A9FBF625CA84A7D7365214311
Modulus 78F13100A2516F9A43CE095B032B886C7A6AB126E203BE7
Exponent 03
Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value B51EC5F7DE9BB6D8BCE8FB5F69BA57A04221F39B

Annexure E
Certification Authority Public Keys Set II
RID: A0 00 00 00 65
Note
Test Key Set
CA PK Index 08
B74670DAD1DC8983652000E5A7F2F8B35DFD083EE593E5BA895C95729F2BADE9
C8ABF3DD9CE240C451C6CEFFC768D83CBAC76ABB8FEA58F013C647007CFF7617
BAC2AE3981816F25CC7E5238EF34C4F02D0B01C24F80C2C65E7E7743A4FA8E232
Modulus 06A23ECE290C26EA56DB085C5C5EAE26292451FC8292F9957BE8FF20FAD53E5
Exponent 03
Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value DD36D5896228C8C4900742F107E2F91FE50BC7EE
CA PK Index 0F
9EFBADDE4071D4EF98C969EB32AF854864602E515D6501FDE576B310964A4F7C2
CE842ABEFAFC5DC9E26A619BCF2614FE07375B9249BEFA09CFEE70232E75FFD64
7571280C76FFCA87511AD255B98A6B577591AF01D003BD6BF7E1FCE4DFD20D0D
0297ED5ECA25DE261F37EFE9E175FB5F12D2503D8CFB060A63138511FE0E125CF
Modulus 3A643AFD7D66DCF9682BD246DDEA1
Exponent 03
Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value 2A1B82DE00F5F0C401760ADF528228D3EDE0F403
CA PK Index 11
A2583AA40746E3A63C22478F576D1EFC5FB046135A6FC739E82B55035F71B09BE
B566EDB9968DD649B94B6DEDC033899884E908C27BE1CD291E5436F762553297
763DAA3B890D778C0F01E3344CECDFB3BA70D7E055B8C760D0179A403D6B55F2
B3B083912B183ADB7927441BED3395A199EEFE0DEBD1F5FC3264033DA856F4A8
Modulus B93916885BD42F9C1F456AAB8CFA83AC574833EB5E87BB9D4C006A4B5346BD9E

17E139AB6552D9C58BC041195336485
Exponent 03
Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value D9FD62C9DD4E6DE7741E9A17FB1FF2C5DB948BCB
CA PK Index 13
A3270868367E6E29349FC2743EE545AC53BD3029782488997650108524FD051E3
B6EACA6A9A6C1441D28889A5F46413C8F62F3645AAEB30A1521EEF41FD4F3445B
FA1AB29F9AC1A74D9A16B93293296CB09162B149BAC22F88AD8F322D684D6B49
A12413FC1B6AC70EDEDB18EC1585519A89B50B3D03E14063C2CA58B7C2BA7FB2
2799A33BCDE6AFCBEB4A7D64911D08D18C47F9BD14A9FAD8805A15DE5A38945
A97919B7AB88EFA11A88C0CD92C6EE7DC352AB0746ABF13585913C8A4E04464B
77909C6BD94341A8976C4769EA6C0D30A60F4EE8FA19E767B170DF4FA80312DB
Modulus A61DB645D5D1560873E2674E1F620083F30180BD96CA589
Exponent 03
Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value 54CFAE617150DFA09D3F901C9123524523EBEDF3

Annexure F
Certification Authority Public Keys Set III
RID: A0 00 00 0524
Note
Test Key Set

CA PK Index 6A
92795EAA4FE39EB30441FE952D5423778E02F86783B89DD7C587AE80A69F4D6D
C55EAFB6604040D875C72002425EE529CE4EA26FD864BAD760160C2AA0C5AF92
381894A5CBBC8AB3AF2641606C379B927A397CB1E9B9EA2EF8C0A9C0DDEBB81B
Modulus 0F8913A118F7044156EA7D23AF626EAF30C2C9ECE8534D3563EF5FE95DE76249
Exponent 03
Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value 51ED4570323CD41A0348BDFEA81CCC0B8D9BAB3F
CA PK Index 6B
C9DFDB625ADA4B5E86049F85A0237627B59524F52BD499B4C5482C1EE012D61A
1446E9383CC0B7EE2922D323A5ECDA12941EA8177CFA512DA6B5B7663A89B793
B10D314CBB776EB96D0B1734EDE7E1591713915E9991B7B4E8A017A6901279AE
BDD6136C9FE7E0C6CBF94C77FA606B629D00B1F890473905EB4DAD1AD93B29C2
Modulus C1829A82F880B08986B9387611EE409D
Exponent 03
Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value 9602428A46271C63CCC6DD99477CDB70435D6D5B
CA PK Index 6C
C76259FF785ABD5FF613223C01F5BDA0F36F9342CF336B66C32D4B2CD5096E094
D8E04DFA11A9B2E3BC78DA63B5C10148D8ED79EBA685D5D0EFE1C58B3F929D8
61B40FF3AAA3B527148D0C24921EE42DA048E01E38F6A3A49DFA67DD1CD5DD2
091412DD36D3269FAF7D2E0FFB1A3E028969CB6BA5A9303A6FF65540F421B069
A31B553398EE525EFA5C2CE26BCB81C5345018D5E3E9B7130F72F598C0EAA4682
Modulus D4DA2F2204518780A8108F82DDC9CF1F
Exponent 03

Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value 3B18A21BF34F781208145D7567982513D1CE8C92
CA PK Index 6D
B747E8CB3615E8D26231355488F3C76C4746F7BB1C381E6C6E6ABF0A6D7CD93CF
C6B2C310288CA8BE7EE1730DE621A59D1BB2D8C02C9148FA06E5D1F5E672EEFC
E8AECBAD4A1C18F3175F1BEA1AEF539376592366B46A5044E32E59B3F35F50E85
F843BA01851E5386B7EBE27367D3D483C5472D3020AF42116DDDA32341557EBA
BB043EBC6006B99A652009045BFA50C527028586E05942E1D594223B49FE85669
31C31FBE8C903ABD4F283E1FAB03D758247EC4B728A85A9897601B753293263A
DBD10BE988D0C52FE0091C2721DC02C5130FC7663E95739A70EE2F84DFD2E50C
Modulus 88A1A26587EF7CC047FCA2D03C2CF0CE4B524B4EC3F07
Exponent 03
Hash Algorithm
Public Key
Algorithm
Indicator 01 (RSA)
Hash Value 411008F9921B89C62E2160F6D0358614115ECD4A
*** End of Document ***

RuPay Chip Terminal Implementation Requirements Guide - v1.1

Uploaded by

Copyright:

Available Formats

You might also like

RuPay Chip Terminal Implementation Requirements Guide - v1.1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RuPay Chip Terminal Implementation Requirements Guide - v1.1

Uploaded by

Copyright:

Available Formats

RuPay CHIP – Terminal

Date: March 21, 2013

Confidential RuPay CHIP-Acquiring Requirements Guide Page 2 of 117

Confidential RuPay CHIP-Acquiring Requirements Guide Page 3 of 117

Confidential RuPay CHIP-Acquiring Requirements Guide Page 4 of 117

Confidential RuPay CHIP-Acquiring Requirements Guide Page 5 of 117

Confidential RuPay CHIP-Acquiring Requirements Guide Page 6 of 117

Table 1 POS Entry Code......................................................................................................................... 15

Confidential RuPay CHIP-Acquiring Requirements Guide Page 7 of 117

Figure 1 - Payment Transaction Overview ........................................................................................... 13

Confidential RuPay CHIP-Acquiring Requirements Guide Page 8 of 117

1.2 Scope of the Document

1.3 Document Organization

1.3.1 Naming Conventions

 National Payments Corporation of India is referenced as NPCI

Confidential RuPay CHIP-Acquiring Requirements Guide Page 9 of 117

AAC Application Authentication Cryptogram

Confidential RuPay CHIP-Acquiring Requirements Guide Page 10 of 117

1.3.3 Reference Materials

Confidential RuPay CHIP-Acquiring Requirements Guide Page 11 of 117

• Network support for RuPay Chip Card Transactions

• RuPay requirements for Chip Cards and Terminals

• Acquirer and Issuer planning and implementation guides

• Certificate Authority requirements and processes

• Testing and certification requirements

Confidential RuPay CHIP-Acquiring Requirements Guide Page 12 of 117

Figure 1 - Payment Transaction Overview

Confidential RuPay CHIP-Acquiring Requirements Guide Page 13 of 117

The message types supported for RuPay are as below –

Confidential RuPay CHIP-Acquiring Requirements Guide Page 14 of 117

5.1 DE#22 – PoS Entry Code

Description Contains a 3 digit code indicating the method used to enter

Table 1 POS Entry Code

Digits 1 & 2 Condition

95 ICC with Unreliable CVD. This condition may

80 Fall back from chip to magnetic stripe

5.2 DE#23 – Card Sequence Number

Description Card Sequence Number is used by the issuer to distinguish

Confidential RuPay CHIP-Acquiring Requirements Guide Page 15 of 117

5.3 DE#35 – Track 2 Data Element

 Primary Account Number (PAN)

 Expiration Date (YYMM)

5.4 DE#39 – Response Data

Description The issuer indicates its decision for a transaction through

Requirement The terminal will receive information about issuer declines

Confidential RuPay CHIP-Acquiring Requirements Guide Page 16 of 117

Response Meaning Action to be taken

E3 ARQC Validation failed by Issuer D

E4 Transaction Declined by Issuer D

E5 Transaction Declined by Issuer D

Response Codes to be populated by the Acquirer in case of Reversal of an Issuer

Table 3 Chip Reversal Decline Codes

Response Meaning Action to be taken

E2 Terminal does not receive final Reverse the transaction

5.5 DE#55 – Chip Data

Requirement Table below shows the minimum required data in DE 55

Online authorization requests must conform to Section