EMV Implementation Guide

Version: 1.4
Date: 3/21/2015

CONFIDENTIAL

©2015 Total System Services, Inc. All rights reserved worldwide. Total System Services, Inc.® and TSYS are federally registered service marks of Total System Services, Inc., in the United States.
Total System Services, Inc., owns a number of service marks that are registered in the United States and in other countries. All other products and company names are trademarks or registered
trademarks of their respective companies.
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Document Information

Copyright
2014 by B2 Payment Solutions Inc. developed for Total System Services Inc. All rights reserved. All information
contained herein is confidential and propriety to B2 Payment Solutions Inc and/or Total System Services Inc. It shall
not be disclosed, duplicated or used in part or in whole, for any purpose without prior written consent from B2
Payment Solutions Inc. and Total System Services Inc. All trademarks, service marks and trade names referenced
in this material are the property of their respective owner.
®
Total System Services, Inc. and TSYS are federally registered service marks of Total System Services, Inc. in the
United States. Total System Services, Inc. owns a number of service marks that are registered in the United States
and in other countries. All other products and company names are trademarks or registered trademarks of their
respective companies.

Disclaimer
This document describes a generic product or service and should be read in conjunction with other documents
relevant to the configuration of any specific system. The recipient of this document is responsible for ensuring that
the products and/or services described herein meets its own requirements. The information contained in this
document is subject to change without notice and should not be taken as a commitment by TSYS. TSYS assumes no
responsibility for any errors that may appear in this document.

Confidentiality
®
The information contained herein is the property of Total System Services, Inc. . This document contains
CONFIDENTIAL information that is produced solely for the benefit of the named parties. All parties should keep all
information contained herein confidential and on no account should the information, in whole or in part, be disclosed
or disseminated to any third party without the express written permission of TSYS.

Page 2 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Document Publication Details

Area Description
Title EMV Implementation Guide
Released Date 03/31/2015
Version 1.4
Author B2 Payment Solutions/TSYS
Owner TSYS

Document Version Control

Version Date Comments
1.0 07/31/2014 Initial document creation
1.1 09/03/2014  Re-numbered BP‟s, RQ‟s and Tables
 Small content and cosmetic corrections
 Updated based on TSYS internal review
1.2 09/04/14  Cosmetic changes and corrections throughout document
 Added additional Glossary definitions
1.4 03/31/2015  Edited page 128-129, cardholder identification code.
 Edited table 37, edited Record Format to K

Page 3 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 4 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

1. Tables of Contents
1. Tables of Contents ............................................................................................................................ 5
1.1 Requirements ................................................................................................................................. 11
1.2 Best Practices ................................................................................................................................ 13
1.3 Tables ............................................................................................................................................. 15
2. Introduction...................................................................................................................................... 19
2.1 Target Audience ............................................................................................................................. 19
2.2 Implementation Guide Overview .................................................................................................... 19
2.2.1 EMVCo LLC ...................................................................................................................... 20
2.3 EMV and Contactless Configurations ............................................................................................ 20
2.3.1 Fully Integrated ECR Solution ........................................................................................... 22
2.3.2 Partially Integrated ECR Solution ..................................................................................... 23
2.3.3 Semi-Integrated ECR Solution .......................................................................................... 24
2.3.4 Standalone POS Solution (Internal PINPad) .................................................................... 25
2.3.5 Standalone POS Solution (External PINPad) ................................................................... 26
2.4 EMV and Contactless Solution Components ................................................................................. 27
2.5 Supported Configurations............................................................................................................... 27
2.6 EMV Configuration Type ................................................................................................................ 27
2.7 U.S. Debit ....................................................................................................................................... 28
2.8 EMV and Contactless Migration ..................................................................................................... 32
3. Development Process ..................................................................................................................... 33
3.1 Configuration Review ..................................................................................................................... 35
3.2 Training........................................................................................................................................... 36
3.3 Technical Support .......................................................................................................................... 36
3.4 Testing and Certification................................................................................................................. 37
3.5 Pilot Requirements ......................................................................................................................... 38
3.6 Production Notification ................................................................................................................... 39
3.7 Development Host Connection Information ................................................................................... 39
3.8 TSYS Certification and Testing Service ........................................... Error! Bookmark not defined.
3.8.1 New Users ........................................................................... Error! Bookmark not defined.
3.9 EMV and Contactless Test Tool Requirements ............................................................................. 40
3.9.1 Collis Merchant Test Suite ................................................................................................ 40
3.10 Integration Validation Test Cards ................................................................................................... 42
3.11 Card Brand Certification ................................................................................................................. 42
4. EMV Overview .................................................................................................................................. 43
4.1 EMV Benefits .................................................................................................................................. 43
4.2 Online vs. Offline EMV Transactions ............................................................................................. 43
4.3 EMV Smart Card Schemes ............................................................................................................ 43
4.4 EMV Transaction Set ..................................................................................................................... 43
4.4.1 EMV Credit Transaction Set ............................................................................................. 44
4.4.2 EMV Debit Transaction Set ............................................................................................... 45

Page 5 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

4.5 Transaction Processing .................................................................................................................. 46

4.5.1 Purchase Transactions ..................................................................................................... 46
4.5.2 Pre-Authorizations and Incremental Authorizations .......................................................... 46
4.5.3 Completions ...................................................................................................................... 46
4.5.4 Refunds ............................................................................................................................. 47
4.5.5 Quick Service Transactions (QSR, QPS, FPS) ................................................................ 47
4.5.6 Currency Conversion (CC) ................................................................................................ 47
5. Contactless Overview ..................................................................................................................... 49
5.1 Contactless Benefits ....................................................................................................................... 49
5.2 MSD vs. EMV Grade ...................................................................................................................... 49
5.2.1 Magstripe Environment (Replacement) ............................................................................ 49
5.2.2 EMV Environment (Complement) ..................................................................................... 49
5.2.3 EMV Environment (Replacement) .................................................................................... 50
5.3 Contactless Card Schemes ............................................................................................................ 51
5.4 EMV Contactless Transaction Sets ................................................................................................ 51
6. EMV Transaction Flow .................................................................................................................... 53
6.1 Full EMV Transaction Flow ............................................................................................................ 53
6.1.1 Full EMV Transaction Flowchart ....................................................................................... 56
6.2 Partial EMV Transaction Flow ........................................................................................................ 57
6.2.1 Partial EMV Transaction Flowchart ................................................................................... 59
7. Contactless Transaction Flow ....................................................................................................... 61
7.1.1 Contactless Transaction Flowchart ................................................................................... 62
8. Chip Processing Guidelines........................................................................................................... 63
8.1 Tender Processing ......................................................................................................................... 63
8.1.1 Cashback Transaction Flow .............................................................................................. 63
8.1.2 Tip Transaction Flow ......................................................................................................... 64
8.2 EMV Transaction Initiation ............................................................................................................. 64
8.2.1 Service Code Processing .................................................................................................. 64
8.3 Chip Read Flow .............................................................................................................................. 65
8.3.1 Chip Read Flowchart......................................................................................................... 67
8.4 Fallback Processing ....................................................................................................................... 68
8.4.1 MSR Fallback .................................................................................................................... 68
8.4.2 Technical Fallback ............................................................................................................ 69
8.4.3 Fallback Not Allowed Scenarios ....................................................................................... 69
8.4.4 Fallback Prompting ........................................................................................................... 69
8.4.5 Fallback Timelines ............................................................................................................ 70
8.5 Application Selection ...................................................................................................................... 70
8.5.1 Application Selection Methods .......................................................................................... 72
8.5.1.1 Implicit Application Selection (PSE) ................................................................ 72
8.5.1.2 Explicit Application Selection ........................................................................... 72
8.5.2 Credit / Debit Selection and U.S. Debit Processing .......................................................... 73
8.5.3 U.S. Debit Processing Flowchart ...................................................................................... 75

Page 6 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.5.4 Final Selection ................................................................................................................... 76

8.5.5 Cardholder Application Confirmation ................................................................................ 77
8.6 Read Data Records ........................................................................................................................ 77
8.7 Cardholder Language Selection ..................................................................................................... 78
8.8 Cardholder Prompting .................................................................................................................... 78
8.8.1 Card Entry Prompting........................................................................................................ 78
8.8.2 PIN Prompting ................................................................................................................... 79
8.8.3 Amount Confirmation Prompting ....................................................................................... 79
8.9 Processing Restrictions .................................................................................................................. 80
8.9.1 Processing Restrictions Steps .......................................................................................... 81
8.10 Offline Card Authentication ............................................................................................................ 82
8.10.1 Offline Card Authentication Methods ................................................................................ 82
8.11 Cardholder Verification ................................................................................................................... 82
8.11.1 Supported Cardholder Verification Methods (CVM) ......................................................... 83
8.11.2 PIN Prompting ................................................................................................................... 84
8.11.3 CVM Results Validation (Tag 9F34) ................................................................................. 85
8.12 Terminal Risk Management ........................................................................................................... 85
8.12.1 EMV Floor Limit................................................................................................................. 86
8.12.2 EMV Random Selection .................................................................................................... 86
8.13 Data Object Lists ............................................................................................................................ 87
8.13.1 Dynamic Data Object List (DDOL Tag 9F49) ................................................................... 87
8.13.2 Transaction Certificate Data Object List (TDOL Tag 97) .................................................. 87
8.13.3 Processing Data Object List (PDOL Tag 9F38) ................................................................ 87
8.14 Terminal Action Analysis ................................................................................................................ 88
8.14.1 Issuer Action Codes (IACs) ............................................................................................... 88
8.14.2 Terminal Action Codes (TACs) ......................................................................................... 88
8.15 1st Generate Application Cryptogram ............................................................................................ 89
8.15.1 Terminal Action Analysis ................................................................................................... 89
8.15.2 Card Action Analysis ......................................................................................................... 89
8.16 Stand-In Processing (STIP)............................................................................................................ 90
8.16.1 Merchant Stand-in Processing .......................................................................................... 91
8.16.2 Merchant Stand-In Processing Flowchart ......................................................................... 93
8.17 Offline Transaction Upload ............................................................................................................. 94
8.18 Online Response Processing ......................................................................................................... 94
8.18.1 Partial Authorizations ........................................................................................................ 95
8.18.2 Referrals ............................................................................................................................ 95
8.19 External Authenticate ..................................................................................................................... 96
8.20 2nd Generate Application Cryptogram ........................................................................................... 96
8.20.1 Issuer Script Processing ................................................................................................... 97
8.21 Transaction Completion Processing .............................................................................................. 97
8.21.1 Reversal Processing ......................................................................................................... 97
8.21.2 Card Removal Prompting .................................................................................................. 98
8.21.3 Transaction Storage .......................................................................................................... 98

Page 7 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

9. Certificate Authority Public Key Management ........................................................................... 101

10. EMV and Contactless Parameters ............................................................................................... 103
10.1 Contact EMV Parameters............................................................................................................. 103
10.2 Contactless EMV Parameters ...................................................................................................... 105
11. Host Message Formats ................................................................................................................. 107
11.1 Host EIS 1080 Message Formats ................................................................................................ 107
11.1.1 EIS 1080 Request Message Format ............................................................................... 107
11.1.2 EIS 1080 Response Message Format ............................................................................ 109
11.1.3 EIS 1081 Settlement Record .......................................................................................... 110
11.1.4 EIS Message Data Fields ............................................................................................... 111
11.1.4.1 Device Code .................................................................................................. 111
11.1.4.2 Cardholder ID Code ....................................................................................... 111
11.1.4.3 Account Data Source ..................................................................................... 111
11.1.4.4 Chip Condition Code...................................................................................... 111
11.1.4.5 Customer Data Field ...................................................................................... 112
11.1.4.6 Group III Version 027 POS Data Code .......................................................... 112
11.1.4.7 Group III Version 055 TLV EMV Tag Data .................................................... 114
11.2 Host Summit Message Formats ................................................................................................... 117
11.2.1 Summit Request Message Header Format..................................................................... 117
11.2.2 Summit Response Message Format............................................................................... 117
11.2.3 Summit Message Data Fields ......................................................................................... 118
11.2.3.1 Field <A21> POS Entry Data ......................................................................... 118
11.2.3.2 Field <A58> Visa Contactless Data Group .................................................... 119
11.2.3.3 Field <A111> Chip Card Data ....................................................................... 120
11.2.3.4 <A116> MasterCard PayPass Data Group ................................................... 123
11.3 Response Message Processing Flow .......................................................................................... 123
11.3.1 Host Declined Transactions ............................................................................................ 123
11.3.2 Host Approved Transactions ........................................................................................... 124
11.4 Reversal Processing .................................................................................................................... 124
11.4.1 EMV Chip Reversals ....................................................................................................... 124
11.4.2 Reversal Message Format .............................................................................................. 125
11.5 EMV Credit Card Transaction Examples ..................................................................................... 127
11.5.1 Example #1: EMV Online Purchase using Visa ADVT 01 Card ..................................... 127
11.5.1.1 EMV Online Credit Purchase Request Message .......................................... 127
11.5.1.2 EMV Online Credit Purchase Response Message ........................................ 130
11.5.2 Example #2: EMV Online Purchase using MasterCard MTIP06 Card ........................... 132
11.5.2.1 EMV Online Credit Purchase Request Message .......................................... 132
11.5.2.2 EMV Online Credit Purchase – Response Message ..................................... 135
11.5.3 Example #3: Summit EMV Online Purchase .................................................................. 137
11.5.3.1 EMV Online Credit Purchase Request Message .......................................... 137
11.5.3.2 EMV Online Credit Purchase – Response Message ..................................... 139
12. EMV Receipts ................................................................................................................................. 141
12.1 Offline Decline EMV Receipt Data ............................................................................................... 143
Page 8 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

12.2 Receipt Samples .......................................................................................................................... 144

12.2.1 Credit Card (Online Approved – Signature) .................................................................... 145
12.2.2 Credit Card (Online Approved – PIN) ............................................................................. 146
12.2.3 Credit Card (Online Approved – Fallback) ...................................................................... 147
12.2.4 Credit Card (Offline Declined) ......................................................................................... 148
13. Reporting Guidelines .................................................................................................................... 151
13.1 Chip Transaction Report .............................................................................................................. 151
13.2 EMV Technical Fallback Reports ................................................................................................. 152
13.2.1 EMV Clerk Technical Fallback Report ............................................................................ 153
13.2.2 PINPad Technical Fallback Report ................................................................................. 154
13.3 POS Entry Mode Report............................................................................................................... 154
13.4 EMV Configuration Report ........................................................................................................... 155
14. EMV and Contactless Data Elements .......................................................................................... 161
14.1 EMV & Contactless Data Elements Definitions ............................................................................ 161
15. Reference Materials ...................................................................................................................... 179
15.1 Answer to Reset ........................................................................................................................... 179
15.2 EMV Reference Tables ................................................................................................................ 180
15.2.1 Application Interchange Profile (Tag 82) ........................................................................ 180
15.2.2 Application Priority Indicator (Tag 87) ............................................................................. 181
15.2.3 Application Usage Control (Tag 9F07)............................................................................ 181
15.2.4 Cardholder Verification Rule (part of CVM List) .............................................................. 182
15.2.5 Cardholder Verification Method Results (Tag 9F34) ...................................................... 183
15.2.6 Card Verification Results (included in Tag 9F10) ........................................................... 184
15.2.7 Cryptogram Information Data (Tag 9F27) ....................................................................... 185
15.2.8 Terminal Capabilities (Tag 9F33) .................................................................................... 186
15.2.9 Additional Terminal Capabilities ...................................................................................... 187
15.2.10 Terminal Verification Results (Tag 95)............................................................................ 188
15.2.11 Transaction Status Indicator (Tag 9B) ............................................................................ 190
15.3 EMV Chip Commands .................................................................................................................. 191
15.3.1 Application Block ............................................................................................................. 192
15.3.2 Application Unblock......................................................................................................... 192
15.3.3 Card Block ....................................................................................................................... 193
15.3.4 External Authenticate ...................................................................................................... 193
15.3.5 Generate AC ................................................................................................................... 194
15.3.6 Get Challenge ................................................................................................................. 195
15.3.7 Get Data .......................................................................................................................... 196
15.3.8 Get Processing Options .................................................................................................. 196
15.3.9 Internal Authenticate ....................................................................................................... 197
15.3.10 PIN Change/Unblock....................................................................................................... 198
15.3.11 Read Record ................................................................................................................... 199
15.3.12 Select .............................................................................................................................. 200
15.3.13 Verify ............................................................................................................................... 202
15.3.14 EMV Response Codes (SW1 SW2)................................................................................ 203
Page 9 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.4 BCD to ASCII Conversion ............................................................................................................ 205

15.5 ASCII Chart .................................................................................................................................. 206
16. EMV Testing and Certification Parameters ................................................................................. 207
16.1 Amex Certification Parameters .................................................................................................... 207
16.2 Diners Certification Parameters ................................................................................................... 208
16.3 Discover Certification Parameters ................................................................................................ 209
16.4 JCB Certification Parameters ....................................................................................................... 210
16.5 MasterCard Certification Parameters ........................................................................................... 211
16.6 Visa Certification Parameters ....................................................................................................... 213
17. Glossary of Terms ......................................................................................................................... 215

Page 10 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

1.1 Requirements
RQ 00100 All EMV POS Solutions must support MSR transactions ...................................................... 32
RQ 00200 A Configuration Review is required before development begins .......................................... 36
RQ 00300 Multiple certifications required if multiple kernel configurations supported ........................... 36
RQ 00400 EMV certification letters must be current .............................................................................. 36
RQ 00500 qVSDC certification is required for contactless-only EMV POS Solutions ............................ 38
RQ 00600 Transactions must go online for issuer authorization ............................................................ 43
RQ 00700 Purchase transactions must be processed as Full EMV transactions .................................. 46
RQ 00800 AFD Pre-Authorizations must be processed as Full EMV transactions ................................ 46
RQ 00900 Incremental Authorizations must be sent as keyed transactions .......................................... 46
RQ 01000 Completions require Pre-Authorization chip data.................................................................. 46
RQ 01100 Credit Refunds must be Partial EMV transactions ................................................................ 47
RQ 01200 Debit Refunds must be Full EMV transactions ...................................................................... 47
RQ 01300 CVM processing must be performed for QSR transactions .................................................. 47
RQ 01400 Transaction Currency Code (Tag 5F2A) must be set to CC currency .................................. 48
RQ 01500 Transaction amounts must be converted to selected currency ............................................. 48
RQ 01600 Transaction Currency Code (Tag 5F2A) must be used in G3v032 ....................................... 48
RQ 01800 Issuer decision must be used for MasterCard 2nd Gen AC chip error ................................. 55
RQ 02000 Total transaction amount must be known before card is presented ..................................... 63
RQ 02100 Transaction Amount (Tag 9F02) must be set to total transaction amount ............................ 63
RQ 02200 Cardholder amount confirmation is mandatory ..................................................................... 63
RQ 02300 Transaction Amount (Tag 9F02) must include the cashback amount................................... 63
RQ 02400 Other Amount (Tag 9F03) must contain the cashback amount ............................................ 63
RQ 02500 Cashback only allowed for debit AIDs ................................................................................... 64
RQ 02600 Service Code „2xx‟ and „6xx‟ must force a chip usage .......................................................... 65
RQ 02700 Cancel transaction if card accepted but removed before host authorization ........................ 66
RQ 02800 Reverse and cancel if host approves but card removed before 2nd Gen AC ....................... 66
RQ 02900 Decline transaction if host declines and card is removed before 2nd Gen AC ..................... 66
RQ 03000 Service Code „2xx‟ and „6xx‟ must be accepted for fallback card swipes ............................. 68
RQ 03100 Fallback must be cancelled when a card is inserted at fallback card entry .......................... 68
RQ 03200 Fallback must be cancelled if a non-EMV card is swiped during fallback ............................. 68
RQ 03300 Fallback must be allowed for empty Candidate List .............................................................. 68
RQ 03400 MSR Fallback transaction must be sent to host as a swipe transaction ............................... 69
RQ 03500 Technical Fallback transactions must be identified in the host message ............................. 69
RQ 03600 Fallback is not allowed if not supported by card scheme ...................................................... 70
RQ 03700 Partial Selection must be supported ..................................................................................... 71
RQ 03800 The AID list must be loaded into the kernel at kernel initialization ........................................ 72
RQ 03900 Transaction must be cancelled if Cardholder Application Confirmation fails ........................ 77
RQ 04000 PAN must be MOD10 verified ............................................................................................... 77
RQ 04100 PAN tag must match account number in Track2 Equivalent Data ........................................ 77
RQ 04200 BIN must be found in BIN table ............................................................................................. 77
RQ 04300 Application Expiration Date must match Track2 Equivalent Data expiry date ...................... 78

Page 11 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

RQ 04400 Service Code must not be validated against Track2 Equivalent Data .................................. 78
RQ 04500 AID list must be supported with associated Application Version Numbers ........................... 81
RQ 04600 All Offline CAM failures must be sent for online authorization .............................................. 82
RQ 04700 If offline CAM is not performed transaction must go online .................................................. 82
RQ 04800 All Offline Card Authentication Methods must be supported ................................................ 82
RQ 04900 Online PIN CVM must be supported if solution supports PIN ............................................... 84
RQ 05000 Signature CVM must be supported by attended solutions .................................................... 84
RQ 05100 PIN Bypass is only allowed for U.S. Debit AIDs .................................................................... 84
RQ 05200 Maximum number of PIN tries must not exceed PIN Try Counter (Tag 9F17) ..................... 84
RQ 05300 Cardholder must be notified of last offline PIN attempt ......................................................... 84
RQ 05400 Cardholder must be notified when maximum Offline PIN tries is exceeded ......................... 84
RQ 05500 EMV Floor Limit must be zero ............................................................................................... 86
RQ 05600 A Default DDOL is required for EMV POS Solutions that support DDA ............................... 87
RQ 05700 EMV PIN Debit transactions must always be sent online for authorization .......................... 91
RQ 05800 Issuer Response Code must be set based on host Response Code ................................... 94
RQ 05900 Issuer scripts must be supported in host responses ............................................................. 95
RQ 06000 Reversal must be sent if cardholder declines partial authorization ....................................... 95
RQ 06100 Transaction Amount (Tag 9F02) must reflect the partially authorized amount ..................... 95
RQ 06200 Partially authorized amount must be sent in the settlement message .................................. 95
RQ 06300 Referral transactions must be cancelled ............................................................................... 96
RQ 06400 Issuer Scripts must be executed for approved and declined transactions ............................ 97
RQ 06500 Must support Issuer Scripts up to 128 bytes in length .......................................................... 97
RQ 06600 Handling Issuer Script errors ................................................................................................. 97
RQ 06700 EMV transaction reversals must include EMV tags .............................................................. 98
RQ 06800 Last EMV transaction data must be available even if transaction is declined ...................... 99
RQ 06900 Application Name must be printed on the receipt ............................................................... 142
RQ 07000 Application PAN must be printed on receipt ........................................................................ 142
RQ 07100 Receipt must identify EMV and Fallback transactions ........................................................ 142
RQ 07200 Transaction amount and a currency indicator must be printed on the receipt .................... 142
RQ 07300 CVM used must be printed on the receipt ........................................................................... 142
RQ 07400 A signature line is required for attended terminals when CVM is “NO CVM” ..................... 142
RQ 07500 Receipt must contain mandatory EMV tags ........................................................................ 143
RQ 07600 Offline Decline EMV receipt data required for all card schemes ......................................... 143
RQ 07700 Chip Transaction Report is mandatory ................................................................................ 152
RQ 07800 EMV Configuration Report is mandatory ............................................................................. 159

Page 12 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

1.2 Best Practices

BP 00300 U.S. Debit selection method should be configurable ............................................................ 31
BP 00400 EMV training is recommended .............................................................................................. 36
BP 00500 Budget adequate time for certification ................................................................................... 38
BP 00600 Respond quickly when notified of recertification requirements ............................................. 39
BP 00800 Use the Application Currency Code (Tag 9F42) to determine CC eligibility ......................... 48
BP 01300 Use Pay at Table for restaurant tipping ................................................................................. 64
BP 01400 Fallback Prompting should only be allowed for a limited time .............................................. 70
BP 01500 Card insert and card tap should be supported in fallback ..................................................... 70
BP 01600 Fallback Enable/Disable should be a configurable parameter by card scheme ................... 70
BP 01700 Accept valid AIDs only ........................................................................................................... 72
BP 01800 Cardholder Verification should be handled by EMV kernel ................................................... 74
BP 01900 A default application name should be assigned for all AIDs ................................................. 76
BP 02000 If multiple languages supported cardholder should be prompted to select ........................... 78
BP 02100 Do not use “remove” in the cardholder prompt to leave card inserted .................................. 79
BP 02200 All CVMs should be supported .............................................................................................. 83
BP 02300 PIN Bypass for U.S. Maestro ................................................................................................ 84
BP 02400 Terminal Risk Management features should be supported .................................................. 86
BP 02500 Do not print receipt until the card has been removed ........................................................... 98
BP 02600 Sound audible beep while waiting for card to be removed ................................................... 98
BP 03000 Merchant and Customer receipts should contain the same data ........................................ 142
BP 03100 Chip Transaction Report includes data element name and tag number ............................. 152
BP 03200 EMV Technical Fallback reports are recommended ........................................................... 153
BP 03300 POS Entry Mode Report is recommended .......................................................................... 155

Page 13 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 14 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

1.3 Tables
Table 01 EMV Configuration Types ..................................................................................................... 27
Table 02 EMV Configuration Modes – By Terminal Type .................................................................... 28
Table 03 U.S. Common Debit AIDs ...................................................................................................... 28
Table 04 U.S. Common Debit Scenarios ............................................................................................. 30
Table 05 Development and Certification Process ................................................................................ 33
Table 06 Vendor Certification Documents............................................................................................ 35
Table 07 Testing and Certification Process.......................................................................................... 37
Table 08 General Lab Contact Information .......................................................................................... 40
Table 09 Full vs. Partial EMV Transaction Steps ................................................................................. 44
Table 10 EMV Credit Transaction Set .................................................................................................. 44
Table 11 EMV Debit Transaction Set ................................................................................................... 45
Table 12 Contactless Card Schemes ................................................................................................... 51
Table 13 EMV Contactless Transaction Set......................................................................................... 51
Table 14 Full EMV Transaction Flow ................................................................................................... 53
Table 15 Partial EMV Transaction Flow ............................................................................................... 57
Table 16 Chip Service Codes Processing ............................................................................................ 65
Table 17 Chip Reader Flow .................................................................................................................. 65
Table 18 Magstripe Reader Flow ......................................................................................................... 65
Table 19 Fallback Timelines ................................................................................................................. 70
Table 20 Application Identifiers (AID) ................................................................................................... 71
Table 21 Cardholder Approval Indicator (Tag 87 – bit 8) ..................................................................... 77
Table 22 Recommended Card Entry Prompting .................................................................................. 79
Table 23 Recommended PIN Entry Prompting .................................................................................... 79
Table 24 Recommended Cardholder Amount Confirmation ................................................................ 80
Table 25 Cardholder Verification Methods ........................................................................................... 83
Table 26 (CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 1 ................................... 85
Table 27 (CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 2 ................................... 85
Table 28 (CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 3 ................................... 85
Table 29 Risk Management Requirements .......................................................................................... 85
Table 30 Random Selection Parameters ............................................................................................. 86
Table 31 EMV Reversal Types ............................................................................................................. 97
Table 32 Transaction Batch EMV Tag Information Required............................................................... 98
Table 33 Contact EMV Parameters .................................................................................................... 103
Table 34 Contactless EMV Parameters ............................................................................................. 105
Table 35 EIS 1080 Request Message Format ................................................................................... 107
Table 36 EIS 1080 Response Message Format ................................................................................ 109
Table 37 EIS 1081 Chip Card Addendum Record Format ................................................................. 110
Table 38 Cardholder ID Code ............................................................................................................ 111
Table 39 Account Data Source .......................................................................................................... 111
Table 40 Chip Condition Code ........................................................................................................... 112
Table 41 Group III Version 027 (POS Data Code) ............................................................................. 113

Page 15 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 42 Group III Version 055 (TLV EMV Tag Data) – Request Tags ............................................. 114
Table 43 Group III Version 055 (TLV EMV Tag Data) – Response Tags .......................................... 116
Table 44 Summit Request Message Format ...................................................................................... 117
Table 45 Summit Response Message Format ................................................................................... 117
Table 46 Field <A21> POS Entry Data .............................................................................................. 118
Table 47 Field <A58> Visa Contactless Data Group ......................................................................... 119
Table 48 Field <A111> Request Tags ................................................................................................ 120
Table 49 Field <A111> Response Tags ............................................................................................. 122
Table 50 Field <A116> MasterCard PayPass Data Group ................................................................ 123
Table 51 Host Approval Response Codes ......................................................................................... 124
Table 52 EIS Reversal Request Message Format ............................................................................. 125
Table 53 EIS Reversal Response Message Format .......................................................................... 126
Table 54 EMV Receipt Information .................................................................................................... 141
Table 55 Offline Decline EMV Receipt Data ...................................................................................... 143
Table 56 EMV & Contactless Data Elements – Sorted by Element Name ........................................ 161
Table 57 Basic ATR for T=0 Cards Only ............................................................................................ 179
Table 58 Basic ATR for T=1 Cards Only ............................................................................................ 179
Table 59 Application Interchange Profile (Tag 82) – Byte 1............................................................... 180
Table 60 Application Interchange Profile (Tag 82) – Byte 2............................................................... 180
Table 61 Application Priority Indicator (Tag 87) – Byte 1 ................................................................... 181
Table 62 Application Usage Control (Tag 9F07) – Byte 1 .................................................................. 181
Table 63 Application Usage Control (Tag 9F07) – Byte 2 .................................................................. 181
Table 64 Cardholder Verification Rule – Byte 1 ................................................................................. 182
Table 65 Cardholder Verification Method Results (Tag 9F34) – Byte 1 ............................................ 183
Table 66 Cardholder Verification Method Results (Tag 9F34) – Byte 2 ............................................ 183
Table 67 Cardholder Verification Method Results (Tag 9F34) – Byte 3 ............................................ 183
Table 68 Card Verification Results – Byte 1....................................................................................... 184
Table 69 Card Verification Results – Byte 2....................................................................................... 184
Table 70 Card Verification Results – Byte 3....................................................................................... 184
Table 71 Card Verification Results – Byte 4....................................................................................... 185
Table 72 Card Verification Results – Byte 5....................................................................................... 185
Table 73 Cryptogram Information Data (Tag 9F27) ........................................................................... 185
Table 74 Terminal Capabilities (Tag 9F33) – Byte 1 .......................................................................... 186
Table 75 Terminal Capabilities (Tag 9F33) – Byte 2 .......................................................................... 186
Table 76 Terminal Capabilities (Tag 9F33) – Byte 3 .......................................................................... 186
Table 77 Additional Terminal Capabilities (Tag 9F40) – Byte 1 ......................................................... 187
Table 78 Additional Terminal Capabilities (Tag 9F40) – Byte 2 ......................................................... 187
Table 79 Additional Terminal Capabilities (Tag 9F40) – Byte 3 ......................................................... 187
Table 80 Additional Terminal Capabilities (Tag 9F40) – Byte 4 ......................................................... 188
Table 81 Additional Terminal Capabilities (Tag 9F40) – Byte 5 ......................................................... 188
Table 82 Terminal Verification Results (Tag 95) – Byte 1 (Offline Data Authentication) ................... 188
Table 83 Terminal Verification Results (Tag 95) – Byte 2 (Processing Restrictions) ........................ 189
Table 84 Terminal Verification Results (Tag 95) – Byte 3 (Cardholder Verification) ......................... 189

Page 16 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 85 Terminal Verification Results (Tag 95) – Byte 4 (Terminal Risk Management) .................. 189
Table 86 Terminal Verification Results (Tag 95) – Byte 5 (Transaction Completion) ........................ 189
Table 87 Transaction Status Indicator (Tag 9B) – Byte 1 .................................................................. 190
Table 88 Transaction Status Indicator (Tag 9B) – Byte 2 .................................................................. 190
Table 89 APPLICATION BLOCK Command Values .......................................................................... 192
Table 90 APPLICATION UNBLOCK Command Values .................................................................... 192
Table 91 CARD BLOCK Command Values ....................................................................................... 193
Table 92 EXTERNAL AUTHENTICATE Command Values ............................................................... 193
Table 93 EXTERNAL AUTHENTICATE Response Codes ................................................................ 193
Table 94 GENERATE AC Command Values ..................................................................................... 194
Table 95 GENERATE AC Reference Control Parameter .................................................................. 194
Table 96 Coding of Cryptogram Information Data ............................................................................. 195
Table 97 GET CHALLENGE Command Values ................................................................................ 195
Table 98 GET DATA Command Values ............................................................................................. 196
Table 99 GET PROCESSING OPTIONS Command Values ............................................................. 196
Table 100 INTERNAL AUTHENTICATE Command Values ................................................................ 197
Table 101 PIN CHANGE/UNBLOCK Command Values ...................................................................... 198
Table 102 READ RECORD Command Values .................................................................................... 199
Table 103 READ RECORD Reference Control Parameter .................................................................. 199
Table 104 SELECT Command Values ................................................................................................. 200
Table 105 SELECT Reference Control Parameter (P1) ...................................................................... 200
Table 106 SELECT Command Options Parameter (P2) ...................................................................... 200
Table 107 SELECT Response Message Data Field (FCI) of the PSE ................................................ 200
Table 108 SELECT Response Message Data Field (FCI) of the DDF ................................................ 201
Table 109 SELECT Response Message Data Field (FCI) of the ADF ................................................ 201
Table 110 VERIFY Command Values .................................................................................................. 202
Table 111 VERIFY Reference Data (P2) ............................................................................................. 202
Table 112 EMV Response Codes (SW1 SW2) .................................................................................... 203
Table 113 Certification Parameters – Amex Credit .............................................................................. 207
Table 114 Certification Parameters – Diners Credit ............................................................................. 208
Table 115 Certification Parameters – Discover Credit ......................................................................... 209
Table 116 Certification Parameters – JCB Credit ................................................................................ 210
Table 117 Certification Parameters – MasterCard Credit .................................................................... 211
Table 118 Certification Parameters – MasterCard Debit ..................................................................... 212
Table 119 Certification Parameters – Visa Credit ................................................................................ 213
Table 120 Certification Parameters – Visa Debit ................................................................................. 214
Table 121 Glossary of Terms ............................................................................................................... 215

Page 17 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 18 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

2. Introduction
This document is the TSYS EMV Implementation Guide specific to Point of Sale environments. This
document is intended for integrators and developers who wish to interface an EMV POS Solution with the
TSYS “Summit” or “Gen2” (referred to in this document as “EIS”) host, to process EMV and contactless
credit and debit card transactions.
This document outlines the guidelines for developing an EMV and contactless capable device:
 Development Process
 EMV Transaction Flow
 Testing and Certification Processes
 EMV Reference Material
 TSYS EMV Requirements
 TSYS EMV Best Practices

2.1 Target Audience

This document is intended for developers, integrators, testers and project managers (generically referred
to in this document as the “Developer”) who are involved in the development of an EMV or contactless
POS Solution that interfaces with the TSYS host. The document is structured such that the early
chapters contain process and high level information applicable to all readers and the later chapters
contain detailed information more applicable to developers.
It is assumed in this document that the reader has a good understanding of POS credit and debit
transaction processing and a general understanding of EMV and contactless smartcard concepts.

2.2 Implementation Guide Overview

This document is intended to provide developers with a set of guidelines for processing EMV transactions
using the EIS or Summit host and includes the rules being used by TSYS to certify EMV POS Solutions.
However, it does not provide information on all EMV regulatory requirements.
This document is intended to be used in conjunction with the following TSYS documents:
 TSYS External Interface Specifications – Authorization Record Formats – EIS 1080
This document describes the request and response authorization record formats for POS
authorization devices using TSYS Acquiring Solution Authorization Services.
 TSYS External Interface Specifications – Data Capture Record Formats – EIS 1081
This document describes the request and response data capture record formats for POS
authorization devices using TSYS Acquiring Solution Authorization Services.
 Host Capture System Summit Gateway Message Format (SGMF) Specification
This document describes the request and response message formats for POS authorization
devices using TSYS Summit host capture host.

Page 19 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

The following documents should be obtained from your PINPad vendor. The names shown are generic
names for the documents as each PINPad vendor will have their own document naming convention:
 The PINPad EMV Kernel Interface document
This document will provide information required to interface your EMV POS Solution with the
PINPad vendor‟s EMV kernel.
 External PINPad API Documentation
This document will provide information required to interface your EMV POS Solution with an
external PINPad using the vendor‟s PINPad API.
This guide is intended to provide the minimum requirements to process EMV transactions. Additionally,
developers should consult other EMV documents that provide additional EMV information useful to
developers. These documents can be obtained directly from the PINPad vendor, EMVCo and the specific
card brands (i.e. Visa, MasterCard, etc.).

2.2.1 EMVCo LLC

EMVCo LLC is the regulator agency originally formed by Europay International, MasterCard International
and Visa International to manage, maintain and enhance the EMV Integrated Circuit Card specification for
Payment Systems. EMVCo is responsible for the EMV type approval process and compliance testing. It
is imperative that developers are familiar with the EMVCo requirements when developing their EMV POS
Solution. Current active EMVCo members are Amex, Discover, JCB, MasterCard, UnionPay and Visa.
This TSYS EMV Implementation Guide provides insight into the EMVCo requirements and outlines the
expected EMV transaction flow. However, because EMV rules differ for each card brand and include
rules specific to the PINPad kernel and related EMV chip interaction, it is not possible to provide all
EMVCo and certification requirements; nor is it possible to ensure this document always reflects the most
current EMVCo requirements. For the most current EMV information and to keep up to date with all EMV
regulatory updates, please refer to the EMVCo web site at www.emvco.com.

2.3 EMV and Contactless Configurations

There are several possible EMV and contactless configurations which can be split into two categories:
Integrated and Standalone.
Integrated solutions generally have an Electronic Cash Register (ECR) directly connected to an external
PINPad which provides the EMV and contactless functionality. The smartcard reader, PIN entry
capability and EMV kernel all reside within the external PINPad. There are three supported integrated
configurations:
 Fully Integrated – The ECR interfaces with the PINPad for EMV functionality only. This solution
gives the ECR developer the most control of the transaction process.
- PCI is in scope for the ECR as the ECR handles the card track data (PCI scope may be
reduced or eliminated if P2PE and tokenization are implemented)
- An EMV certification is required on the complete solution
 Partially Integrated – The ECR interfaces with the PINPad for EMV functionality, and the
PINPad also builds the TSYS authorization message and parses the TSYS response message.
The ECR provides the actual host connectivity and is responsible for transmitting and receiving
host messages and storing the authorization data. This solution reduces the amount of
development required on the ECR as the PINPads builds the authorization message.
- PCI is in scope for the ECR as the ECR handles the card track data (PCI scope may be
reduced or eliminated if P2PE and tokenization are implemented)
Page 20 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

- An EMV certification is required on the complete system

 Semi-Integrated – The ECR interfaces with a PINPad (or terminal) for EMV functionality, and
the PINPad also provides the TSYS host interface and stores the authorization data. This
solution eliminates much of the ECR development as the ECR does not build the authorization
message.
- PCI is not in scope for the ECR as the ECR does not see the card data
- An EMV certification of the complete solution is not required as the PINPad contains the full
payment application

Standalone solutions consist of a POS terminal that utilizes a PINPad to provide the EMV contact and
contactless functionality. The smartcard reader, PIN entry capability and EMV kernel all reside within the
PINPad. There are two supported standalone solutions. Both solutions are within PCI scope and require
a full EMV certification:
 Internal PINPad – The standalone POS terminal includes an internal PINPad that provides EMV
functionality.
 External PINPad – The standalone POS terminal interfaces with an external PINPad that
provides EMV functionality.

Note: Within this document all EMV and contactless configurations are generically referred to as the
“EMV POS Solution” and the customer that is implementing the TSYS EMV POS Solution is referred to
as the “Developer”.

Page 21 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

2.3.1 Fully Integrated ECR Solution

In Fully Integrated mode the ECR application controls the transaction, provides the TSYS host interface
and stores the authorization batch data. The ECR interfaces with an external PINPad for card entry
(swipe / insert / tap) and EMV kernel functionality.

TSYS Host

Fully Integrated ECR External PINPad

MSD Interface Magstripe Magnetic Stripe Reader

PIN Entry Device

EMV Interface EMV Kernel
ICC Reader
ECR EMV POS
Amex ExpressPay
Application Application
Contactless Discover D-PAS
Contactless Interface
Kernel MasterCard PayPass

Visa payWave

Note: For Fully Integrated implementations the ECR is within PCI scope as the ECR can see non-
encrypted card data. An EMV certification of the complete solution is required.

Page 22 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

2.3.2 Partially Integrated ECR Solution

In Partially Integrated mode the ECR application controls the transaction, communicates with the host
and stores the authorization data. The ECR interfaces with an external PINPad for card entry (swipe /
insert / tap) and EMV kernel functionality. In this mode the PINPad is also used to build the host request
messages and parse the host response messages.
Partially Integrated mode is generally used when the ECR wants to control the host interface and see
card data without having to implement the host request and response message logic. This
implementation is ideal for companies with ECR applications that connect to multiple hosts as the ECR
application can remain consistent and just the PINPad logic would need to differ.

TSYS Host

Partially Integrated ECR External PINPad

Host Build Request Msg
Host Msg Interface
Messaging Parse Response Msg

MSD Interface Magstripe Magnetic Stripe Reader

PIN Entry Device

ECR EMV POS EMV Interface EMV Kernel
ICC Reader
Application Application
Amex ExpressPay

Contactless Discover D-PAS

Contactless Interface
Kernel MasterCard PayPass

Visa payWave

Note: For Partially Integrated implementations the ECR is within PCI scope as the ECR can see non-
encrypted card data. An EMV certification of the complete solution is required.

Page 23 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

2.3.3 Semi-Integrated ECR Solution

In Semi-Integrated mode the ECR initiates the transaction and utilizes the external PINPad to provide the
TSYS host interface, to store the authorization data, for card entry (swipe / insert / tap) and to provide
EMV kernel functionality.
In this mode the PINPad interface generally consists of high level commands that are simple to
implement on an ECR. This is ideal for companies with multiple ECR vendors (or types) as most of the
host and EMV functionality is contained within the PINPad, meaning that host and EMV development
would not need to be replicated on each ECR type supported.

Note: For Semi-Integrated implementations the ECR is not within PCI scope as the transaction is
controlled by the external PINPad so the ECR will not see cardholder data. An EMV certification of the
complete solution is not required as the PINPad contains the complete payment application.

Page 24 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

2.3.4 Standalone POS Solution (Internal PINPad)

In this mode a single standalone POS terminal is used that includes an internal PINPad. The POS
terminal contains the POS application and utilizes the EMV kernel residing in the internal PINPad to
provide EMV functionality.
This is often the simplest and most cost effective EMV POS Solution.

TSYS Host

Standalone POS Terminal Internal PINPad

Magstripe Magnetic Stripe Reader

PIN Entry Device

EMV Kernel
ICC Reader

EMV POS Application Amex ExpressPay

Contactless Discover D-PAS

Kernel MasterCard PayPass

Visa payWave

Page 25 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

2.3.5 Standalone POS Solution (External PINPad)

In this mode a standalone POS terminal controls the transaction, provides the TSYS host interface and
stores the authorization batch data. The POS terminal interfaces with an external PINPad for card entry
(swipe / insert / tap) and EMV kernel functionality.
This is a cost effective EMV POS Solution for environments where the merchant and customer cannot
easily share the same device, or if you have an existing terminal base that is not EMV compliant and you
wish to cost effectively add EMV functionality by just adding an EMV certified PINPad.

Page 26 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

2.4 EMV and Contactless Solution Components

All EMV POS Solutions must have the following elements:
1. An EMV capable PINPad that is:
 EMV Level 1 and Level 2 type approved
 PCI PTS approved
 MasterCard TQM (Terminal Quality Management) labeled
 TSYS-approved (i.e. can be injected by TSYS or a TSYS authorized provider, and the
PINPad application has been approved for use by TSYS).
2. A receipt printer (if an attended device)
3. The ability to download EMV parameters. The methods used to manage and download EMV
parameters are the responsibility of the developer. For a list of required EMV parameters, see
section EMV Testing and Certification Parameters (page 207).
4. The ability to download Certificate of Authority (CA) Public Key information. The CA Public Key
file cannot be hardcoded as it will change. For more information on downloading CAPK
information, see section Certificate of Authority Public Key Management (page 101).

2.5 Supported Configurations

There are several modes of operation for EMV POS Solutions. TSYS currently only supports online
authorization with the EMV floor limit set to zero.
The following chart shows the EMV configuration modes and for each mode whether it is supported by
the EIS and Summit hosts.

2.6 EMV Configuration Type

Table 01 EMV Configuration Types
Mode Usage EIS Summit

Transactions are always sent to the host for authorization.

Online Only Yes Yes
Floor Limit processing is not used.

Transactions can be locally authorized, based on Risk

Management processing or sent to the host for authorization.
Online / Offline Yes Yes
If the EMV Floor Limit is set to zero, the EMV POS Solution
will behave like an online-only solution.

Transactions are always locally approved.

Offline Only No No
Generally used for unattended, cardholder activated devices.

The following table shows the EMV Terminal Types and identifies whether they are supported by the
TSYS host.

Page 27 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 02 EMV Configuration Modes – By Terminal Type

Terminal EIS Summit
Environment Operation Modes
Type Host Host
Online Only 11 Yes Yes
Financial
Offline with Online Capabilities 12 Yes Yes
Institutions
Offline Only 13 No No
Attended
Online Only 21 Yes Yes

Merchant Offline with Online Capabilities 22 Yes Yes

Offline Only 23 No No

Online Only 14 Yes Yes

Financial
Offline with Online Capabilities 15 Yes Yes
Institutions
Offline Only 16 No No
Unattended
Online Only 24 Yes Yes

Merchant Offline with Online Capabilities 25 Yes Yes

Offline Only 26 No No

Note: The Terminal Type (Tag 9F35), Terminal Capabilities (Tag 9F33) and Additional Terminal
Capabilities (Tag 9F40) tags are used to set and identify the current EMV kernel configuration.

2.7 U.S. Debit

To meet the requirements of the Durbin amendment to the Dodd–Frank Wall Street Reform and
Consumer Protection Act (“Durbin regulations”), to enable merchants or acquirers to choose to route
transactions from debit and prepaid card programs via unaffiliated networks, Visa and MasterCard have
introduced the following AIDs (commonly referred to as the “U.S. Common Debit AIDs”).

Table 03 U.S. Common Debit AIDs

Brand Scheme AID

MasterCard US Maestro A0000000042203

Visa Visa Common Debit A0000000980840

In addition to Visa and MasterCard, the DNA (Debit Network Alliance) and other individual debit networks
may offer their own U.S. Debit AIDs that will only reside on non-Visa and non-MasterCard branded cards.
On the release date of this guide, only the Visa and MasterCard AIDs are supported.
Visa or MasterCard branded chip cards issued in the U.S. under debit and prepaid card programs, will
support both a U.S. Common Debit AID and a Global Debit AID (either the standard Visa AID, the
standard MasterCard AID or the Maestro AID).
 If a Global Debit AID (Visa, MasterCard or Global Maestro) is used to initiate the chip transaction, the
transaction must be routed via a Visa or MasterCard network only. The network used is based on the
AID selected.
 If a U.S. Common Debit AID is used to initiate the chip transaction, the transaction may also be routed
Page 28 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

via unaffiliated networks that have executed the necessary access agreement with Visa or
MasterCard.
For both contact and contactless transactions, EMV POS Solutions should use the standard Application
Selection process described for EMV transactions. However, the merchant may filter the Candidate List to
remove multiple AIDs which access the same underlying funding account. EMV POS Solutions must not
assume that if a U.S. Common Debit AID is present that this AID can be automatically selected to the
exclusion of all other AIDs on the card as those AIDs may relate to alternative products which the
cardholder wishes to use (such as a credit product which is issued together with a debit product).
All AIDs which relate to debit or prepaid programs will be identified in the data read during Application
Selection. The presence of both of the following data elements identifies the AID as relating to a U.S.
Debit or prepaid program:
 Issuer Country Code (Tag 5F55) - Two alpha characters with a value of 0x5553 (“US”)
 Issuer Identification Number (Tag 42) - Contains the Bank Identification Number (BIN)

There are four possible situations that must be handled:

1. The card has two or more AIDs where these data elements are present and the values of the
Issuer Identification Number (IIN) are the same (Scenario One below):
- The EMV POS Solution may assume that the AIDs with the same IIN access the same
underlying funding account and can eliminate all but one of those AIDs from the Candidate
List.
- When these are the only AIDs present in the card, the EMV POS Solution may automatically
select the remaining AID in the Candidate List.
2. The card has two or more AIDs where these data elements are present and the values of the
Issuer Identification Number (IIN) are the same. There are also one or more other AID(s) present
on the card that have a different IIN or the IIN is not present (Scenario Two below):
- The EMV POS Solution may assume that the AIDs with the same IIN access the same
underlying funding account and can eliminate all but one of those AIDs from the Candidate
List.
- For contact transactions the EMV POS Solution must present the remaining Candidate List
choices to the cardholder in accordance with Final Selection processing.
- For contactless transactions, the EMV POS Solution should automatically select the AID in
the Candidate List with the highest Application Priority Indicator (Tag 87).
3. When a card has two or more groups of AIDs where these data elements are present and each
group has two or more AIDs with the same IIN (Scenario Three below):
- For each group of AIDs with the same IIN, the EMV POS Solution may assume the AIDs
access the same underlying funding account and can eliminate all but one those AIDs from
the Candidate List - leaving only one AID for each IIN.
- For contact transactions the EMV POS Solution must present the remaining Candidate List
choices to the cardholder in accordance with Final Selection processing.
- For contactless transactions, the EMV POS Solution should automatically select the AID in
the Candidate List with the highest Application Priority Indicator (Tag 87).
4. When a card has multiple AIDs where these data elements are present and all AIDs have the
same IIN, and there are also multiple U.S. Common Debit AIDs present (Scenario Four below):
- The EMV POS Solution should assume that each U.S. Common Debit AID relates to a
different underlying funding account.
- The EMV POS Solution should eliminate either of the following from the Candidate List:

Page 29 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

 All of the U.S. Common Debit AIDs

 All of the Global Debit AIDs
- For contact transactions the EMV POS Solution must present the remaining Candidate List
choices to the cardholder in accordance with Final Selection processing.
- For contactless transactions, the EMV POS Solution should automatically select the AID in
the Candidate List with the highest Application Priority Indicator (Tag 87).

Table 04 U.S. Common Debit Scenarios

Country Code IIN Candidate List
Scenario AID
Tag 5F55 Tag 42 Processing Options
One Card accesses single debit funding account

Merchant may decide which AID to select

Global Debit based on the routing choice they want:
A00000000X1010 US XX0000
AID o Global Debit AID – may only be
routed to either Visa or MasterCard
(any supported CVM may be used).
o U.S. Common Debit AID – may be
U.S. Common routed to any of the supported debit
A00000000XXXXX US XX0000
Debit AID networks (any supported CVM may
be used).
Two Combo card accessing a credit account and a single funding debit account

Global Credit Global Credit AID will remain in the

A00000000X1010AA01
AID Candidate List for cardholder selection.

Merchant should decide on either the

Global Debit AID or the U.S. Common
Global Debit
A00000000X1010AA02 US XX0000 Debit AID based on the routing choice they
AID
want:
o Global Debit AID – may only be
routed to either Visa or MasterCard
(any supported CVM may be used).
U.S. Common o U.S. Common Debit AID – may be
A00000000XXXXX US XX0000
Debit AID routed to any of the supported debit
networks (any supported CVM may
be used).
Three Card accesses two debit funding accounts, Accounts have different IINs

Merchant should choose either the Global

Debit AID 1 or the U.S. Common Debit AID
Global Debit
A00000000X1010AA01 US XX0000 1 based on the routing choice they want:
AID 1
o Global Debit AID 1 – may only be
routed to either Visa or MasterCard
(any supported CVM may be used).
o U.S. Common Debit AID 1 – may
U.S. Common be routed to any of the supported
A00000000XXXXXAA01 US XX0000
Debit AID 1 debit networks (any supported
CVM may be used).

Page 30 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Country Code IIN Candidate List

Scenario AID
Tag 5F55 Tag 42 Processing Options
Merchant should choose either the Global
Debit AID 2 or the U.S. Common Debit AID
Global Debit
A00000000X1010AA02 US XY9999 2 based on the routing choice they want:
AID 2
o Global Debit AID 2 – may only be
routed to either Visa or MasterCard
(any supported CVM may be used).
o U.S. Common Debit AID 2 – may
U.S. Common
A00000000XXXXXAA02 US XY9999 be routed to any of the supported
Debit AID 2
debit networks (any supported
CVM may be used).
Four Card accesses two debit funding accounts, Accounts have same IINs

Global Debit Merchant should choose either Global

A00000000X1010AA01 US XX0000 Debit AID 1 and Global Debit AID 2 or U.S.
AID 1
Common Debit AID 1 and U.S. Common
Debit AID 2 based on the routing choice
U.S. Common
A00000000XXXXXAA01 US XX0000 they want:
Debit AID 1
o Global Debit AID 1 and Global
Debit AID 2 – may only be routed to
Global Debit either Visa or MasterCard (any
A00000000X1010AA02 US XX0000
AID 2 supported CVM may be used).
o U.S. Common Debit AID 1 and U.S.
Common Debit AID 2 – may be
U.S. Common routed to any of the supported debit
A00000000XXXXXAA02 US XX0000
Debit AID 2 networks (any supported CVM may
be used).

For each of the scenarios described above, the method used by the EMV POS Solution to identify the
AID(s) to eliminate from the Candidate List is described in more detail in section 8.5.2.

Note: It is not advisable to use legacy processes, such as Credit/Debit option buttons when migrating
to EMV. The method used to eliminate AIDs from the Candidate List is described in more detail in the
Credit / Debit Selection and U.S. Debit Processing section (page 73).

BP 00300 U.S. Debit selection method should be configurable

 It is recommended that the U.S. Debit identification method be configurable to support changes
in merchant and acquirer preferences.

Page 31 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

2.8 EMV and Contactless Migration

The U.S. payment industry is migrating to EMV. All existing non-EMV applications, at some point, should
be upgraded to support EMV. All industry payment partners are committed to this migration.
The migration to EMV is expected to take some time and as a result the requirements for processing
magnetic stripe transactions are not expected to be completely replaced in the near future. Hence, it is
necessary for EMV solutions to continue to support magnetic stripe capabilities until such time as the
market reaches a critical mass of chip cards and the use of magstripe is no longer permitted.

RQ 00100 All EMV POS Solutions must support MSR transactions

 The EMV and contactless migration will take time. Magstripe only cards and fallback support
will be required for the foreseeable future. Therefore, all EMV POS Solutions being certified by
TSYS must continue to support MSR transactions.

Page 32 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

3. Development Process
Developers should be aware that developing an EMV POS Solution is a much more difficult and time
consuming process than developing a non-EMV solution. EMV POS Solutions are more complex and are
subject to an extended and more rigorous certification process which, in addition to the standard TSYS
certification, includes certification by the card brands and a mandatory pilot.

IT IS IMPORTANT THAT YOUR DEVELOPMENT TIMELINES REFLECT THE DEVELOPMENT COMPLEXITY

AND THE ADDITIONAL TIME REQUIRED TO COMPLETE THE CERTIFICATION PROCESS.

Note: TSYS charges to certify an EMV POS Solution. The actual cost will vary depending on the
complexity of your implementation. Contact your Implementation Manager to determine the actual cost
to certify your solution.

The following table outlines the steps that must be completed when developing an EMV POS Solution
with TSYS.

Table 05 Development and Certification Process

Step Process

1. Register on the TSYS www.TSYSPartnerPortal.com

Partner Portal o Sign the NDA
o Provide name, address and market information

2. TSYS Implementation TSYS will assign an Implementation Manager to your project. The
Manager Assigned Implementation Manager will send you an introductory email including:
o Information related to completing the TSYS Project Intake Document
(required to define your project)
o Host connection and support information:
 Developer ID Number
 Merchant ID Number
 BIN
 Agent #
 Chain #
 Store #
 Terminal Number
 Category Code
 Terminal ID Number
 Test Analyst Assigned (name / email / phone)
 General Lab Information (email / phone)
o TSYS EMV Implementation Guide (this document)

3. Complete Intake Document Developer completes the TSYS Intake document and returns it to their TSYS
Implementation Manager.

Page 33 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

4. Configuration Review Your TSYS Implementation Manager will review the completed Intake
document to ensure the proposed configuration is understood and supported
by TSYS. You will be notified if your configuration is accepted or if TSYS has
any questions or concerns.
Once completed you will be sent the TSYS EMV Test Plan including:
o TSYS certification scripts (MSR, EMV and contactless)
o MasterCard M-TIP questionnaire

5. Training EMV and contactless projects are much more complex than standard
magstripe applications. First time EMV POS Solution developers and testers
should undergo EMV training prior to beginning an EMV project.

6. Certification Test Tools The developer can purchase the Collis Merchant Test Suite (MTS) which
includes the Brand Test Tool (BTT) software that will be used for testing, TSYS
certification and card brand certification. TSYS uses this tool internally and if
the developer is using the same tool, issues may be resolved in a more timely
manner.
For more information on the Collis Merchant Test Suite and BTT software see
page 40.
Order forms for the Collis Merchant Test Suite can be obtained from the TSYS
Partner Portal www.TSYSPartnerPortal.com.

7. Development The developer begins development of the EMV POS Solution that includes
EMV and non-EMV functionality.

8. Testing During development the developer tests against the TSYS Certification and
Testing Service platform.
For more information about this test platform see page Error! Bookmark not
defined.. If you require additional information, contact your Implementation
Manager.

9. Certification Scheduling The developer notifies their TSYS Implementation Manager to schedule the
start of certification.
Make sure you‟re ready for certification. The certification process is rigorous
and time consuming. It‟s generally best if you perform your own pre-
certification by running all of the TSYS and card brand test cases before
scheduling certification.
TSYS recommends that you schedule certification three (3) months in
advance.

10. Certification Preparation The TSYS Implementation Manager will co-ordinate the EMV certification
process with you and will provide any required host connectivity and
scheduling information.

11. Certification The developer certifies the EMV POS Solution with the assistance of their
TSYS Implementation Manager.

Page 34 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

12. Certification Review The developer submits all certification results (test case results, M-TIP
questionnaire, receipts etc.) required by TSYS and the card brands. Once
received the TSYS Implementation Manager will:
o Review the certification results to determine if the EMV POS Solution
has successfully completed all testing
o Submit the brand certification test results to the card brands for brand
approval
If any certification tests have failed, part or all of the Certification will have to be
repeated.

13. Pilot Once certification has been successfully completed, the EMV POS Solution
must be piloted in a limited number of locations before beginning a full rollout.
Once the TSYS pilot criteria has been met, the Implementation Manager will
send an email informing you that the pilot has been successfully completed
and a Live rollout may begin.
Note: It is possible that MasterCard will also require that your EMV POS
Solution undergo MasterCard End-To-End Demonstration (ETED) testing. If
required, this must be completed to MasterCard‟s satisfaction during the pilot
before a full rollout may begin.

14. Live A full rollout of the EMV POS Solution may begin.

15. Rollout Complete Keep up to date on the status of your EMV hardware and kernel certifications.
EMV POS Solutions are not certified forever. It may be necessary to re-certify
due to expiring certifications or regulatory changes.

3.1 Configuration Review

Once you have identified the EMV configuration you wish to implement, it is important that it be reviewed
by the TSYS to ensure that it is a valid, supportable EMV configuration that meets TSYS requirements.
This is done by completing the TSYS EMV Intake document which can be downloaded from the TSYS
Partner Portal (www.TSYSPartnerPortal.com/IntakeDocument)
Once you have completed the TSYS EMV Intake document return it to your Implementation Manager for
review. You will be notified if the submitted document is acceptable or if a technical walkthrough is
required.
As part of this review you will be required to provide the following hardware vendors certification letters.
These letters can generally be obtained from your hardware vendor.

Table 06 Vendor Certification Documents

Document Expires After
EMVCo EMV Level 1 Letter of Approval 4 Years

EMVCo EMV Level 2 Letter of Approval 3 Years

EMVCo Contactless Level 1 Letter of Approval 4 Years

Brand Contactless Level 2 Letters of Approval

Typically 2 years after date of approval
(one per supported brand)

MasterCard TQM Letter NA

Page 35 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Document Expires After

PCI PTS certification expiry is dependent on the
PCI PTS Certification Letter PTS version the device was certified under.
Note: PTS 1.0 devices are no longer supported

RQ 00200 A Configuration Review is required before development begins

 The Configuration Review process must be completed prior to beginning development.

Failure to do so may result in additional development and extended timelines if TSYS does
not approve your proposed configuration.

RQ 00300 Multiple certifications required if multiple kernel configurations supported

 If your EMV POS Solutions supports more than one kernel configuration, multiple card brand
certifications are required. One for each kernel configuration supported.

RQ 00400 EMV certification letters must be current

 EMV certification letters must be current and not about to expire. TSYS will not certify a
device if any of the certification letters is scheduled to expire within six (6) months of the date
of certification.

3.2 Training
It is important that everyone involved in the development and testing of an EMV project receive EMV
training before beginning an EMV project. This is considered critical as EMV and contactless solutions
are much more complex than traditional magstripe solutions. Beginning EMV projects without proper
training often leads to extended project timelines and certification issues that can result in extensive re-
development to resolve.
There are several sources available where this training may be obtained:
 www.emv-connection.com
 www.smartcardalliance.org
 www.b2ps.com/education
 www.ul-ts.com/elearning

BP 00400 EMV training is recommended

 TSYS highly recommends that everyone involved in an EMV development project get training
before beginning the project.

3.3 Technical Support

The intent of this document is to provide developers who are familiar with EMV practices the necessary
information to be self-supporting when developing their EMV POS Solution. Your TSYS Implementation
Manager can provide some additional EMV implementation information and recommendations. However,

Page 36 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

TSYS cannot provide low level EMV, contactless or PINPad kernel integration support. It is up to the
developer to obtain this information from other sources.
 EMV requirements and guidelines can be obtained from the EMVCo website www.emvco.com.
 For PINPad kernel technical support refer to the PINPad vendor‟s documentation or contact the
PINPad vendor to inquire about PINPad integration training.
 There are external EMV technical support resources that can be utilized. Please note that these
are not TSYS services and are available at an additional cost.

3.4 Testing and Certification

TSYS requires a full certification of all EMV, contactless and traditional magnetic stripe transactions
before an EMV POS Solution will be approved for pilot in a limited number of live merchant sites. The
certification duration is dependent on the complexity of the EMV POS Solution and the quality of the
implementation. If the EMV POS Solution fails certification at any point, the entire certification process
may have to be repeated.
Please note that the EMV certification process involves completing a TSYS certification and then
completing a card brand certification for every EMV card brand supported and every kernel configuration
supported. This is an extremely rigorous process and much more time consuming than the traditional
non-EMV certification process. This additional complexity should be accounted for in your project
implementation timelines.
The TSYS certification process cannot begin until the EMV POS Solution development has been
completed.
The TSYS certification process is performed as per the following steps. All steps must be completed
before certification will be considered complete and a limited pilot may begin.

Table 07 Testing and Certification Process

Step Certification Process

1. Pre-Certification The developer tests the EMV POS Solution to ensure it connects to the TSYS host
and performs all implemented transactions. This includes testing EMV,
contactless and non-EMV transactions.
o Receipts and host messages should be checked to ensure they conform to
the best practices and requirements outlined in this document.
o The developer provides test results to TSYS for validation, along with the
receipts generated during testing.

2. Class B Certification The developer runs the TSYS Class B certification scripts that test non-EMV, EMV
and contactless transactions.
o When complete, forward the test script results, along with any required
receipts, to TSYS for verification.

Page 37 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

3. Brand Certification The developer uses the Collis Brand Test Tool to execute test cases required by
each of the brands supported.
Brand EMV Suite Contactless Suite
Amex AEIPS ExpressPay
Discover/Diners D-PAS
MasterCard M-TIP M-TIP
JCB TCI
Visa ADVT CDET
qVSDC (required for contactless-only
device certifications)

4. Card Brand The developer will submit the card brand testing results to TSYS for review and
Certification Results submission to the card brands:
o Collis Brand Test Tool test case results
o Completed M-TIP questionnaire
o Receipts
o Sample Reports

5. Card Brand TSYS will ensure all card brand test cases have been completed satisfactorily and
Submission will submit the results to the card brands for brand approval.
This process takes 10 – 15 days to complete per kernel configuration supported.

If you have questions or require more detailed information related to the TSYS EMV certification process
please contact your Implementation Manager.

BP 00500 Budget adequate time for certification

EMV POS Solutions require much more time to certify than traditional magstripe solutions.
 Please ensure that you budget sufficient time to complete the certification cycle. Certification is
a multi-month process that will vary based on the complexity of the implementation and the
number of card brands being certified.

RQ 00500 qVSDC certification is required for contactless-only EMV POS Solutions

A qVSDC certification must be completed when implementing a Visa contactless-only EMV
 POS Solution.
This is in addition to the CDET certification that must be completed for all contactless Visa
implementations.

3.5 Pilot Requirements

Once the EMV POS Solution has completed certification, a pilot must be run at a few locations for several
weeks to ensure the EMV POS Solution functions properly in a live environment. During this time the
pilot will be monitored by both TSYS and the merchant.

Page 38 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

In addition to the TSYS pilot requirements MasterCard will sometimes require that End-To-End
Demonstration (ETED) testing be performed at the first pilot site. If this is required, a MasterCard
representative will go to the pilot site to perform live EMV transactions and to analyze the results.
The exact TSYS pilot completion requirements may vary based on the EMV POS Solution being
implemented. In most cases they will be as follows (please contact your TSYS Implementation Manager
to confirm your exact pilot criteria):
 Pilot will be run in 2-3 locations
 Pilot will be considered complete when both of the following conditions have been met:
- The pilot has either been running for three (3) months or 30 EMV transactions have been
successfully processed and settled
- All MasterCard mandated ETED pilot requirements have been completed to MasterCard‟s
satisfaction
When TSYS determines that all pilot completion criteria has been met, a pilot completion email will be
sent informing you that your EMV POS Solution pilot has been completed and that a live rollout may
begin.

3.6 Production Notification

There are a number of reasons that a deployed EMV POS Solution may need updated and recertified
after it has been rolled out:
 Changes to required EMV parameters
 Changes to CAPK keys
 Expiring certifications (hardware or software)
 Interoperability issues
It is your responsibility to ensure your solution conforms to all card brand and regulatory requirements.
The EMV Migration Forum www.emv-connection.com has relevant information that can assist in this
effort.
Whenever possible, TSYS will contact you when a re-certification is required. The TSYS notification will
include the reason the update is required, the corrective action required and the timeline to implement the
changes.

BP 00600 Respond quickly when notified of recertification requirements

Act quickly when you are notified by TSYS, or become aware, that your EMV POS Solution
 must be updated to meet new regulatory requirements.
When regulatory changes are mandated many deployed solutions will require recertification
and the TSYS certification queue will fill quickly.

3.7 Development Host Connection Information

During the development it will be necessary to send online EMV transactions to the TSYS host (or host
simulator). You should have received a welcome email with your specific host access information
(Developer ID Number, Merchant ID Number, BIN, Agent #, Chain #, Store #, Terminal Number, Category

Page 39 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Code and Terminal ID Number). You should have also received the name, email address and phone
number of the Test Analyst assigned to your project.
If you do not received your host access information or are unable to contact your assigned Test Analyst,
you can contact Developer Services by email or phone:

Table 08 Developer Services Contact Information

Email Phone Number
TSYS Developer Services [email protected] 1-888-959-2017

3.8
EMV and Contactless Test Tool Requirements
Before implementing an EMV POS Solution you will need to obtain a certification test tool. These test
tools include EMV card simulators and physical “fallback” cards that can be used for testing, certification
and card brand certification. B2 and UL Transaction Security (UL-TS formally known as Collis) together
can deliver a comprehensive set of testing products that can support all of your EMV, contactless and
mobile needs.

3.8.1 Collis Merchant Test Suite

The Collis Merchant Test Suite (MTS) is a fully-equipped hardware and software suite that provides
merchants, acquirers, processors and acceptance device vendors with the tools necessary to validate
their EMV configurations, and to run all of the major card brand certification test suites.
The Collis MTS supports both Point of Sale (POS) terminals and
Automated Teller Machines (ATM), and includes detailed scripts that
guide the user through the testing process, eliminating much of the
complexity and confusion associated with EMV and contactless brand
certifications.
The Collis MTS comes with all of the hardware and software required for
contact and contactless EMV certifications and it includes a robust
carrying case so the complete MTS kit can be easily taken to wherever
you need it.
The Collis Merchant Test Suite includes two unique boxes (SmartLink™
and SmartWave™) to emulate both contact and contactless cards. The
MTS software provides true card simulation by emulating all the functions
of actual EMV and contactless cards.

Collis MTS Software:

 Collis Brand Test Tool (BTT) – Supports all major U.S. card brand contact and contactless
certification test scripts, and it not only guides you through the certification process, it also tells
you if each test case passed or failed. Once certification testing is complete, the BTT allows you
to extract all information and reports required for card brand submission.
 Collis Card Simulator – Simulates physical contact and contactless EMV cards allowing
developers to perform ad hoc testing. Developers and testers can also alter existing simulated
card profiles or create their own to test specific EMV conditions.
 Collis Card Spy – Inspects, measures performance and reports on the flow of data between
the EMV chip (contact and contactless interfaces) and acceptance devices such as terminals and

Page 40 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

PINPads.
All of the Collis MTS software applications provide a comprehensive interface that displays and
interprets all of the commands being passed between an EMV capable device and the EMV chip
card. This information is invaluable to developers and testers when debugging EMV applications.

Collis MTS Hardware:

 SmartLink™ Box – Physical box and probe used for
contact EMV testing
 SmartWave™ Box – Physical box and contactless
probe used for contactless EMV testing
 Magstripe Test Cards – Physical cards used to
perform Fallback card swipes
 License Dongle – Secures access to the software and
allows the Collis MTS tobe run on any PC
All necessary accessories such as cables, probes, power supplies are included.

The real key to the Collis MTS is the Collis Brand Test Tool (BTT) software. Using the Collis BTT
software you can test EMV devices within the environment in which they will be operated, and test them
using the actual brand settings that will be used for development, certification and production.
The BTT software produces reports that can be used for local examination and documentation of the test
cases. The reports can also be easily exchanged with other parties involved in the certification process.
Using the BTT software results in a more robust, repeatable and well-documented development
environment which leads to a contact and contactless-compliant, brand-certified payment device that can
perform trouble-free EMV transactions within the payment infrastructure.
The BTT is constantly being improved and upgraded to keep up with the latest brand certification
requirements. It currently supports the following certification suites:
 Visa ADVT, qVSDC, CDET, payWave™
 MasterCard M-TIP, PayPass™
 Amex AEIPS
 Discover D-PAS
 Diners
 JCB TCI
 Interac Flash™

Collis is constantly updating their products to add functionality, improve their usability and to keep pace
with ever changing card brand certification requirements. The Collis product roadmap can be found at:
Collis Product Roadmap.

For more information on the Collis MTS visit www.b2ps.com or email [email protected].

Page 41 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

3.9 Integration Validation Test Cards

A full certification may not be required when certifying solutions that integrate to a pre-certified
middleware product or when implementing a semi-integrated solution. In some cases TSYS will only
require the developer to execute a small number of test cases using either the Collis Brand Test Tool or
physical cards. For this purpose physical cards are significantly less expensive than purchasing the
Collis Brand Test Tool.

Note: Physical test cards can also be very useful for development testing, training and demonstration
purposes as multiple sets of cards are often required and physical cards are the most economical
solution.

Physical cards can be purchased using the order form on the TSYS partner portal.

3.10 Card Brand Certification

During the card brand certification phase it will be necessary to send online EMV transactions to the host
while attached to EMV card brand simulators. This must be scheduled with your Implementation
Manager to ensure TSYS is aware of the certification, to ensure the EMV POS Solution is connecting to
the correct environment and that the environment is properly configured for brand certification.

Note: Card brand certification requires connecting to a different URL than used for other testing.
Contact your Implementation Manager to obtain the correct URL and port information.

Page 42 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

4. EMV Overview

4.1 EMV Benefits

EMV is an international payment system standard for the use of an integrated chip card. Because EMV
utilizes a smart card chip, EMV card transactions, depending on how the Issuer personalized the card,
can be processed either online or offline and validated using NO CVM, Signature or PIN.
EMV provides several significant benefits:
 Counterfeiting and skimming of cards is more difficult than with existing magnetic stripe cards
 Lost & stolen cards can‟t be used as EMV cards if the card requires a PIN to be used
successfully
 Transactions can be approved offline depending on how the issuer personalized the card
parameters and whether offline approvals are supported by the payment processor (not currently
supported by TSYS)

4.2 Online vs. Offline EMV Transactions

When authorizing an EMV transaction, the transaction must first be sent to the card for an authorization
decision. The card has three options; approve the transaction, decline the transaction or request the
transaction be sent to the issuer‟s host for authorization. If the EMV chip approves or declines the
transaction, it is considered an “Offline” transaction. If the EMV chip requests the transaction be sent to
the issuer‟s host for authorization, it is considered an “Online” transaction.
The card makes the final authorization decision for all online and offline full EMV transactions (e.g.
Purchase). Even if a transaction is sent for online authorization the issuer authorization decision returned
must be sent back to the card for a final authorization decision by the card.

RQ 00600 Transactions must go online for issuer authorization

 TSYS does not support offline card approvals. All transactions must go online to the TSYS
host for issuer authorization.

4.3 EMV Smart Card Schemes

The EMV references in this document are based on the EMV 4.3 specification.

4.4 EMV Transaction Set

EMV POS Solutions can perform a combination of EMV and non-EMV transactions. In general terms,
“Full” EMV transactions are Purchase transactions where the EMV chip participates in the authorization
decision. Other transactions such as credit Refunds and Reversals are generally implemented as
“Partial” EMV transactions as they are performed the same as magstripe transactions with the exception
that the Track 2 data is read from the chip rather than from the magstripe.
 Full EMV Transaction – EMV chip is used to read card data and the chip participates in the
authorization decision

Page 43 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

 Partial EMV Transaction – EMV chip is used to read card data but, the chip does not participate
in the authorization decision (referred to as non-EMV transactions that use EMV functionality)

Table 09 Full vs. Partial EMV Transaction Steps

Full Partial
EMV Transaction Step Comment
EMV EMV
Transaction Initiation Y Y
Card Presentation Y Y Card is inserted or tapped
Application Selection Y Y
Read Card Data Y Y
Offline Data Authentication Y N
Processing Restrictions Y N
Cardholder Verification Y N
Terminal Risk Management Y N
1
1st Generate AC Y Y Includes Terminal Action Analysis and Card Action Analysis
Online Processing Y N
Y Some cards do not support this step as they include the
Issuer Authentication Data as part of 2nd Generate AC (in
External Authenticate N
CDOL 2 (Tag 8D) – when the AIP is set to support Issuer
Authentication (Tag 82 Byte1 bit 3))
Script Processing (Tag 71) Y N Executes Tag 71 script commands
Y Some cards include the Issuer Authentication Data as part of
2nd Generate AC N the 2nd Generate AC (in CDOL 2 (Tag 8D) - when the AIP is
not set to support Issuer Authentication (Tag 82 Byte1 bit 3))
Script Processing (Tag 72) Y N Executes Tag 72 script commands
Card Removal Prompt Y Y

Notes:
1. Partial EMV transactions request an AAC at the 1st Generate AC to terminate the card usage.

For information relating to the Full EMV and Partial EMV transaction flow see page 52.

4.4.1 EMV Credit Transaction Set

The following table lists the EMV credit transactions supported by TSYS and indicates how they should
utilize the EMV chip.

Table 10 EMV Credit Transaction Set

EIS Summit Transaction Store EMV
Transaction EMV Chip Usage 1
Tran Code Tran Code Authorized By Cryptogram
Purchase Online 54 10 Issuer Full Required
2
Return 13 POS Partial N/A
2
Offline Authorization 19 POS Partial N/A
Tip Adjustment 102 POS Partial or None N/A
3
AFD Pre-Authorization 5C Issuer Full Required
4 5
AFD Completion 54 POS Partial or None Required

Page 44 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

EIS Summit Transaction Store EMV

Transaction EMV Chip Usage 1
Tran Code Tran Code Authorized By Cryptogram
Incremental Authorization 2
59 Issuer Partial N/A
(Card Present)
Incremental Authorization
5A Issuer None N/A
(Card Not Present)
6
Purchase Reversal 58 103 POS Partial or None N/A
Refund (reversal after 2
5L POS Partial N/A
batch settlement)
7
Card Authentication Issuer Full Optional
Balance Inquiry 14 Issuer Full Optional

Notes:
1. Column indicates if the final EMV cryptogram (TC – Transaction Certificate) should be stored with an
approved transaction.
2. The EMV chip is only used to obtain the card PAN.
3. The EMV cryptogram will be required when performing the Pre-Authorization Completion.
4. The card must be presented if the Pre-Authorization transaction did not store the PAN.
5. The final Pre-Authorization cryptogram is used for the Pre-Authorization Completion.
6. The original transaction PAN is read from the transaction database. If desired that card may also be used to
validate that the cardholder is present by comparing the original PAN to the card PAN.
7. Cryptogram must be stored if the Card Authentication transaction will ever be completed. If the transaction
will not be completed, the cryptogram does not need to be stored.

4.4.2 EMV Debit Transaction Set

The following table lists the EMV debit transactions and indicates how the transaction should utilize the
EMV chip.

Table 11 EMV Debit Transaction Set

EIS Summit Transaction Store EMV
Transaction EMV Chip Usage 1
Tran Code Tran Code Authorized By Cryptogram
Purchase 93 10 Issuer Full Required
Bill Payment 9B Issuer Full Required
PINLess Bill Payment 9C Issuer Full Required
Purchase Reversal A3 103 Issuer Partial or None Optional
Refund 94 13 Issuer Full Optional
Refund Reversal A4 103 Issuer Partial or None Optional
Balance Inquiry 9A 14 Issuer Partial Optional

Notes:
1. Column indicates if the final EMV cryptogram (TC – Transaction Certificate) should be stored with an
approved transaction.

Page 45 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

4.5 Transaction Processing

The following sections identify EMV transaction specific processing rules.

4.5.1 Purchase Transactions

Credit and debit Purchase transactions are processed as Full EMV transactions.

RQ 00700 Purchase transactions must be processed as Full EMV transactions

 All credit and debit Purchase transactions must follow the Full EMV transaction flow and the
cryptogram requested at the 2nd Generate AC must be based on the issuer authorization
decision.

4.5.2 Pre-Authorizations and Incremental Authorizations

Pre-Authorizations are Full EMV transactions performed with the cardholder present.
Incremental Authorizations are required when a transaction amount exceeds the original authorization
limits. Incremental authorizations are not EMV transactions and do not require chip data.

RQ 00800 AFD Pre-Authorizations must be processed as Full EMV transactions

 Automated Fuel Dispenser (AFD) Pre-Authorization transactions must follow the Full EMV
transaction flow and the cryptogram requested at the 2nd Generate AC must be based on the
issuer authorization decision.

RQ 00900 Incremental Authorizations must be sent as keyed transactions

 Incremental authorizations must be sent to the host in keyed format. They must not include
any other card data obtained from the original Pre-Authorization transaction.

4.5.3 Completions

Completions are Partial EMV transactions that use EMV data from the original Pre-Authorization
transaction. The cardholder does not need to be present when the Completion is performed.

RQ 01000 Completions require Pre-Authorization chip data

The Completion transaction must include all chip data from the original Pre-Authorization
 transaction including the final Pre-Authorization cryptogram.
The POS Entry Mode value sent in the host message must indicate that the card information
was read from the chip.

Page 46 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

4.5.4 Refunds

The Refund transaction processing differs depending on the type of refund being performed.

RQ 01100 Credit Refunds must be Partial EMV transactions

 Credit Refund transactions must follow the Partial EMV transaction flow and request a decline
(AAC) at the 1st Generate AC to terminate the card interaction.

RQ 01200 Debit Refunds must be Full EMV transactions

 Debit Refund transactions must follow the Full EMV transaction flow and the cryptogram
requested at the 2nd Generate AC must be based on the issuer authorization decision.

4.5.5 Quick Service Transactions (QSR, QPS, FPS)

For traditional magstripe Quick Service Transactions receipt printing is optional if the transaction amount
is below the “no signature floor limit”. However, “no signature floor limit” processing does not apply to Full
EMV transactions. EMV transactions must follow CVM processing rules for determining if a signature or
PIN is required.
Quick Service Restaurants may wish to have a floor limit under which NO CVM is used and over which a
Signature or PIN CVM is used. To do this multiple selectable kernel configurations must be implemented.
One kernel configuration would include a standard configuration supporting multiple CVMs (i.e. PIN,
Signature and/or NO CVM) and the other would support only the NO CVM option. The kernel
configuration to be used for each transaction would be selected by the EMV POS Solution based on the
transaction amount.

Note: EMV POS Solutions that implement a selectable kernel configuration must undergo multiple
EMV card brand certifications. One certification for each kernel configuration supported.

RQ 01300 CVM processing must be performed for QSR transactions


Cardholder Verification Method (CVM) processing must be performed for EMV QSR
transactions. If a Signature CVM is selected, a receipt must be printed regardless of the
transaction amount. Using a selectable kernel configuration will allow for the transaction to use
a NO CVM kernel configuration, in which case, no receipt is required.

4.5.6 Currency Conversion (CC)

Currency Conversion allows cardholders to have the transaction amount converted to an alternate
currency rather than using the merchant currency.
Currency Conversion is supported for EMV transactions as long as the currency is selected before
performing the 1st Generate AC and the TSYS host request message reflects the chosen currency.

Page 47 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

BP 00800 Use the Application Currency Code (Tag 9F42) to determine CC eligibility
 The Application Currency Code (Tag 9F42) should be used to determine if the card is eligible
for Currency Conversion.

RQ 01400 Transaction Currency Code (Tag 5F2A) must be set to CC currency

 The Transaction Currency Code (Tag 5F2A) must be set to the selected currency before
performing the 1st Generate AC.

RQ 01500 Transaction amounts must be converted to selected currency

 The Transaction Amount (Tag 9F02) and Other Amount (Tag 9F03) must be converted to the
selected currency before performing the 1st Generate AC.

RQ 01600 Transaction Currency Code (Tag 5F2A) must be used in G3v032

 The Acquirer Transaction Currency Code and Settlement Currency Code fields in Group 3
Version 32 “Currency Conversion Data” must be set to the Transaction Currency Code (Tag
5F2A) value.

Page 48 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

5. Contactless Overview

5.1 Contactless Benefits

From a consumer‟s and merchant‟s point of view there are three benefits to contactless transactions:
1. Efficiency – There is no need for consumer verification (i.e. PIN) for low value payments – it‟s
just Tap and Go.
2. Security – With the chip, there can be dynamic security. The consumer receives the same level
of fraud protection on contactless payments that they would for contact payments. This means
the consumer is not liable for any losses.
3. Speed – Using contactless technology, there is no need for swiping or inserting the payment
card, therefore transaction throughput can be increased. In many cases, a receipt is only printed
if a customer requests one.
These benefits create an advantage for merchants as consumers tend to spend more. When merchants
can accept a payment method that encourages consumers to spend more and the transaction speed is
faster, there is an incentive to invest in this technology.

5.2 MSD vs. EMV Grade

When implementing contactless technology, two current environments must be supported for global
acceptance:
 Magstripe – where cards must be replaced to support the technology
 EMV – where cards are either complemented with a contactless interface or replaced when
migrating to Mobile.

5.2.1 Magstripe Environment (Replacement)

For the magstripe environment, there is only one implementation option and it is magstripe replacement.
In this implementation, the contactless interface accesses the chip through the contactless antenna.
A magstripe replacement contactless card contains a magnetic stripe on the back of the card and an
antenna and chip inside it. The only way to know that a card is a contactless magstripe replacement card
is by looking for the contactless icon on the front or back of the card.
 Transaction must always go online for authorization
 The cardholder may be prompted for a signature or PIN (depending upon the transaction
amount)

5.2.2 EMV Environment (Complement)

For EMV complement implementations, a “dual interface” card is used. A dual interface card supports
both a contact and a contactless interface to the same chip.
These cards are referred to as dual interface cards because the contact interface accesses the chip using
the contact plate, while the contactless interface accesses the same chip through the contactless
antenna. You can tell the card is a dual interface card by the contactless icon on the front or back of the
card and the contact plate which is visible on the front of the card.

Page 49 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

EMV Risk Management and decision making are supported by the chip through both interfaces:
 The contactless interface is aimed primarily at the micropayments market. Transactions are
mostly offline where there is no need for PIN or signature.
 The contact interface is used for higher transaction amounts, where online is needed and
consumer verification is required (i.e. PIN or Signature), or when EMV risk management
parameters need to be updated.

5.2.3 EMV Environment (Replacement)

EMV replacement is when the card is replaced with a different form factor, such as a mobile phone.
With a mobile phone only a contactless interface exists; there is no contact interface. For a contactless
mobile phones:
 Online and offline transactions are supported
 Online and offline PIN are supported
 EMV Risk Management updates are achieved via Over the Air (OTA) protocols

Page 50 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

5.3 Contactless Card Schemes

There are a number of contactless card schemes have been implemented by the card brands.

Table 12 Contactless Card Schemes

Scheme Specifications
MasterCard PayPass Reader Card Application Interface Specification 3.0
MasterCard PayPass
MasterCard M/Chip Advance

Visa PayWave VCPS 2.1 + Updates List

Amex ExpressPay ExpressPay 3.0 Card Specification

Discover D-PAS D-PAS Contactless Specifications 1.0

5.4 EMV Contactless Transaction Sets

The following table lists the EMV Contactless Form Factor (CFF) transactions supported by TSYS and
indicates how the transaction should utilize the EMV chip.

Table 13 EMV Contactless Transaction Set

EIS Summit Transaction CFF Used Store EMV
Transaction 1
Tran Code Tran Code Authorized By Interactively Cryptogram
2
Purchase Online 54 10 Issuer Yes Mandatory
Purchase Reversal 59 103 Issuer No N/A
Refund 5A 13 Issuer Yes N/A
Balance Inquiry 5L 14 Issuer Yes Optional

Notes:
1. Column indicates whether the final EMV cryptogram (TC – Transaction Certificate) should be stored with an
approved transaction.
2. The CFF is used interactively only up until the 1st Generate Application Cryptogram or until the magstripe
data has been received by the reader.

Page 51 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 52 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

6. EMV Transaction Flow

6.1 Full EMV Transaction Flow

The following table outlines a generic overview of the steps required to perform a Full EMV transaction
(e.g. Purchase). With Full EMV transactions the card makes the final authorization decision.

Table 14 Full EMV Transaction Flow

Step Process

1. Tender Initialization Transaction type is selected and the total transaction amount is determined
including:
o Tax
o Tip
o Cashback
o Surcharge

2. Card Insertion Chip initialization is performed:

o Validate ATR (Answer To Reset)
o Set Language
o Set Terminal Country Code (USA=”840”)

3. Application Selection A Candidate List is created of AIDs that are mutually supported by both the
card and the EMV POS Solution:
o U.S. Common Debit selection processing (see page 73)
o If the Candidate List is empty fallback processing is performed
o If only one mutually supported AID is found:
 AID is automatically selected
 Cardholder is required to confirm selection if Cardholder Approval
Indicator (Application Priority Indicator (Tag 87 – bit 8) is set to „1‟
o If more than one mutually supported AID is found, the user is prompted
to select an application or, if prompting is not possible, the highest
priority AID is auto-selected

4. Read Data Records Card data is read for the selected AID:
o Card PAN (Tag 5A)
o Expiry Date (Tag 5F24)
o Track2 Equivalent Data (Tag 57)
o Card Validation Checks (BIN, MOD10, etc.)
o Etc.
Card Validation Checks (BIN, MOD10, etc.) are performed on data read.

Page 53 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

5. Risk Management The kernel and chip perform multiple Risk Management processes. The
results are stored in the TVR (Tag 95) and CVR (part of Tag 9F10) and will be
transmitted to the issuer as part of the authorization request:
o Offline Card Authentication (SDA / DDA / CDA)
o Processing Restrictions
 Application Version Number
 Card Usage Control
 Application Effective Date
 Application Expiry Date
o Cardholder Verification (PIN / Signature / NO CVM)
o Terminal Risk Management

6. 1st Generate AC The EMV POS Solution requests an authorization from the chip. The EMV
chip will respond with an Application Cryptogram:
o Offline Approved (returns TC) – TSYS has zero floor limit so a TC
should never be generated
o Offline Declined (returns AAC)
o Online Authorization Required (returns ARQC)

7. Host Authorization The EMV POS Solution sends the transaction to the TSYS host for
authorization.
If unable to go online, the EMV POS Solution may, based on floor limits and
Merchant STIP processing, locally approve or decline the transaction.
Note: EMV U.S. Debit transactions cannot be approved locally.

8. Transaction Completion The authorization decision is sent to the EMV chip for final processing
Processing including:
o Issuer Authentication Data (Tag 91)
o Issuer Scripts (Tag 71 or Tag 72)
o Issuer Response Code (Tag 8A) – from the issuer or locally generated
Completion processing includes:
o External Authenticate (if an ARPC is returned by the issuer and card
supports Issuer Authentication in the AIP (Tag 82 Byte1 Bit3))
o Script Processing (if Tag 71 or Tag 72 returned by the issuer)
o 2nd Generate AC (to determine the final transaction disposition –
Approved (TC) or Declined (AAC)

9. Host Reversal Processing If the issuer approves the transaction and any of the following occur during
(if required) Transaction Completion Processing, a reversal must be sent to the host:
o PINPad not available
o Card removed prior to the completion of processing
o Chip Malfunction (except MasterCard – see requirement below)
o Chip declines the transaction (2nd Generate AC)
o Cardholder cancels transaction

10. Store Transaction Results The transaction results including the Application Cryptogram should be stored
in the transaction database.
Note: It is optional whether Decline and Reversal transactions are stored in the
transaction database however, the information relating to the transaction must
be available for the EMV Transaction report.

11. Remove Card The cardholder is prompted to remove the EMV card.

Page 54 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

12. Receipt Printing The EMV transaction receipt is printed. The receipt must contain the following
EMV information:
o Chip Indicator (to indicate cardholder data was read from a chip)
o AID
o Application Preferred Name (or Application Label)
o TVR
o TSI
o IAD
o Signature Line (if the CVM was Signature or NO CVM)
o “PIN Verified” (if the CVM was one of the PIN types)

RQ 01800 Issuer decision must be used for MasterCard 2nd Gen AC chip error
 For chip malfunctions at the 2nd Generate AC, MasterCard requires that the transaction be
approved or declined based on the issuer authorization decision returned in the host response.

Page 55 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

6.1.1 Full EMV Transaction Flowchart

EMV POS Solution

Calculates Total
Transaction Amount

EMV Card Inserted

Cancel
No Fallback Allowed? Failed
Transaction
Set EMV Parameters

OK
Yes Failed

Application Selection
Process Build AID Candidate List
as non-EMV
Transaction
OK

Is IIN Tag 42 Perform U.S. Common Debit

present in Yes AID Processing
Failed Candidate List? Update Candidate List

No

Final AID Selection

OK

Read Data Records

OK

Risk Management
 Offline Card Authentication
 Processing Restrictions
 Cardholder Verification
 Terminal Risk Management

Store Transaction
Print
Transaction Declined Approved
“Declined” 1st Generate AC
Unsuccessful AAC Returned TC Returned EMV data is saved with
Receipt
transaction

Go Online
ARQC Returned
Print
Host Authorization “Approved”
Receipt
Build host message and send
to host and receive response

Completion Processing Transaction

 Set ARC Tag 8A Successful
Generate Reversal  Issuer Authentication
 Issuer Script Processing
 2nd Generate AC

Yes

Was Host EMV Chip Approved

Declined
No Response an Authorization TC Returned
AAC Returned
Approval? Decision?

Error

Page 56 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

6.2 Partial EMV Transaction Flow

The following table outlines a generic overview of the steps required to perform a Partial EMV transaction
(e.g. Credit Refund or Reversal). For these transactions the EMV card is only used to obtain Track 2
information stored on the chip. The card does not participate in the authorization decision.

Table 15 Partial EMV Transaction Flow

Step Process

1. Tender Initialization Transaction type is selected and the total transaction amount is determined
including:
o Tax
o Tip
o Cashback
o Surcharge
Note: For transactions such as reversals or completions this information may
be read from the transaction batch.

2. Card Insertion Chip initialization is performed:

o Validate ATR (Answer To Reset)
o Set Language
o Set Terminal Country Code (USA=”840”)

3. Application Selection A Candidate List is created of AIDs that are mutually supported by both the
chip and the EMV POS Solution:
o USA Common Debit selection processing (see page 73)
o If the Candidate List is empty, fallback processing is performed
o If only one mutually supported AID is found:
 AID is automatically selected
 Cardholder is required to confirm selection if Cardholder Approval
Indicator (Application Priority Indicator (Tag 87 – bit 8) is set to „1‟
o If more than one mutually supported AID is found, the user is prompted
or, if prompting is not possible, the highest priority AID is auto-selected

4. Read Data Records EMV POS Solution reads data records for the AID selected (including):
o Card PAN (Tag 5A)
o Expiry Date (Tag 5F24)
o Track2 Equivalent Data (Tag 57)
o Etc.
Card Validation Checks (BIN, MOD10, etc.) are performed on data read.

5. 1st Generate AC The EMV POS Solution requests an AAC to terminate the chip interaction.

6. Authorization The transaction is sent online or is authorized locally.

7. Store Transaction Results The transaction results are stored in the transaction batch.

8. Remove Card The cardholder is prompted to remove the EMV card.

Page 57 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

9. Receipt Printing The EMV transaction receipt is printed. The receipt must contain the following
EMV information:
o Chip Indicator (to indicate cardholder data was read from a chip)
o AID
o Application Preferred Name (or Application Label)
o Signature Line (always)

10. Transaction Upload The transaction is sent to the host prior to or at settlement.

Page 58 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

6.2.1 Partial EMV Transaction Flowchart

EMV POS Solution

Calculates Total
Transaction Amount

EMV Card Inserted

Cancel
No Fallback Allowed? Failed
Transaction
Set EMV Parameters

OK
Yes Failed

Application Selection
Process Build AID Candidate List
as non-EMV
Transaction
OK

Candidate List Perform U.S. Common Debit

has IIN Tag 42 Yes AID Processing to
Failed Present? Update Candidate List

No

Final AID Selection

OK

Read Data Records

OK

Force AAC
1st Generate AC

Print Store Transaction

Transaction
“Approved”
Successful
Receipt No EMV data is stored

Page 59 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 60 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

7. Contactless Transaction Flow

When a contactless form factor is presented to the EMV POS Solution, the EMV kernel selects a mutually
supported application. It then reads the data contained in the contactless form factor and makes a
transaction decision. The decision can be to not accept contactless at all (if over the contactless
transaction limit), approve offline (not supported by TSYS), decline offline or request an online
authorization.
The contactless form sends the authorization decision, optionally the cryptogram (depending on which
type of contactless application has been selected – MSD or EMV) and any CVM options that may be
processed based on the contactless CVM limit and conditions, to the payment application for further
processing.

Page 61 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

7.1.1 Contactless Transaction Flowchart

Contactless

Not Accepted
Read Error Y Retry? N
Use Contact/MSR

N Y Contactless

App/Card
Y Not Accepted
Blocked?

Exceed
Not Accepted
Contactless Y
Use Contact/MSR
Limit?

Exceed CVM
Y Set CVM Required
Limit

Transaction
MSD Card? Y
Completed

AAC
Generated?

Y
N

ARQC
Y
Generated?

Transaction
TC Generated? Y
Completed

Use Contact/MSR

Page 62 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8. Chip Processing Guidelines

The transaction process implemented will be strongly affected by the PINPad and the API that the
PINPad supports. The process described in this document is based on a “typical” PINPad API which
combines several EMV transaction steps into a single API command.
Please refer to your PINPad vendors‟ specification for details on implementing the PINPad API
commands.

8.1 Tender Processing

For EMV transactions the full transaction amount must be known prior to card entry. This includes the
base transaction amount plus any cashback, surcharge or tip amounts that may be added.

Note: Suggested amount confirmation displays can be found on page 79.


RQ 02000 Total transaction amount must be known before card is presented
All EMV POS Solutions must complete the tendering process before prompting for card entry.

RQ 02100 Transaction Amount (Tag 9F02) must be set to total transaction amount
 The Transaction Amount (Tag 9F02) must be set to the total transaction amount including
cashback, surcharge and tip.

RQ 02200 Cardholder amount confirmation is mandatory

 It is mandatory that the cardholder be provided an opportunity to approve all transaction

amounts (Total, Cashback, Surcharge and Tip). If the cardholder does not confirm the amount
the transaction must be cancelled.

8.1.1 Cashback Transaction Flow

Cashback is supported for debit card transactions only. The cashback amount must be known before
card entry. Therefore, if a cashback amount is entered and the AID selected is not a debit AID, the
transaction must be cancelled.

RQ 02300 Transaction Amount (Tag 9F02) must include the cashback amount
 The cashback amount must be included in the full transaction amount stored in Transaction
Amount (Tag 9F02).

RQ 02400 Other Amount (Tag 9F03) must contain the cashback amount
 The cashback amount must be stored in Other Amount (Tag 9F03) and sent to the host as part
of the authorization message.

Page 63 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

RQ 02500 Cashback only allowed for debit AIDs

 If a cashback amount is entered and the AID selected for the transaction is not a debit AID, the
transaction must be cancelled.

8.1.2 Tip Transaction Flow

Historically, an Authorization would be performed for the pre-tip amount (e.g. the meal amount in a
restaurant) and the settled amount would be for the pre-tip amount + tip amount. As EMV POS Solutions
will always have a cardholder entry device (e.g. PINPad), it is recommended that the EMV Purchase
transaction be used for transactions that would include a tip. This would allow the authorization amount
and settlement amount to be the same.
The EMV Purchase (with tip) transaction flow would be:
1. Display transaction amount on the PINPad for cardholder approval
2. Prompt cardholder to add a tip amount
3. Confirm total (Transaction Amount (including cashback and surcharge) + Tip)
4. Begin standard EMV Purchase transaction flow using the new total
5. Settle transaction using the authorized amount.

BP 01300 Use Pay at Table for restaurant tipping

 For environments such as Restaurants that require tipping it is recommended that a Pay at
Table solution be implemented so that Purchase transactions with a tip prompt can be used.
Also if a PIN is required the customer will be able to enter it while remaining at the table.

8.2 EMV Transaction Initiation

EMV transaction initiation prepares the PINPad to accept an EMV card. A prompt must be displayed on
the PINPad indicating the card should be inserted or tapped (if contactless is supported). It is optional
whether the prompt indicates that the card may be swiped.
EMV transactions can be initiated by:
 Card Insertion or Card Tap – Must be attempted first for all EMV chip cards
 Card Swipe – If a card is swiped, the Service Code must be interpreted to determine if the card
contains a chip. If the Service Code indicates a chip card, the swipe must be discarded and a
prompt to insert or tap (if contactless EMV is supported) must be displayed. A card swipe is only
allowed for EMV cards when in fallback. For more information on Fallback processing see page
68

8.2.1 Service Code Processing

When processing the magnetic stripe information, the EMV POS Solution must read and act upon the
Track 2 Service Code.
EMV chip cards contain a Track 2 Service Code beginning with “2” or “6”. The Service Code value must
be checked to determine if a chip read is required.

Page 64 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 16 Chip Service Codes Processing

Service Code Card Type Action Required
2xx International Use Chip
6xx Domestic Use Chip

RQ 02600 Service Code „2xx‟ and „6xx‟ must force a chip usage
 If a card is swiped with Service Code „2xx‟ or „6xx‟ (indicating that a chip is present), the EMV
POS Solution must prompt for the card to be inserted into the chip reader.

8.3 Chip Read Flow

For EMV cards it is mandatory that a chip transaction be attempted before a magnetic stripe or fallback
transaction is allowed. If your EMV POS Solution accepts magnetic stripe reads from a device other than
a locally attached PINPad, you must ensure the Service Code is being checked by that device and that
an attempt is made to use the EMV chip before proceeding as a magnetic stripe or fallback transaction.
If a card with an EMV Service Code („2xx‟ or „6xx‟) is swiped, the swipe must be rejected and the
cardholder must be prompted to use the chip reader. For suggested text see page 78.
The following tables show the processing when reading from the chip and magstripe readers.

Table 17 Chip Reader Flow

Condition Action
Card Insertion (ATR) Error Technical Fallback processing
Card Blocked (card returns “6A81”) Reject card – Prompt for another card
Application Blocked (card returns “6283”) Reject card – Prompt for another card or cancel
Empty Candidate List MSR Fallback processing
Card removed before host authorization Cancel transaction
Fallback enabled for AID – Technical Fallback
1st Generate AC Unsuccessful
Fallback not enabled for AID – Cancel transaction
1st Generate AC Successful Proceed with EMV transaction
Card removed after host authorization (Approved) Send host reversal then cancel transaction
Card removed after host authorization (Declined) Process as a Declined transaction

Table 18 Magstripe Reader Flow

Condition Action
Read Failed Reject card – Prompt for another card
Unknown BIN Reject card – Prompt for another card
If a fallback swipe – Continue with fallback
EMV Service Code „2xx‟ or „6xx‟
If not a fallback swipe – Force chip read
Non-EMV Service Code (not „2xx‟ or „6xx‟) Proceed with magstripe transaction

Page 65 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

RQ 02700 Cancel transaction if card accepted but removed before host authorization
 When an EMV card is successfully read but is removed during EMV processing, before
performing an online authorization, the transaction must be cancelled.

RQ 02800 Reverse and cancel if host approves but card removed before 2nd Gen AC

 If a host authorization is performed and the transaction is approved by the issuer, but the card
is removed before the 2nd Generate AC completes, a host reversal must be sent and then the
transaction must be cancelled.

RQ 02900 Decline transaction if host declines and card is removed before 2nd Gen AC
 If a host authorization is performed and the transaction is declined by the issuer, but the card is
removed before the 2nd Generate AC completes, the transaction must be declined.

Page 66 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.3.1 Chip Read Flowchart

Chip Reader Mag Stripe Reader

Use Mag Stripe Good Read? No Not Accepted

ATR Error? Yes
(Technical Fallback)

No Yes

Card Blocked? Yes Not Accepted Valid BIN? No Not Accepted

SW=6A81

No Yes

App Blocked? Service Code Normal MSR

Yes Not Accepted No
SW=6283 = 2xx or 6xx? Transaction

No
Yes

Use Mag Stripe

Empty Candidate Yes
(MSR Fallback)
List? Fallback Active? No Try Chip Reader

No
Yes

Execute Commands up
to and including the
1st Generate AC Fallback
Transaction

Successful
Proceed with EMV
Command? Yes
Transaction
SW=9000

No

Was Card Transaction

Removed? Yes
Terminated

No

Use Mag Stripe

Fallback Enabled Yes
(Technical Fallback)
For AID?

No

Transaction
Terminated

Page 67 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.4 Fallback Processing

For the purposes of this document, the term “Fallback” is defined as the acceptance of chip cards via
magnetic-stripe processing at a chip-capable device. EMV POS Solutions must accept both chip and
magnetic-stripe cards and thus have both chip and magnetic-stripe readers.
When a chip card is presented, the card information must be obtained via the chip reader (or EMV
contactless interface) and not the magnetic-stripe reader, if the chip and chip reader are both functioning.
In situations where either the chip or the chip reader is not functioning, card information may be obtained
by reading the magnetic stripe. The resulting transaction is referred to as a “Fallback” transaction. These
transactions are deemed less secure because magnetic-stripe acceptance circumvents the control and
risk management protection available with chip acceptance.
There are two types of fallback transactions. The difference between the two types is based on where in
the transaction flow it is determined that a chip transaction cannot proceed and that a magnetic stripe
transaction must be performed:
 MSR Fallback – Empty Candidate List (no mutually supported AIDs)
 Technical Fallback – Unable to read chip (chip or chip reader failure)

RQ 03000 Service Code „2xx‟ and „6xx‟ must be accepted for fallback card swipes

 In a fallback situation the magnetic stripe reader must accept a swiped EMV card and process
it as a non-chip card (i.e. as a standard magstripe card) even though the Service Code is „2xx‟
or „6xx‟.

RQ 03100 Fallback must be cancelled when a card is inserted at fallback card entry
 When waiting for a fallback card swipe, if an EMV card is inserted or tapped, fallback
processing must be cancelled and the transaction must proceed as an EMV transaction.

RQ 03200 Fallback must be cancelled if a non-EMV card is swiped during fallback

 When waiting for a fallback card swipe, if the card swiped does not have a „2xx‟ or „6xx‟
Service Code, fallback must be cancelled and the transaction must be performed as a
traditional magstripe transaction.

8.4.1 MSR Fallback

MSR Fallback is used when Application Selection fails (i.e. when none of the AIDs supported by the EMV
POS Solution matches any of the AIDs loaded on the EMV card). This scenario is also known as an
“Empty Candidate List”. When this occurs the transaction must be completed as a fallback transaction
using the magnetic stripe.

RQ 03300 Fallback must be allowed for empty Candidate List

 If during Application Selection the Candidate List is empty, the cardholder must have the option
to swipe the card and continue the transaction as an MSR Fallback transaction.

Page 68 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

RQ 03400 MSR Fallback transaction must be sent to host as a swipe transaction

 When a MSR Fallback is performed the TSYS host request message must have the Account
Data Source field is set to “W” indicating that the EMV POS Solution does not have any EMV
applications (AIDs) in common with the chip card.

8.4.2 Technical Fallback

Technical Fallback is used when a chip enabled device is unable to read a chip card. In these cases the
card information must be obtained by reading the magnetic stripe. There a several situations where
Technical Fallback may occur:
1. When the chip on the card is inoperative (No ATR received from the chip)
2. An invalid ATR is received from the chip
3. When the PINPad chip reader is malfunctioning

RQ 03500 Technical Fallback transactions must be identified in the host message

 When a Technical Fallback is performed the host request message must have Account Data
Source is set to “Z” indicating a Technical Fallback transaction.

8.4.3 Fallback Not Allowed Scenarios

After successfully completing Application Selection there are several reasons why a chip transaction may
fail and fallback processing is not allowed:
1. The card has been blocked
2. The card application has been blocked
3. The transaction is offline declined (AAC generated at 1st Generate AC)
4. Premature card removal before the transaction has been completed
5. Fallback is not supported by the card brand
6. Transaction is cancelled at any point
When any of these situations occur, another form of payment is required.

8.4.4 Fallback Prompting

If fallback is required, the cardholder should be prompted to use the magnetic-stripe reader, followed by a
standard card entry prompt indicating that a card may be inserted, swiped or tapped (if supported). Even
though fallback is active the cardholder should be allowed to insert or tap the same or a different EMV
card.

Page 69 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

BP 01400 Fallback Prompting should only be allowed for a limited time

 When a fallback prompt is displayed it should only be enabled for 30 – 90 seconds. After that
period, if a card is swiped with an EMV Service Code („2xx‟ or „6xx‟), a prompt to use the chip
reader should be displayed.

BP 01500 Card insert and card tap should be supported in fallback

 When in fallback it is recommended that the EMV POS Solution allows the cardholder to
swipe, insert or tap a card. This allows a second attempt at the chip usage and allows the
cardholder to switch to a different EMV cards without restarting the transaction.

8.4.5 Fallback Timelines

Fallback is a temporary practice that will only be allowed for a limited time, after which fallback
transactions will not be permitted. EMV POS Solutions should have the technical capability to allow or
disallow fallback transactions by card scheme and should be able to activate/deactivate this capability
based on rules established by the card brands and subsequently directed by TSYS.
When fallback is discontinued for a card scheme, the EMV chip cards for that scheme may no longer be
processed as magnetic stripe cards.
The chart below shows the date fallback will be disallowed by each card brand.

Table 19 Fallback Timelines

Card Brand Fallback Timeline
Amex No date set
Diners No date set
Discover No date set
JCB No date set
MasterCard No date set
Visa No date set

BP 01600 Fallback Enable/Disable should be a configurable parameter by card scheme

 Fallback should be implemented as a configurable parameter by card scheme (AID) to simplify
the process of disabling fallback when it is no longer permitted by the scheme.

RQ 03600 Fallback is not allowed if not supported by card scheme

 Fallback may only be performed when permitted by the card scheme. If a fallback situation
occurs and fallback is not allowed for the card presented, the transaction must be cancelled.

8.5 Application Selection

An EMV card may support more than one application (AID). When a card with multiple applications is
presented, Application Selection will be performed to select the AID to be used for the transaction.

Page 70 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

The EMV POS Solution must be configured with the AIDs of all chip payment applications it supports. If
none of the AIDs supported by the EMV POS Solution match any AID supported by the card, a chip
transaction cannot be performed. In this case MSR Fallback processing must be initiated.
The AID consists of three components:
 Registered Application Identifier (RID) – Represents the payment scheme (e.g. Visa,
MasterCard, etc.)
 Proprietary Application Identifier Extension (PIX) – Represents the payment application type
(i.e. credit, debit, prepaid, ATM-only, etc.)
 Issuer Suffix – Optional suffix sometimes added to the end of the AID by the issuer
An Application Selection Indicator associated with each AID designates how application matching is
performed:
 Full Selection – The EMV POS Solution AID must exactly match the entire card AID, including
any issuer assigned suffix, to be selected
 Partial Selection – The EMV POS Solution can select an AID based on only its AID matching
the card AID excluding the issuer assigned suffix (if any)

RQ 03700 Partial Selection must be supported

 It is mandatory that Partial Selection be supported for all card schemes. This ensures that all
chip applications for a supported AID can be selected regardless of any issuer assigned suffix.

The following table shows the EMV AIDs supported by TSYS.

Table 20 Application Identifiers (AID)

Application AID (RID + PIX) RID PIX
Amex A00000002501 A000000025 01

Diners A0000001523010 A000000152 3010

Discover A0000003241010 A000000324 1010

JCB A0000000651010 A000000065 1010

MasterCard Credit A0000000041010 A000000004 1010

MasterCard International Maestro A0000000043060 A000000004 3060

MasterCard US Maestro A0000000042203 A000000004 2203

Visa U.S. Common Debit A0000000980840 A000000098 0840

Visa Credit A0000000031010 A000000003 1010

Visa Debit International A0000000031010 A000000003 1010

Visa Electron A0000000032010 A000000003 2010

Visa Interlink A0000000033010 A000000003 3010

Page 71 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

BP 01700 Accept valid AIDs only

 EMV POS Solutions should only accept AIDs supported based on your merchant agreement.
Any AID that has not been approved for use should be rejected by the EMV POS Solution
without being sent to the host for authorization.

8.5.1 Application Selection Methods

The first step of Application Selection is to build a Candidate List of AIDs supported by both the card and
the EMV POS Solution. There are two methods that may be used by the kernel to build the Candidate
List. The method used is dependent on whether or not the card has a Payment System Environment
(PSE) present:
 Implicit Application Selection Method – used when PSE is present on the chip
 Explicit Application Selection Method – used when PSE is not present on the chip

Note: The Payment System Environment (PSE) is a list of all payment applications (AIDs) that exist on
the card.

Implicit or Explicit Application Selection is performed by the kernel not the EMV POS Solution. It is up to
the kernel to determine which selection method to use and to build the initial Candidate List of commonly
supported AIDs.
Implicit Application Selection is the most efficient selection method but, it can only be used when the chip
contains a Payment System Environment (PSE). Therefore, the first step of Application Selection is for
the kernel to read the PSE from the card. If a PSE is returned, Implicit Application Selection will be
performed. If no PSE is returned, Explicit Application Selection will be performed.

RQ 03800 The AID list must be loaded into the kernel at kernel initialization
 As part of kernel initialization, all AIDs supported by the EMV POS Solution must be loaded
into the kernel for use during Application Selection.

8.5.1.1 Implicit Application Selection (PSE)

To perform Implicit Application Selection the kernel reads the PSE from the card to obtain the list of
supported AIDs. This list is then compared to the list of AIDs supported by the EMV POS Solution. AIDs
supported by the EMV POS Solution and found in the PSE application list are added to the Candidate
List.

8.5.1.2 Explicit Application Selection

To perform Explicit Application Selection the kernel uses the list or AIDs supported by the EMV POS
Solution. For each supported AID, the kernel attempts to select the AID from the card. If successful, the
AID is added to the Candidate List.

Page 72 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.5.2 Credit / Debit Selection and U.S. Debit Processing

In the traditional magstripe debit transactions, merchants can decide when selecting the card type, what
cardholder verification to use for the debit transaction. This may be either to:
1. Prompt the cardholder to enter the PIN (commonly referred to as “PIN Preferring Merchants”).
The cardholder can bypass the PIN to allow for a signature transaction.
2. Prompt the cardholder to select either “Credit” or “Debit” (commonly referred to as “Credit/Debit
button supporting merchants”). In this situation:
- Credit – means perform a Signature Debit transaction
- Debit – means perform a PIN Debit transaction
This section describes how to perform Application Selection for EMV U.S. Debit so that the routing choice
of the merchant is retained and the expected cardholder verification is performed based on merchant
and/or cardholder preferences.
The following assumptions have been made when describing the Application Selection process for U.S.
Debit:
 Solutions supporting U.S. Debit will have two kernel configurations:
- All CVM Config – Terminal Capabilities (Tag 9F33) is set to support all CVMs the merchant
wishes to support (e.g. PIN, Signature, and NO CVM).
- NO CVM Only Config – Terminal Capabilities (Tag 9F33) is set to support only NO CVM.
 When using a configurable kernel the Terminal Type (Tag 9F35) and Additional Terminal
Capabilities (Tag 9F40) values will remain the same regardless of the value used for Terminal
Capabilities (Tag 9F33).
 PIN Bypass is supported in all PIN supporting kernel configurations (regardless of merchant
option – PIN Preferring or Credit/Debit button).
 The payment application supports a NO CVM limit for all interfaces other than contactless for all
payment products.
The steps required to manipulate the Candidate List to fully support U.S. Debit are:
1. For each transaction the final amount for the transaction must be known prior to manipulating the
Candidate List.
2. Once the final amount is known and the Candidate List is created, the card type will be identified
based on the list of AIDs in the Candidate List. There are two options:
- The Candidate List doesn‟t contain any U.S. Common Debit AIDs – This is either an
international or domestic credit card or an international debit card. In this case there are no
additional steps needed and the application can continue to Final Selection (section 8.5.4).
- The Candidate List contains one or more U.S. Common Debit AIDs – This is a U.S. Debit
card.
3. For U.S. Debit cards, the EMV POS Solution must determine which AIDs should remain in the
Candidate List (based on the various options described in section 2.6 and where applicable
always ensuring that the U.S. Common Debit AID is the only AID that will remain in the Candidate
List). Based on the number of AIDs the following should be performed:
- Candidate List only contains one AID – Continue to step 4 below.
- Candidate List contains more than one AID – Continue to Final Selection step (section 8.5.4).
4. If the Candidate List only contains the U.S. Common Debit AID, the EMV POS Solution needs to
decide if the transaction is under or over the U.S. Debit CVM limit:

Page 73 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

- Transaction is under the U.S. Debit CVM limit – Set Terminal Capabilities (Tag 9F33) to “NO
CVM Only Config” and continue to Final Selection (section 8.5.4).
- Transaction is over the U.S. Debit CVM limit – continue to step 5 below.
5. If the Candidate List contains only the U.S. Common Debit AID and the transaction is over the
NO CVM limit for U.S. Debit, the following should be performed based on the cardholder
verification process supported by the merchant:
- PIN Preferred Merchants – Set the Terminal Capabilities (Tag 9F33) to “All CVM Config”.
Later during Cardholder Verification the application will prompt for PIN and may allow the
cardholder to bypass the PIN.
- Credit/Debit Button Merchants – Prompt the cardholder to select either Credit or Debit.
o Credit Selected – Set the Terminal Capabilities (Tag 9F33) to “NO CVM only
Config”. In this case the transaction will be defined as a “NO CVM”; however,
since the transaction is over the NO CVM limit the application should capture or
print a signature at the end of the transaction.
o Debit Selected – Set the Terminal Capabilities (Tag 9F33) to “All CVM Config”
and proceed to the Final Selection step (section 8.5.4) PIN Bypass may still be
allowed during the Cardholder Verification step of EMV.

Note: The U.S. Common Debit AIDs supported are MasterCard US Maestro (A0000000042203) and
Visa Common Debit (A0000000980840).

BP 01800 Cardholder Verification should be handled by EMV kernel

 When migrating to EMV the cardholder verification used is handled by the EMV kernel and the
card application (based on the issuer priority and choice), TSYS recommends that solutions no
longer use the Credit/Debit button option.

Page 74 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.5.3 U.S. Debit Processing Flowchart

Chip Reader

Get Candidate List

Do any AIDs have Tags

5F55 & 42?

Yes

Compare IIN values in

AIDs

No

Are any of the IINs the

same?

No Yes

Remove Global AIDs with

same IIN

Is there more than 1

AID?

Yes
No

Display AID selection to

cardholder to select AID

Is Transaction Amount
>= NO CVM Limit
Yes No

Set Terminal Capabilities Set Terminal Capabilities

to All CVM Config to NO CVM Config

Final Selection

Page 75 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.5.4 Final Selection

Once the Candidate List has been built and U.S. Common Debit processing has been performed, Final
Selection can begin. During this process the AID to be used for the transaction is selected.
If the Candidate List only contains one application it is automatically selected, Final Selection ends and
Cardholder Application Confirmation is performed.
If the Candidate List contains two or more mutually supported applications (AIDs), the application list
must be presented to the cardholder for selection. The list of applications may be presented all on one
screen or may be displayed with one application name per screen using navigation buttons (e.g. „Next‟
and „Previous‟) to view the list.
Regardless of the method used to display the Candidate List, the application names displayed are
determined as follows:
1. Display the Application Preferred Name (Tag 9F12) if it is stored in a character set supported by
the display. This can be determined by checking the Issuer Code Table Index (Tag 9F11). A
value of “1” indicates that the Application Preferred Name is encoded using the Latin character
set (i.e. contains standard English alphabetic characters).
2. Display the Application Label (Tag 50) if the Application Preferred Name is not present or cannot
be displayed.
3. If the Application Preferred Name and Application Label are not present or cannot be displayed,
display a default application name assigned to the AID by the EMV POS Solution.
Once the application has been chosen, the kernel may relay the application information back to the
payment application so the following can be performed:
1. Set the Terminal Capabilities (Tag 9F33) – This will be based on the NO CVM limit for the card
type based on the AID that has been selected (either the “All CVM Config” or the “NO CVM Only
Config”):
- Transaction is over the NO CVM limit – Select the All CVM Config
- Transaction is under the NO CVM limit – Select the NO CVM Only Config
2. Set the Processing Code:
- International AID selected – a credit Processing Code should be used
- U.S. Common Debit AID selected – a debit Processing Code should be used
The kernel can now select the card AID on the chip and Final Selection ends.
In some implementations, it may not be feasible to perform cardholder Application Selection. For these
implementations an EMV transaction should not be performed if the chip card contains multiple
applications, unless there is a method to inform the cardholder which application is being used.

Note: Certification will test that up to five mutually supported applications can be supported in the
Candidate List.

BP 01900 A default application name should be assigned for all AIDs

 The EMV POS Solutions should have a default application name assigned to each supported
AID to be used to display and print the application name when the Application Preferred Name
and Application Label are not present or cannot be used.

Page 76 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.5.5 Cardholder Application Confirmation

Cardholder Application Confirmation is only required when the Candidate List contains only one AID and
the Cardholder Approval Indicator (Application Priority Indicator (Tag 87 – bit 8) is set to „1‟.
If cardholder confirmation is required, the cardholder must be prompted to confirm that the selected
application may be used. To do this the Application Preferred Name (Tag 9F12) or the Application Label
(Tag 50) is displayed to the cardholder who must confirm the selection.

Table 21 Cardholder Approval Indicator (Tag 87 – bit 8)

Value Action
The EMV POS Solution must request confirmation from the cardholder before using
„1‟ the application for the transaction. If the cardholder declines the transaction must be
cancelled.

„0‟ The application may be used without prompting the cardholder.

RQ 03900 Transaction must be cancelled if Cardholder Application Confirmation fails

 If Cardholder Application Confirmation is required and cardholder indicates that the application
should not be used, the transaction must be cancelled.

Note: There is currently no requirement to perform Cardholder Application Confirmation at unattended

EMV implementations.

8.6 Read Data Records

After the AID has been selected, AID information is read from the chip. During Read Data Records
processing several checks should be performed to validate the card data. If any of these checks fail the
card should be rejected and the transaction should be terminated.
When performing this validation any field padding (hex `F`) should be stripped before the check is
performed.

RQ 04000 PAN must be MOD10 verified

 The PAN (Tag 5A) value must be MOD10 verified to ensure it is valid and has been read
correctly. If MOD10 fails the card must be rejected.

RQ 04100 PAN tag must match account number in Track2 Equivalent Data
 The PAN (Tag 5A) value should be the same as the account number included as part of
Track2 Equivalent Data (Tag 57). If they are different then the card must be rejected.

RQ 04200 BIN must be found in BIN table

 The BIN portion of the PAN (Tag 5A) value must be found in the EMV POS Solution BIN table.
If not found the card must be rejected.

Page 77 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

RQ 04300 Application Expiration Date must match Track2 Equivalent Data expiry date
 The Application Expiration Date (Tag 5F24) should be the same as the expiry date included as
part of Track2 Equivalent Data (Tag 57). If they are different the card must be rejected.

RQ 04400 Service Code must not be validated against Track2 Equivalent Data
 The Service Code (Tag 9F30) must not be validated against the Service Code included as part
of the Track2 Equivalent Data (Tag 57).

8.7 Cardholder Language Selection

Cardholder Language Selection is only performed if the EMV POS Solution supports more than one
language. If required, language selection is performed after the card has been presented and the AID
has been selected. Cardholder Language Selection is performed by reading the Language Preference
(Tag 5F2D) from the card and comparing it to the languages supported by the EMV POS Solution:
 If there is only one common language, it should be used
 If there are multiple common languages, the language with the highest preference based on the
order the languages are listed in the Language Preference (Tag 5F2D) should be used
 If none of the languages in the Language Preference (Tag 5F2D) are supported by the EMV
POS Solution, the cardholder should be prompted to select one of the supported languages. If
the EMV POS Solution only supports one language, it may be auto-selected
Until the card is presented the EMV POS Solution default terminal language should be used for
cardholder display and prompting.

BP 02000 If multiple languages supported cardholder should be prompted to select

 If the EMV POS Solution supports multiple languages and none of them match a language in
the Language Preference (Tag 5F2D) list, the cardholder should be prompted to choose one of
the languages supported by the EMV POS Solution.

8.8 Cardholder Prompting

This section outlines the TSYS recommended card entry, PIN entry and amount confirmation prompting.
These prompts are not mandated and should be considered guidelines only.

8.8.1 Card Entry Prompting

During the EMV transaction process there are several steps that require PINPad prompting to obtain
cardholder confirmation or provide instructions to the cardholder. This prompting must be performed in
the cardholder language determined by the Cardholder Language Selection process.
TSYS recommends that the following prompts be used for card entry.

Page 78 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 22 Recommended Card Entry Prompting

Prompt Reason Recommended Prompt Text

Card presentation required “Insert, Tap or Swipe Card”

Inform cardholder not to remove the card “Leave Card Inserted”

Transaction is complete, card should be removed “Remove Card”

Chip card is swiped with Service Code „2xx‟ or „6xx‟ “Use Chip Reader”

Fallback is initiated “Use Mag Stripe”

BP 02100 Do not use “remove” in the cardholder prompt to leave card inserted
TSYS highly recommends that the prompt informing the cardholder to leave the EMV card
 inserted does not include the word “remove”. Doing this often leads to confusion with the
remove card prompt, displayed at the end of the transaction, causing the EMV card to be
removed prematurely (i.e. Avoid using the prompt “Do Not Remove Card”).

8.8.2 PIN Prompting

Several prompts are required for PIN entry to inform the cardholder of the status of the PIN entry process.

Table 23 Recommended PIN Entry Prompting

Prompt Reason Recommended Prompt Text

PIN entry required “Enter PIN”

Incorrect PIN entered “Invalid PIN”

Only one PIN try remaining before card is blocked “Last PIN Try”

PIN tries exceeded and card has been blocked “PIN Tries Exceeded”

8.8.3 Amount Confirmation Prompting

There are a number of transaction amounts that require confirmation during transaction processing.
When multiple amounts require confirmation, the amount confirmation prompts should be combined onto
a single display.

Page 79 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 24 Recommended Cardholder Amount Confirmation

Amount Confirmation Prompt 4-Line Display

Amount confirmation only Amount $xxxx.xx

OK?

Cashback only Amount $xxxx.xx

(for multi-line displays can be added to amount Cashback $xxxx.xx
confirmation)
Total $xxxx.xx
OK?

Surcharge confirmation only Amount $xxxx.xx

(for multi-line displays can be added to amount Surcharge $xxxx.xx
confirmation)
Total $xxxx.xx
OK?

Tip confirmation only Amount $xxxx.xx

Tip $xxxx.xx
Total $xxxx.xx
OK?

Cashback and Tip confirmation Amount $xxxx.xx

Cashback $xxxx.xx
Tip $xxxx.xx
Total $xxxx.xx OK?

Cashback and Surcharge confirmation Amount $xxxx.xx

Cashback $xxxx.xx
Surcharge $xxxx.xx
Total $xxxx.xx OK?

8.9 Processing Restrictions

Processing Restrictions processing is performed to determine if a transaction should be allowed.
However, failure of any check doesn‟t require that the transaction be cancelled. The failed result is just
logged in the Terminal Verification Results (Tag 95) and Processing Restrictions continues.
Processing Restrictions includes the following checks:
 That the effective date for the card has been reached
 That the card has not expired
 That the application versions of the EMV chip and application match
 If any Application Usage Control (Tag 9F07) restrictions are in effect

Page 80 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Note: An Issuer may use Application Usage Controls to restrict a card‟s use for domestic or
international transactions; as well as cash, goods, services or cashback.

8.9.1 Processing Restrictions Steps

The Processing Restrictions steps involve comparing data read from the EMV chip with data resident in
the EMV POS Solution. Depending on the PINPad capabilities, this step may be performed by the kernel
or the EMV POS Solution. Please refer to the EMV PINPad specification to determine your PINPad
capabilities.
The Processing Restrictions steps are as follows:
1. Check the Card Application Version Number (Tag 9F08) to ensure it matches one of the
application versions supported. Some kernels are able to support a primary and a secondary
application version number. The table below shows the Application Version Numbers currently
supported for each brand.
Primary Secondary
Card Brand
Version Version
Amex 001
Diners 001
Discover 001
JCB 200 120
MasterCard 002
Visa 08C 096

2. Verify that the type of transaction (POS, cash advance, purchase, cashback) is in domestic or
international mode and is compatible with the card‟s Application Usage Control. The Application
Usage Control (Tag 9F07) bits are checked as follows:
- Valid at EMV POS Solutions other than ATMs (Byte1-bit1) must be „On‟
- Valid for domestic use:
o Issuer Country Code (Tag 5F28) = Terminal Country Code (Tag 9F1A)
o Goods and Services (Byte1-bit6, Byte1-bit4) must be „On‟
- Valid for international use:
o Issuer Country Code (Tag 5F28) ≠ Terminal Country Code (Tag 9F1A)
o Goods and Services (Byte1-bit7, Byte1-bit5) must be enabled
3. Verify that the Application Effective Date (Tag 5F25) is equal to or before the current date.
4. Verify that the Application Expiration Date (Tag 5F24) is after the current date.
The results of these tests are stored in the Terminal Verification Results (Tag 95).

RQ 04500 AID list must be supported with associated Application Version Numbers
 The EMV POS Solution must maintain a list of supported AIDs and corresponding Application
Version Numbers.

Page 81 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.10 Offline Card Authentication

Offline Card Authentication is performed between the EMV chip and the kernel and it ensures that the
EMV chip is valid. This EMV transaction step may or may not be performed automatically by the kernel
(i.e. without being requested to do so by the EMV POS Solution).
Please refer to the PINPad EMV specification to determine how this function is performed.

8.10.1 Offline Card Authentication Methods

EMV defines three offline Card Authentication Methods (CAM). All three methods use Certificate of
Authority Public Key (CAPK) technology to protect against card counterfeiting and / or card skimming.
 Static Data Authentication (SDA) – is comparable to CVV checking on magnetic-stripe
transactions as it detects alteration of selected static data elements after personalization. SDA
differs from CVV in that it is performed offline at the PINPad
 Dynamic Data Authentication (DDA) – has all the benefits of SDA and additionally protects
against copying of chip data by generating a dynamic signature for each transaction
 Combined DDA/Application Cryptogram Generation (CDA) – has all the benefits of DDA and
additionally assures that the transaction data is not altered between the card and kernel by
including transaction data as part of the DDA calculation

RQ 04600 All Offline CAM failures must be sent for online authorization
 For each of the offline CAM failure TVR bits, the TAC settings must ensure the transaction is
selected for online for authorization.

RQ 04700 If offline CAM is not performed transaction must go online

 If offline CAM is not performed, and there is no other reason to offline decline the transaction,
the TAC value must ensure that the transaction is sent online for authorization.


RQ 04800 All Offline Card Authentication Methods must be supported
All three offline Cardholder Authentication Methods must be supported (SDA, DDA and CDA).

8.11 Cardholder Verification

Cardholder Verification is used to ensure that the cardholder is legitimate and that the card has not been
lost or stolen. The kernel uses the Cardholder Verification Method (CVM) List from the card to determine
the type of verification to be performed (e.g. Signature or PIN). The CVM List establishes a priority of
CVMs to be used relative to the capabilities of the PINPad and characteristics of the transaction.
If the card does not support CVM processing or if “No CVM Required” is selected, the EMV POS Solution
must perform the cardholder verification as specified for magnetic stripe transactions:
 Signature for attended devices
 NO CVM for unattended devices

Page 82 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Note: Visa recommends merchants retain CVM information for 180 days to assist in chargeback
resolution.

8.11.1 Supported Cardholder Verification Methods (CVM)

Table 25 Cardholder Verification Methods
CVM Description
The PINPad prompts the cardholder for a PIN and transmits the cardholder-entered PIN
Offline Plaintext to the card in the clear. The card then compares the cardholder-entered PIN to the
(also known as Clear Reference PIN stored secretly in the chip.
Text PIN) Note: PIN Bypass is only allowed for U.S. PIN Debit AIDs (i.e. pressing „Enter‟ during
PIN entry without entering a PIN will not skip the PIN entry).

The PINPad prompts the cardholder for a PIN, encrypts it with public key technology
and sends it to the card, where the card decrypts it. The card then compares the
Offline Enciphered PIN cardholder-entered PIN to the Reference PIN stored secretly in the chip.
Note: PIN Bypass is only allowed for U.S. PIN Debit AIDs (i.e. pressing „Enter‟ at PIN
entry without entering a PIN will not skip the PIN entry).

The PINPad prompts the cardholder for a PIN and encrypts it using the same DUKPT
key used for magstripe debit PIN encryption. The encrypted PIN block is sent to the
Online PIN host in the online authorization message.
Note: PIN Bypass is not allowed except for U.S. Debit AIDs (i.e. Pressing Enter at PIN
entry without entering a PIN will not skip the PIN entry).

This method operates in the same manner as in the magnetic-stripe environment. The
Signature cardholder signs the transaction receipt and the merchant compares this signature to
the signature on the card.

This method operates in the same manner as in the magnetic-stripe environment where
transaction authorization is independent of cardholder verification.
NO CVM No cardholder verification is currently supported in some merchant environments, such
as certain unattended environments, quick service restaurants and other small ticket
environments. For attended environments, signature is required.

The EMV POS Solution should use the CVM Results (Tag 9F34) to determine if a signature line is
required on the receipt. For more information on receipt CVM requirements see page 140.

Note: A failed CVM does not mean that the transaction has failed or is declined. The CVM failure is
logged in the Cardholder Verification Results (CVR) and forwarded along with the Terminal Verification
Results (TVR) to the host during online authorization.

BP 02200 All CVMs should be supported

 All CVMs (Online PIN, Offline Plaintext PIN, Offline Enciphered PIN, Signature and NO CVM)
should be supported for attended solutions.

Page 83 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

BP 02300 PIN Bypass for U.S. Maestro

 MasterCard recommends that PIN Bypass be supported for attended terminals supporting the
U.S. Maestro AID.


RQ 04900 Online PIN CVM must be supported if solution supports PIN
Online PIN CVM must be supported by all EMV POS Solutions that support PIN entry.


RQ 05000 Signature CVM must be supported by attended solutions
Signature CVM must be supported by all attended EMV POS Solutions.

RQ 05100 PIN Bypass is only allowed for U.S. Debit AIDs

 PIN Bypass is only allowed for U.S. Debit AIDs. For other AIDs pressing the „Enter‟ key during
PIN entry without entering a PIN must not skip PIN entry. If the „Cancel‟ key is pressed during
PIN entry, the transaction must be cancelled.

8.11.2 PIN Prompting

The EMV POS Solution must have the ability to perform PIN prompting. Several rules must be followed
for this process:
1. The prompt text displayed for offline and online PIN entry should be identical
2. PIN Bypass is only allowed for PIN entry for U.S. Debit cards. If PIN Bypass is attempted for
other cards (by pressing the „Enter‟ key at the PIN prompt with no PIN entered), PIN entry must
not be skipped
3. The PIN Try Counter (Tag 9F17) value must be obtained before PIN entry begins and its value
must be used as the maximum number of PIN attempts allowed
4. The cardholder must be notified before the last Offline PIN attempt and when the card is blocked
because the maximum Offline PIN tries have been exceeded

Note: The PIN Try Counter (Tag 9F17) is reset every time a valid Offline PIN is entered.

RQ 05200 Maximum number of PIN tries must not exceed PIN Try Counter (Tag 9F17)
 The number of Offline PIN tries allowed must not exceed the initial PIN Try Counter (Tag
9F17) value.

RQ 05300 Cardholder must be notified of last offline PIN attempt

 The cardholder must be notified when only one invalid Offline PIN attempt remains before the
card is blocked.


RQ 05400 Cardholder must be notified when maximum Offline PIN tries is exceeded
The cardholder must be notified when Offline PIN tries have been exceeded.

Page 84 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.11.3 CVM Results Validation (Tag 9F34)

The following details how the CVM result is interpreted.

Table 26 (CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 1

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x 0 0 0 0 0 0 Fail CVM processing
x x 0 0 0 0 0 1 Plaintext PIN verification performed by card
x x 0 0 0 0 1 0 Enciphered PIN verified online
x x 0 0 0 0 1 1 Plaintext PIN verification performed by card and signature (paper)
x x 0 0 0 1 0 0 Enciphered PIN verification performed by card
x x 0 0 0 1 0 1 Enciphered PIN verification performed by card and signature (paper)
x x 0 1 1 1 1 0 Signature (paper)
x x 0 1 1 1 1 1 NO CVM

Table 27 (CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 2

Value Meaning
00 – 09 Ignore this byte

Table 28 (CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 3

Value Meaning
00 Unknown (e.g. for signature)
01 Failed (e.g. Offline PIN)
02 Successful (e.g. Offline PIN)

8.12 Terminal Risk Management

Terminal Risk Management is always performed by the kernel regardless of the setting of the „Terminal
Risk Management Is To Be Performed‟ bit in the Application Interchange Profile (Tag 82 Byte1-bit4).

Table 29 Risk Management Requirements

Type Requirement Usage
Required for all EMV POS Solutions
EMV Floor Limit Checking Mandatory
Performed by EMV kernel

Required for EMV POS Solutions capable of both offline and

Random Transaction Selection Mandatory online transactions
Performed by EMV kernel

Required for EMV POS Solutions capable of offline

transactions. Checks if the card‟s consecutive offline
Transaction Velocity Checking Mandatory transaction or cumulative offline spend limit has been
exceeded.
Performed by EMV kernel

Page 85 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Type Requirement Usage

Required for EMV POS Solutions capable of offline
New Card Verification Mandatory transactions.
Performed by EMV kernel

The following EMV Risk Management parameters control the EMV 1st Generate AC offline approval
process. These parameters are described in more detail in the following sections:
 EMV Floor Limit – Defines the maximum transaction amount that can be approved offline at the
1st Generate AC
 EMV Random Selection – Defines values used to force transactions online even if the
transaction amount is below the EMV Floor Limit

BP 02400 Terminal Risk Management features should be supported

 All EMV POS Solutions should support the EMV Terminal Risk Management features
regardless of the offline capabilities of the terminal.

8.12.1 EMV Floor Limit

For a transaction to be approved offline by the chip the EMV Floor Limit must be greater than zero. Each
card scheme has defined a maximum EMV Floor Limit that can be used for each Merchant Category
Code. TSYS does not support non-zero EMV Floor Limits; therefore, all transactions will be sent online
and will never be approved offline by the card.

Note: Even if the transaction amount is below the EMV Floor Limit the card can decline the transaction
offline for other reasons.

RQ 05500 EMV Floor Limit must be zero

 TSYS does not support offline card authorizations. The EMV Floor Limit must always be set to
zero.

8.12.2 EMV Random Selection

EMV Risk Management parameters can be set to ensure that all transactions are “Randomly Selected to
Go Online” at the 1st Generate AC, even if the transaction amount is below the EMV Floor Limit. Even
when the EMV Floor Limit is set to zero the following values should be set.

Table 30 Random Selection Parameters

Parameter Value
Target Percentage to be used for Random Selection 99%
Maximum Target Percentage to be used for Biased Random Selection 99%
Threshold Value for Biased Random Selection 0

Page 86 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Note: Most EMV kernels interpret 99% as being 100% but that should be confirmed with your
hardware vendor.

8.13 Data Object Lists

There are a number of Data Object Lists (DOL) used by the chip during transaction processing. Each
DOL is stored on the chip and contains one or more EMV tag number and length pairs identifying tag data
that should be used for specific functions. The Data Object Lists currently supported are:
 Card Risk Management Data Object List 1 (CDOL1 Tag 8C) – List of data objects (tag and
length) to be passed to the card in the first GENERATE AC command
 Card Risk Management Data Object List 2 (CDOL2 Tag 8D) – List of data objects (tag and
length) to be passed to the card in the second GENERATE AC command
 Dynamic Data Object List (DDOL Tag 9F49) – List of data objects (tag and length) to be
passed to the chip in the INTERNAL AUTHENTICATE command
 Processing Options Data Object List (PDOL Tag 9F38) – List of terminal-related data objects
(tag and length), requested by the card, and transmitted to the card in the GET PROCESSING
OPTIONS command
 Transaction Certificate Data Object List (TDOL Tag 97) – List of data objects (tag and length)
to be used by the EMV POS Solution to generate the TC Hash Value

8.13.1 Dynamic Data Object List (DDOL Tag 9F49)

The DDOL is stored on the card and contains the list of data objects (tag and length) to be passed in the
INTERNAL AUTHENTICATE command. However, in some cases the chip does not contain a DDOL.
Therefore, if the EMV POS Solution supports DDA, a Default DDOL must be defined that can be used
when the chip DDOL is not present.

RQ 05600 A Default DDOL is required for EMV POS Solutions that support DDA

 EMV POS Solutions supporting DDA must have a Default DDOL defined that can be used
when the chip does not contain a DDOL. The Default DDOL must only contain the
Unpredictable Number (Tag 9F37).

8.13.2 Transaction Certificate Data Object List (TDOL Tag 97)

The TDOL is stored on the chip and contains the list of data objects (tag and length) to be used by the
EMV application to generate the TC Hash value. In some cases the chip does not contain a TDOL.
Therefore, the EMV POS Solution should have a Default TDOL defined that can be used when the chip
TDOL is not present.

8.13.3 Processing Data Object List (PDOL Tag 9F38)

The Transaction Amount (Tag 9F02) is sometimes contained in the card PDOL list. Therefore, it is
mandatory that the Transaction Amount (Tag 9F02) be set to the total transaction amount before the Get
Processing Options step is performed.

Page 87 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.14 Terminal Action Analysis

In Terminal Action Analysis the kernel makes its authorization recommendation. This is done by
comparing three data objects:
 Issuer Action Codes (IACs) – Rules set by the issuer in the card
 Terminal Action Codes (TACs) – Rules set by the payment system in the kernel
 Terminal Verification Results (TVR) – Contains the current transaction results generated by
the Processing Restrictions, Offline Data Authentication, Cardholder Verification and Terminal
Risk Management steps
The IACs and TACs are applied against the results stored (bits set) in the TVR to determine if the
transaction should be approved offline, declined offline or sent online for an authorization.
The results from Terminal Action Analysis will determine the cryptogram to be requested by the kernel
from the card in the 1st Generate AC.

8.14.1 Issuer Action Codes (IACs)

The IACs are three data elements personalized on the card by the issuer. The IACs consist of a series of
bits with each bit corresponding to a bit in the Terminal Verification Results (TVR). When an IAC bit is set
to „1‟ and the corresponding TVR bit is set to „1‟ then the action specified by the IAC is taken. There are
three possible actions; decline offline, go online for an authorization and decline offline if online
authorization is unable to complete:
 IAC-Denial – Tag 9F0E (used at 1st Generate AC)
The issuer sets the IAC bits to „1‟ that correspond to the TVR bits for conditions which the issuer
wants to result in a 1st Generate AC offline decline.
 IAC-Online – Tag 9F0F (used at 1st Generate AC)
The issuer sets the bits to „1‟ that correspond to the TVR bits for conditions which the issuer
wants to result in the 1st Generate AC requesting an online authorization.
 IAC-Default – Tag 9F0D (used at 2nd Generate AC)
The issuer sets the bits to „1‟ that correspond to the TVR bits for conditions which the issuer
wants to result in a 2nd Generate AC decline when online processing was requested, but was not
possible.

8.14.2 Terminal Action Codes (TACs)

The TACs are three data elements set by the card scheme and loaded as parameters by the EMV POS
Solution. The TACs consist of a series of bits with each bit corresponding to a bit in the Terminal
Verification Results (TVR). Similar to the card‟s IACs, when a TAC bit is set to „1‟ and the corresponding
TVR bit is set to „1‟, the action specified by the TAC is taken. There are three possible actions: decline
offline; go online for an authorization; decline offline if online authorization is unable to complete.
The three TACs defined by the card schemes are:
 TAC-Denial – No Tag defined (used at 1st Generate AC)
The card scheme sets the TAC bits to „1‟ that correspond to TVR bits for conditions which the
card scheme wants to result in a 1st Generate AC offline decline.
 TAC-Online – No Tag defined (used at 1st Generate AC)

Page 88 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

The card scheme sets the bits to „1‟ that correspond to TVR bits for conditions which the card
scheme wants to result in the 1st Generate AC requesting an online authorization.
 TAC-Default – No Tag defined (used at 2nd Generate AC)
The card scheme sets the bits to „1‟ that correspond to the TVR bits for conditions which the card
scheme wants to result in a 2nd Generate AC decline when online processing was requested, but
was not possible.

8.15 1st Generate Application Cryptogram

The 1st Generate AC consists of two steps. The first step is for the kernel to request the Generate AC.
The second step is performed by the card and results in the Generate AC response.
1. Terminal Action Analysis – The kernel makes an authorization recommendation and then
sends a GENERATE AC command to the card with this recommendation
2. Card Action Analysis – The card makes the initial authorization decision to; offline approve (not
supported by TSYS), offline decline or request online authorization, and returns the decision to
the EMV kernel

8.15.1 Terminal Action Analysis

During Terminal Action Analysis the kernel analyzes the IAC, TAC and TVR values, and sends a
GENERATE AC command requesting the card to return an Application Cryptogram with its offline
authorization decision. This 1st Generate AC command must:
1. Specify whether a CDA signature is requested
2. Indicate the type of Application Cryptogram being requested based on the kernel‟s preliminary
authorization decision:
- AAC – Decline the transaction (this is generally used to terminate chip interaction for Partial
EMV transactions, e.g. credit Refund after card data has been obtained)
- ARQC – Process the transaction online
- TC – Approve the transaction offline (should never occur as TSYS requires the EMV Floor
Limit be set to zero)
3. Provide the transaction data required by the card to perform Card Risk Management
4. Provide the transaction data required to calculate the Application Cryptogram (data required by
the chip is specified by CDOL1 (Tag 8C) retrieved from the chip during the Read Application Data
stage).

8.15.2 Card Action Analysis

The EMV card performs Card Action Analysis and responds with one of three possible decisions based
on the type of cryptogram requested in the 1st Generate AC command. This decision is returned in the
Cryptogram Information Data (Tag 9F27):
1. AAC ( Decline) Requested – card must respond with:
- AAC – Declined
2. ARQC (Online authorization CID=80/90) Requested – card may respond with either:
- ARQC – Go Online (online issuer authorization required)

Page 89 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

- AAC – Declined
3. TC (Approval CID=40/50) Requested – card may respond with any of the following:
- TC – Approved
- ARQC – Online Authorization Required
- AAC – Declined

Note: The Application Cryptogram returned by the card will always be the same or more restrictive
than the Application Cryptogram requested.
For example, if the GENERATE AC command requests that the transaction go online for authorization
(requests an ARQC), the chip will either agree (return an ARQC) or decline the transaction (return an
AAC). In this case the chip cannot offline approve the transaction (return a TC).

8.16 Stand-In Processing (STIP)

It is sometimes not possible to obtain on-line authorizations due to communication issues or host
outages. In these situations it is possible for the EMV POS Solution to approve EMV credit card
transactions offline. However, this is not supported for EMV PIN debit transactions which must always be
approved online.
There are four types of authorizations possible for EMV transactions:
1. Transaction is authorized on-line by the issuer:
- This is the usual transaction approval method
- The issuer assumes the liability for the transaction
2. Transaction is authorized on-line by the acquirer (i.e. TSYS):
- In situations where the acquirer is unable to access the payment network the acquirer may
authorize the transaction (Acquirer Stand-In)
- The acquirer assumes liability for the transaction
3. Transaction is authorized by the Merchant host (if any):
- In situations where the merchant host is unable to access the TSYS host the merchant host
may do one of the following:
 Authorize the transaction (Merchant Stand-in) – the merchant usually assumes liability
for the transaction
 Send a response back to the EMV POS Solution requesting it to proceed with merchant
stand-in approval
4. Transaction is approved by the merchant as a stand-in authorization
- In these cases the transaction is approved only if the transaction amount is below the
merchant stand-in floor limit
- With EMV transactions there is additional transactional data available to assist with the stand-
in authorization process which allows the merchant to minimize the risk of stand-in
authorizations
- The merchant assumes the liability of the stand-in authorization

Page 90 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

RQ 05700 EMV PIN Debit transactions must always be sent online for authorization

 Merchant stand-in processing is not supported for EMV debit transactions. All EMV PIN debit
transactions must be sent online for authorization. If this is not possible the transaction must
be declined.

8.16.1 Merchant Stand-in Processing

The following transaction flow describes the steps required to perform Merchant Stand-in Authorization
for an EMV credit card transaction:
1. Check if Stand-in processing is enabled and if not, decline the transaction
2. Check if the transaction amount is below the Stand-in Floor Limit for this card type. Each card
scheme could have a different Stand-in Floor Limit. Proceed if the transaction amount is below
the Stand-in Floor Limit; otherwise, decline the transaction.
3. Check if the card is domestic (i.e. issued within USA). This can be determined by ensuring the
that Issuer Country Code (Tag 5F28) = “840”. International cards pose a higher risk and should
not be approved using stand-in authorization. Proceed if card is domestic; otherwise, decline the
transaction.
4. Apply the TVR Mask to the transaction‟s Terminal Verification Results (Tag 95) value. If any of
the bits in the TVR match the corresponding bits in the TVR Mask then a condition exists that
indicates the transaction should not be approved via stand-in authorization. The recommended
TVR Mask is „FD 7F FB 27 0F‟ which means that if any of the following conditions exists, the
transaction should be declined:
- Offline data authentication not performed
- Offline static data authentication failed
- ICC data missing
- Card appears on terminal exception file
- Offline dynamic data authentication failed
- Offline CDA failed
- Application expired
- Application not effective
- Requested service not allowed
- Cardholder verification not successful
- PIN entry required and PINPad not present or inoperable
- PIN entry required, PINPad present but PIN was not entered
- Upper consecutive off-line limit exceeded
- Any reserved for future use bits
Proceed if a bitwise AND of the TVR and TVR Mask bits are all zero; otherwise, decline the
transaction.
5. Use the TSI Mask and the transaction‟s Transaction Status Indicator (Tag 9B) value to check that
the required EMV transaction steps were performed. If any of the bits in the TSI are zero in the
corresponding bits of the TSI Mask then a required EMV transaction step was not performed.
The recommended TSI Mask is „E8 00‟ which means that the following transaction steps were
performed:
- Off-line data authentication performed
- Cardholder Verification performed

Page 91 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

- Card Risk Management performed

- Terminal Risk Management performed
Proceed if a bitwise AND of the TSI and TSI Mask equals the TSI Mask; otherwise, decline the
transaction.
6. If all steps pass the transaction should be approved.

Page 92 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.16.2 Merchant Stand-In Processing Flowchart

If the host is not available and an AAC cryptogram is generated at the 2nd Generate AC, Merchant
Stand-in Processing may be performed.

Auth Host
Not
Available

2nd GENERATE AC
Authorization Response Code (Tag 8A) = Z3
(Host Not Available, Zero EMV Floor Limit)

AAC (Declined)

Merchant STIP

Standin
No
Enabled?

Yes

Amount < Standin

Floor Limit?
No

Yes

Is EMV Card
Domestic?
No

Yes

TVR &
No
TVR_Mask = 0?

Notes:
1. Stand-in Floor limit should be Yes
defined for each card scheme
2. A card will be considered
domestic if the Issuer Country TSI & TSI_Mask No
Code tag = 840 = TSI_Mask?

3. TVR Mask = FD 7F FB 27 0F
Yes
4. TSI Mask = E8 00

Stand-in Declined
Approved

Page 93 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.17 Offline Transaction Upload

Prior to performing Settlement, all offline approved transactions must be uploaded to the host. Uploading
Merchant STIP (offline) approved transactions may be done using the same process used for traditional
magstripe transactions.
For terminal capture implementations, the offline approved transactions may be uploaded at settlement
time or using a settlement Data Capture EIS1081 record with an Authorization Source Code = „6‟
indicating the POS Device generated the authorization code.
For host capture implementations, the offline approved transactions must be sent to the host individually
or in a transaction batch prior to or at settlement.

8.18 Online Response Processing

When a transaction is sent online for authorization the host may return several data elements required by
the card during 2nd Generate AC, External Authenticate and Issuer Script processing (Full EMV
transactions only). This applies to both host approved and host declined transactions.
The data elements required by the card to complete an online transaction are:
 Issuer Response Code (Tag 8A) – This is not returned by the TSYS host and must be set
based on the Response Code field as per the following chart

Tag 8A
Host Decision
ASCII Hex
Approved 00 0x3030

Declined 05 0x3035

 Issuer Authentication Data (Tag 91) – Used for External Authenticate (see page 90) - as
returned in the EIS Group 3 Version 55 field (TLV EMV Tag Data) / Summit <A111> field
 Issuer Scripts (Tag 71 or Tag 72) – Issuer Script commands are forwarded to the card by the
PINPad kernel for execution - as returned in the EIS Group 3 Version 55 field (TLV EMV Tag
Data) / Summit <A111> field

The card will return one of the following in the 2nd Generate AC response:
 TC (CID=40/50) – The transaction was approved
 AAC (CID=00) – The transaction was declined (If the transaction was originally approved by the
issuer, a Reversal must be sent to the host)

RQ 05800 Issuer Response Code must be set based on host Response Code

 The EMV POS Solution must interpret the host Response Code field and set the Authorization
Response Code (Tag 8A) to indicate if the transaction was approved or declined by the host.
This must be done before the 2nd Generate AC command is sent to the card.

Page 94 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

RQ 05900 Issuer scripts must be supported in host responses

 The TSYS host may return an Issuer Script (Tag 71 or Tag 72) in the host response. The
EMV POS Solution must be capable of extracting the script and forwarding it to the kernel for
execution by the card.

8.18.1 Partial Authorizations

For gift or pre-paid cards it is possible for the host to partially approve a transaction for an amount less
than the amount requested. When this occurs the cardholder must be prompted to accept the lower
authorization amount before the External Authenticate or 2nd Generate AC processing is performed.
If the cardholder does not approve the authorized amount, the cardholder should be prompted to remove
the card, a host reversal should be sent and the transaction should be cancelled.
If the cardholder wishes to continue the transaction using the lower amount the EMV POS Solution must:
1. Store the lower authorized amount in Transaction Amount (Tag 9F02) and make sure it is
updated in the kernel
2. Set Authorization Response Code (Tag 8A) = 0x3030 to indicate the transaction was approved
3. Perform an External Authenticate (if required by kernel)
4. Perform a 2nd Generate AC
The transaction is now complete and the receipt should be printed using the updated Transaction Amount
(Tag 9F02).

RQ 06000 Reversal must be sent if cardholder declines partial authorization


If the host returns a partial authorization and the cardholder does not wish to continue the
transaction using the lower amount, the EMV POS Solution must request a decline (AAC) at
the 2nd Generate AC, reverse the transaction to the host and set the Authorization Response
Code (Tag 8A) to 0x3035.

RQ 06100 Transaction Amount (Tag 9F02) must reflect the partially authorized amount

 If the host returns a partial authorization and the cardholder wishes to continue the transaction,
the Transaction Amount (Tag 9F02) must be updated to reflect the lower authorized amount
and then sent to the kernel prior to the 2nd Generate AC.

RQ 06200 Partially authorized amount must be sent in the settlement message

 The amount sent in the settlement message for the transaction must reflect the lower partially
authorized amount.

8.18.2 Referrals

The TSYS host will return a Referral response when additional information is required and a voice
authorization should be attempted. When this occurs, the current transaction must be cancelled. If the
voice authorization is successful another transaction can be processed to obtain the funds.

Page 95 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

RQ 06300 Referral transactions must be cancelled

 When a Referral response is received from the TSYS host the transaction must be cancelled
by requesting a Decline (AAC) at the 2nd Generate AC.

8.19 External Authenticate

External Authenticate is used to validate that the Issuer Authentication Data (Tag 91) included in an
issuer authorization response message is valid and was created by the issuer.
An EXTERNAL AUTHENTICATE command must be sent to the card when the host response includes
Issuer Authentication Data (Tag 91) and the Application Interchange Profile (Tag 82 Byte1-Bit3) indicates
that the chip supports Issuer Authentication.

Note: Some cards do not support the EXTERNAL AUTHENTICATE command and will validate the
ARPC as part of the 2nd Generate AC processing. This is managed by the EMV kernel.

8.20 2nd Generate Application Cryptogram

The last step of the issuer authorization process (Full EMV transactions only) is for the EMV POS
Solution to send the card a GENERATE AC command requesting the card to return a final Application
Cryptogram. This is generally referred to as the 2nd Generate AC (or 2nd Gen AC). The 2nd Generate
AC command must:
1. Indicate the type of Application Cryptogram being requested based on the host (or stand-in)
authorization decision:
- AAC – Decline the transaction (issuer declined the transaction)
- TC – Approve the transaction (issuer approval)
2. Provide the transaction data required to calculate the Application Cryptogram (data required by
the chip is specified by CDOL2 (Tag 8D) retrieved from the chip during the initial Read
Application Data processing)

The EMV chip responds with one of two possible decisions based on the type of cryptogram requested in
the 2nd Generate AC command:
1. AAC (Decline requested) – card must respond with:
- AAC – Declined
2. TC (Approval requested) – card may respond with either of the following:
- TC – Approved
- AAC – Declined

Note: The Application Cryptogram returned by the card will always be the same or more restrictive
than the Application Cryptogram requested by the Generate AC command.
For example, if the 2nd Generate AC command requests that the transaction be declined (requests an
AAC), the chip will always agree (return an AAC). In this case the chip cannot approve the transaction
(return a TC).

Page 96 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

8.20.1 Issuer Script Processing

If an Issuer Script is returned by the issuer it must be sent to the kernel for execution by the card prior to
performing the 2nd Generate AC. Tag 71 scripts will be executed before the 2nd Generate AC decision
and Tag 72 scripts will be executed after the 2nd Generate AC.
A host response will never contain both Tag 71 and Tag 72 Issuer Scripts. A maximum of one Issuer
Script will be returned in each host response message.

RQ 06400 Issuer Scripts must be executed for approved and declined transactions
 Issuer Scripts returned in the host response message must be sent to the card for execution
regardless of whether the transaction was approved or declined.


RQ 06500 Must support Issuer Scripts up to 128 bytes in length
The EMV POS Solution must support Issuer Scripts up to 128 bytes in length.

RQ 06600 Handling Issuer Script errors

 If an error is returned from an Issuer Script command, the transaction should not be terminated
but no other issuer commands should be sent to the card. If a Tag 71 Issuer Script returns an
error, the application should continue to the 2nd Generate AC command.

8.21 Transaction Completion Processing

Transaction Completion Processing consists of analyzing the final card decision to determine if a host
reversal is required, performing the reversal when required, prompting the cardholder to remove the card,
printing receipts and storing the transaction data in the transaction batch.

8.21.1 Reversal Processing

EMV POS Solutions must support several additional reversal reasons in addition to the standard reversal
processing required by traditional magstripe implementations. The additional reversal requirements are
because Full EMV transactions return the online authorization decision to the card for final authorization.
Reversals are only required if online host authorization was completed and the transaction was approved
by the host. When generating a reversal for an EMV transaction EMV tags must be included in the host
reversal message. The following table identifies the EMV reversal reasons and whether EMV tag data
from the first or second Generate AC is required in the reversal message.

Table 31 EMV Reversal Types

Reversal Reason EMV Tags Description
PINPad disconnected or malfunctioning when attempting 2nd
PINPad Unavailable 1st Generate AC
Generate AC

Transaction is cancelled by the merchant or cardholder (after host

Transaction Cancelled 1st Generate AC
authorization)

Card Removed 1st Generate AC Card was removed card before 2nd Generate AC

Page 97 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Reversal Reason EMV Tags Description

Card returned an error during 2nd Generate AC or External
Authenticate processing indicating the chip is malfunctioning
Chip Error 1st Generate AC Note: For a chip malfunction at the 2nd Generate AC, MasterCard
requires that the authorization decision be based on the issuer
decision from the host response message (Approved/Declined).

The card declined the host-approved transaction at the 2nd

Card Decline 2nd Generate AC
Generate AC

RQ 06700 EMV transaction reversals must include EMV tags

 All reversals for EMV transactions must include tag data from either the 1st or 2nd Generate
AC. The list of tags sent must match the original authorization message but must be updated
to include 2nd Generate AC values if a 2nd Generate AC is performed.

8.21.2 Card Removal Prompting

When the transaction completes the cardholder should be prompted to remove their card before receipts
are printed.

BP 02500 Do not print receipt until the card has been removed
 It is recommended that the EMV POS Solution does not print a receipt until the cardholder has
removed the card. This decreases the incidence of the cardholder forgetting their card.

BP 02600 Sound audible beep while waiting for card to be removed

 It is recommended that the EMV POS Solution sound an audible beep while waiting for the
EMV card to be removed. This decreases the incidence of the cardholder forgetting their card.

8.21.3 Transaction Storage

At the completion of a transaction the EMV data must be stored to ensure it is available for settlement or
problem determination reporting. The following table identifies the EMV tags that should be stored in the
transaction batch.

Table 32 Transaction Batch EMV Tag Information Required

Tag Tag Name Comment
9F03 Additional Amount
9F26 Application Cryptogram 1st Generate AC value
9F26 Application Cryptogram 2nd Generate AC value
4F Application ID
82 Application Interchange Profile
50 Application Label
9F12 Application Preferred Name
9F40 Application Terminal Capabilities

Page 98 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Tag Tag Name Comment

9F36 Application Transaction Counter
9F07 Application Usage Control
9F09 Application Version Number
8A Authorization Response Code Final value
9F27 Cryptogram Information Data 1st Generate AC value
9F27 Cryptogram Information Data 2nd Generate AC value
9F34 CVM Results
84 Dedicated File Name
5F24 Expiry Date
9F0D IAC Default
9F0E IAC Denial
9F0F IAC Online
9F10 Issuer Application Data
91 Issuer Authentication Data
9F11 Issuer Code Table Index
5A PAN Encrypted / Masked / Tokenized
5F34 PAN Sequence Number
9F39 POS Entry Indicator
9F33 Terminal Capabilities
9F1A Terminal Country Code
95 Terminal Verification Results 1st Generate AC value
95 Terminal Verification Results 2nd Generate AC value
9F02 Transaction Amount
5F2A Transaction Currency Code
9A Transaction Date
9F21 Transaction Time
9F35 Terminal Type
9C Transaction Type
9B Transaction Status Indicator Final value
9F37 Unpredictable Number

RQ 06800 Last EMV transaction data must be available even if transaction is declined
It is mandatory that the f EMV transaction tag data be retained so it can be printed if
 necessary. This applies to all transactions regardless of whether they are approved or
declined.
It is preferred that EMV transaction data be available for every transaction in the batch.

Page 99 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

9. Certificate Authority Public Key Management

The Certificate Authority Public Keys (CAPKs) must be loaded into the EMV POS Solution. This can be
accomplished in two ways:
1. TSYS will provide the CAPKs in a document, per card brand and the values must be entered into
the EMV POS Solution.
2. If you already have a relationship with the card brands, they will be able to provide to you the
needed CAPK files.

Page 101 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 102 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

10. EMV and Contactless Parameters

The following sections list the EMV and contactless parameters that should be supported by EMV POS
Solutions. Production parameter values can be obtained in two ways:
1. TSYS will provide the EMV and contactless parameters in a document and they must be entered into
the EMV POS Solution.
2. The parameters can be downloaded from OneTouch POS. The details of the download process and
message details can be found in the EMV Direct Access Plus Specification.
For development and certification parameter values see page 207.

10.1 Contact EMV Parameters

Table 33 Contact EMV Parameters
Tag Name Report Label Description

Additional Terminal Addl Capability Indicates the data input and output capabilities of the
9F40
Capabilities terminal.

Allow Fallback Flag Allow Fallback Controls whether fallback to swipe is allowed for a
card type when an error occurs while reading the
chip.

Allow PIN Bypass Allow PIN Bypass Identifies if PIN entry can be bypassed by pressing
the „Enter‟ key without entering a PIN.
Note: Method used to bypass the PIN prompt may
differ based on the PINPad being used.

9F06 Application Identifier (AID) AID Uniquely identifies the application (RID + PIX).

Application Version Number App Ver Num Pri Version number assigned for the application by the
9F09
(Primary) payment system.

Application Version Number App Ver Num Sec (Optional) Secondary version number assigned for
9F09
(Secondary) the application by the payment system.

Certificate Authority Public CAPKx Index Certificate Authority Public Key index number.
Key Index Number

Certificate Authority Public CAPKx Exp Date Certificate Authority Public Key expiry date.
Key Expiry Date

Default AID Label AID Label EMV POS Solution assigned AID label.
Used when both Application Preferred Name (Tag
9F11) and Application Label (Tag 50) are unavailable
or unusable.

Default DDOL (Dynamic Default DDOL Used to construct the Internal Authenticate command
Data Authentication Data if card DDOL is not present on the card.
Object List) Padded with trailing zeroes.

Default TDOL (Transaction Default TDOL Used to construct the TC Hash Value if card TDOL is
Certificate Data Object List) not present on the card.
Padded with trailing zeroes.

Page 103 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Tag Name Report Label Description

EMV Random Selection Rand Sel Max% Maximum percentage of transactions having a value
Maximum Percentage more than the EMV Random Selection Threshold
that must be sent online.
Numeric, 0 to 99.

EMV Random Selection Rand Sel Target% Percentage of transactions having a value more than
Target Percentage EMV the Random Selection Threshold that must be
sent online.
Numeric, 0 to 99.

EMV Random Selection Rand Sel Thresh The transaction amount which is used to determine
Threshold when to apply random selection to go online.
Numeric, whole numbers.

Merchant Category Code Merch Cat Code Type of business being performed by the merchant‟s
9F15 device, represented according to ISO standard
8583:1993.

Partial Name Selection Flag Partial Select Used to determine whether the terminal„s AID must
exactly match the entire card AID including issuer
suffix or whether only the AID portion must match to
be selected.

Terminal Action Code – TAC Default Identifies conditions where the transaction should be
Default offline declined at the 2nd Generate AC if unable to
go online.

Terminal Action Code – TAC Denial Identifies conditions that cause a transaction to be
Denial offline declined at the 1st Generate AC.

Terminal Action Code – TAC Online Identifies conditions that cause a transaction to be
Online sent for online authorization at the 1st Generate AC.

Terminal Capabilities Term Capability Identifies the supported hardware, cardholder

9F33
verification methods and security capabilities.

9F1A Terminal Country Code Term Country “840” represents USA.

5F2A Terminal Currency Code Term Currency “840” represents U.S. Dollars.

Terminal Currency Trans Curr Exp Number of digits to the right of the decimal place in
5F36 Exponent the currency.
E.g. If the value is „2‟ then 12345 represents 123.45.

Terminal Floor Limit (EMV) Term Floor Lim The amount indicating the lowest value at which
9F1B
EMV transactions must seek online authorization.

Terminal Type Term Type Indicates the environment of the terminal, its
9F35 communications capability and its operational
control.

Transaction Category Code Trans Cat Code MasterCard AIDs only.

9F53
May be used to assist with Card Risk Management.

Page 104 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

10.2 Contactless EMV Parameters

Table 34 Contactless EMV Parameters
Tag Name EMV Report ID Description
Contactless CVM Required CTLS CVM Req Transaction amount above which a CVM is required
Limit Lim and the Contactless Terminal Capabilities CVM
Required setting should be used.

Contactless Floor Limit CTLS Floor Limit The number indicating the lowest value at which
contactless EMV transactions must seek
authorization online.

Contactless Terminal CTLS Used to overwrite Terminal Capabilities when the

Capabilities CVM Req TermCapCVMR transaction amount is above the Terminal CVM
Required Limit (i.e. CVM is Required).
MasterCard Only

Contactless Terminal CTLS Used to overwrite Terminal Capabilities when the

Capabilities CVM NotReq TermCapCVMN transaction amount is below the Terminal CVM
Required Limit (i.e. NO CVM).
MasterCard Only

Contactless Transaction CTLS Trans Limit Amounts above this limit cannot be performed as
Limit contactless transactions.

Default UDOL Default UDOL list used to Compute Cryptographic

Checksum when a TDOL is not available.
Default 0x9F, 0x6A, 0x04 – Unpredictable Number
(Tag 9F6A)
M/Chip Only

Enable ExpressPay EMV Enable ExPay Flag indicating if ExpressPay contactless EMV is
EMV supported.
Amex Only

Enable ExpressPay MSD Enable Flag indicating if ExpressPay contactless MSD is

ExPayMSD supported.
Amex Only

Enable MChip Enable MChip Flag indicating if PayPass contactless EMV is

supported.
MasterCard Only

Enable MStripe Enable MStripe Flag indicating if PayPass contactless MSD is

supported.
MasterCard Only

9F6D MSD Version Number MSD Version Num Version number assigned by the payment system for
the specific PayPass – Mag Stripe functionality of the
application.
MasterCard Only

9F66 Visa TTQ Visa TTQ Terminal Transaction Qualifiers

Visa Only.

Page 105 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 106 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11. Host Message Formats

This section describes the EIS and Summit host request and response message formats.

11.1 Host EIS 1080 Message Formats

This section describes the EIS 1080 host request and response message formats.

11.1.1 EIS 1080 Request Message Format

The EIS 1080 EMV request message format is almost identical to the non-EMV request message format.
The “Reference” column identifies the fields that are related to EMV transactions.

Table 35 EIS 1080 Request Message Format

Byte Length Format Field Description Content Reference
1 1 A/N Record Format D
2 1 A/N Application Type 0, 2, 4
3 1 A/N Message Delimiter .
4-9 6 NUM Acquirer BIN TSYS Assigned
10-21 12 NUM Merchant Number TSYS Assigned
22-25 4 NUM Store Number TSYS Assigned
26-29 4 NUM Terminal Number TSYS Assigned
30 1 A/N Device Code X EMV
31 1 A/N Industry Code A, B, F, G, H, L, O, P, R
32-34 3 NUM Currency Code 840 – US Dollars
35-37 3 NUM Country Code 840 – United States
38-46 9 A/N City Code (ZIP) Left-justified / space-filled
47-48 2 NUM Language Indicator 00 – English
49-51 3 NUM Time Zone Differential 705, 706, 707, 708
52-55 4 NUM Merchant Category Code TSYS Assigned
56 1 A/N Requested ACI Y
57-60 4 NUM Tran Sequence Number 0001
61-62 2 A/N Transaction Code 54
63 1 A/N Cardholder ID Code F, K, P, Z, @ EMV
64 1 A/N Account Data Source G, P, Q, R, S, W, Z EMV
- 5-76 A/N Customer Data Field Full Track 2 (Tag 57) EMV
- 1 A/N Field Separator <FS>
- 1 A/N Field Separator <FS>
- 1 A/N Field Separator <FS>
- 1-12 NUM Transaction Amount
- 1 A/N Field Separator <FS>
- 0-12 NUM Secondary Amount
- 1 A/N Field Separator <FS>

Page 107 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Byte Length Format Field Description Content Reference

- 1 A/N Field Separator <FS>
- 40 A/N Card Acceptor Data
- 1 A/N Field Separator <FS>
- 1 A/N Field Separator <FS>
- 1 A/N Field Separator <FS>
- 3 NUM Group III Version 011 011
- 6 A/N Chip Condition Code EMV
- 1 A/N Group Separator <GS>
- 3 NUM Group III Version 020 020
- 6 A/N Developer ID TSYS Assigned
- 4 A/N Version ID TSYS Assigned
- 1 A/N Field Separator <FS>
- 1 A/N Field Separator <FS>
- 1 A/N Group Separator <GS>
- 3 NUM Group III Version 027 027
- 12 A/N POS Data Code EMV
- 1 A/N Group Separator <GS>
- 3 NUM Group III Version 055 055
- 6-255 ASCII Hex TLV EMV Tag Data EMV
- 1 A/N Field Separator <FS>
- 1 A/N Group Separator <GS>

Page 108 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.1.2 EIS 1080 Response Message Format

The EIS 1080 EMV response message format is almost identical to the non-EMV response message
format. The “Reference” column identifies the fields that are related to EMV transactions.

Table 36 EIS 1080 Response Message Format

Byte Length Format Field Description Content Reference
1 1 A/N Record Format E
2 1 A/N Application Type 0, 2, 4
3 1 A/N Message Delimiter .
4 1 NUM Return ACI
5-8 4 NUM Store Number TSYS Assigned
9-12 4 NUM Terminal Number TSYS Assigned
13 1 A/N Authorization Source Code
14-17 4 A/N Tran Sequence Number
18-19 2 A/N Response Code
20-25 6 A/N Approval Code
26-31 6 NUM Local Transaction Date MMDDYY
32-37 6 NUM Local Transaction Time HHMMSS
38-53 16 A/N Auth Response Text
54 1 A/N AVS Result Code
55-66 12 NUM Retrieval Reference Number
67 1 A/N Market Data Identifier
- 0-15 A/N Transaction Identifier
- 1 A/N Field Separator <FS>
- 0,4 A/N Validation Code
- 3 NUM Group III Version 020 020
- 1 A/N Group Separator <GS>
- 3 NUM Group III Version 027 027
- 12 A/N POS Data Code
- 1 A/N Group Separator <GS>
- 3 NUM Group III Version 055 055 EMV
- 6-255 ASCII Hex TLV EMV Tag Data EMV
- 1 A/N Field Separator <FS>
- 1 A/N Group Separator <GS>

Page 109 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.1.3 EIS 1081 Settlement Record

Note: Where the card brand requirements determine if a field needs to be included or not:
 R – Required
 O – Optional
 C – Conditional

Table 37 EIS 1081 Chip Card Addendum Record Format

Card Brand
V M A D Length Format Field Description Content Ref
1 A/N Record Format K
1 NUM Application Type
1 A/N Message Delimiter .
1 NUM X.25 Routing ID Z
5 NUM Record Type C
O R R R 2 NUM Transaction Type Tag 9C EMV
O R R R 6 NUM Transaction Date Tag 9A EMV
O R R R 10 A/N Terminal Verification Results Tag 95 EMV
O R R R 3 NUM Terminal Currency Code Tag 5F2A EMV
O R R R 4 A/N Application Transaction Counter Tag 9F36 EMV
O R R R 4 A/N Application Interchange Profile Tag 82 EMV
O R R R 16 A/N Application Cryptogram Tag 9F26 EMV
1
O R R C 8 A/N Unpredictable Number Tag 9F37 EMV
1
O C R C 64 A/N Issuer Application Data Tag 9F10 EMV
O R R O 2 A/N Cryptogram Information Data Tag 9F27 EMV
O O O R 6 A/N Terminal Capabilities Tag 9F33 EMV
O C R R 3 NUM PAN Sequence Number Tag 5F34 EMV
O O O R 32 A.N Issuer Authentication Data Tag 91 EMV
O R O O 6 A/N CVM Results Tag 9F34 EMV
2
O O O C 50 A/N Issuer Script Results Tag 9F5B EMV
O O O O 8 A/N Form Factor Identifier Tag 9F6E EMV

Notes:
1. If this field is available
2. If an Issuer Script (Tag 71 or Tag 72) was processed

Page 110 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.1.4 EIS Message Data Fields

The following sections identify the fields required for EIS EMV transactions.

11.1.4.1 Device Code

The Device Code is a one-character field identifying the device type of the EMV POS Solution submitting
the authorization request. This field should be configured as a parameter.
 “X” – Identifies an EMV mode contact and / or contactless terminal. This value must be used on
all EMV chip card transactions.
The EIS 1080 specification provides a summary of all currently defined Device Codes.

11.1.4.2 Cardholder ID Code

The Cardholder ID Code is a one-character field identifying the method used to verify the cardholder
identity when performing an EMV transaction.
The EIS 1080 specification provides a summary of all the currently defined Cardholder ID Codes.

Table 38 Cardholder ID Code

ID Code Identification Method
F Offline PIN Authentication for EMV transactions
K Online PIN using DUKPT PIN
P NO CVM
@ Cardholder Signature (No PINPad is available)
Z Cardholder Signature (PINPad is available)

11.1.4.3 Account Data Source

The Account Data Source is a one-character field identifying the source of the Customer Data Field.

Table 39 Account Data Source

Code Account Source
G Chip Card Read Data
P Manually keyed in an EMV capable terminal
Q Contactless payment device using track data rules (only Track 2 sent to the host)
R Contactless payment device using EMV-Chip data rules
S Full magnetic stripe read (Track 2 only), EMV capable terminal
Chip card processed as magnetic stripe due to the terminal application not having any EMV
W applications in common with the chip card Empty Candidate List
(i.e. MSR Fallback)
Chip card processed as magnetic stripe from an EMV terminal, due to card or terminal failure.
Z (i.e. Technical Fallback)
Note: For this value the G3v011 Chip Condition Code field must be sent

11.1.4.4 Chip Condition Code

The Chip Condition Code is a one-character field that provides information about magnetic stripe read
transactions, using chip capable cards, at chip capable POS devices.
The Chip Condition Code (Group 3 Version 11) field must be sent when the Account Data Source is “Z”.

Page 111 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 40 Chip Condition Code

Value Description
Service code does not begin with a two (2) or six (6).
0
This value should be used when the EMV POS Solution is in fallback and a non-chip card is swiped.

Service code begins with two (2) or six (6); last Chip Card Read Data at the chip capable terminal
was successful, was not a chip transaction or was unknown.
1
This value should be used when the EMV POS Solution is in fallback due to a chip malfunction.
(i.e. The chip returned an error code like 0x6985)

Service code begins with two or six; last transaction at the chip capable terminal was unsuccessful
chip read.
2
This value should be used when the EMV POS Solution is in fallback due to a chip read error where
no communication with the chip card was possible.

11.1.4.5 Customer Data Field

The following shows an example of Track 2 Equivalent Data (Tag 57) as read from a chip card. Card
information read from the chip must be sent to the host exactly as read from the chip:

4761739001010010D151220114380448F

Notes:
1. Hex „D‟ (0xD) is used (Instead of “=”) to separate the PAN and expiry date.
2. Hex „F‟ (0xF) is used to right pad the data to an even number of nibbles.

11.1.4.6 Group III Version 027 POS Data Code

The POS Data Code is a fixed 12 characters string (S1 to S12) that indicates the condition of the POS
device at the time of the transaction. This field must be sent on all transactions from a device that is
capable of reading an EMV or contactless chip card. The following table shows values that are applicable
for a chip capable device.

Page 112 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 41 Group III Version 027 (POS Data Code)

Field Value Account Source
Terminal Data - Card Data Input Capability
5 Integrated Circuit Card (ICC) capability
A PAN auto-entry via contactless magnetic stripe
C Magnetic stripe reader, ICC and key entry capability
S1
D Magnetic stripe reader and ICC capability
E ICC and key entry capability
H ICC Reader and Contactless Capability
M PAN auto-entry via contactless chip
Terminal Data - Cardholder Authentication Capability
0 No electronic authentication capability
S2
1 PIN entry capability
2 Electronic signature analysis capability
Terminal Data - Card Capture Capability
0 No card capture capability
S3
1 Card capture capability
9 Unspecified, data not available
Terminal Operating Environment
S4 1 On card acceptor premises; attended terminal
2 On card acceptor premises; unattended terminal
Cardholder Present Data
S5 0 Cardholder present
1 Cardholder not present; unspecified reason
Card Present Data
0 Card not present
S6
1 Card present
X Contactless chip
Card Data - Input Mode
C Online Chip
F Offline Chip
S7
M PAN auto-entry via contactless Chip Card (EMV Mode)
N Track data read, chip capable terminal, chip data could not be read (Technical Fallback)
P Empty Candidate List fallback (MSR Fallback)
Cardholder Authentication Method
0 Cardholder not authenticated
S8 1 Cardholder entered PIN (offline PIN or online PIN)
2 Electronic signature
5 Manual signature
Cardholder Authentication Entity
0 Not authenticated
1 Offline PIN authenticated by chip card
S9
2 Authenticated by card acceptance device
3 Online PIN authenticated by authorizing agent
4 Signature validated by merchant or card acceptor
Card Data Output Capability
S10 1 None
3 ICC

Page 113 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Field Value Account Source

Terminal Data Output Capability
1 None
S11 2 Printing capability only
3 Display capability only
4 Printing and display capability
PIN Capture Capability
S12 0 No PIN capture capability
C PIN capture capability (maximum 12 characters)

11.1.4.7 Group III Version 055 TLV EMV Tag Data

The following sections identify the primary tags used in a chip card transaction. Not all tags are used in
every transaction. The tags being sent should be as close to the following list as possible and in the order
listed below.

Note: Request tags should be requested from the kernel prior to building the TLV formatted EMV Tag
Data. This ensures that the values used by the card to build the cryptogram are the same values sent
in the request message. The tags should be sent in the following order; fixed length tags in ascending
order by tag number, followed by variable length tags in ascending order by tag number.
Tag 9F34 is a fixed length tag but it should be included with the variable length tags as it is sometimes
not present on the chip.

Table 42 Group III Version 055 (TLV EMV Tag Data) – Request Tags
Tag Name Description
82 AIP Application Interchange Profile

95 TVR Terminal Verification Result

Local date that the transaction was performed.

9A Transaction Date
This date is in YYYMMDD format.

9B TSI Transaction Status Information

Indicates the type of financial transaction, represented by the first two digits
9C Transaction Type of ISO 8583:1987 Processing Code.
0x00 = Goods and Services

Transaction Indicates the currency code of the transaction according to ISO 4217.
5F2A
Currency Code 840 = U.S. Dollars

Transaction
9F02 Transaction amount of the transaction.
Amount

Secondary amount associated with the transaction representing a cashback

9F03 Other Amount
amount.

Issuer Action Code which specifies the issuer's conditions that cause a
9F0D IAC-Default transaction to be declined when an online authorization was attempted, but
the terminal is unable to process the transaction online.

Issuer Action Code which specifies the issuer's conditions that cause a
9F0E IAC-Denial
transaction to be declined offline.

Page 114 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Tag Name Description

Issuer Action Code which specifies the issuer's conditions that cause a
9F0F IAC-Online
transaction to be transmitted online.

Terminal Country Indicates the country of the terminal, represented according to ISO 3166.
9F1A
Code o 840 = United States

Local time that the transaction was authorized.

9F21 Transaction Time
This time is in HHMMSS format

Application Cryptogram returned by the card in response to the GENERATE AC

9F26
Cryptogram command.

Cryptogram Information Data which indicates the type of cryptogram

generated by the chip card.
9F27 CID o 00 = AAC (declined)
o 40 = TC (approved)
o 80 = ARQC (go online)

Indicates the card data input, CVM and security capabilities of the terminal.
Terminal
9F33 This field must match the value for the EMV kernel configuration being used
Capabilities
for the transaction.

9F34 CVM Results Cardholder Verification Method Results

Indicates the environment of the terminal, its communications capability and

its operational control.
9F35 Terminal Type
This field must match the EMV kernel configuration being used for the
transaction.

9F36 ATC Application Transaction Counter (maintained by the chip card)

Unpredictable Value to provide variability and uniqueness to the generation of a

9F37
Number cryptogram.

Indicates the method by which the PAN was entered (the first two digits of
9F39 POS Entry Mode
the ISO 8583:1987 POS Entry Mode).

Additional Indicates the data input and output capabilities of the terminal.
9F40 Terminal This field must match the EMV kernel configuration being used for the
Capabilities transaction.

Identifies the application identifier used for the transaction.

4F AID
e.g. A0000000031010

Dedicated File Identifies the name of the Dedicated File as described in ISO/IEC 7816-4
84
Name (usually the same as Tag 4F).

Language Two alphabetical characters indicating the language preference used for
5F2D
Preference the transaction (the card can have 1-4 languages).

PAN Sequence
5F34 Identifies and differentiates cards with the same PAN.
Number

Identifies the application identifier used for the transaction.

9F06 AID (Terminal)
e.g. A0000000031010

Page 115 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Tag Name Description

Issuer Application Contains proprietary application data for transmission to the issuer in an
9F10
Data online transaction.

The manufacturer's unique serial number of the device that interacts with
Device Serial the chip card.
DF78
Number
(variable 1 - 20)

The version number of the kernel used to process the chip data in the
Kernel Version
DF79 transaction.
Number
(variable 1 - 32)

Response Tags

Table 43 Group III Version 055 (TLV EMV Tag Data) – Response Tags
Tag Name Description
Response code that indicates the approved/declined status of the
transaction.
Authorization This tag must be provided to the kernel. If this tag is not present in the
8A
Response Code response message, the following values should be used:
o “00” (0x3030) if the transaction was approved
o “05” (0x3035) if the transaction was declined

Contains proprietary Issuer Script commands that must be sent to the card
Issuer Script before the 2nd Generate AC command.
71
Template 1 The Issuer Script must be provided to the EMV kernel for both approved and
declined transactions.

Contains proprietary Issuer Script commands that must be sent to the card
Issuer Script after the 2nd Generate AC command.
72
Template 2 The Issuer Script must be provided to the EMV kernel for both approved and
declined transactions.

This tag contains the ARPC cryptogram. Data must be sent to the card for
Issuer online issuer authentication.
91 Authentication
This tag must be provided to the EMV kernel so that it can be authenticated
Data
by the card.

Page 116 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.2 Host Summit Message Formats

This section shows the Summit host request and host response message formats.

11.2.1 Summit Request Message Header Format

The EMV request message format is almost identical to the non-EMV request message format. The
“Reference” column identifies the fields that are related to EMV transactions.

Table 44 Summit Request Message Format

Byte Length Format Field Description Content Reference
1 1 A/N Record Format H Host Capture

2 1 A/N Application Type 0, 2, 4

3 1 A/N Message Delimiter .

4-9 6 NUM Routing ID TSYS Assigned

Must be first
10-24 15 A/N <A1> POS ID TSYS Assigned
field
- A/N <A21> POS Entry Mode EMV
- A/N <A58> Visa Contactless Data EMV
- 2-510 Hex <A111> Chip Card Data EMV

- <A116> MasterCard PayPass EMV

- Other fields…

11.2.2 Summit Response Message Format

The EMV response message format is almost identical to the non-EMV response message format. The
“Reference” column identifies the fields that are related to EMV transactions.

Table 45 Summit Response Message Format

Byte Length Format Field Description Content Reference
1 1 A/N Record Format H Host Capture

2 1 A/N Application Type 0, 2, 4

3 1 A/N Message Delimiter .

4-9 6 NUM Routing ID TSYS Assigned

- 2-510 Hex <A111> Chip Card Data EMV

Other fields…

Page 117 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.2.3 Summit Message Data Fields

The following sections identify the fields required for Summit EMV transactions.

11.2.3.1 Field <A21> POS Entry Data

The POS Entry Data field has 13 character sub-fields (B1 to B13) that indicates the condition of the POS
device at the time of the transaction. This field must be sent for all transactions from a device that is
capable of reading an EMV or contactless chip card. The following table shows values that are applicable
for a chip capable device.

Table 46 Field <A21> POS Entry Data

Field Value Account Source
Cardholder Present Data
B1 0 Cardholder present
1 Cardholder not present; unspecified reason
Card Present Data
0 Card not present
B2
1 Card present
X Contactless chip
Card Data - Input Mode
C Online Chip
F Offline Chip
B3
M PAN auto-entry via contactless Chip Card (EMV Mode)
N Track data read, chip capable terminal, chip data could not be read (Technical Fallback)
P Empty Candidate List fallback (MSR Fallback)
Cardholder Authentication Method
0 Cardholder not authenticated
B4 1 Cardholder entered PIN (offline PIN or online PIN)
2 Electronic signature
5 Manual signature
Cardholder Authentication Entity
0 Not authenticated
1 Offline PIN authenticated by chip card
B5
2 Authenticated by card acceptance device
3 Online PIN authenticated by authorizing agent
4 Signature validated by merchant or card acceptor
Terminal Data - Card Data Input Capability
5 Integrated circuit card (ICC) capability
A PAN auto-entry via contactless magnetic stripe
C Magnetic stripe reader, ICC and key entry capability
B6
D Magnetic stripe reader and ICC capability
E ICC and key entry capability
H ICC Reader and Contactless Capability
M PAN auto-entry via contactless chip
Terminal Data - Cardholder Authentication Capability
0 No electronic authentication capability
B7
1 PIN entry capability
2 Electronic signature analysis capability

Page 118 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Field Value Account Source

Terminal Data - Card Capture Capability
0 No card capture capability
B8
1 Card capture capability
9 Unspecified, data not available
Terminal Operating Environment
B9 1 On card acceptor premises; attended terminal
2 On card acceptor premises; unattended terminal
Card Data Output Capability
B10 1 None
3 ICC
Terminal Data Output Capability
1 None
B11 2 Printing capability only
3 Display capability only
4 Printing and display capability
PIN Capture Capability
B12 0 No PIN capture capability
C PIN capture capability (maximum 12 characters)
Chip Condition Code
0 Default value when the Service Code does not begin with „2‟ or „6‟
1 Use this value when Service Code begins with „2‟ or „6‟, and the last chip read from the chip
B13
capable terminal was successful, or was not a chip transaction, or unknown (MSR Fallback)
2 Use this value when the Service Code begins with „2‟ or „6‟, and last transaction at the chip
capable terminal was an unsuccessful chip read (Technical Fallback)

11.2.3.2 Field <A58> Visa Contactless Data Group

The Visa Contactless Data Group field has seven character sub-fields (B1 to B7) that support data from
Visa contactless payWave cards.

Table 47 Field <A58> Visa Contactless Data Group

Field Value Account Source
Amount Authorized (Tag 9F02)
B1 Num
For U.S. processors, the expected amount value is 0.
Application Cryptogram (Tag 9F26)
B2 A/N This subfield contains the cryptogram used for authentication of the transaction.
Send value as ASCII representation of hex.
Application Transaction Counter (Tag 9F36)
This subfield contains a count of the transactions performed within the card application. The
B3 A/N
count is incremented by one each time a transaction is initiated. Counter implemented in hex.
Send value as ASCII representation of hex.
Customer Exclusive Data (9F7C)
B4 A/N This subfield is a Visa proprietary field (Tag 9F7C) that contains data to be included in the
request message.

Page 119 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Field Value Account Source

Form Factor Indicator (Tag 9F6E)
This subfield contains indicators about the attributes of cardholder's device and the technology
B5 A/N
used for communication between the cardholder's device and the acquiring POS device.
Send as ASCII representation of hex.
Issuer Application Data (Tag 9F10)
B6 A/N This subfield contains the issuer application data transmitted from the card to the issuer.
Send as ASCII representation of hex.
Unpredictable Number (Tag 9F37)
This subfield contains the issuer application data transmitted from the card to the issuer and is
B7 A/N
updated by the issuer in the response messages.
Send as ASCII representation of hex.

11.2.3.3 Field <A111> Chip Card Data

This field contains a string of data elements in a TLV format:
1. Chip Card Tag: This value contains the tag of the chip dataset.
2. Chip Card Data Length: This value indicates how many bytes of data constitute the tag value.
3. Value: This is the actual chip card tag data.
The TLV chip card data elements are preceded by a length field to indicate the length of the entire data
string.
The following sections identify the primary tags used in a chip card transaction. Not all tags are used in
every transaction. The tags being sent should be as close to the following list as possible and should be
in the order shown in the table below.

Request Tags
The request tags should be requested from the kernel prior to building the TLV EMV Tag Data to ensure
that the same values that were used by the card to build the cryptogram are used in the request
message.
The tags should be sent in the order; fixed length tags in ascending order by tag number, followed by
variable length tags in ascending order by tag number.

Table 48 Field <A111> Request Tags

Tag Name Description
82 AIP Application Interchange Profile

95 TVR Terminal Verification Result

Local date that the transaction was performed.

9A Transaction Date
This date is in YYYMMDD format.

9B TSI Transaction Status Information

Indicates the type of financial transaction, represented by the first two digits of
9C Transaction Type ISO 8583:1987 Processing Code.
o 0x00 = Goods and Services

Transaction Indicates the currency code of the transaction according to ISO 4217.
5F2A
Currency Code o 840 = US Dollars

Page 120 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Tag Name Description

Transaction
9F02 The total amount of the transaction.
Amount

Secondary amount associated with the transaction representing a cashback

9F03 Other Amount
amount.

Issuer Action Code which specifies the issuer's conditions that cause a
9F0D IAC-Default transaction to be declined if online authorization was requested, but the
terminal is unable to process the transaction online.

Issuer Action Code which specifies the issuer's conditions that cause a
9F0E IAC-Denial
transaction to be declined offline.

Issuer Action Code which specifies the issuer's conditions that cause a
9F0F IAC-Online
transaction to be transmitted online.

Terminal Country Indicates the country of the terminal, represented according to ISO 3166.
9F1A
Code o 840 = United States

Local time that the transaction was authorized.

9F21 Transaction Time
(HHMMSS format)

Application Cryptogram returned by the card in response of the GENERATE AC

9F26
Cryptogram command.

Cryptogram Information Data which indicates the type of cryptogram generated

by the chip card.
9F27 CID o 00 = AAC (declined)
o 40 = TC (approved)
o 80 = ARQC (go online)

Indicates the card data input, CVM and security capabilities of the terminal.
Terminal
9F33 This field must match the value for the EMV kernel configuration being used for
Capabilities
the transaction.

9F34 CVM Results Cardholder Verification Method Results.

Indicates the environment of the terminal, its communications capability and its
operational control.
9F35 Terminal Type
This field must match the value for the EMV kernel configuration being used for
the transaction.

9F36 ATC Application Transaction Counter which is maintained by the chip card.

Unpredictable
9F37 Value to provide variability and uniqueness to the generation of a cryptogram.
Number

Indicates the method by which the PAN was entered, according to the first two
9F39 POS Entry Mode
digits of the ISO 8583:1987 POS Entry Mode.

Additional Indicates the data input and output capabilities of the terminal.
9F40 Terminal This field must match the value for the EMV kernel configuration being used for
Capabilities the transaction.

Identifies the application identifier used for the transaction.

4F AID (Card)
e.g. A0000000031010

Page 121 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Tag Name Description

Dedicated File Identifies the name of the DF as described in ISO/IEC 7816-4. This is usually
84
Name the same as tag 4F.

Language Two alphabetical characters indicating language preference used for the
5F2D
Preference transaction. A card can have 1 - 4 languages.

PAN Sequence
5F34 Identifies and differentiates cards with the same PAN.
Number

Identifies the application identifier used for the transaction.

9F06 AID (Terminal)
e.g. A0000000031010

Issuer Application Contains proprietary application data for transmission to the issuer in an online
9F10
Data transaction.

The manufacturer's unique serial number of the device that interacts with the
Device Serial chip card.
DF78
Number
(variable 1 - 20)

The version number of the kernel used to process the chip data in the
Kernel Version transaction.
DF79
Number
(variable 1 - 32)

Response Tags

Table 49 Field <A111> Response Tags

Tag Name Description
Response code that indicates the approved/declined status of the transaction.
This tag must be provided to the kernel. If this tag is not present in the
Authorization
8A response message then the following values should be used:
Response Code
o “00” (0x3030) if the transaction was approved
o “05” (0x3035) if the transaction was declined

Contains proprietary Issuer Script commands for transmission to the card

Issuer Script before the 2nd Generate AC command.
71
Template 1 The Issuer Script must be provided to the EMV kernel for both approved and
declined transactions.

Contains proprietary Issuer Script commands for transmission to the card after
Issuer Script the 2nd Generate AC command.
72
Template 2 The Issuer Script must be provided to the EMV kernel for both approved and
declined transactions.

Data sent to the chip card for online issuer authentication. This tag contains the
Issuer
ARPC cryptogram.
91 Authentication
Data This tag must be provided to the EMV kernel so that it can be authenticated by
the card.

Page 122 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.2.3.4 <A116> MasterCard PayPass Data Group

The MasterCard PayPass Data Group field has 3 character sub-fields (B1 to B3) that support data from
MasterCard contactless PayPass cards.

Table 50 Field <A116> MasterCard PayPass Data Group

Field Value Account Source
Mapped PAN Indicator
B1 A/N This conditional one-character field indicates the type of mapping account used and comes
with the MasterCard PayPass mapping service.
Mapped Product Code
B2 A/N This conditional three-character field represents the product code for the mapped account used
and optionally comes with the MasterCard PayPass mapping service.
Mapped Expiry Date
B3 A/N This conditional four-character numeric field contains the mapped card expiration date.
(MMYY format)

11.3 Response Message Processing Flow

When a host response message is received for an online EMV transaction, it must be sent to the EMV
chip for final processing. The EMV chip will make the final authorization decision and respond to the
EMV POS Solution. Only at this point has the transaction authorization been completed. It should be
noted that the EMV chip may override the host authorization decision. The EMV POS Solution must be
capable of handling that situation.

11.3.1 Host Declined Transactions

If the host declines or refers a transaction, the Response Code field in the host response message will be
set to a value indicating the transaction was declined. The current host approval values are listed in Host
Approved Transaction section (below). All other values should be interpreted as a decline.
The following should be done for declined transactions:
1. Send the host “Declined” response message fields to the EMV chip for final authorization
2. EMV chip will return a declined (AAC) response
3. Print “Decline” receipts
4. End transaction

Page 123 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.3.2 Host Approved Transactions

If the host approves a transaction, the Response Code field in the header record will be set to one of the
following values.

Table 51 Host Approval Response Codes

Response Response
Code Definition
00 Approved and completed
08 Honor MasterCard with Id
10 Partial Approval for the authorized amount returned in G3v022
11 VIP Approval

The following should be done for host approved transactions:

1. Send the host “Approved” response message fields to the EMV chip for final authorization.
2. Obtain the EMV chip response:
- Approved (TC)
 Transaction has been approved
 Print “Approved” receipts
 Save transaction results
- Declined (AAC)
 EMV chip has overridden the host response - Transaction has been declined
 Send an Authorization Reversal message to the host prior to performing another host
transaction
 Print “Declined” receipts
3. End transaction

11.4 Reversal Processing

There are several reasons why a transaction may need to be reversed to the host. EMV transactions are
reversed for all of the same reasons as non-EMV transactions. No new reversal types have been added
to support EMV. However, for EMV transactions there are additional reasons why a transaction must be
reversed. For more information, refer to the following sections.

11.4.1 EMV Chip Reversals

In addition to the reasons non-EMV transactions may be reversed, EMV POS Solution must also reverse
transactions that have been approved by the issuer host but the host response either cannot be
processed by the EMV chip due to an error (e.g. card was prematurely removed) or the EMV chip
declines the transaction (at 2nd Generate AC). In these cases the transaction must be considered a
declined transaction and the host approval must be reversed. This is done by sending an Authorization
Reversal message to the host.
When the card declines the transaction by generating an AAC at the 2nd Generate AC, the Authorization
Reversal sent to the host must contain an updated Group3v55 field containing the field values set when
generating the AAC cryptogram.

Page 124 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.4.2 Reversal Message Format

The following table shows the Reversal Message Format. When performing an Authorization Reversal
transaction, the Settlement Amount field must contain the 1-12-character numeric transaction amount to
be settled. The Settlement Amount must be set to zero to reverse the transaction. The Settlement amount
is submitted in the Secondary Amount field.
When performing an Authorization Reversal transaction, the Transaction Amount field contains the total
sum of all amounts authorized for this transaction (including any and all incremental authorizations).

Table 52 EIS Reversal Request Message Format

Byte Length Format Field Description Content Reference
1 1 A/N Record Format D
2 1 A/N Application Type Value from original Request
3 1 A/N Message Delimiter .
4-9 6 NUM Acquirer BIN TSYS Assigned
10-21 12 NUM Merchant Number TSYS Assigned
22-25 4 NUM Store Number TSYS Assigned
26-29 4 NUM Terminal Number TSYS Assigned
30 1 A/N Device Code X EMV
31 1 A/N Industry Code Value from original Request
32-34 3 NUM Currency Code 840 – US Dollars
35-37 3 NUM Country Code 840 – United States
38-46 9 A/N City Code (ZIP) Left-justified / space-filled
47-48 2 NUM Language Indicator 00 – English
49-51 3 NUM Time Zone Differential Value from original Request
52-55 4 NUM Merchant Category Code TSYS Assigned
56 1 A/N Returned ACI Value from Response
57-60 4 NUM Tran Sequence Number Value from original Request
61-62 2 A/N Transaction Code 59
63 1 A/N Cardholder ID Code Value from original Request EMV
64 1 A/N Account Data Source Value from original Request EMV
- 5-76 A/N Customer Data Field Value from original Request EMV
- 1 A/N Field Separator <FS>
- 1 A/N Field Separator <FS>
- 1 A/N Field Separator <FS>
- 1-12 NUM Transaction Amount Value from original Request
- 1 A/N Field Separator <FS>
- 1-12 NUM Secondary Amount 0
- 1 A/N Field Separator <FS>
- 1 A/N Field Separator <FS>
- 40 A/N Card Acceptor Data Value from original Request
- 1 A/N Field Separator <FS>
- 0-15 A/N Transaction Identifier Value from Response
- 1 A/N Field Separator <FS>

Page 125 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Byte Length Format Field Description Content Reference

- 6 A/N Approval Code Value from Response
- 6 NUM Local Transaction Date Value from Response
- 6 NUM Local Transaction Time Value from Response
- 12 A/N Retrieval Reference Num Value from Response
- 1 A/N Field Separator <FS>
- 3 NUM Group III Version 020 020
- 6 A/N Developer ID TSYS Assigned
- 4 A/N Version ID TSYS Assigned
- 1 A/N Field Separator <FS>
- 1 A/N Field Separator <FS>
- 1 A/N Group Separator <GS>
- 3 NUM Group III Version 027 027
- 12 A/N POS Data Code EMV
- 1 A/N Group Separator <GS>
- 3 NUM Group III Version 055 055
- 6-255 ASCII Hex TLV EMV Tag Data EMV
- 1 A/N Field Separator <FS>
- 1 A/N Group Separator <GS>

Table 53 EIS Reversal Response Message Format

Byte Length Format Field Description Content Ref
1 1 A/N Record Format E
2 1 A/N Application Type 0, 2, 4
3 1 A/N Message Delimiter .
4 1 NUM Returned ACI
5-8 4 NUM Store Number TSYS Assigned
9-12 4 NUM Terminal Number TSYS Assigned
13 1 A/N Authorization Source Code
14-17 4 A/N Tran Sequence Number
18-19 2 A/N Response Code
20-25 6 A/N Approval Code
26-31 6 NUM Local Transaction Date MMDDYY
32-37 6 NUM Local Transaction Time HHMMSS
38-53 16 A/N Auth Response Text
54 1 A/N AVS Result Code
55-66 12 NUM Retrieval Reference Number
67 1 A/N Market Data Identifier
- 0-15 A/N Transaction Identifier
- 1 A/N Field Separator <FS>
- 0,4 A/N Validation Code
- 3 NUM Group III Version
- 1 A/N Group Separator <GS>

Page 126 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.5 EMV Credit Card Transaction Examples

The following notation has been used for the examples provided in this chapter:
 „<FS>‟ – is the Field Separator character (0x1C).
 „<GS>‟ – is the Record/Group Separator character (0x1D).

11.5.1 Example #1: EMV Online Purchase using Visa ADVT 01 Card

The following example shows a Visa chip card transaction using a VISA ADVT test card.

11.5.1.1 EMV Online Credit Purchase Request Message

The EMV POS Solution sends the following request message.

Raw Trace - EMV Credit Purchase – Request Message

D0.(??????)(????????????)00010004DR84084085284 001075999Y000254PG
4761739001010119=15122011758989389<FS><FS><FS>2100<FS><FS><FS>??????? EMV TEST
TEMPE AZ<FS><FS><FS>001!010<GS>020??????????<FS><FS><GS>022<GS>026A<FS>
<GS>027????????????<GS>034<GS>049????????????????????????<FS><GS>
05582025C00950500000080009A031407159B02E8009C01005F2A0208409F02060000000021009F0306000
0000000009F0D05F0400088009F0E0500100000009F0F05F0400098009F1A0208409F26081A4B315C6AA31
2D99F2701809F3303E0F8C89F34031E03009F3501229F360200029F3704BB05C8939F40057000F0A0014F0
7A00000000310108407A00000000310105F3401019F0607A00000000310109F100706010A03A00000DF780
9323832343237313337DF790C303030303030303030363230<FS>

Interpreted Trace - EMV Credit Purchase – Request Message

Field Description Length Content Comments
Record Format 1 D Credit Card Authorization Req
Application Type 1 0 Single Transaction
Message Delimiter 1 . Delimiter
Acquirer BIN 6 ??????
Merchant Number 12 ????????????
Store Number 4 0001
Terminal Number 4 0004
Device Code 1 D Dial Terminal
Industry Code 1 R Retail
Currency Code 3 840 US Dollars
Country Code 3 840 United States
City Code (ZIP) 9 85284
Language Indicator 2 00
Time Zone Differential 3 107
Merchant Category Code 4 5999
Requested ACI 1 Y
Tran Sequence Number 4 0002

Page 127 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Interpreted Trace - EMV Credit Purchase – Request Message

Transaction Code 2 54 Purchase
Cardholder ID Code 1 P NO CVM
Account Data Source 1 G Chip Card Read Data
4761739001010119=151220117589893
Customer Data Field 5-76
89
Field Separator 1 <FS>
Field Separator 1 <FS>
Field Separator 1 <FS>
Transaction Amount 1-12 2100 $21.00
Field Separator 1 <FS>
Field Separator 1 <FS>
Field Separator 1 <FS>
??????? EMV TEST
Card Acceptor Data 40 TEMPE
AZ
Field Separator 1 <FS>
Field Separator 1 <FS>
Field Separator 1 <FS>
Group III Version 3 001 Commercial Card
Commercial Card Request
!001
Indicator
Group Separator 1 <GS>
Group III Version 020 3 020 Developer Information
Developer ID 6 ??????
Version ID 4 ????
Field Separator 1 <FS>
Field Separator 1 <FS>
Group Separator 1 <GS>
Group III Version 3 022 Additional Amounts
Group Separator 1 <GS>
Group III Version 3 026 Product Participation Group
1 A
Field Separator 1 <FS>
Group Separator 1 <GS>
Group III Version 3 027 POS Data Code
POS Data Code 12 ????????????
Group Separator 1 <GS>
Group III Version 3 034 Card Product Code
Group Separator 1 <GS>
Group III Version 3 049 Gen2 Terminal Authentication
12 3B6B1DA144390DFF1D8DBA3
Field Separator 1 <FS>

Page 128 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Interpreted Trace - EMV Credit Purchase – Request Message

Group Separator 1 <GS>
Group III Version 3 055 EMV TLV Tag Data
82025C00 AIP
95050000008000 Terminal Verification Results
9A03140715 Transaction Date
9B02E800 Transaction Status Indicator
9C0100 Transaction Type
5F2A020840 Transaction Currency Code
9F0206000000002100 Authorization Amount
9F0306000000000000 Other Amount
9F0D05F040008800 IAC – Default
9F0E050010000000 IAC – Denial
9F0F05F040009800 IAC – Online
9F1A020840 Terminal Country Code
9F26081A4B315C6AA312D9 Application Cryptogram
TLV EMV Tag Data 6-255 9F270180 CID
9F3303E0F8C8 Terminal Capabilities
9F34031E0300 CVM Results
9F350122 Terminal Type
9F36020002 ATC
9F3704BB05C893 Unpredictable Number
9F40057000F0A001 Additional Terminal Cap.
4F07A0000000031010 AID (ICC)
8407A0000000031010 Dedicated File Name
5F340101 PAN Sequence Number
9F0607A0000000031010 AID (Terminal)
9F100706010A03A00000 Issuer Application Data
DF7809323832343237313337 Device Serial Number
DF790C303030303030303030363230 Kernel Version Number

Field Separator 1 <FS>

Page 129 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.5.1.2 EMV Online Credit Purchase Response Message

The host sends the following Response message.

Raw Trace – EMV Credit Purchase – Response Message

E0.N000100044000200??????071514084803APPROVAL ?????? 0????????????
???????????????<FS>SLJ7<FS>0010<GS>020<GS>022<FS><FS><FS><FS><FS><FS><FS>
<FS><FS><FS><FS><FS><FS><FS><FS><FS><FS><FS><FS><FS><GS>026<GS>027<GS>
034A <FS><GS>049<FS><GS>0559F36020002910A3BF3E27D5A16AF013030<FS>

Interpreted Trace - EMV Credit Purchase – Response Message

Field Description Length Content Comments
Record Format 1 E Credit Card Authorization Resp
Application Type 1 0 Single Transaction
Message Delimiter 1 . Delimiter
Return ACI 1 N Not CPS qualified
Store Number 4 0001 Matches Request
Terminal Number 4 0004 Matches Request
Direct Connect Issuer
Authorization Source Code 1 4
Generated Response
Tran Sequence Number 4 0002 Matches Request
Response Code 2 00 Approval
Approval Code 6 ??????
Local Transaction Date 6 071514 June 24, 2014
Local Transaction Time 6 084803 09:22:36
Auth Response Text 16 APPROVAL ??????
Address verification not
AVS Result Code 1 0
requested
Retrieval Reference
12 ????????????
Number
Market Data Identifier 1 blank
Transaction Identifier 0-15 ???????????????
Field Separator 1 <FS>
Validation Code 0,4 SLJ7
Group III Version 001 3 001
0
Group Separator 1 <GS>
Group III Version 020 3 020 Developer Information
Group Separator 1 <GS>
Group III Version 022 3 022 Additional Amounts
Field Separator <FS>x20
Group III Version 026 3 026 Product Participation Group
Group Separator 1 <GS>
Group III Version 027 3 027 POS Data Code

Page 130 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Interpreted Trace - EMV Credit Purchase – Response Message

Group Separator 1 <GS>
Group III Version 034 3 034 Card Product Code
1 A
Field Separator 1 <FS>
Group Separator 1 <GS>
Group III Version 049 3 049 Gen2 Terminal Authentication
Field Separator 1 <FS>
Group Separator 1 <GS>
Voltage Encryption
Group III Version 052 3 052
Transmission Block
Group Separator 1 <GS>
Group III Version 055 3 055 EMV TLV Tag Data
ATC
9F36020002
TLV EMV Tag Data 6-255 Issuer Authentication Data
910A3BF3E27D5A16AF013030
No Tag 71 or Tag 72
Field Separator 1 <FS>

Note: The host response message may contain an Issuer Script (Tag 71 or Tag 72). When present
the Issuer Script must be sent to the EMV chip. A maximum of one Issuer Sript will be returned in a
host response message.

Page 131 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.5.2 Example #2: EMV Online Purchase using MasterCard MTIP06 Card

The following example shows a MasterCard chip card transaction using a MasterCard M-TIP test card.
The response for this example also contains an Issuer Script.

11.5.2.1 EMV Online Credit Purchase Request Message

The EMV POS Solution sends the following request message.

Raw Trace - EMV Credit Purchase – Request Message

D0.(??????)( ????????????)00010004DR84084085284 001075999Y000154FG5413330
089020011=2512601079360805<FS><FS><FS>6000<FS><FS><FS>??????? EMV TEST TEMPE
AZ<FS><FS><FS>001!010<GS>020??????????<FS><FS><GS>022<GS>026A<FS><GS>027
????????????<GS>034<GS>049????????????????????????<FS><GS>05582023000950500000080009A0
31407159B02E8009C01005F2A0208409F02060000000060009F03060000000000009F0D05FC50A000009F0
E0500000000009F0F05F870A498009F1A0208409F260816802E5200F3Cl999F2701809F3303E0F8C89F340
34103029F3501229F360200279F37040E6E6DEA9F4005F000F0A0014F07A00000000410108407A00000000
410105F3401039F0607A00000000410109F10120210A5800F040000000000000000000000FFDF780932383
2343237313337DF790C303030303030303030363230<FS>

Interpreted Trace - EMV Credit Purchase – Request Message

Field Description Length Content Comments
Record Format 1 D Credit Card Authorization Req
Application Type 1 0 Single Transaction
Message Delimiter 1 . Delimiter
Acquirer BIN 6 ??????
Merchant Number 12 ????????????
Store Number 4 0001
Terminal Number 4 0004
Device Code 1 D Dial Terminal
Industry Code 1 R Retail
Currency Code 3 840 US Dollars
Country Code 3 840 USA
City Code (ZIP) 9 85284
Language Indicator 2 00 English
Time Zone Differential 3 107
Merchant Category Code 4 5999
Requested ACI 1 Y
Tran Sequence Number 4 0001
Transaction Code 2 54 Purchase
Cardholder ID Code 1 F
Account Data Source 1 G Chip Card Read Data
Customer Data Field 5-76 5413330089020011=2512601079360805
Field Separator 1 <FS>
Field Separator 1 <FS>

Page 132 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Interpreted Trace - EMV Credit Purchase – Request Message

Field Separator 1 <FS>
Transaction Amount 1-12 6000 $60.00
Field Separator 1 <FS>
Field Separator 1 <FS>
Field Separator 1 <FS>
??????? EMV TEST
Card Acceptor Data 40 TEMPE
AZ
Field Separator 1 <FS>
Field Separator 1 <FS>
Field Separator 1 <FS>
Group III Version 3 001 Commercial Card
Commercial Card Request
!001
Indicator
Group Separator 1 <GS>
Group III Version 020 3 020 Developer Information
Developer ID 6 ??????
Version ID 4 ????
Field Separator 1 <FS>
Field Separator 1 <FS>
Group Separator 1 <GS>
Group III Version 3 022 Additional Amounts
Group Separator 1 <GS>
Group III Version 3 026 Product Participation Group
1 A
Field Separator 1 <FS>
Group Separator 1 <GS>
Group III Version 3 027 POS Data Code
POS Data Code 12 ????????????
Group Separator 1 <GS>
Group III Version 3 034 Card Product Code
Group Separator 1 <GS>
Group III Version 3 049 Gen2 Terminal Authentication
12 ???????????????????????
Field Separator 1 <FS>
Group Separator 1 <GS>
Group III Version 3 055 EMV TLV Tag Data

Page 133 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Interpreted Trace - EMV Credit Purchase – Request Message

82023000 AIP
95050000008000 Terminal Verification Results
9A03140715 Transaction Date
9B02E800 Transaction Status Indicator
9C0100 Transaction Type
5F2A020840 Transaction Currency Code
9F0206000000006000 Authorization Amount
9F0306000000000000 Other Amount
9F0D05FC50A00000 IAC – Default
9F0E050000000000 IAC – Denial
9F0F05F870A49800 IAC – Online
9F1A020840 Terminal Country Code
9F260816802E5200F3Cl99 Application Cryptogram
9F270180 CID
TLV EMV Tag Data 6-255
9F3303E0F8C8 Terminal Capabilities
9F3403410302 CVM Results
9F350122 Terminal Type
9F36020027 ATC
9F37040E6E6DEA Unpredictable Number
9F4005F000F0A001 Additional Terminal Capabilities
4F07A000000004101 0 AID (ICC)
8407A0000000041010 Dedicated File Name
5F340103 PAN Sequence Number
9F0607A0000000041010 AID (Terminal)
9F10120210A5800F04000000000000000 Issuer Application Data
0000000FF
DF7809323832343237313337 Device Serial Number
DF790C303030303030303030363230 Kernel Version Number
Field Separator 1 <FS>

Page 134 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.5.2.2 EMV Online Credit Purchase – Response Message

The host sends the following Response message.
Raw Trace – EMV Credit Purchase – Response Message
E0.A000100045000100??????071514084408APPROVAL ?????? 0???????????? ???????????????
<FS> <FS>0010<GS>020<GS>022<FS><FS><FS><FS><FS><FS><FS><FS><FS><FS><FS>
<FS><FS><FS><FS><FS ><FS><FS><FS><FS><GS>026<GS>027<GS>034<FS><GS>049
<FS><GS>05572178615841600001011223344556677886D878475D96C66F9910A0A758203EB1D
94F00012<FS>

Interpreted Trace - EMV Credit Purchase – Response Message

Field Description Length Content Comments
Record Format 1 E Credit Card Authorization Resp
Application Type 1 0 Single Transaction
Message Delimiter 1 . Delimiter
Return ACI 1 A CPS qualified
Store Number 4 0001 Matches Request
Terminal Number 4 0004 Matches Request
Direct Connect Issuer Generated
Authorization Source Code 1 5
Response
Tran Sequence Number 4 0001 Matches Request
Response Code 2 00 Approval
Approval Code 6 ??????
Local Transaction Date 6 071514 July 15, 2014
Local Transaction Time 6 084408 08:44:08
Auth Response Text 16 APPROVAL ??????
Address verification not
AVS Result Code 1 0
requested
Retrieval Reference
12 ????????????
Number
Market Data Identifier 1 Space (0x20)
Transaction Identifier 0-15 ???????????????
Field Separator 1 <FS>
Validation Code 0,4 <FS>
Group III Version 010 3 010
Group Separator 1 <GS>
Group III Version 020 3 020 Developer Information
Group Separator 1 <GS>
Group III Version 022 3 022 Additional Amounts
Field Separator <FS>x20
Group III Version 026 3 026 Product Participation Group
Group Separator 1 <GS>
Group III Version 027 3 027 POS Data Code
Group Separator 1 <GS>

Page 135 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Interpreted Trace - EMV Credit Purchase – Response Message

Group III Version 034 3 034 Card Product Code
Field Separator 1 <FS>
Group Separator 1 <GS>
Group III Version 049 3 049 Gen2 Terminal Authentication
Field Separator 1 <FS>
Group Separator 1 <GS>
Group III Version 055 3 055 EMV TLV Tag Data
72178615841600001011223344556677 Issuer Script Template 72
TLV EMV Tag Data 6-255 886D878475D96C66F9
910A0A758203EB1D94F00012 Issuer Authentication Data
Field Separator 1 <FS>

Page 136 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.5.3 Example #3: Summit EMV Online Purchase

The following example shows a Visa chip card transaction using a VISA test card.

11.5.3.1 EMV Online Credit Purchase Request Message

The EMV POS Solution sends the following request message.

Raw Trace - EMV Credit Purchase – Request Message

H4.TSH950A1?????????????????A3??????????????????????????A10?10?A12?C?A15?000000000200?
A17?5401500?A18?5999?A21?B1?0?B2?1?B3?C?B4?1?B5?1?B6?C?B7?1?B8?0?B9?1?B10?3?B11?4?B12?
C??A24?4427808001112223337=151220118222983?A41????????A42??????A46?A?A111?00007A82025C
00950500000080009A031201209C01005F2A0201249F02060000000002009F03060000000000009F1A0201
249F21031419399F2608AB96605D318809B29F2701809F3303E0B8C89F34031E03009F3501229F36020001
9F370421A320884F07A00000000310105F3401019F0607A00000000310109F100706010A03A00000DF7804
72920545DF7902B024?

Interpreted Trace - EMV Credit Purchase – Request Message

Field Description Length Content Comments
Record Format 1 H Host Capture Request
Application Type 1 4 Interleaved
Message Delimiter 1 .
Routing ID 6 TSH950
<A1> POS ID ???????????????
<A3> GenKey ????????????????????????
<A10> Transaction Code 10 Purchase
<A12> Payment Code C Credit
<A15> Transaction
000000000200 $2.00
Amount
<A17> TON 5400100
<A18> MCC 5999

<B1> 0 Cardholder present

<B2> 1 Card Present
<B3> C Online Chip
<B4> 1 PIN
<B5> 1 ICC – Offline PIN
<B6> C Magnetic stripe reader, ICC
and key entry capability
<A21> POS Entry Data
PIN capability
<B7> 1
No card capture capability
<B8> 0
Attended POS device
<B9> 1
ICC
<B10> 3
Printing and display capability
<B11> 4
PIN capture capability twelve
<B12> C characters maximum

Page 137 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Interpreted Trace - EMV Credit Purchase – Request Message

4427808001112223337=151220118222
<A24> Track2 Track2 (Tag 57)
983
<A41> Developer ID ??????
<A42> Version ID ????
<A46> Partial Merchandise sales can be
A
Authorization Indicator partially approved
00 Visa Dataset Indicator
007A Length of Data
82025C00 AIP
95050000008000 Terminal Verification Results
9A03120120 Transaction Date
9C0100 Transaction Type
5F2A020124 Transaction Currency Code
9F020600 0000000200 Authorization Amount
9F0306000000000000 Other Amount
9F1A020124 Terminal Country Code
9F2103141939 Transaction Time
<A111> Chip Card Data 9F2608AB96605D318809B2 Application Cryptogram
(TLV Format) 9F270180 CID
9F3303E0B8C8 Terminal Capabilities
9F34031E0300 CVM Results
9F350122 Terminal Type
9F36020001 ATC
9F370421A32088 Unpredictable Number
4F07A0000000031010 AID (Card)
5F340101 PAN Sequence Number
9F0607 A0000000031010 AID (Terminal)
9F100706010A03A00000 Issuer Application Data
DF780472920545 Device Serial Number
DF7902B024 Kernel Version Number

Page 138 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

11.5.3.2 EMV Online Credit Purchase – Response Message

The host sends the following Response message. This is an approved with an Issuer Script.
Raw Trace – EMV Credit Purchase – Response Message
I4.A80?1?A17?5401500?A81?052614?A82?121940?A83?00?A84?TAS018?A78?000000
000000771?A86?414618900050?A93?VISA?A92?A?A111?001C710E9F18040001020386
0580CA9F3600910A01020304050607080000?A85?APPROVAL?

Interpreted Trace - EMV Credit Purchase – Response Message

Field Description Length Content Comments
Record Format 1 I Host Capture Response
Application Type 1 4 Interleaved
Message Delimiter 1 .
<A80> Batch Number 1
<A17> TON 5400100 Matches Request
<A81> Transaction Date 052614 June 26, 2014
<A82> Transaction Time 121940 12:19:40
<A83> Response Code 00 Approved
<A78> Transaction ID 000000000000771
<A86> RRN 414618900050
<A93> Card Type VISA
<A92> Card Product Codes A Visa Traditional
001C Length
<A111> Chip Card Data
710E9F180400010203860580CA9F3600 Issuer Script Template 71
(TLV Format)
910A01020304050607080000 Issuer Authentication Data
<A85> Authorization
APPROVAL
Response Text

Page 139 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 140 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

12. EMV Receipts

The following table outlines EMV specific information that must be printed on all EMV transaction
receipts. The information shown must be present and may be printed in any order.
The information in the table below identifies the EMV receipt information requirements only.

Table 54 EMV Receipt Information

Field Description
The chip card application name (i.e. Visa, MasterCard, etc.) used to process the EMV
transaction. The EMV tag value printed depends on the personalization of the chip.
o The Application Preferred Name (Tag 9F12) should be printed if possible
Application o If the Issuer Code Table Index (Tag 9F11) indicates that Tag 9F12 is stored in
a ISO-8859 character set that is not supported by the printer, the Application
Name Label (Tag 50) should be printed
Note: If the Issuer Code Table Index (Tag 9F11) is “1” it indicates that the Application
Preferred Name is encoded using the Latin character set (i.e. contains standard
English alphabetic characters).

The Application PAN (Tag 5A) must be printed on the receipt as follows:
Application PAN o PAN must be truncated to remove any trailing hex „F‟s
o The PAN must be masked
Indicator identifying how the card information was obtained.

Printed Text Usage

Chip Card information read from EMV chip
Card Entry
Contactless Card information read by contactless reader
Mode
Fallback Swipe Fallback swipe (insert was attempted but failed)
Manual Manually entered card number and expiry date
Swiped Card swiped (not Fallback – an insert was not attempted)

The receipt Amount line must identify the currency used to process the transaction.
For U.S. dollar transactions “USD$” should be printed.
If the receipt has no Cashback, Surcharge or Tip lines the Amount line must reflect the
Transaction Total Transaction Amount (Tag 9F02).
If the receipt has a Cashback, Surcharge or Tip line the Amount line must be the base
transaction amount and a Total line must be printed showing the total Transaction
Amount (Tag 9F02).

Identifies the Cardholder Verification Method (CVM) must be one of the following:
o PIN VERIFIED – PIN CVM was selected and a PIN was entered
Cardholder o SIGN – Signature CVM selected (a signature line must be printed)
Verification o NONE – NO CVM was used (for attended implementations a signature line
Method must be printed)
The Cardholder Verification must be printed on both the merchant and customer
receipts.

Page 141 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Field Description
Several EMV tag values must be printed on all receipts to assist in problem resolution.
These fields should be printed in the order shown and may be identified by either their
tag name or tag number.

Name Tag Description

EMV Tag AID 4F Application Identifier
Data TVR 95 Terminal Verification Results
IAD 9F10 Issuer Application Data
TSI 9B Transaction Status Indicator
ARC 8A Application Response Code

BP 03000 Merchant and Customer receipts should contain the same data

 It is recommended that the same information be printed on both the merchant and customer
receipts with the exception of the Merchant/Customer copy indicator printed at the bottom of
the receipt.

RQ 06900 Application Name must be printed on the receipt

 The Application Preferred Name (Tag 9F12) must be printed on the receipt if it is stored on the
chip in a character set supported by the printer. Otherwise, the Application Label (Tag 50)
must be printed.

RQ 07000 Application PAN must be printed on receipt

 The Application PAN (Tag 5A) must be printed on the receipt. The PAN must be truncated to
remove trailing hex „F‟s and masked.

RQ 07100 Receipt must identify EMV and Fallback transactions

 The Card Entry Method must always be printed on the receipt. The text printed must be “Chip”
for an inserted transaction, “Contactless” for a contactless transaction or “Fallback Swipe” for a
fallback transaction.

RQ 07200 Transaction amount and a currency indicator must be printed on the receipt

 The receipt must show the transaction total amount as stored in Transaction Amount (Tag
9F02) and include text to identify the currency used for the transaction. For U.S. dollar
transactions “USD$” must be used.

RQ 07300 CVM used must be printed on the receipt

 The Cardholder Verification Method must be printed on the receipt. If the CVM is PIN “PIN
VERIFIED” must be printed, if the CVM is signature “SIGN” must be printed and for NO CVM
“NONE” must be printed.

RQ 07400 A signature line is required for attended terminals when CVM is “NO CVM”
 Attended devices must print a signature line on the receipt when the CVM selected is
“Signature” or “NO CVM”.

Page 142 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

RQ 07500 Receipt must contain mandatory EMV tags

 EMV receipts must contain “AID”, “TVR”, “IAD”, “TSI” and “ARC” tag values. This information
must be printed in the order shown. These fields are not required on Fallback receipts.

12.1 Offline Decline EMV Receipt Data

The following chart identifies the EMV tags that must be printed on chip offline decline receipts. This is
the minimum information required by TSYS. Additional information may be printed if desired.

Table 55 Offline Decline EMV Receipt Data

Receipt Text Tag # Description Comment
Tag 50 50 Application Label
Tag 5A 5A Application PAN Truncate trailing „F‟ (if any) and mask
Tag 5F2A 5F2A Transaction Currency Code
Tag 5F34 5F34 PAN Sequence Number Blank if not present
Tag 82 82 Application Interchange Profile
Tag 95 95 Terminal Verification Results
Tag 9A 9A Transaction Date
Tag 9C 9C Transaction Time
Tag 9F02 9F02 Amount Authorized Printed with decimal point
Tag 9F03 9F03 Other Amount Printed with decimal point
Tag 9F07 9F07 Application Usage Control
Tag 9F0D 9F0D Issuer Action Code – Default
Tag 9F0E 9F0E Issuer Action Code – Denial
Tag 9F0F 9F0F Issuer Action Code – Online
Tag 9F10 9F10 Issuer Application Data Variable length (up to 32 characters)
Tag 9F12 9F12 Application Preferred Name Blank if in unprintable format
Tag 9F1A 9F1A Terminal Country Code
Tag 9F26 9F26 Application Cryptogram
Tag 9F27 9F27 Cryptogram Information Data
Tag 9F34 9F34 CVM Results
Tag 9F36 9F36 Application Transaction Data
Tag 9F37 9F37 Unpredictable Number
TAC Default - Terminal Action Code – Default
TAC Denial - Terminal Action Code – Denial
TAC Online - Terminal Action Code – Online

RQ 07600 Offline Decline EMV receipt data required for all card schemes

 Offline Decline EMV data is required on all offline decline receipts regardless of card scheme.
The data fields must be printed in the order shown in the table above and be identified by the
label defined „Receipt Text‟ or “Description” column.

Page 143 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

12.2 Receipt Samples

The receipt is a legal document that represents a transaction that has taken place. The receipt must
identify the financial details of the transaction as well as merchant and terminal information.
Sample EMV receipts layouts have been illustrated below. The exact receipt layout may differ as long as
the EMV requirements (shown above) have been met and the receipt conforms to the guidelines for non-
EMV receipts.

Page 144 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

12.2.1 Credit Card (Online Approved – Signature)

The following is an example of a receipt for a credit Purchase transaction approved online by the host.
The CVM used was signature and the Track 2 information was obtained by a contactless tap.

EMV Receipt Requirements

Merchant Name
Merchant Address1  Transaction Type (Purchase)
Merchant Address 2  Application Preferred Name (Tag 9F12) is
Merchant Address 3 present on card in a supported characters set
Customer Service Phone Number so it must be printed (VISA CREDIT)

05/16/2014 11:55AM  Card Entry Method indicates that card

information was obtained from a contactless tap
(Contactless)
MID: XXXXXXXXXXXX1234
TID: 12345678  Currency indicator “USD$” must be printed on
the Amount line
 Transaction Amount (Tag 9F02) must be printed
Purchase (90.01)
VISA CREDIT ************8106  Application PAN (Tag 5A) must be truncated
Entry Mode: Contactless and masked (************8106)
CVM: SIGN  EMV Information must be printed in the order
shown and identified by the tag names:
<optional – Invoice #>  AID (A0000000031010)
<optional – Clerk/Server>  TVR (0000008000)
<optional – Table #>  IAD (06010A03A40002)
<optional – more…>  TSI (E800)
 ARC (00)
Amount USD$ 90.01  Cardholder Verification Method was “Signature”
<optional – Cashback:> <amount> so a “SIGN” was printed as well as a Signature
Line
<optional – Surcharge:> <amount>
<optional – Tip:> <amount>
<optional – Total:> 90.01 EMV Receipt Best Practices
 The “<optional>” lines should not be printed if
Response: APPROVED they have no associated value
Auth Code: 123456
 The Total line should not be printed if none of
the Cashback, Surcharge or Tip lines are
<optional – Transition Ref1> printed
<optional – Transition Ref2>
 For Pre-Authorization transitions the “Amount”
<optional – Transition Ref3>
line is required and the Tip / Total lines should
be replaced with underlines that the cardholder
EMV Details: can use to enter amounts
AID: A0000000031010 (i.e. “______________”)
TVR: 0000008000  Merchant and Customer receipt copies should
IAD: 06010A03A40002 be identical with the exception of the receipt
TSI: E800 copy indicator
ARC: 00

X_________________________________________
Cardholder Signature

MERCHANT COPY / CUSTOMER COPY

Page 145 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

12.2.2 Credit Card (Online Approved – PIN)

The following is an example of a receipt for a credit Purchase transaction approved online by the host.
The CVM used was PIN and the Track 2 information was obtained by reading the EMV chip. Additionally
the Application Preferred Name was not present on the card in a character set supported by the printer.

EMV Receipt Requirements

Merchant Name
Merchant Address1  Transaction Type (Purchase)
Merchant Address 2  Application Preferred Name (Tag 9F12) is not
Merchant Address 3 on the chip or present in an unsupported
Customer Service Phone Number characters set, so the Application Label (Tag
50) must be printed (Visa Credit)
05/16/2014 11:55AM
 Card Entry Method indicates that card
information was obtained from a contact insert
MID: XXXXXXXXXXXX1234 (Chip)
TID: 12345678
 Cardholder Verification Method was PIN so “PIN
VERIFIED” to was printed
Purchase  Currency indicator “USD$” must be printed on
Visa Credit ************8106 the Amount line
Entry Mode: Chip  Transaction Amount (Tag 9F02) must be printed
CVM: PIN VERIFIED (90.02)
 Application PAN (Tag 5A) must be truncated
<optional – Invoice #> <value> and masked (************8106)
<optional – Clerk/Server> <value>  EMV Information must be printed in the order
<optional – Table #> <value> shown and identified by the tag names:
<optional – more…> <value>  AID (A0000000031010)
 TVR (0000008000)
Amount USD$ 90.02  IAD (06010A03A40002)
<optional – Cashback:> <amount>  TSI (F800)
 ARC (00)
<optional – Surcharge:> <amount>
<optional – Tip:> <amount>
<optional – Total:> 90.02 EMV Receipt Best Practices
 The “<optional>” lines should not be printed if
Response: APPROVED they have no associated value
Auth Code: 123456
 The Total line should not be printed if none of
the Cashback, Surcharge or Tip lines are
<optional – Transition Ref1> printed
<optional – Transition Ref2>
 Merchant and Customer receipt copies should
<optional – Transition Ref3> be identical with the exception of the receipt
copy indicator
EMV Details:
AID: A0000000031010
TVR: 0000008000
IAD: 06010A03A40002
TSI: F800
ARC: 00

MERCHANT COPY / CUSTOMER COPY

Page 146 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

12.2.3 Credit Card (Online Approved – Fallback)

The following is an example of a receipt for a credit transaction approved online by the host. The card
had a chip present Service Code, but there was a chip read error, so the card was swiped and the
transaction was completed as a fallback transaction.

EMV Receipt Requirements

Merchant Name
Merchant Address1  Transaction Type (Purchase)
Merchant Address 2  Application Preferred Name cannot be obtained
Merchant Address 3 from chip so the BIN table name is printed
Customer Service Phone Number (Visa)

05/16/2014 11:55AM  Track 2 PAN is printed (masked)

 Card Entry Method indicates that card
MID: XXXXXXXXXXXX1234 information was obtained by swiping the card
after a failed chip read (Fallback Swipe)
TID: 12345678
 Card was a fallback swipe so “SIGN” is printed
and a signature line is printed
Purchase
 Currency indicator “USD$” must be printed on
Visa ************8106 the Amount line
Entry Mode: Fallback Swipe
 Total transaction amount must be printed on the
CVM: SIGN total line (90.03)

<optional – Invoice #> <value>

<optional – Clerk/Server> <value> EMV Receipt Best Practices
<optional – Table #> <value>
 EMV Information section (AID, TVR, IAD, TSI
<optional – more…> <value> and ARC) is not printed as the chip was not
used
Amount USD$ 90.03  The “<optional>” lines should not be printed if
<optional – Cashback:> <amount> they have no associated value
<optional – Surcharge:> <amount>  The Total line should not be printed if none of
<optional – Tip:> <amount> the Cashback, Surcharge or Tip lines are
<optional – Total:> 90.03 printed
 Merchant and Customer receipt copies should
Response: APPROVED be identical with the exception of the receipt
Auth Code: 123456 copy indicator

<optional – Transition Ref1>

<optional – Transition Ref2>
<optional – Transition Ref3>

X_________________________________________
Cardholder Signature

MERCHANT COPY / CUSTOMER COPY

Page 147 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

12.2.4 Credit Card (Offline Declined)

The following is an example of a receipt for a credit transaction declined offline by the EMV chip. The
CVM used was Signature and the Track 2 PAN was obtained by reading the EMV chip.

EMV Receipt Requirements

Merchant Name
Merchant Address1  Transaction Type (Purchase)
Merchant Address 2  Application Preferred Name (Tag 9F12) is
Merchant Address 3 printed (VISA CREDIT)
Customer Service Phone Number
 Application PAN (Tag 5A) must be truncated
and masked (************8106)
05/16/2014 11:55AM
 Card Entry Method indicates card was inserted
MID: XXXXXXXXXXXX1234 and card information was obtained by reading
TID: 12345678 the chip (Chip)
 Cardholder Verification Method “SIGN”
Purchase  Currency indicator “USD$” must be printed on
the total line
VISA CREDIT ************8106
 Transaction Amount (Tag 9F02) must be printed
Entry Mode: Chip
on the total line (90.04)
CVM: SIGN
 EMV Information must be printed in the order
shown and identified by the tag names:
<optional – Invoice #> <value>
<optional – Clerk/Server> <value>  AID (A0000000031010)
 TVR (0010008000)
<optional – Table #> <value>
 IAD (06010A03A40002)
<optional – more…> <value>
 TSI (E800)
 ARC (00)
Amount USD$ 90.04  EMV Offline Data block (i.e. Tag 50, Tag 5A,
<optional – Cashback:> <amount> etc.) is printed in the order shown using the
<optional – Surcharge:> <amount> labels shown
<optional – Tip:> <amount>
<optional – Total:> 90.04
EMV Receipt Best Practices
Response: DECLINED  Merchant and Customer receipt copies should
Auth Code: be identical with the exception of the receipt
copy indicator
<optional – Transition Ref1>
<optional – Transition Ref2> Additional Notes
<optional – Transition Ref3>
 A signature line is optional because the
transaction was declined
EMV Details:
AID: A0000000031010
TVR: 0010008000
IAD: 06010A03A40002
TSI: E800
ARC: Z1

EMV Offline Data

Tag 50: VISA Credit
Tag 5A: ************8106

Page 148 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Tag 5F2A:
Tag 5F34: 12
Tag 82: 1234
Tag 95: 1234567890
Tag 9A: 140516
Tag 9C: 115528
Tag 9F02: 90.0417117 Walder
Tag 9F03: 0.00
Tag 9F07: 1234
Tag 9F0D: 1234567890
Tag 9F0E: 1234567890
Tag 9F0F: 1234567890
Tag 9F10: 0123456789ABCDEF
Tag 9F12: VISA CREDIT
Tag 9F1A: 123
Tag 9F26: 0123456789ABCDEF
Tag 9F27: 12
Tag 9F34: 123456
Tag 9F36: 1234
Tag 9F37: 12345678
TAC Default: DC4000A800
TAC Denial: 0010000000
TAC Online: DC4004F800

MERCHANT COPY / CUSTOMER COPY

Page 149 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 150 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

13. Reporting Guidelines

There are a several EMV reports that can be very beneficial to TSYS and merchants. The following
sections identify the TSYS mandatory and recommended EMV reports.

13.1 Chip Transaction Report

The Chip Transaction Report shows the final EMV data element values for a transaction.
This is a mandatory report that, at a minimum, must be available for the last transaction processed.
TSYS recommends that the report be available for all transactions in the current batch.
The following sample report format is recommended.

CHIP TRANSACTION REPORT

TID: 12345678 06/28/2014 12:50

5A PAN xxxxxxxxxxxx1234
82 AIP 5C00
84 Dedicated file name A0000000031010
9A Transaction Date YYMMDD
9F21 Transaction Time HHMMSS
9C Transaction Type 00
5F34 PAN Seq Num 01
5F2A Tran Currency Code 840
9F02 Amount, authorized 000000001000
($10.00)
9F03 Amount, Other 000000000000
9F08 ICC App Version Num 008C
9F09 Term App Version Num 008C
9F1A Term Country Code 840
9F33 Terminal Capabilities F0 00 D8 80 01
9F34 CVM Results 040302
9F35 Terminal Type 22
9F36 ATC 0197
9F37 Unpredictable Number 1234567890
9F0D IAC Denial 0010000000
9F0E IAC Online F040009800
9F0F IAC Default F040008800
TAC Denial 0010000000
TAC Online D84004F800

Page 151 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

TAC Default D84000A800

1st GENERATE AC
95 TVR 0000008000
9F10 Issuer Appl Data 06010A03A40002
9F26 Appl Cryptogram 1234567890ABCDEF
9F27 CID 80
2nd GENERATE AC
91 Issuer Authentication Data
7A1416ECA2F20F7E3030
95 TVR 0000008000
9F26 Appl Cryptogram 1234567890ABCDEF
9F27 CID 40
Final
8A Auth Response Code 3030
9B TSI F800

BP 03100 Chip Transaction Report includes data element name and tag number
 It is recommended that the Chip Transaction Report show both the data element name and the
tag number (if assigned) for each field.

RQ 07700 Chip Transaction Report is mandatory


It is mandatory that the EMV POS Solution includes a Chip Transaction Report that prints the
EMV data element values. At a minimum this report must be available for the last transaction
processed regardless of whether the transaction was approved or declined. It is preferred that
this report be available for all transactions in the current batch.

13.2 EMV Technical Fallback Reports

TSYS recommends that the EMV POS Solution includes two fallback reports to monitor Technical
Fallback percentages:
 Clerk Fallback Report – Identifies clerks that have a high incidence of fallback transactions
 PINPad Fallback Report – Identifies PINPads that have a high incidence of fallback
transactions
A high number of Technical Fallback transactions are a sign of a problem. Having Technical Fallback
reports available makes it possible to identify if the issue is related to a specific clerk that may require
additional training or a PINPad that may require servicing.

Page 152 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

BP 03200 EMV Technical Fallback reports are recommended

 It is recommended that the EMV POS Solution include Technical Fallback reports to identify
clerks and PINPads with high Technical Fallback rates. The card brands also monitor fallback
rates so it‟s best to keep them as low as possible.

13.2.1 EMV Clerk Technical Fallback Report

This report shows Technical Fallback transactions by clerk and will help identify personnel who may need
additional training. The report should only identify the clerks that have a Technical Fallback percentage
over a defined threshold.

CLERK TECHNICAL FALLBACK REPORT

TID: 12345678 06/30/14 11:28AM

Period: 06/19/14 07:30AM
06/28/14 10:00AM
Threshold%: 5.0%

Clerk Total Tran # Technical Fallback # Technical Fallback %

123456 893 91 10%
987654 1,721 231 13%
Total 2,614 322 12%

Note: This report may be created by a store controller or back office system and contain statistics for
multiple devices. In this case the „TID‟ is not required and should be replaced with a site identifier.

Page 153 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

13.2.2 PINPad Technical Fallback Report

This report shows Technical Fallback transactions by PINPad and will help identify hardware that requires
servicing. The report should only identify the PINPads that have a Technical Fallback percentage over a
defined threshold percentage.

PINPAD TECHNICAL FALLBACK REPORT

TID: 12345678 06/29/14 11:28AM

Period: 06/19/14 07:30AM
06/28/14 10:00AM
Threshold%: 5.0%

PINPad Total Tran # Technical Fallback # Technical Fallback %

123456 455 76 17%
987654 140 92 66%
Total 595 168 28%

Note: This report may be created by a store controller or back office system and include statistics for
multiple PINPads. In this case the „TID‟ is not required and should be replaced with a site identifier. If
the report is created for a single terminal ID, the report will generally only list one PINPad unless the
PINPad was replaced during the period being printed.

13.3 POS Entry Mode Report

The POS Entry Mode Report identifies how card information data is being captured. This provides a view
of the type of cards being used by cardholders and the cardholders preferred method of payment.

POS ENTRY MODE REPORT

TID: 12345678 06/29/14 11:28AM

Period: 06/26/14 09:00AM
06/28/14 12:00AM
Transactions: 306

Mode Transactions % of Transactions

Chip Read 112 36%
Contactless 95 31%
Fallback 20 7%
Swiped 72 24%
Manual 7 2%

Page 154 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

BP 03300 POS Entry Mode Report is recommended

 The POS Entry Mode Report provides good insight into how cardholder data is being obtained.
It is a TSYS best practice that this report be available.

13.4 EMV Configuration Report

The EMV Configuration Report identifies all the EMV parameters loaded for all card schemes. It is
mandatory that this report be included in all EMV POS Solutions.

EMV CONFIGURATION REPORT

TID: 12345678 06/30/14 09:28AM

AID A00000002501
AID Label American Express Credit
Term Type 22
Term Capability E0B8C8
Addl Capability 7000F8AF
Term Country 840
Merch Cat Code 7411
TAC Default C8 00 00 00 00
TAC Denial 00 00 00 00 00
TAC Online C8 00 00 00 00
Term Country 840
Term Currency 840
Trans Curr Exp 2
Trans Cat Code
App Ver Num Pri 0x0001
App Ver Num Sec N/A
Term Floor Lim 0.00
Rand Sel Thresh 0.00
Rand Sel Max% 99
Rand Sel Target% 99
Partial Select Y
AllowFallback Y
AllowPINBypass N
Acquirer ID 00000
Default DDOL 9F3704
Default TDOL
----- Contactless -----
TAC Default DC 50 84 00 00
TAC Denial 00 00 00 00 00

Page 155 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

TAC Online C4 00 00 00 00
CTLS Floor Limit 15.00
CTLS Trans Limit 0.00
CTLS Req CVMLim 10.00
Enable ExPay MSD N
Enable ExPay EMV N
----- CAPK -----
CAPK1 Index 03
CAPK1 Exp Date 141231
CAPK2 Index 0E
CAPK2 Exp Date 180631
CAPK3 Index 0F
CAPK3 Exp Date 210631
CAPK4 Index 10
CAPK4 Exp Date 210631

AID A0000001523010
AID Label Discover Credit
Term Type 22
Term Capability E0B8C8
Add Capability 7000F8AF
Term Country 840
Merch Cat Code 7411
TAC Default DC 00 00 20 00
TAC Denial 00 10 00 00 00
TAC Online FC E0 9C F8 00
Term Country 840
Term Currency 840
Trans Curr Exp 2
Trans Cat Code
App Ver Num Pri 0x0001
App Ver Num Sec
Term Floor Limit 0.00
Rand Sel Thresh 0.00
Rand Sel Max 99
Rand Sel Target 99
Partial Select Y
Allow Fallback Y
Allow PIN Bypass N
Acquirer ID 610046
Default DDOL 9F3704
Default TDOL

Page 156 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

----- Contactless -----

TAC Default DC 00 00 20 00
TAC Denial 00 10 00 00 00
TAC Online FC E0 9C F8 00
CTLS Floor Limit 10.00
CTLS Trans Limit 1.00
CTLS Req CVMLim 0.00
----- CAPK -----
CAPK1 Index 5A
CAPK1 Exp Date 151231
CAPK2 Index 5B
CAPK2 Exp Date 161231
CAPK3 Index 5C
CAPK3 Exp Date 171231
CAPK4 Index 5D
CAPK4 Exp Date 181231

AID A0000000041010
AID Label MasterCard Credit
Term Type 22
Term Capability E0B8C8
Addl Capability 7000F8AF
Term Country 840
Merch Cat Code 7411
TAC Default FC 50 B8 A0 00
TAC Denial 00 00 00 00 00
TAC Online FC 50 B8 F8 00
Term Country 840
Term Currency 840
Trans Curr Exp 2
Trans Cat Code R
App Ver Num 1 0x0002
App Ver Num 2 0x0002
Term Floor Lim 0.00
RandSel Thresh 0.00
RandSel Max 99
RandSel Target 99
Partial Select Y
AllowFallback Y
AllowPINBypass N
Acquirer ID 12097
Default DDOL 9F3704

Page 157 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Default TDOL 9F0206…

----- Contactless -----
TAC Default FC 50 80 88 00
TAC Denial 00 00 00 00 00
TAC Online FC 50 80 88 00
CTLS TermCapCVMR E0B8C8
CTLS TermCapCVMN E0B0C8
CTLS Floor Limit 10.00
CTLS Trans Limit 1.00
CTLS Req CVMLim 50.00
MSD Version Num 1
Enable MChip Y
Enable MStripe Y
----- CAPK -----
CAPK1 Index FE
CAPK1 Exp Date 141231
CAPK2 Index F8
CAPK2 Exp Date 141231
CAPK3 Index FA
CAPK3 Exp Date 141231
CAPK4 Index EF
CAPK4 Exp Date 161231
CAPK5 Index F1
CAPK5 Exp Date 161231

AID A0000000031010
AID Label Visa Credit
Term Type 22
Term Capability E0B8C8
Addl Capability 7000F8AF
Term Country 840
Merch Cat Code 7411
TAC Default DC 40 00 A8 00
TAC Denial 00 10 00 00 00
TAC Online DC 40 04 F8 00
Term Country 840
Term Currency 840
Trans Curr Exp 2
Trans Cat Code
App Ver Num Pri 8C
App Ver Num Sec 96
Term Floor Lim 0.00

Page 158 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Rand Sel Thresh 0.00

Rand Sel Max 99
Rand Sel Target 99
Partial Select Y
Allow Fallback Y
Allow PIN Bypass N
Acquirer ID 412700
Default DDOL 9F3704
Default TDOL 9F0206
----- Contactless -----
TAC Default DC 40 00 A8 00
TAC Denial 00 10 00 00 00
TAC Online DC 40 04 F8 00
CTLS Floor Limit 0.00
CTLS Trans Limit 10.00
CTLS Req CVMLim 5.00
Visa TTQ xx x0 x0 00
----- CAPK -----
CAPK1 Index 95
CAPK1 Exp Date 141231
CAPK2 Index 99
CAPK2 Exp Date 141231
CAPK3 Index 92
CAPK3 Exp Date 141231
CAPK4 Index 94
CAPK4 Exp Date 161231

Note: For a definition of the report field names refer to the EMV and Contactless Parameters section
page 102.

RQ 07800 EMV Configuration Report is mandatory

 An EMV Configuration Report is a required by TSYS and must be available on all EMV POS
Solutions.

Page 159 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 160 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

14. EMV and Contactless Data Elements

14.1 EMV & Contactless Data Elements Definitions

The following table defines the EMV and contactless data elements and for each element provides the
tag number, data length, format and description. The format of each element is defined as follows:
an Alphanumeric
an x Alphanumeric of fixed length „x‟
an x-y Variable length alphanumeric with a minimum length „x‟ and a maximum length „y‟
ans Alphanumeric Special data elements that contain a single character per byte
(refer to EMVCo Book4 Annex B)
b Binary
cn Compressed Numeric
(similar to BCD but left justified and padded with trailing hexadecimal „F‟s)
nx Numeric of length „x‟
n x-y Variable length numeric with a minimum length of „x‟ and a maximum length of „y‟

When the length defined for the data object is greater than the length of the actual data, the following
rules apply for each data element:
 „n‟ – is right justified and padded with leading hexadecimal zeroes.
 „cn‟ – is left justified and padded with trailing hexadecimal „F‟ (0xF).
 „a‟, „an‟ or „ans‟ – are left justified and padded with trailing hexadecimal zeroes.
When data is moved from one entity to another (e.g. card to terminal), it will always be passed in order of
high order to low order, regardless of how it is internally stored. The same rule applies when
concatenating data.

Table 56 EMV & Contactless Data Elements – Sorted by Element Name

Name Description Source Format Tag Len

Acquirer Uniquely identifies the acquirer within each payment

Terminal n 6-11 „9F01‟ 6
Identifier system.

Additional
Indicates the data input and output capabilities of the
Terminal Terminal b „9F40‟ 5
terminal.
Capabilities

Amount,
Authorized amount of the transaction (excluding
Authorized Terminal b „81‟ 6
adjustments).
(Binary)

Authorized amount of the transaction (excluding

Amount,
adjustments).
Authorized Terminal n 12 „9F02‟ 6
(Numeric) Referred to in this document as “Transaction
Amount”.

Amount, Other Secondary amount associated with the transaction

Terminal b „9F04‟ 6
(Binary) representing a cashback amount.

Page 161 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Secondary amount associated with the transaction

Amount, Other representing a cashback amount. Terminal n 12 „9F03‟ 6
(Numeric)
Referred to in this document as “Other Amount”.

Amount,
Authorized amount expressed in the reference
Reference Terminal b „9F3A‟ 4
currency.
Currency

Application Cryptogram returned by the ICC in response of the

ICC b „9F26‟ 8
Cryptogram GENERATE AC command.

Application Indicates the currency in which the account is

ICC n3 „9F42‟ 2
Currency Code managed according to ISO 4217.

Application Indicates the implied position of the decimal point

Currency from the right of the account represented according ICC n1 „9F44‟ 1
Exponent to ISO 4217.

Application Indicates actions for the ICC to take for certain

ICC b „9F52‟ 4
Default Action exception conditions

Application
Issuer or payment system specified data relating to
Discretionary ICC b „9F05‟ 1-32
the application.
Data

Application n6
Date from which the application may be used. ICC „5F25‟ 6
Effective Date YYMMDD

Application n6
Date after which application expires. ICC „5F24‟ 3
Expiration Date YYMMDD

Application File Indicates the location (SFI, range of records) of the <=
ICC Var. „94‟
Locator (AFL) AEFs related to a given application 252

Application
Identifies the application as described in ISO/IEC
Identifier (AID) – ICC b „4F‟ 5-16
7816-5.
ICC

Application
Identifies the application as described in ISO/IEC
Identifier (AID) – Terminal b „9F06‟ 5-16
7816-5.
Terminal

Application
Indicates the capabilities of the card to support
Interchange ICC b „82‟ 2
specific functions in the application.
Profile

Application Mnemonic associated with the AID according to

ICC an 1-16 „50‟ 1-16
Label ISO/IEC 7816-5.

Application
Preferred mnemonic associated with the AID. ICC an 1-16 „9F12‟ 1-16
Preferred Name

Application
cn
Primary Account Valid cardholder account number. ICC „5A‟ <= 10
<= 19
Number (PAN)

Page 162 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Application
Primary Account
Identifies and differentiates cards with the same
Number (PAN) ICC n2 „5F34‟ 1
PAN.
Sequence
Number

Application Indicates the priority of a given application or group

ICC b „87‟ 1
Priority Indicator of applications in a directory.

1-4 currency codes used between the terminal and

Application
the ICC when the Transaction Currency Code is
Reference ICC n3 „9F3B‟ 2–8
different from the Application Currency Code; each
Currency
code is 3 digits according to ISO 4217.

For an application in the ICC to be supported by an At the

application in the terminal, the Application Selection discretion
Indicator indicates whether the associated AID in the of the
Application
terminal must match the AID in the card exactly terminal.
Selection Terminal -- var
(including the length of the AID) or only up to the The data
Indicator
length of the AID in the terminal. There is only one is not sent
Application Selection Indicator per AID supported by across the
the terminal. interface

Application Indicates the implied position of the decimal point

Reference from the right of the amount, for each of the 1-4
ICC n1 „9F43‟ 1–4
Currency reference currencies represented according to ISO
Exponent 4217.

This field is used by Canadian issuers if they want

Application
their application to be displayed for a particular ICC b „DF62‟ 2-32
Selection Flag
service. Also known as the “Canadian Flag”.

Application
Counter maintained by the application in the ICC
Transaction ICC b „9F36‟ 2
(incrementing the ATC is managed by the ICC).
Counter (ATC)

Indicates issuer's specified restrictions on the

Application
geographic usage and services allowed for the ICC b „9F07‟ 2
Usage Control
application.

Application
Version number assigned by the payment system for
Version Number ICC b „9F08‟ 2
the application.
(ICC)

Application
Version number assigned by the payment system for
Version Number Terminal b „9F09‟ 2
the application.
(Terminal)

Authorization Value generated by the issuer for an approved

Issuer an 6 „89‟ 6
Code transaction.

Authorization Issuer /
Code that defines the disposition of a message. an 2 „8A‟ 2
Response Code Terminal

Page 163 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Authorization
Response Cryptogram generated by the issuer and used by the
Issuer b N/A 4 or 8
Cryptogram card to verify that the response came from the issuer
(ARPC)

A calculated field used to allow the reader to print or

display the amount of offline spend available on the
Available Offline
card. The card will not allow this tag to be included
Spending ICC n 12 „9F5D‟ 6
in a record to be read by the reader or in the
Amount
response to GPO unless this tag is personalized with
a value of 1.

Card Additional Indicates card processing requirements and

Processes preferences. ICC b „9F68‟ 4
(Visa)

Card Additional Processes is mandatory unless the

Card Additional var. 5
qVSDC path is Streamlined Online only qVSDC (and ICC b „9F69‟
Processes -16
supported by the card implementation)

Card CVM Limit If present, indicates that when card and reader
(Visa) currencies match and a contactless transaction ICC n 12 „9F6B‟ 6
exceeds this value, a CVM is required by the Card.

Card Risk
Management List of data objects (tag and length) to be passed to <=
ICC b „8C‟
Data Object List the ICC in the 1st GENERATE AC command. 252
1 (CDOL1)

Card Risk
Management List of data objects (tag and length) to be passed to <=
ICC b „8D‟
Data Object List the ICC in the 2nd GENERATE AC command. 252
2 (CDOL2)

Used to indicate to the device which CVMs are

requested by the card.
Byte 1
bit 8 1 = Online PIN Required
bit 7 1 = Signature Required4
bit 6 1 = Go Online if Offline Data
Card
Authentication Fails and Reader is online
Transaction ICC b „9F6C‟ 2
capable.
Qualifiers (Visa)
bit 5 1 = Terminate if Offline Data
Authentication fails and Reader
supports contact VSDC.
bits 4-1 RFU
Byte 2
bits 8-1 RFU

Cardholder
Indicates cardholder name according to ISO 7813. ICC ans 2-26 „5F20‟ 2-26
Name

Page 164 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Indicates the whole cardholder name when greater

Cardholder
than 26 characters using the same coding ICC ans 27-45 „9F0B‟ 27-45
Name Extended
convention as in ISO 7813.

Cardholder
Verification Identifies a method of verification of the cardholder <=
ICC b „8E‟
Method (CVM) supported by the application. 252
List

Cardholder
Verification
Indicates the results of the last CVM performed. Terminal b „9F34‟ 3
Method (CVM)
Results

A check value calculated on the concatenation of all

Certification parts of the Certification Authority Public Key (RID,
Authority Public Certification Authority Public Key Index, Certification Terminal b -- 20
Key Check Sum Authority Public Key Modulus, Certification Authority
Public Key Exponent) using SHA-1

Certification
Value of the exponent part of the Certification
Authority Public Terminal b -- 1 or 3
Authority Public Key
Key Exponent

Certification
Identifies the certification authority's public key in
Authority Public ICC b „8F‟ 1
conjunction with the RID
Key Index

Certification
Identifies the certification authority's public key in
Authority Public Terminal b „9F22‟ 1
conjunction with the RID
Key Index

Certification NCA
Value of the modulus part of the Certification
Authority Public Terminal B -- (<=
Authority Public Key
Key Modulus 248)

Command
Identifies the data field of a command message Terminal b „83‟ var.
Template

Cryptogram Indicates the type of cryptogram and the actions to

ICC b „9F27‟ 1
Information Data be performed by the terminal.

Contains data for transmission to the Issuer in MSD

transactions with a cryptogram. Customer Exclusive
Customer Data is both an implementation and Issuer option.
var.
Exclusive Data Inclusion of the Customer Exclusive Data in online ICC b „9F7C‟
<= 32
(CED) (Visa) messages is an option for MSD readers compliant to
this specification. Customer Exclusive Data will be
updateable via an Issuer Script command.

The CVC3TRACK1 is a 2-byte cryptogram returned

CVC3 (Track1)
by the card in the response to the COMPUTE ICC b „9F60‟ 2
(MasterCard)"
CRYPTOGRAPHIC CHECKSUM command.

Page 165 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

The CVC3TRACK2 is a 2-byte cryptogram returned

CVC3 (Track2)
by the card in the response to the COMPUTE ICC b „9F61‟ 2
(MasterCard)
CRYPTOGRAPHIC CHECKSUM command.

Data An issuer assigned value that is retained by the

Authentication terminal during the verification process of the Signed ICC b „9F45‟ 2
Code Static Application Data

If Track 1 Data is present, DDCARD,TRACK1

contains a copy of the discretionary data field of
DDCARD, Track 1 Data as returned by the card in the file read var <=
Terminal ans --
TRACK1 using the READ RECORD command during a 56
PayPass – Mag Stripe transaction (i.e. without UN
(Numeric), ATC, CVC3TRACK1 and nUN included).

DDCARD,TRACK2 contains a copy of the

discretionary data field of Track 2 Data as returned
DDCARD, by the card in the file read using the READ RECORD var <=
ans --
TRACK2 command during a PayPass – Mag Stripe transaction 8
(i.e. without UN (Numeric), ATC, CVC3TRACK2 and
nUN included).

Dedicated File Identifies the name of the DF as described in

ICC b „84‟ 5-16
(DF) Name ISO/IEC 7816-4. Usually the same as the AID.

Default Dynamic
Data DDOL to be used for constructing the INTERNAL
Authentication AUTHENTICATE command if the DDOL in the card Terminal b -- var.
Data Object List is not present
(DDOL)

Default
Transaction
TDOL to be used for generating the TC Hash Value if
Certificate Data Terminal b -- var.
the TDOL in the card is not present
Object List
(TDOL)

Directory
Identifies the name of a DF associated with a
Definition File ICC b „9D‟ 5 – 16
directory
(DDF) Name

Directory var.
Issuer discretionary part of the directory according to
Discretionary ICC var. „73‟ <=
ISO/IEC 7816-5
Template 252

Dynamic Data
List of data objects (tag and length) to be passed to
Authentication <=
the ICC in the INTERNAL AUTHENTICATE ICC b „9F49‟
Data Object List 252
command
(DDOL)

Enciphered
Personal Transaction PIN enciphered at the PINPad for online
Identification verification or for offline verification if the PINPad and Terminal b -- 8
Number (PIN) IFD are not a single integrated device
Data

Page 166 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

File Control
Information
<=
(FCI) Issuer Issuer discretionary part of the FCI ICC var. „BF0C‟
222
Discretionary
Data

File Control
Identifies the data object proprietary to this
Information
specification in the FCI template according to ICC var. „A5‟ var.
(FCI) Proprietary
ISO/IEC 7816-4
Template

File Control
Identifies the FCI template according to ISO/IEC <=
Information ICC var. „6F‟
7816-4 252
(FCI) Template

Indicates the form factor of the consumer payment

device and the type of contactless interface over
which the transaction was conducted. The Form
Form Factor Factor Indicator is both an implementation and Issuer
Indicator (FFI) option. Inclusion of the Form Factor Indicator in ICC b „9F6E‟ 4
(Visa) online messages (and clearing records for offline
capable readers) is an option for qVSDC and MSD
readers. The Form Factor Indicator will be
updateable via an Issuer script command.

PayPass Third
The PayPass Third Party Data contains proprietary var 5 -
Party Data ICC b „9F6E‟
information from a third party. 32
(MasterCard)

ICC Dynamic Time-variant number generated by the ICC, to be

ICC b „9F4C‟ 2–8
Number captured by the terminal

Integrated
Circuit Card
(ICC) PIN ICC PIN Encipherment Public Key certified by the
ICC b „9F2D‟ NI
Encipherment issuer
Public Key
Certificate

Integrated
Circuit Card
(ICC) PIN ICC PIN Encipherment Public Key Exponent used for
ICC b „9F2E‟ 1 or 3
Encipherment PIN encipherment
Public Key
Exponent

Integrated
Circuit Card
NPE −
(ICC) PIN Remaining digits of the ICC PIN Encipherment Public
ICC b „9F2F‟ NI +
Encipherment Key Modulus
42
Public Key
Exponent

Page 167 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Integrated
Circuit Card
(ICC) PIN
ICC Public Key certified by the issuer ICC b „9F46‟ NI
Encipherment
Public Key
Remainder

Integrated
Circuit Card ICC Public Key Exponent used for the verification of
ICC b „9F47‟ 1 to 3
(ICC) Public Key the Signed Dynamic Application Data
Certificate

Integrated
NPE −
Circuit Card
Remaining digits of the ICC Public Key Modulus ICC b „9F48‟ NI +
(ICC) Public Key
42
Remainder

Interface Device
Unique and permanent serial number assigned to the
(IFD) Serial Terminal an 8 „9F1E‟ 8
IFD by the manufacturer.
Number

Specifies the issuer's conditions that cause a

Issuer Action transaction to be rejected if it might have been
ICC b „9F0D‟ 5
Code – Default approved online, but the terminal is unable to
process the transaction online.

Issuer Action Specifies the issuer's conditions that cause the

ICC b „9F0E‟ 5
Code – Denial denial of a transaction without attempt to go online.

Issuer Action Specifies the issuer's conditions that cause a

ICC b „9F0F‟ 5
Code – Online transaction to be transmitted online.

Issuer Contains proprietary application data for transmission

ICC b „9F10‟ <= 32
Application Data to the issuer in an online transaction.

Issuer
Authentication Data sent to the card for online issuer authentication. Issuer b „91‟ 8-16
Data

Issuer Code Indicates the code table according to ISO 8859 for
ICC n2 „9F11‟ 1
Table Index displaying the Application Preferred Name.

Issuer Country Indicates the country of the issuer according to ISO

ICC n3 „5F28‟ 2
Code 3166.

Issuer Country Code (alpha 2 format) used as part of

Issuer Country
the Candidate List editing for U.S. Common Debit ICC a2 „5F55‟ 2
Code (Alpha 2)
AIDs

Issuer Country
Issuer Country Code (alpha 3 format) ICC a3 „5F56‟ 3
Code (Alpha 3)

Issuer
Issuer Identification Number – this tag is used as part
Identification
of the Candidate List editing for U.S. Common Debit ICC b „42‟ 3
Number (IIN or
AIDs
BIN)

Page 168 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Issuer Public
Issuer public key certified by a certification authority ICC b „90‟ NCA
Key Certificate

Issuer public key exponent used for the verification of

Issuer Public
the Signed Static Application Data and the ICC ICC b „9F32‟ 1–3
Key Exponent
Public Key Certificate

NI −
Issuer Public
Remaining digits of the Issuer Public Key Modulus ICC b „92‟ NCA +
Key Remainder
36

Issuer Script <=

Contains a command for transmission to the ICC Issuer b „86‟
Command 261

Issuer Script
Identification of the Issuer Script Issuer b „9F18‟ 4
Identifier

Issuer Script
Indicates the result of the chip script processing. Terminal b „9F5B‟ var.
Results

Contains proprietary issuer data for transmission to

Issuer Script
the ICC before the second GENERATE AC Issuer b „71‟ var.
Template 1
command.

Issuer Script Contains proprietary issuer data for transmission to

Issuer b „72‟ var.
Template 2 the ICC after the second GENERATE AC command.

The URL provides the location of the Issuer‟s Library

Issuer URL ICC ans „5F50‟ var.
Server on the Internet.

1-4 languages stored in order of preference, each

Language
represented by 2 alphabetical characters according ICC an 2 „5F2D‟ 2-8
Preference
to ISO 639.

Last Online
Application
Transaction ATC value of the last transaction that went online ICC b „9F13‟ 2
Counter (ATC)
Register

Issuer-specified preference for the maximum number

Lower
of consecutive offline transactions for this ICC
Consecutive ICC b „9F14‟ 1
application allowed in a terminal with online
Offline Limit
capability.

Mag Stripe
Version number assigned by the payment system for
Application
the specific PayPass – Mag Stripe functionality of the ICC B „9F6C‟ 2
Version Number
application.
(MasterCard)

Mag Stripe
Version number assigned by the payment system for
Application
the specific PayPass – Mag Stripe functionality of the Terminal B „9F6D‟ 2
Version Number
application.
(MasterCard)

Page 169 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Maximum Target
Percentage to
Value used in terminal risk management for random
be used for Terminal -- -- --
transaction selection.
Biased Random
Selection

Classifies the type of business being done by the

Merchant
merchant, represented according to ISO 8583:1993 Terminal n4 „9F15‟ 2
Category Code
for Card Acceptor Business Code.

Merchant When concatenated with the Acquirer Identifier,

Terminal ans 15 „9F16‟ 15
Identifier uniquely identifies a given merchant

Indicates whether the batch data capture record is a

Message Type Terminal n2 -- 1
financial record or advice

• Specifies the offset from the beginning of Track 2

Equivalent Data (Tag „57‟) to the first digit/nibble of
the dCVV.
• Implementations may support updating of the MSD
Offset via an Issuer Script command. If the MSD
Offset is not personalized or is personalized with a
value of zero, Track 2 Equivalent Data (Tag „57‟) will
be returned exactly as it was personalized.
• Personalizing the MSD Offset with a value greater
than zero indicates that the dCVV and ATC will be
MSD Offset calculated and inserted into Track 2 Equivalent Data
for MSD transactions without a cryptogram. ICC b „9F67‟ 1
(Visa)
• If the implementation supports insertion of the ATC
in Track 2 Equivalent Data for qVSDC and MSD
transactions, the high-order bit of the MSD Offset is
used to activate this functionality:
bit 8 1 = Insert ATC into Track 2 Equivalent
Data for all qVSDC and MSD
transactions
bits 7-1 Offset from the beginning of Track 2
Equivalent Data to the first digit of the
CVV placeholder

Indicates for each AID whether the PayPass – Mag

PayPass – Msg
Stripe profile is supported or not by the PayPass Terminal -- -- --
Stripe Indicator
reader. Its value is implementation specific.

Personal Secret key of a symmetric algorithm used by the

Identification PINPad to encipher the PIN and by the card reader
Terminal -- -- --
Number (PIN) to decipher the PIN if the PINPad and card reader
Pad Secret Key are not integrated

PIN Try Counter Number of PIN tries remaining. ICC b „9F17‟ 1

Indicates the method by which the PAN was entered,

POS Entry Mode according to the first two digits of the ISO 8583:1987 Terminal n2 „9F39‟ 1
POS Entry Mode.

Page 170 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Processing
Contains a list of terminal resident data objects (tags
Options Data
and lengths) needed by the ICC in processing the ICC b „9F38‟ var.
Object List
GET PROCESSING OPTIONS command.
(PDOL)

Service Code Service Code as defined on Track 1 and Track 2 ICC n3 „5F30‟ 2

Identifies the SFI to be used in the commands

Short File related to a given AEF or DDF. The SFI data object
ICC b „88‟ 1
Identifier (SFI) is a binary field with the three high order bits set to
zero.

Signed Dynamic Digital signature on critical application parameters for

ICC b „9F4B‟ NIC
Application Data dynamic data authentication

Signed Static Digital signature on critical application parameters for

ICC b „93‟ NI
Application Data static data authentication

Static Data List of tags of primitive data objects defined in this

Authentication specification whose value fields are to be included in ICC -- „9F4A‟ var.
Tag List the Signed Static or Dynamic Application Data

Target
Percentage to
Value used in terminal risk management for random
be used for Terminal -- -- --
transaction selection.
Random
Selection

Specifies the acquirer‟s conditions that cause a

Terminal Action transaction to be rejected if it might have been
Terminal b -- 5
Code – Default approved online, but the terminal is unable to
process the transaction online.

Terminal Action Specifies the acquirer‟s conditions that cause the

Terminal b -- 5
Code – Denial denial of a transaction without attempt to go online.

Terminal Action Specifies the acquirer‟s conditions that cause a

Terminal b -- 5
Code – Online transaction to be transmitted online.

Terminal Indicates the card data input, CVM and security

Terminal b „9F33‟ 3
Capabilities capabilities of the terminal.

Terminal Indicates the country of the terminal, represented

Terminal n3 „9F1A‟ 2
Country Code according to ISO 3166.

Terminal
Indicates the transaction amount limit for the related
Contactless
AID above which transactions must be authorized Terminal n 12 -- 6
Floor Limit (Visa,
online.
MasterCard)

Terminal
Indicates the transaction amount limit for the related
Contactless
AID above which the selection of the AID on the card
Transaction Terminal n 12 -- 6
is not allowed. It is permitted to attempt the
Limit (Visa,
transaction over another interface.
MasterCard)

Page 171 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

If a contactless transaction exceeds this value, a

Terminal CVM CVM is required by the Reader.
Required Limit
Online PIN and Signature are CVMs defined for Visa. Terminal n 12 -- 6
(Visa,
MasterCard) Online PIN, Signature and NO CVM are CVMs
defined for MasterCard.

Terminal
Contactless
Indicates for the related AID if the Terminal
Floor Exceeded Terminal -- -- --
Contactless Floor Limit is exceeded.
Flag
(MasterCard)

Terminal
Contactless
Transaction Indicates for the related AID if the Terminal
Terminal -- -- --
Limit Exceeded Contactless Transaction Limit is exceeded.
Flag
(MasterCard)

Terminal CVM
Required Limit Indicates for the related AID if the Terminal CVM
Terminal -- -- --
Exceeded Flag Required Limit is exceeded.
(MasterCard)

Terminal Floor Indicates the floor limit in the terminal in conjunction

Terminal b „9F1B‟ 4
Limit with the AID.

Terminal Designates the unique location of a terminal at a

Terminal an 8 „9F1C‟ 8
Identification merchant.

Terminal Risk
Application-specific value used by the card for risk
Management Terminal b „9F1D‟ 1-8
management purposes.
Data

Page 172 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Indicates reader capabilities, requirements and

preferences to the card.
Byte 1
8 '1' – Contactless magstripe (MSD) supported
'0' – Contactless magstripe (MSD) not supported
7 '1'– Contactless VSDC supported
'0'– Contactless VSDC not supported
6 '1'– Contactless qVSDC supported
'0' – Contactless qVSDC not supported
5 '1'– Contact VSDC (EMV chip) supported
'0'– Contact VSDC (EMV chip) not supported
4 '1'– Reader is Offline Only
Terminal '0'– Reader is Online Capable
Transaction Terminal b „9F66‟ 4
3 '1'– Online PIN supported
Qualifiers
'0'– Online PIN not supported
2 '1'– Signature supported
'0'– Signature not supported
1 RFU – b'x'
Byte 2
8 '1'– Online cryptogram required
'0'– Online cryptogram not required
7 '1'– CVM required
'0'– CVM not required
6-1 RFU
Byte 3 RFU
Byte 4 RFU

Indicates the environment of the terminal, its

Terminal Type communications capability and its operational Terminal n2 „9F35‟ 1
control.

Terminal
Status of the different functions as seen from the
Verification Terminal b „95‟ 5
terminal.
Results

Threshold Value
for Biased Value used in terminal risk management for random
Terminal -- -- --
Random transaction selection.
Selection

Page 173 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

The Track 1 Data may be present in the file read

using the READ RECORD command during a
PayPass – Mag Stripe transaction. The PayPass
Track 1 Data reader copies the required digits of the UN var.
ICC ans „56‟
(MasterCard) (Numeric), CVC3TRACK1, ATC and nUN into the <= 76
discretionary data field of the Track 1 Data and
stores the modified Track 1 Data in the Data Record
to be sent to the terminal.

Track 1 Number The value of NATCTRACK1 represents the number of

of ATC Digits digits of the ATC to be included in the discretionary ICC b „9F64‟ 1
(NATCTRACK1) data field of the Track 1 Data.

Track 1
Discretionary part of track 1 according to ISO/IEC
Discretionary ICC an „9F1F‟ var.
7813.
Data

Contains the data elements of the track 2 according

b
to ISO/IEC 7813, excluding start sentinel, end
sentinel and LRC, as follows:
Primary Account Number
n, <= 40
Track 2 Field Separator (hex „D‟) ICC b „57‟ <= 40
Equivalent Data
Expiration Date (YYMM)
n4
Service Code
n3
Discretionary Data (Define by the payment systems)
n, var.
Pad with hex „F‟ to ensure whole bytes.

The Track 2 Data is present in the file read using the

READ RECORD command during a PayPass – Mag
Stripe transaction. The PayPass reader copies the
Track 2 Data var.
required digits of the UN (Numeric), CVC3TRACK2, ICC b „9F6B‟
(MasterCard) <= 19
ATC and nUN into the discretionary data field of the
Track 2 Data and stores the modified Track 2 Data in
the Data Record to be sent to the terminal.

Track 2 Bitmap PCVC3TRACK2 indicates to the PayPass reader the

for CVC3 positions in the discretionary data field of the Track 2
ICC b „9F65‟ 2
(PCVC3TRACK2)( Data where the qTRACK2 CVC3TRACK2 digits have to be
MasterCard) copied.

Track 2 Bitmap PUNATCTRACK2 indicates to the PayPass reader the

for UN and ATC positions in the discretionary data field of the Track 2
ICC b „9F66‟ 2
(PUNATCTRACK2) Data where the nUN UN (Numeric) digits and tTRACK2
(MasterCard) ATC digits have to be copied.

Track 2 Number The value of NATCTRACK2 represents the number of

of ATC Digits digits of the ATC to be included in the discretionary ICC b „9F67‟ 1
(NATCTRACK2) data field of the Track 2 Data.

Transaction Clearing amount of the transaction, including tips and

Terminal n 12 -- 6
Amount other adjustments.

Page 174 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Transaction
Result of a hash function specified in Book 2, Annex
Certificate (TC) Terminal b „98‟ 20
B3.1 of the EMVCo Specifications.
Hash Value

Transaction
var.
Certificate Data List of data objects (tag and length) to be used by the
ICC b „97‟ <=
Object List terminal in generating the TC Hash Value
252
(TDOL)

Transaction Indicates the currency code of the transaction

Terminal n3 „5F2A‟ 2
Currency Code according to ISO 4217

Transaction Indicates the implied position of the decimal point

Currency from the right of the transaction amount represented Terminal n1 ‟5F36‟ 1
Exponent according to ISO 4217

Data object used to indicate to the terminal the

outcome of the CVM Selection function. Possible
Transaction values are:
CVM • NO CVM Terminal -- -- --
(MasterCard) • Signature
• Online PIN
The coding of the value is implementation specific.

Transaction n6
Local date that the transaction was authorized. Terminal „9A‟ 3
Date YYMMDD

Data object used to indicate to the terminal the

outcome of the transaction processing. Possible
values are:
• Approved – The PayPass reader is satisfied that
the transaction is acceptable with the selected card
application and wants the transaction to be offline
approved.
• Online Request – The PayPass reader has found
that the transaction requires an online authorization.
Transaction
• Declined – The PayPass reader has found that the
Outcome Terminal -- -- --
transaction is not acceptable with the selected card
(MasterCard)
application and wants the transaction to be offline
declined.
• Try Another Interface – The PayPass reader is
unable to complete the transaction with the selected
card application, but knows that another interface
(e.g. contact or magnetic-stripe) may be available.
• End Application – The PayPass reader experienced
an application error (e.g. missing data)
The coding of the value is implementation-specific.

Page 175 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

Transaction
Personal
Data entered by the cardholder for the purpose of the
Identification Terminal b „99‟ var.
PIN verification
Number (PIN)
Data

Transaction Code defining the common currency used by the

Reference terminal in case the Transaction Currency Code is Terminal n3 „9F3C‟ 2
Currency Code different from the Application Currency Code

Transaction Indicates the implied position of the decimal point

Reference from the right of the transaction amount, with the
Terminal n1 „9F3D‟ 1
Currency Transaction Reference Currency Code represented
Exponent according to ISO 4217

Transaction
Counter maintained by the terminal that is
Sequence Terminal n 4-8 „9F41‟ 2–4
incremented by one for each transaction
Counter

Transaction
Status Indicates the functions performed in a transaction. Terminal b „9B‟ 2
Information

Transaction n6
Local time that the transaction was authorized. Terminal „9F21‟ 3
Time HHMMSS

Indicates the type of financial transaction,

Transaction
represented by the first two digits of ISO 8583:1987 Terminal n2 „9C‟ 1
Type
Processing Code.

Unpredictable Value to provide variability and uniqueness to the

Terminal b „9F37‟ 4
Number generation of a cryptogram.

The UDOL is the DOL that specifies the data objects

Unpredictable to be included in the data field of the COMPUTE
Number Data CRYPTOGRAPHIC CHECKSUM command. The
Object List UDOL must at least include the UN (Numeric). The ICC b „9F69‟ var.
(UDOL) UDOL is not mandatory for the card. There will
(MasterCard) always be a Default UDOL, including as its only entry
the tag and length of the UN (Numeric) (tag '9F6A').

Unpredictable number generated by the PayPass

reader during a PayPass – Mag Stripe Transaction.
Unpredictable
The UN (Numeric) is passed to the card in the data
Number
field of the COMPUTE CRYPTOGRAPHIC Terminal n „9F6A‟ 8
(Numeric)
CHECKSUM command.
(MasterCard)
The (8-nUN) most significant digits must be set to
zero.

Issuer-specified preference for the maximum number

Upper
of consecutive offline transactions for this ICC
Consecutive ICC b „9F23‟ 1
application allowed in a terminal without online
Offline Limit
capability.

Page 176 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Name Description Source Format Tag Len

A counter that may be decremented (for LV or CTTA

VLP Available
the funds may be added to CTTA) by the Amount,
Funds ICC n 12 „9F79‟ 6
Authorized when an offline low-value qVSDC
(Visa)
transaction takes place.

VLP Funds Limit

Value to which VLP Available Funds is reset. ICC n 12 „9F77‟ 6
(Visa)

If Amount, Authorized is greater than VLP Available

VLP Reset
Funds minus this threshold, the card requests online ICC n 12 „9F6D‟ 6
Threshold (Visa)
processing.

VLP Single
Transaction ICC n12 „9F78‟ 6
Limit (Visa)

Page 177 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

This page intentionally blank

Page 178 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15. Reference Materials

The information in this chapter has been extracted from the EMV 4.3 specifications.

15.1 Answer to Reset

Table 57 Basic ATR for T=0 Cards Only
Character Value Remarks

TS „3B‟ or „3F‟ Indicates direct or inverse convention

T0 „6x‟ TB1 to TC1 present; x indicates the number of historical bytes present

TB1 „00‟ VPP not required

TC1 „00‟ to „FF‟ Indicates the amount of extra guard time required

Table 58 Basic ATR for T=1 Cards Only

Character Value Remarks

TS „3B‟ or „3F‟ Indicates direct or inverse convention

T0 „Ex‟ TB1 to TD1 present; x indicates the number of historical bytes present

TB1 „00‟ VPP not required

TC1 „00‟ to „FF‟ Indicates the amount of extra guard time required.

TD1 „81‟ TA2, TB2 and TC2 absent; TD2 present; T=1 to be used

TD2 „31‟ TA3 and TB3 present; TC3 and TD3 absent; T=1 to be used

Returns IFSI, which indicates initial value for information field size for ICC
TA3 „10‟ to „FE‟
and IFSC of 16-254 bytes

m.s. nibble „0‟ – BWI = 0 to 4

TB3 „4‟
CWI = 0 to 5
l.s. nibble „0‟ – „5‟

TCK Check character

Page 179 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.2 EMV Reference Tables

The following tables are provided as reference material to assist in understanding the EMV processes.

15.2.1 Application Interchange Profile (Tag 82)

Table 59 Application Interchange Profile (Tag 82) – Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Reserved for future use
1 Static data authentication supported
1 Dynamic data authentication supported
1 Cardholder verification supported
1 Perform Terminal Risk Management
1 Issuer authentication supported
0 Reserved for future use
1 Combined DDA/AC supported

Table 60 Application Interchange Profile (Tag 82) – Byte 2

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Page 180 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.2.2 Application Priority Indicator (Tag 87)

Table 61 Application Priority Indicator (Tag 87) – Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Application cannot be selected without cardholder confirmation
0 Application can be selected without confirmation of the cardholder.
0 0 0 Reserved for future use
0 0 0 0 No Priority Assigned
Order in which the application is to be listed or selected.
x x x x
Ranging from 1 – 15, with 1 being the highest priority.

15.2.3 Application Usage Control (Tag 9F07)

Table 62 Application Usage Control (Tag 9F07) – Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Valid for domestic cash transactions
1 Valid for international cash transactions
1 Valid for domestic goods
1 Valid for international goods
1 Valid for domestic services
1 Valid for international services
1 Valid at ATMs
1 Valid at terminals other than ATMs

Table 63 Application Usage Control (Tag 9F07) – Byte 2

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Domestic cashback allowed
1 International cashback allowed
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Page 181 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.2.4 Cardholder Verification Rule (part of CVM List)

Table 64 Cardholder Verification Rule – Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 Reserved for future use
0 Fail cardholder verification if CVM unsuccessful.
1 Apply succeeding CVR if CVM unsuccessful.
0 0 0 0 0 0 Fail CVM processing.
0 0 0 0 0 1 Plain text PIN verification performed by ICC.
0 0 0 0 1 0 Enciphered PIN verified online.
0 0 0 0 1 1 Plain text PIN verification performed by ICC and signature (paper).
0 0 0 1 0 0 Enciphered PIN verification performed by ICC.
0 0 0 1 0 1 Enciphered PIN verification performed by ICC and signature (paper).
Reserved for future use by the EMV specification.
0 x x x x x
Range 000110-011101
0 1 1 1 1 0 Signature (paper).
0 1 1 1 1 1 No CVM required.
Reserved for future use by the EMV specification.
1 0 x x x x
Range 100000-101111
Reserved for future use by the EMV specification.
1 1 x x x x
Range 110000-111110

Cardholder Verification Rule – Byte 2

Value Meaning
00 Always
01 If unattended cash
02 If not unattended cash and not manual cash and not purchase with cashback
03 If terminal supports the CVM
04 If manual cash
05 If purchase with cashback
06 If transaction is in the application currency and is under „x‟ value
07 If transaction is in the application currency and is over „x‟ value
08 If transaction is in the application currency and is under „y‟ value
09 If transaction is in the application currency and is over „y‟ value
0A – 7F Reserved for future use
80 – FF Reserved for use by individual payment schemes

Page 182 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.2.5 Cardholder Verification Method Results (Tag 9F34)

Table 65 Cardholder Verification Method Results (Tag 9F34) – Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 Reserved for future use
0 Fail cardholder verification if CVM unsuccessful
1 Apply succeeding CVR if CVM unsuccessful
0 0 0 0 0 0 Fail CVM processing
0 0 0 0 0 1 Plain text PIN verification performed by ICC
0 0 0 0 1 0 Enciphered PIN verified online
0 0 0 0 1 1 Plain text PIN verification performed by ICC and signature (paper)
0 0 0 1 0 0 Enciphered PIN verification performed by ICC
0 0 0 1 0 1 Enciphered PIN verification performed by ICC and signature (paper)
Reserved for future use by the EMV specification.
0 x x x x x
Range 000110-011101
0 1 1 1 1 0 Signature (paper)
0 1 1 1 1 1 No CVM required
Reserved for future use by the EMV specification.
1 0 x x x x
Range 100000-101111
Reserved for future use by the EMV specification.
1 1 x x x x
Range 110000-111110
1 1 1 1 1 1 This value is not available for use

Table 66 Cardholder Verification Method Results (Tag 9F34) – Byte 2

Value Meaning
00 Always
01 If cash or cashback
02 If not cash or cashback
03 If terminal supports the CVM
04 Reserved for future use
05 Reserved for future use
06 If transaction is in the application currency and is under „x‟ value
07 If transaction is in the application currency and is over „x‟ value
08 If transaction is in the application currency and is under „y‟ value
09 If transaction is in the application currency and is over „y‟ value

Table 67 Cardholder Verification Method Results (Tag 9F34) – Byte 3

Value Meaning
00 Unknown (e.g. for signature)
01 Failed (e.g. Offline PIN)
02 Successful (e.g. Offline PIN)

Page 183 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.2.6 Card Verification Results (included in Tag 9F10)

The following Card Verification Results (CVR) definition is as per the EMVCo CCD specifications.
Specific card brand definitions may differ.

Table 68 Card Verification Results – Byte 1

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
nd
x x Application Cryptogram Type returned in 2 GENERATE AC
0 0 AAC
0 1 TC
nd
1 0 2 GENERATE AC Not Requested
1 1 Reserved for future use
st
x x Application Cryptogram Type returned in 1 GENERATE AC
0 0 AAC
0 TC
1 0 ARQC
1 1 Reserved for future use
1 CDA Performed
1 Offline DDA Performed
1 Issuer Authentication Not Performed
1 Issuer Authentication Failed

Table 69 Card Verification Results – Byte 2

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x Low Order Nibble of PIN Try Counter
1 Offline PIN Verification Performed
1 Offline PIN Verification Performed and PIN Not Successfully Verified
1 PIN Try Limit Exceeded
1 Last Online Transaction Not Completed

Table 70 Card Verification Results – Byte 3

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Lower Offline Transaction Count Limit Exceeded
1 Upper Offline Transaction Count Limit Exceeded
1 Lower Cumulative Offline Amount Limit Exceeded
1 Upper Cumulative Offline Amount Limit Exceeded
1 Issuer-discretionary bit 1
1 Issuer-discretionary bit 2
1 Issuer-discretionary bit 3
1 Issuer-discretionary bit 4

Page 184 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 71 Card Verification Results – Byte 4

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x Number of Issuer Script commands containing secure messaging
processed
1 Issuer Script Processing Failed
1 Offline Data Authentication Failed on Previous Transaction
1 Go Online on Next Transaction was Set
1 Unable to Go Online

Table 72 Card Verification Results – Byte 5

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
1 Reserved for future use
0 Reserved for future use

15.2.7 Cryptogram Information Data (Tag 9F27)

Table 73 Cryptogram Information Data (Tag 9F27)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
nd
x x Application Cryptogram Type returned in 2 GENERATE AC
0 0 AAC
0 1 TC
1 0 ARQC
1 1 AAR
0 0 Payment System specific cryptogram
0 No Advice Required
1 Advice Required
x x x Reason/advice/referral code
0 0 0 No information given
0 0 1 Service not allowed
0 1 0 PIN Try Limit Exceeded
0 1 1 Issuer Authentication Failed

Page 185 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.2.8 Terminal Capabilities (Tag 9F33)

Table 74 Terminal Capabilities (Tag 9F33) – Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Manual Key Entry
1 Magnetic Stripe
1 IC with Contacts
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Table 75 Terminal Capabilities (Tag 9F33) – Byte 2

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Plain text PIN for ICC verification.
1 Enciphered PIN for online verification.
1 Signature (paper).
1 Enciphered PIN for offline verification.
1 NO CVM
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Table 76 Terminal Capabilities (Tag 9F33) – Byte 3

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Static data authentication.
1 Dynamic data authentication.
1 Card capture.
0 Reserved for future use
1 Combined DDA/AC supported.
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Page 186 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.2.9 Additional Terminal Capabilities

Table 77 Additional Terminal Capabilities (Tag 9F40) – Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Cash
1 Goods
1 Services
1 Cashback
1 Inquiry
1 Transfer
1 Payment
1 Administrative

Table 78 Additional Terminal Capabilities (Tag 9F40) – Byte 2

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Table 79 Additional Terminal Capabilities (Tag 9F40) – Byte 3

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Numeric keys
1 Alphabetic and special character keys
1 Command keys
1 Function keys
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Page 187 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 80 Additional Terminal Capabilities (Tag 9F40) – Byte 4

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Print – attendant
1 Print – cardholder
1 Display – attendant
1 Display – cardholder
0 Reserved for future use
0 Reserved for future use
1 Code table 10
1 Code table 9

Table 81 Additional Terminal Capabilities (Tag 9F40) – Byte 5

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Code table 8
1 Code table 7
1 Code table 6
1 Code table 5
1 Code table 4
1 Code table 3
1 Code table 2
1 Code table 1

15.2.10 Terminal Verification Results (Tag 95)

Table 82 Terminal Verification Results (Tag 95) – Byte 1 (Offline Data Authentication)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Off-line data authentication not performed.
1 Off-line static data authentication failed.
1 ICC data missing.
1 Card appears on terminal exception file.
1 Off-line dynamic data authentication failed.
1 Combined DDA/AC generation failed.
1 SDA selected
0 Reserved for future use

Page 188 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 83 Terminal Verification Results (Tag 95) – Byte 2 (Processing Restrictions)

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 ICC and terminal have different application versions.
1 Expired application.
1 Application not yet effective.
1 Requested service not allowed for card product.
1 New card.
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Table 84 Terminal Verification Results (Tag 95) – Byte 3 (Cardholder Verification)

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Cardholder verification failed.
1 Unrecognized CVM.
1 PIN try limit exceeded.
1 PIN entry required and PINPad not present or not working.
1 PIN entry required. PINPad present but PIN was not entered.
1 Online PIN entered.
0 Reserved for future use
0 Reserved for future use

Table 85 Terminal Verification Results (Tag 95) – Byte 4 (Terminal Risk Management)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Transaction exceeds floor limit.
1 Lower consecutive off-line limit exceeded.
1 Upper consecutive off-line limit exceeded.
1 Transaction selected randomly for online processing.
1 Merchant forced transaction online.
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Table 86 Terminal Verification Results (Tag 95) – Byte 5 (Transaction Completion)

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Default TDOL used.
1 Issuer authentication was unsuccessful.
1 Script processing failed before final generate AC.
1 Script processing failed after final generate AC.
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Page 189 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.2.11 Transaction Status Indicator (Tag 9B)

Table 87 Transaction Status Indicator (Tag 9B) – Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 Offline data authentication performed
1 Cardholder verification performed
1 Card risk management performed
1 Issuer authentication performed
1 Terminal risk management performed
1 Script processing performed
0 Reserved for future use
0 Reserved for future use

Table 88 Transaction Status Indicator (Tag 9B) – Byte 2

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use
0 Reserved for future use

Page 190 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.3 EMV Chip Commands

This section contains that can be sent to the chip for processing. The commands are sent in Application
Protocol Data Unit (APDU) format consisting of a mandatory four byte header followed by a conditional
variable length body.
The APDU command format is as follows.

CLA INS P1 P2 Lc Data Le

Mandatory Header Conditional Body

Where:
 CLA – Class Byte of the Command Message
 INS – Instruction Byte of Command Message
 P1 – Parameter 1
 P2 – Parameter 2
 Lc – Length of command Data field
 Data – Command data
 Le – Maximum length of expected data returned (when set to zero - 256 bytes may be returned)

Note: The CLA, INS, P, P2, Lc, Data and Le values have been provided for each of the commands
described in the sections below.

The APDU response format is as follows.

Data SW1 SW2

Body Trailer

Where:
 Data – Response Data
 SW1 – Status Byte 1
 SW2 – Status Byte 2

For a list of the SW1/SW2 status bytes see page 203.

Page 191 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.3.1 Application Block

The APPLICATION BLOCK command is a post-issuance command that invalidates the currently selected
application.
Following the successful completion of an APPLICATION BLOCK command:
 An invalidated application will return the status bytes SW1 SW2 = '6283' („Selected file
invalidated‟) in response to a SELECT command.
 An invalidated application will return only an Application Authentication Cryptogram (AAC) as AC
in response to a GENERATE AC command.

Table 89 APPLICATION BLOCK Command Values

Code Value

CLA '8C' or '84'; coding according to the secure messaging specified in Book 2

INS '1E'

P1 '00'; all other values are RFU

P2 '00'; all other values are RFU

Lc Number of data bytes

Message Authentication Code (MAC) data component

Data
Coding according to the secure messaging specified in Book 2

Le Not present

15.3.2 Application Unblock

The APPLICATION UNBLOCK command is a post-issuance command that rehabilitates the currently
selected application. Following the successful completion of an APPLICATION UNBLOCK command, the
restrictions imposed by the APPLICATION BLOCK command are removed.

Table 90 APPLICATION UNBLOCK Command Values

Code Value

CLA '8C' or '84'; coding according to the secure messaging specified in Book 2

INS '18'

P1 '00'; all other values are RFU

P2 '00'; all other values are RFU

Lc Number of data bytes

Message Authentication Code (MAC) data component; coding according to the secure
Data
messaging specified in Book 2

Le Not present

Page 192 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.3.3 Card Block

The CARD BLOCK command is a post-issuance command that permanently disables all applications in
the ICC. This command will disable all applications in the ICC, including applications that may be
selected implicitly. Following the successful completion of a CARD BLOCK command, all subsequent
SELECT commands will return the status bytes SW1 SW2 = '6A81' („Function not supported‟) and
perform no other action.

Table 91 CARD BLOCK Command Values

Code Value

CLA '8C' or '84'; coding according to the secure messaging specified in Book 2

INS '16'

P1 '00'; all other values are RFU

P2 '00'; all other values are RFU

Lc Number of data bytes

Message Authentication Code (MAC) data component; coding according to the secure
Data
messaging specified in Book 2

Le Not present

15.3.4 External Authenticate

The EXTERNAL AUTHENTICATE command is used to request the ICC to verify a cryptogram returned
by the issuer after going online.

Table 92 EXTERNAL AUTHENTICATE Command Values

Code Value

CLA '00'

INS '82'

P1 '00'

P2 '00'

Lc 8-16

Data Issuer Authentication Data

Le Not present

Table 93 EXTERNAL AUTHENTICATE Response Codes

Code Value

6300 Indicates “Issuer authentication failed”

9000 Indicates the command was successfully executed

Page 193 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.3.5 Generate AC

The GENERATE AC command sends transaction-related data to the ICC, which computes and returns a
cryptogram.

Table 94 GENERATE AC Command Values

Code Value

CLA '80'

INS 'AE'

P1 Reference control parameter (see below)

P2 '00'

Lc Var.

Data Transaction-related data

Le '00'

Table 95 GENERATE AC Reference Control Parameter

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 AAC
0 1 TC
1 0 ARQC
1 1 RFU
X RFU
0 CDA signature not requested
1 CDA signature requested
X X X X RFU

The data field of the response message consists of a TLV coded data object. The coding of the data
object will be according to one of the following two formats.
 Format 1 – The data object returned in the response message is a primitive data object with tag
equal to '80'. The value field consists of the concatenation without delimiters (tag and length) of
the value fields of the data objects specified in the table below:

Value Presence
Cryptogram Information Data (CID) M
Application Transaction Counter (ATC) M
Application Cryptogram (AC) M
Issuer Application Data (IAD) O

 Format 2 – The data object returned in the response message is a constructed data object with
tag equal to '77'. The value field may contain several TLV coded objects, but will always include
the Cryptogram Information Data, the Application Transaction Counter and the cryptogram
computed by the ICC (either an AC or a proprietary cryptogram). The utilization and
interpretation of proprietary data objects which may be included in this response message are

Page 194 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

outside the scope of these specifications. Format 2 will be used if the response is being
returned in a signature as specified for the CDA function described in section 6.6 of Book 2. The
required data elements for the response are shown in the appropriate tables in that section.

Table 96 Coding of Cryptogram Information Data

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 AAC
0 1 TC
1 0 ARQC
1 1 AAR
X X Payment brand specific
0 No advice required
1 Advice required
X X X Reason/advice/referral code
0 0 0 No information given
0 0 1 Service not allowed
0 1 0 PIN Try limit exceeded
0 1 1 Issuer Authentication failed
1 X X RFU

15.3.6 Get Challenge

The GET CHALLENGE command is used to obtain an unpredictable number from the ICC for use in a
security-related procedure. The challenge will be valid only for the next issued command.

Table 97 GET CHALLENGE Command Values

Code Value

CLA '00'

INS '84'

P1 '00'

P2 '00'

Lc Not present

Data Not present

Le '00'

Page 195 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.3.7 Get Data

The GET DATA command is used to retrieve a primitive data object not encapsulated in a record within
the current application. The usage of the GET DATA command is limited to the retrieval of the following
primitive data objects:
 ATC (Tag 9F36)
 Last Online ATC Register (Tag 9F13)
 PIN Try Counter (Tag 9F17)
 Log Format (Tag 9F4F)

Table 98 GET DATA Command Values

Code Value

CLA '80'

INS 'CA'

P1 P2 '9F36', '9F13', '9F17' or '9F4F'

Lc Not present

Data Not present

Le '00'

15.3.8 Get Processing Options

The GET PROCESSING OPTIONS command initiates the transaction within the ICC. The ICC returns
the Application Interchange Profile (AIP) and the Application File Locator (AFL).

Table 99 GET PROCESSING OPTIONS Command Values

Code Value

CLA '80'

INS 'A8'

P1 '00'

P2 '00'

Lc Var.

Data Processing Options Data Object List (PDOL) related data

Le '00'

The coding of the data object will be according to one of the following two formats.
 Format 1 – The data object returned in the response message is a primitive data object with tag
equal to '80'. The value field consists of the concatenation without delimiters (tag and length) of
the value fields of the AIP and the AFL. The coding of the data object returned in the response
message is shown below:

Page 196 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

'80' Length Application Interchange Profile Application File Locator

 Format 2 – The data object returned in the response message is a constructed data object with
tag equal to '77'. The value field may contain several TLV coded objects, but will always include
the AIP and the AFL. The utilization and interpretation of proprietary data objects which may be
included in this response message are outside the scope of these specifications.
- The AIP specifies the application functions that are supported by the application in the ICC.
- The AFL consists of the list, without delimiters, of files and related records for the currently
selected application.

15.3.9 Internal Authenticate

The INTERNAL AUTHENTICATE command initiates the computation of the Signed Dynamic Application
Data by the card using all of the following:
 Challenge data sent from the terminal
 ICC data
 A relevant private key stored in the card.

Table 100 INTERNAL AUTHENTICATE Command Values

Code Value

CLA '00'

INS '88'

P1 '00'

P2 '00'

Lc Length of authentication-related data

Data Authentication-related data

Le '00'

The ICC returns the Signed Dynamic Application Data to the terminal.
The data field of the response message consists of a TLV coded data object. The coding of the data
object will be according to one of the following two formats.
 Format 1 – The data object returned in the response message is a primitive data object with tag
equal to '80'. The value field consists of the value field of the Signed Dynamic Application Data.
 Format 2 – The data object returned in the response message is a constructed data object with
tag equal to '77'. The value field may contain several TLV coded objects, but will always include
the Signed Dynamic Application Data. The utilization and interpretation of proprietary data
objects which may be included in this response message are outside the scope of these
specifications.

Note: To ensure that the INTERNAL AUTHENTICATE command response data length is within the
256 byte limit, the length of the Signed Dynamic Application Data plus the length of the TLV encoded
optional data (if present) will remain within the limits as specified in Book 2 Annex D.

Page 197 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.3.10 PIN Change/Unblock

The PIN CHANGE/UNBLOCK command is a post-issuance command. Its purpose is to provide the
issuer the capability either to unblock the PIN or to simultaneously change and unblock the reference
(offline) PIN.

Table 101 PIN CHANGE/UNBLOCK Command Values

Code Value

CLA '8C' or '84'; coding according to the secure messaging specified in Book 2

INS '24'

P1 '00'

'00' – Unblock the reference (offline) PIN by resetting the PIN Try Counter to the PIN Try Limit.
There is no PIN update, since the PIN CHANGE/UNBLOCK command does not contain a new
P2 PIN value
'01' – reserved for each payment scheme
'02' – reserved for each payment scheme

Lc Number of data bytes

Enciphered PIN data component, if present and MAC data component; coding
Data
(according to the secure messaging specified in Book 2)

Le Not present

Upon successful completion of the command, the card will perform the following functions:
 The value of the PIN Try Counter will be reset to the value of the PIN Try Limit
 If requested, the value of the reference PIN will be set to the new PIN value
If PIN data is transmitted in the command it will be enciphered for confidentiality.

Note: The reference (offline) PIN, stored within the card, is the PIN associated with the application and
is the one the card uses to check the Transaction PIN Data transmitted within the VERIFY command.

Page 198 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.3.11 Read Record

The READ RECORD command reads a file record in a linear file. The response from the ICC consists of
returning the record.

Table 102 READ RECORD Command Values

Code Value

CLA '00'

INS 'B2'

P1 Record Number

P2 Reference control parameter (see below)

Lc Not present

Data Not present

Le '00'

Table 103 READ RECORD Reference Control Parameter

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
X X X X X SFI
1 0 0 P1 is a record number

The data field of the of a successful READ RECORD command response message contains the record
read. For SFIs in the range 1-10, the record is a TLV constructed data object and is coded as shown
below:

„70‟ Length Record Template

Page 199 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.3.12 Select

The SELECT command is used to select the ICC PSE, DDF or ADF corresponding to the submitted file
name or AID.

Table 104 SELECT Command Values

Code Value

CLA '00'

INS 'A4'

P1 Reference Control Parameter (see below)

P2 Selection Options (see below)

Lc '05' – '10'

Data File Name

Le '00'

Table 105 SELECT Reference Control Parameter (P1)

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 0 0 0
1 Select by Name
0 0

Table 106 SELECT Command Options Parameter (P2)

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 First or only occurrence
1 0 Next occurrence

The data field of the response message contains the FCI specific to the selected PSE, DDF or ADF. No
additional data elements will be present in the FCI template (tag '6F') returned in the SELECT command
response other than those contained in template 'BF0C'. Data elements present in templates '6F' and/or
'BF0C' that are not expected or understood by the terminal because the terminal does not support any
issuer-specific processing will be ignored.

Table 107 SELECT Response Message Data Field (FCI) of the PSE
Tag Value Presence
'6F' FCI Template M
'84' DF Name M
'A5' FCI Proprietary Template M
'88' SFI of the Directory Elementary File M
'5F2D' Language Preference O
'9F11' Issuer Code Table Index O
'BF0C' FCI Issuer Discretionary Data O

Page 200 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Tag Value Presence

1 or more additional
proprietary data
elements from an
'XXXX' application provider,
(Tag constructed issuer or IC card O
according to Book
3, Annex B) supplier or
EMV-defined tags that
are specifically allocated
to 'BF0C'

Table 108 SELECT Response Message Data Field (FCI) of the DDF
Tag Value Presence
'6F' FCI Template M
'84' DF Name M
'A5' FCI Proprietary Template M
'88' SFI of the Directory Elementary File M
'BF0C' FCI Issuer Discretionary Data O
1 or more additional
proprietary data
elements from an
'XXXX' application provider,
(Tag constructed issuer or IC card O
according to Book
3, Annex B) supplier or
EMV-defined tags that
are specifically allocated
to 'BF0C'

Table 109 SELECT Response Message Data Field (FCI) of the ADF
Tag Value Presence
'6F' FCI Template M
'84' DF Name M
'A5' FCI Proprietary Template M
'50' Application Label M
'87' Application Priority Indicator O
'9F38' PDOL O
'5F2D' Language Preference O
'9F11' Issuer Code Table Index O
'9F12' Application Preferred Name O

'BF0C' FCI Issuer Discretionary Data O

'9F4D' Log Entry O

Page 201 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Tag Value Presence

One or more additional
'XXXX' proprietary data elements from
(Tag constructed an application provider, issuer
O
according to Book or IC card supplier or EMV-
3, Annex B) defined tags that are specifically
allocated to 'BF0C'

15.3.13 Verify

The VERIFY command initiates in the ICC the comparison of the Transaction PIN Data sent in the data
field of the command with the reference PIN data associated with the application. The manner in which
the comparison is performed is proprietary to the application in the ICC.
The VERIFY command applies when the Cardholder Verification Method (CVM) chosen from the CVM
List is an offline PIN.

Table 110 VERIFY Command Values

Code Value

CLA '00'

INS '20'

P1 '00'

P2 Qualifier of the Verify Reference Data (see below)

Lc Var.

Data Transaction PIN Data

Le Not present

Table 111 VERIFY Reference Data (P2)

b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 0 0 0 0 0 0 As defined in ISO/IEC 7816-4
1 0 0 0 0 0 0 0 Plaintext PIN, see below
1 0 0 0 0 X X X Reserved for future use
1 0 0 0 1 0 0 0 Enciphered PIN
1 0 0 0 1 0 X X Reserved for future use
1 0 0 0 1 1 X X Reserved for future use
1 0 0 1 X X X X R Reserved for future use

The plaintext offline PIN block will be formatted as follows:

C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F

Where:
C = Control Field (4 bits „0010‟)
N = Length of PIN (4 to 12) (4 bits)
P = PIN Digit (4 bits)
F = Hex „F‟ for padding (4 bits „1111‟)
Page 202 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.3.14 EMV Response Codes (SW1 SW2)

Table 112 EMV Response Codes (SW1 SW2)
SW1 SW2 Description

61 xx xx=the number of response bytes still available. Use GET_RESPONSE (C0) to access this data.

62 00 No information given

62 81 Returned data may be corrupted

62 82 EOF reached before end of data

62 83 Selected file invalided (Application Blocked)

62 84 Bad file control information format

62 85 Selected file in termination state

62 86 No input data available from a sensor on the card

63 00 No information given

63 81 File filled up with last write

63 Cx Counter value is x

64 00 Execution error

64 01 Immediate response required by the card

65 00 No information given

65 01 Memory failure, problem writing to EEPROM

65 81 Error – memory failure

66 xx Security error

67 xx Check error

68 00 No information given

68 81 Logical channel not supported

68 82 Secure messaging not supported

69 00 No information given

69 81 Command incompatible with file structure

69 82 Security status not satisfied

69 83 Authentication method blocked

69 84 Reference data not usable

69 85 Conditions of use not satisfied

69 86 Command not allowed (no current EF)

69 87 Expected secure messaging data objects missing

69 88 Incorrect secure messaging data objects

6A 00 No information given

Page 203 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

SW1 SW2 Description

6A 80 Incorrect parameters in the command data field

6A 81 Card Blocked / Function not supported

6A 82 File or application not found

6A 83 Record not found

6A 84 Not enough memory space in the file

6A 85 Inconsistent with TLV structure

6A 86 Incorrect parameters P1-P2

6A 87 N inconsistent with parameters P1-P2

6A 88 Referenced data or reference data not found (exact meaning depending on the command)

6A 89 File already exists

6A 8A DF name already exists

6B 00 Wrong parameters P1-P2

6C xx Wrong L field; SW2 encodes the exact number of available data bytes

6D 00 Instruction code not supported or invalid

6E 00 Class not supported

6F 00 No precise diagnosis

90 00 Success – no further qualification

Page 204 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.4 BCD to ASCII Conversion

Some data returned by the EMV kernel is in BCD (Binary Coded Decimal) format. This data may have to
be converted to ASCII prior to being sent to the host.
To convert BCD to ASCII involves taking each binary digit or “nibble” and adding hexadecimal (0x30) to it.
The resulting ASCII field will be twice as long as the BCD field if all of the digits are used.
The following example illustrates the process:
1. Amount Authorized (Tag 9F02) is six bytes in length and contains:
‟00 00 00 01 23 45‟ (BCD)
2. Isolate the 12 binary digits and add 0x30 to each one to obtain the equivalent ASCII digits
3. The resulting field is 12 bytes in length. Expressed as hexadecimal it is:
„0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x32 0x33 0x34 0x35‟ (Hex)
„000000012345‟ (ASCII)

Page 205 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

15.5 ASCII Chart

Dec Bin Hex Char Dec Bin Hex Char Dec Bin Hex Char
00 00000000 00 NUL 44 00101100 2C , 88 01011000 58 X
01 00000001 01 SOH 45 00101101 2D - 89 01011001 59 Y
02 00000010 02 STX 46 00101110 2E . 90 01011010 5A Z
03 00000011 03 ETX 47 00101111 2F / 91 01011011 5B [
04 00000100 04 EOT 48 00110000 30 0 92 01011100 5C \
05 00000101 05 ENQ 49 00110001 31 1 93 01011101 5D ]
06 00000110 06 ACK 50 00110010 32 2 94 01011110 5E ^
07 00000111 07 BEL 51 00110011 33 3 95 01011111 5F _
08 00001000 08 BS 52 00110100 34 4 96 01100000 60 `
09 00001001 09 HT 53 00110101 35 5 97 01100001 61 a
10 00001010 0A LF 54 00110110 36 6 98 01100010 62 b
11 00001011 0B VT 55 00110111 37 7 99 01100011 63 c
12 00001100 0C FF 56 00111000 38 8 100 01100100 64 d
13 00001101 0D CR 57 00111001 39 9 101 01100101 65 e
14 00001110 0E SO 58 00111010 3A : 102 01100110 66 f
15 00001111 0F SI 59 00111011 3B ; 103 01100111 67 g
16 00010000 10 DLE 60 00111100 3C < 104 01101000 68 h
17 00010001 11 DC1 61 00111101 3D = 105 01101001 69 i
18 00010010 12 DC2 62 00111110 3E > 106 01101010 6A j
19 00010011 13 DC3 63 00111111 3F ? 107 01101011 6B k
20 00010100 14 DC4 64 01000000 40 @ 108 01101100 6C l
21 00010101 15 NAK 65 01000001 41 A 109 01101101 6D m
22 00010110 16 SYM 66 01000010 42 B 110 01101110 6E n
23 00010111 17 ETB 67 01000011 43 C 111 01101111 6F o
24 00011000 18 CAN 68 01000100 44 D 112 01110000 70 p
25 00011001 19 EM 69 01000101 45 E 113 01110001 71 q
26 00011010 1A SUB 70 01000110 46 F 114 01110010 72 r
27 00011011 1B ESC 71 01000111 47 G 115 01110011 73 s
28 00011100 1C FS 72 01001000 48 H 116 01110100 74 t
29 00011101 1D GS 73 01001001 49 I 117 01110101 75 u
30 00011110 1E RS 74 01001010 4A J 118 01110110 76 v
31 00011111 1F US 75 01001011 4B K 119 01110111 77 w
32 00100000 20 SP 76 01001100 4C L 120 01111000 78 x
33 00100001 21 ! 77 01001101 4D M 121 01111001 79 y
34 00100010 22 " 78 01001110 4E N 122 01111010 7A z
35 00100011 23 # 79 01001111 4F O 123 01111011 7B {
36 00100100 24 $ 80 01010000 50 P 124 01111100 7C |
37 00100101 25 % 81 01010001 51 Q 125 01111101 7D }
38 00100110 26 & 82 01010010 52 R 126 01111110 7E ~
39 00100111 27 ' 83 01010011 53 S 127 01111111 7F DEL
40 00101000 28 ( 84 01010100 54 T
41 00101001 29 ) 85 01010101 55 U
42 00101010 2A * 86 01010110 56 V
43 00101011 2B + 87 01010111 57 W

Page 206 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

16. EMV Testing and Certification Parameters

16.1 Amex Certification Parameters

Table 113 Certification Parameters – Amex Credit
Tag Description Amex
9F35 Terminal Type Kernel config
9F33 Terminal Capabilities Kernel config
9F40 Additional Terminal Capabilities Kernel config
9F15 Merchant Category Code Assigned by TSYS
9F06 Application Identifier (AID) A00000002501
American Express
Default AID Label
Credit
9F1A Terminal Country Code 840
5F2A Transaction Currency Code 840
5F36 Transaction Currency Exponent 2
Default DDOL 9F3704
97 Default TDOL
TAC – Default C8 00 00 00 00
TAC – Denial 00 00 00 00 00
TAC – Online C8 00 00 00 00
9F1B Terminal Floor Limit (EMV) 0
EMV Random Selection Threshold 0
EMV Random Selection Maximum % 99
EMV Random Selection Target % 99
Partial Name Selection Flag Y
Allow Fallback Flag Y
Allow PIN Bypass N
9F09 Application Version Number (Prim.) 0x0001
9F09 Application Version Number (Sec.) N/A
Contactless
TAC – Default DC 50 84 00 00
TAC – Denial 00 00 00 00 00
TAC – Online C4 00 00 00 00
Contactless Floor Limit 0.00
Contactless CVM Required Limit 10.00
Contactless Transaction Limit 15.00
Enable ExpressPay MSD Y
Enable ExpressPay EMV Y

Page 207 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

16.2 Diners Certification Parameters

Table 114 Certification Parameters – Diners Credit
Tag Description Diners
9F35 Terminal Type Kernel config
9F33 Terminal Capabilities Kernel config
9F40 Additional Terminal Capabilities Kernel config
9F15 Merchant Category Code Assigned by TSYS
9F06 Application Identifier (AID) A0000001523010
Default AID Label Discover Credit
9F1A Terminal Country Code 840
5F2A Transaction Currency Code 840
5F36 Transaction Currency Exponent 2
Default DDOL 9F3704
97 Default TDOL
TAC – Default DC 00 00 20 00
TAC – Denial 00 10 00 00 00
TAC – Online FC E0 9C F8 00
9F1B Terminal Floor Limit (EMV) 0
EMV Random Selection Threshold 0
EMV Random Selection Maximum % 99
EMV Random Selection Target % 99
Partial Name Selection Flag Y
Allow Fallback Flag Y
Allow PIN Bypass N
9F09 Application Version Number (Prim.) 0x0001
9F09 Application Version Number (Sec.) 0x0001
Contactless
TAC – Default -
TAC – Denial -
TAC – Online -
Contactless Floor Limit -
Contactless CVM Required Limit -
Contactless Transaction Limit -

Page 208 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

16.3 Discover Certification Parameters

Table 115 Certification Parameters – Discover Credit
Tag Description Discover
9F35 Terminal Type Kernel config
9F33 Terminal Capabilities Kernel config
9F40 Additional Terminal Capabilities Kernel config
9F15 Merchant Category Code Assigned by TSYS
9F06 Application Identifier (AID) A0000001523010
Default AID Label
9F1A Terminal Country Code 840
5F2A Transaction Currency Code 840
5F36 Transaction Currency Exponent 2
Default DDOL 9F3704
97 Default TDOL
TAC – Default DC 00 00 20 00
TAC – Denial 00 10 00 00 00
TAC – Online FC E0 9C F8 00
9F1B Terminal Floor Limit (EMV) 0
EMV Random Selection Threshold 0
EMV Random Selection Maximum % 99
EMV Random Selection Target % 99
Partial Name Selection Flag Y
Allow Fallback Flag Y
Allow PIN Bypass N
9F09 Application Version Number (Prim.) 0x0001
9F09 Application Version Number (Sec.) 0x0001
Contactless
TAC – Default -
TAC – Denial -
TAC – Online -
Contactless Floor Limit -
Contactless CVM Required Limit -
Contactless Transaction Limit -

Page 209 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

16.4 JCB Certification Parameters

Table 116 Certification Parameters – JCB Credit
Tag Description JCB
9F35 Terminal Type Kernel config
9F33 Terminal Capabilities Kernel config
9F40 Additional Terminal Capabilities Kernel config
9F15 Merchant Category Code Assigned by TSYS
9F06 Application Identifier (AID) A0000000651010
Default AID Label JCB Credit
9F1A Terminal Country Code 840
5F2A Transaction Currency Code 840
5F36 Transaction Currency Exponent 2
Default DDOL 9F3704
97 Default TDOL
TAC – Default FC 60 24 A8 00
TAC – Denial 00 10 00 00 00
TAC – Online FC 60 AC F8 00
9F1B Terminal Floor Limit (EMV) 0
EMV Random Selection Threshold 0
EMV Random Selection Maximum % 99
EMV Random Selection Target % 99
Partial Name Selection Flag Y
Allow Fallback Flag Y
Allow PIN Bypass N
9F09 Application Version Number (Prim.) 0x0200
9F09 Application Version Number (Sec.) 0x0120
Contactless
TAC – Default -
TAC – Denial -
TAC – Online -
Contactless Floor Limit -
Contactless CVM Required Limit -
Contactless Transaction Limit -

Page 210 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

16.5 MasterCard Certification Parameters

Table 117 Certification Parameters – MasterCard Credit
MasterCard
Tag Description
Credit
9F35 Terminal Type Kernel config
9F33 Terminal Capabilities Kernel config
9F40 Additional Terminal Capabilities Kernel config
9F15 Merchant Category Code Assigned by TSYS
9F53 Transaction Category Code „R‟
9F06 Application Identifier (AID) A0000000041010
Default AID Label MasterCard Credit
9F1A Terminal Country Code 840
5F2A Transaction Currency Code 840
5F36 Transaction Currency Exponent 2
Default DDOL 9F3704
97 Default TDOL
TAC – Default FC 50 B8 A0 00
TAC – Denial 00 00 00 00 00
TAC – Online FC 50 B8 F8 00
9F1B Terminal Floor Limit (EMV) 0
EMV Random Selection Threshold 0
EMV Random Selection Maximum % 99
EMV Random Selection Target % 99
Partial Name Selection Flag Y
Allow Fallback Flag Y
Allow PIN Bypass N
9F09 Application Version Number (Prim.) 0x0002
9F09 Application Version Number (Sec.) 0x0002
Contactless
TAC – Default FC 50 80 88 00
TAC – Denial 00 00 00 00 00
TAC – Online FC 50 80 88 00
Enable MChip Y
Enable MStripe Y
Contactless Floor Limit 1000
Contactless CVM Required Limit 100
Contactless Transaction Limit 5000
Contactless Terminal Capabilities
Kernel config
CVM Req
Contactless Terminal Capabilities
Kernel config
CVM NotReq

Page 211 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 118 Certification Parameters – MasterCard Debit

International U.S.
Tag Description
Maestro Maestro
9F35 Terminal Type Kernel config Kernel config
9F33 Terminal Capabilities Kernel config Kernel config
9F40 Additional Terminal Capabilities Kernel config Kernel config
9F15 Merchant Category Code Assigned by TSYS Assigned by TSYS
9F53 Transaction Category Code „R‟ „R‟
9F06 Application Identifier (AID) A0000000043060 A0000000042203
DEBIT
Default AID Label Maestro
MASTERCARD
9F1A Terminal Country Code 840 840
5F2A Transaction Currency Code 840 840
5F36 Transaction Currency Exponent 2 2
Default DDOL 9F3704 9F3704
97 Default TDOL
TAC – Default FC 50 BC A0 00 FC 50 BC A0 00
TAC – Denial 00 00 00 00 00 00 00 00 00 00
TAC – Online FC 50 BC F8 00 FC 50 BC F8 00
9F1B Terminal Floor Limit (EMV) 0 0
EMV Random Selection Threshold 0 0
EMV Random Selection Maximum % 99 99
EMV Random Selection Target % 99 99
Partial Name Selection Flag Y Y
Allow Fallback Flag Y Y
Allow PIN Bypass N N
9F09 Application Version Number (Prim.) 0x0002 0x0002
9F09 Application Version Number (Sec.) 0x0002 0x0002
Contactless
TAC – Default FC 50 1C 88 00 FC 50 1C 88 00
TAC – Denial 00 00 80 00 00 00 00 80 00 00
TAC – Online FC 50 1C 88 00 FC 50 1C 88 00
Enable MChip Y Y
Enable MStripe Y Y
Contactless Floor Limit 0 0
Contactless CVM Required Limit 0 0
Contactless Transaction Limit 0 0
Contactless Terminal Capabilities
Kernel config Kernel config
CVM Req
Contactless Terminal Capabilities
Kernel config Kernel config
CVM NotReq

Page 212 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

16.6 Visa Certification Parameters

Table 119 Certification Parameters – Visa Credit
Visa Visa
Tag Description
Credit Electron
9F35 Terminal Type Kernel config Kernel config
9F33 Terminal Capabilities Kernel config Kernel config
9F40 Additional Terminal Capabilities Kernel config Kernel config
9F15 Merchant Category Code Assigned by TSYS Assigned by TSYS
9F06 Application Identifier (AID) A0000000031010 A0000000032010
Default AID Label Visa Credit Visa Electron
9F1A Terminal Country Code 840 840
5F2A Transaction Currency Code 840 840
5F36 Transaction Currency Exponent 2 2
Default DDOL 9F3704 9F3704
97 Default TDOL
TAC – Default DC 40 00 A8 00 DC 40 00 A8 00
TAC – Denial 00 10 00 00 00 00 10 00 00 00
TAC – Online DC 40 04 F8 00 DC 40 04 F8 00
9F1B Terminal Floor Limit (EMV) 0 0
EMV Random Selection Threshold 0 0
EMV Random Selection Maximum % 99 99
EMV Random Selection Target % 99 99
Partial Name Selection Flag Y Y
Allow Fallback Flag Y Y
Allow PIN Bypass N N
9F09 Application Version Number (Prim.) 8C 8C
9F09 Application Version Number (Sec.) 96 96
Contactless
TAC – Default DC 40 00 A8 00 DC 40 00 A8 00
TAC – Denial 00 10 00 00 00 00 10 00 00 00
TAC – Online DC 40 04 F8 00 DC 40 04 F8 00
Contactless Floor Limit 0 0
Contactless CVM Required Limit 0 0
Contactless Transaction Limit 0 0
9F66 Visa TTQ Kernel config Terminal

Page 213 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Table 120 Certification Parameters – Visa Debit

Visa Debit U.S.
Tag Description
Interlink International Common Debit
9F35 Terminal Type Kernel config Kernel config Kernel config
9F33 Terminal Capabilities Kernel config Kernel config Kernel config
9F40 Additional Terminal Capabilities Kernel config Kernel config Kernel config
9F15 Merchant Category Code Assigned by TSYS Assigned by TSYS Assigned by TSYS
9F06 Application Identifier (AID) A0000000033010 A0000000031010 A0000000980840
Default AID Label INTERLINK VISA DEBIT US DEBIT
9F1A Terminal Country Code 840 840 840
5F2A Transaction Currency Code 840 840 840
5F36 Transaction Currency Exponent 2 2 2
Default DDOL 9F3704 9F3704 9F3704
97 Default TDOL
TAC – Default DC 40 00 A8 00 DC 40 00 A8 00 DC 40 00 A8 00
TAC – Denial 00 10 00 00 00 00 10 00 00 00 00 10 00 00 00
TAC – Online DC 40 04 F8 00 DC 40 04 F8 00 DC 40 04 F8 00
9F1B Terminal Floor Limit (EMV) 0 0 0
EMV Random Selection Threshold 0 0 0
EMV Random Selection Maximum % 99 99 99
EMV Random Selection Target % 99 99 99
Partial Name Selection Flag Y Y Y
Allow Fallback Flag Y Y Y
Allow PIN Bypass N N N
9F09 Application Version Number (Prim.) 8C 8C 8C
9F09 Application Version Number (Sec.) 96 96 96
Contactless
TAC – Default DC 40 00 A8 00 DC 40 00 A8 00 TBD
TAC – Denial 00 10 00 00 00 00 10 00 00 00 TBD
TAC – Online DC 40 04 F8 00 DC 40 04 F8 00 TBD
Contactless Floor Limit 0 0 0
Terminal CVM Required Limit 0 0 0
Contactless CVM Required Limit 0 0 0
9F66 Visa TTQ Kernel config Kernel config Kernel config

Page 214 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

17. Glossary of Terms

Table 121 Glossary of Terms
Term Description
Application Authentication Cryptogram – An Application Cryptogram type
generated by the chip application in response to the Generate AC command (First or
AAC
Second) sent by the CAD. An AAC is generated to indicate that the transaction
should be declined.

Automated Banking Machine – Unattended, customer-operated device used to

ABM dispense and/or deposit cash and conduct other customer operated services. (also
known as ATM – Automated Teller Machine)

Application Cryptogram – AC is a generic term given to describe an application

AC
cryptogram such as TC, AAC, ARQC and ARPC.

Application Default Action – Visa and Amex proprietary data element indicating
issuer-specified action for the ICC to take for certain exception conditions.
ADA This data element is required for Issuer Authentication checks, offline PIN verification
checks, new card checks and Issuer Script processing checks. If this data element is
not present, the ICC behaves as if the value is all zeroes.

Application Dedicated File – The ADF contains application specific data for a
ADF
specific AID (also see DF)

Acquirer Device Validation Tool Kit – Tool kit used for end-to-end Visa contact
transaction certification of deployed EMV devices. ADVT is the Visa brand level
ADVT
certification which follows the device‟s previous EMV level 1 (Hardware) and EMV
level 2 (EMV Kernel) certifications completed by the device vendor.

American Express Integrated Circuit Card Payment Specification – EMV test

AEIPS
suite used for Amex EMV contact transaction certification of deployed EMV devices.

Application File Locator – AFLs identify the location and number of application
records that contain data that must be read by the CAD in order to conduct a
AFL
transaction. In addition to the location and number of records the AFL also indicates
which data elements have been signed by the issuer as part of the SDA process.

Application Identifier – AIDs are used to identify the scheme and type of
application(s) present on an ICC. The AID is made up of two fields, the Registered ID
(RID) which identifies the scheme and the Proprietary Application Identifier Extension
AID (PIX) which identifies the application type. ICCs and CADs use AIDs to determine
which applications are mutually supported, as both the ICC and the CAD must
support an AID to initiate a transaction. Both ICCs and CADs may support multiple
AIDs.

Application Interchange Profile – The AIP contains details of the ICC‟s capabilities
AIP to support specific security functions in the application (e.g. SDA/DDA/CDA,
Cardholder Verification etc.).

Application Protocol Data Unit – APDU is the command message sent from the
APDU interface device (in the CAD) and the response message returned by the ICC to the
interface device.

Application Program Interface – A specification defining the communication

API
protocol and commands used to interact with a device.

Page 215 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Authorization Response Code – The ARC is a two digit code generated by the
issuer and sent to the CAD to approve, decline or refer a transaction. The most
commonly used ARC consists of online approval (00), online decline (05) and referral
(01). The CAD is prohibited to alter the ARC from the issuer. The CAD is allowed to
generate an ARC in the following exception conditions:
ARC
Y1 – Offline Approved
Z1 – Offline declined
Y3 – Unable to go online (offline approved)
Z3 – Unable to go online (offline declined)

Authorization Response Cryptogram – A cryptogram used for a process called

Online Issuer Authentication (IA). The ARPC is the issuer‟s (or scheme in STIP)
authorization response cryptogram signed with a DES key. This cryptogram is
ARPC
generated by the issuer in response to the Authorization Request Cryptogram
(ARQC) and is sent to the ICC in the authorization response message. The ICC will
validate the ARPC to confirm that the response was sent by the true card issuer.

Authorization Request Cryptogram – A cryptogram used for a process called

Online Card Authentication. This cryptogram is generated by the ICC in response to
the FIRST GENEREATE AC command, when the transaction requires online
ARQC authorization. It is the ICC, CAD and transaction result data signed with a DES key.
It is sent to the issuer in the authorization or full financial request message. The issuer
will validate the ARQC to ensure that the ICC is authentic and ICC data was not
copied from a skimmed ICC.

Application Selection Flag – Used by Interac during the Application Selection

ASF process enabling automatic selection of an application without using the highest API
thus allowing for different priorities between SCD and IDP.

Application Selection Indicator – The Application Selection Indicator indicates

whether the associated AID in the CAD must exactly match the AID in the ICC
ASI (including the length of the AID) or if it can be partially selected based on the length of
the AID specified in the CAD (even though the card AID might be longer). There is
only one Application Selection Indicator per AID supported by the CAD.

Application Transaction Counter – The ATC counts the number of transactions

ATC processed since the personalization of the ICC. The ATC increments by 1 when the
Get Processing Options command is issued at the start of each transaction.

ATM Automated Teller Machine – See ABM

Answer To Reset – An ATR is sent from the ICC to the CAD (after the supply
ATR voltage, the clock and reset signal) containing various information related to the
transmission protocol supported by the ICC.

Application Usage Control – The AUC details the ICC‟s processing restrictions.
AUC These restrictions relate to the geographical settings (domestic vs. international) and
the support for specific services (e.g. cash, cash back, goods and services, etc.).

BCD Binary Coded Decimal – A code for representing decimal digits in a binary format.

BER Basic Encoding Rules – Defined in ISO/IEC 8825–1.

Page 216 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Bank Identification Number – The BIN is the first six digits of the PAN and is used
st
BIN to identify the issuer of the card. It is comprised of a Major Industry Identifier (MII) (1
digit) and an Issuer Identifier (up to 5 digits).

Certificate Authority – A CA is a trusted central administration that issues, revokes

CA and expires certificates. A CA is responsible for ensuring that the identity of the user
requesting the certificate is legitimate.

Card Action Analysis – CAA involves the analysis of the Card Risk Management
(CRM) results and responding to the CAD with an appropriate cryptogram (TC, AAC
CAA
or ARQC). CAA is performed by the ICC after the ICC completes the CRM process
and sets the CVR.

Card Acceptance Device – Any device capable of reading and processing data from
CAD a magnetic stripe, ICC (contact or contactless interfaces) or manual entry keyboard
for the purpose of performing a payment transaction.

Card Authentication Method – CAM is the name given to the process of

CAM authenticating the ICC, either by the Issuer (if it is on Online CAM) or by the CAD (if it
is an Offline CAM).

Candidate List – The list of AIDs that are mutually supported by the ICC and EMV
Candidate List
POS Solution.

Card Authentication Program – CAP is a One Time Password application created

by MasterCard. CAP uses chip cryptography similar to the MasterCard payment
CAP application to create a digital signature which can be authenticated by the Issuer in a
CNP transaction. To use CAP a low cost reader which supports the ability to enter a
PIN is required to generate the One Time Password.

C-APDU Command – Application Protocol Data Unit – See APDU.

Certificate Authority Public Key – RSA Public key assigned by a card brand used
CAPK
by an EMV kernel to decrypt chip information signed with a card brand private key.

Certificate Authority Public Key File – A file containing the current card brand
CAPK File assigned RSA public keys, key indexes and expiry dates. The file is downloaded to
the EMV kernel.

Cardholder Activated Terminal – CAT are typically unattended CADs that accept
various payment cards. This type of CAD is frequently installed at rail ticketing
stations, petrol stations, toll roads, parking garages and other merchant locations.
There are four types of cardholder-activated terminals:
Automated Dispensing Machines / Level 1.
CAT Self-Service Terminals / Level 2.
Limited Amount Terminals / Level 3.
In-flight Commerce (IFC) Terminals / Level 4.
The CAT requirements specify related transaction liability for each CAT type and
maximum allowable transaction amounts as well as authorization,
clearing, chargeback and addendum record requirements.

CCC Compute Cryptographic Checksum – See Checksum.

Page 217 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Common Core Definitions – CCD defines a common data element content and
format for sending ICC information between an ICC and the issuer via the acquirer.
CCD
When CCD is incorporated into an ICC specification, issuers of multi-branded cards
can achieve the benefits of the common issuer support system.

Combined Dynamic Data Authentication/Generate AC – CDA is the most secure

option for offline CAM as in addition to protection against counterfeit and skimming it
also protects against man-in-the-middle attacks.
CDA
During the CDA process the ICC uses its RSA Private Key to sign a string of data.
This string of data includes data produced by the ICC, indicating the ICC‟s decision to
approve the transaction, the AC (Application Cryptogram) and the transaction data.

Contactless Device Evaluation Toolkit – Tool kit used for Visa contactless
CDET
transaction certification of deployed EMV devices.

Card Data Object List 1 – CDOL1 is the list of TLV data objects (tags / lengths)
personalized on the ICC that are used for the generation of the first cryptogram. The
CDOL1
CAD will send these data object values to the ICC with the 1st Generate AC
command.

Card Data Object List 2 – CDOL2 is the list of TLV data objects (tags / lengths)
personalized on to the ICC that are used for the generation of the final cryptogram.
CDOL2
The CAD will send these data object values to the ICC with the Second Generate AC
command.

Checksum – A computed numeric value that represents a data element. Used to

Checksum
ensure that the data has not been changed.

Card Issuer Actions Codes – CIAC specifies the ICC conditions that cause a
transaction to be approved off-line, sent on-line or declined if the CAD cannot go on-
CIAC
line. During card risk management the ICC makes its decision by comparing the CVR
with the CIAC. There are three groups of CIAC (Denial, Online and Default).

Cryptogram Information Data – CID Indicates the type of cryptogram (AAC, TC and
CID ARQC) and the actions to be performed by the CAD (e.g. Advice required and the
reason; such as Service not allowed, PTL exceeded etc.).

Class Byte of the Command Message – CLA is the first byte of five consecutive
CLA bytes that create the header in the C-APDU. For this purpose the CLA serves as the
instruction class and may take any value except 'FF'.

Contactless Frontend – Circuitry in the CAD which manages the analogue

CLF contactless communication and the communication protocol layer of the contactless
transmission link to exchange data with the UICC.

Card Not Present – CNP transactions are transactions that are conducted over an
CNP open network (e.g. telephone, Internet, mail order) where a physical card is not
present and therefore the MSD or ICC data can‟t be obtained and used.

Common Payment Application – CPA is a CCD-compliant application specification

developed by EMVCo. CPA enables a single application implementation to be
CPA
personalized with the same data elements and tags, including common Risk
Management controls, for all brands and schemes that support EMV.

Page 218 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Card Production Life Cycle – CPLC is a Visa proprietary data element that provides
auditability for the ICC through the use of card life cycle data. It is composed of
several data elements (e.g. Operating system identifier, personalization machine and
CPLC date etc.)
CPLC is only used with the VIS 1.4 specs (it has been deleted from the VIS 1.5
specs) and is only supported on Global platform cards.

Card Personalization Specification – Specification that defines the card brand

CPS
personalization requirements and chip card rules.

Card Personalization Validation – Card Personalization Validation is a process to

CPV ensure that a Technical Product (e.g. card chip) has been personalized in such a
manner that it is compliant with the MasterCard recommendations and mandates.

Certificate Revocation List – A list of certificates that have been revoked and
CRL
therefore, should no longer be trusted or used.

Card Risk Management – CRM is a process performed by the ICC to determine if

the transaction should be sent online, approved offline or declined offline. The output
CRM
of the CRM process is the setting of the CVR which is subsequently used in the Card
Action Analysis.

CRT Chinese Remainder Theorem

Cryptogram – A numeric value used to validate data integrity. Cryptograms are

calculated by processing and signing specific data elements using a common
Cryptogram
algorithm. Cryptograms are generated by the ICC in response to the “Generate AC”
command and by the Issuer in the authorization response message.

CSI Card Status Indicator

Card Status Update – CSU contains data sent to the ICC to indicate whether the
issuer has approved or declined a transaction and to identify actions required by the
CSU
issuer (e.g. update counters). CSU is transmitted to the card in the Issuer
Authentication Data.

C-TPDU Command Transport Protocol Data Unit – See TPDU.

Card Transaction Qualifiers – A card value defining what actions will take place at
CTQ
the POS when a transaction occurs.

Cumulative Total Transaction Amount Limit – Visa proprietary tag 9F54

specifying the maximum total amount of offline transactions in the designated
CTTAL
currency or designated and secondary currency allowed for the card application
before a transaction is sent online.

Cumulative Total Transaction Amount Upper Limit – Visa proprietary tag 9F5C
specifying the maximum total amount of offline transactions in the designated
CTTAUL
currency or designated and secondary currency allowed for the card application
before a transaction is declined if an online transaction is unable to be performed.

Card Verification Rule – A specific cardholder verification method which is part of

the CVM data element that contains the definition of which type of cardholder
CV Rule
verification should be used, under which conditions and the action to take if the CV
Rule is unsuccessful.

Page 219 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Card Verification Code 1 –The name given to the three digit field coded on the MSR
CVC – 1 of a MasterCard branded card. The value is generated using TDES from the PAN,
expiry date and Service Code.

Card Verification Code 2 – The name given to the three digit field printed on the
signature panel of a MasterCard branded card. The value is generated using TDES
CVC – 2
from the PAN, Expiry Date and Service Code „000‟. CVC2 is used for CNP to prove
the presence of a legitimate card.

Card Verification Code 3 – Also referred to as dynamic CVC. CVC3 is the process
of generating a two byte cryptogram returned by the card in the response to the
CVC – 3
COMPUTE CRYPTOGRAPHIC CHECKSUM command. CVC3 is used by
MasterCard for the security of the PayPass contactless MSD application.

Cardholder Verification Method – Method by which a cardholder is identified during

CVM
an ICC transaction (e.g. PIN or Signature).

Cryptogram Version Number – Informs the issuer about the algorithm and data
CVN used for the Application Cryptogram computation during online transactions (in the
authorization request) and after transaction completion in the clearing record.

Card Verification Results – Proprietary data field used to report transaction-

CVR processing information to the issuer (e.g. successful PIN validation, previous
transaction information, script results, etc…).

Card Verification Value 1 – Name given to the three digit field coded on the MSR of
CVV – 1 a Visa branded card. The value is generated using TDES from the PAN, expiry date
and Service Code.

Card Verification Value 2 – Name given to the three digit field printed on the
signature panel of a Visa branded card. The value is generated using TDES from the
CVV – 2
PAN, Expiry Date and Service Code. CVV2 is used for CNP to prove the presence of
a legitimate card.

Dynamic Card Verification Value – The process of generating a dynamic CVV

dCVV (using the same algorithm as CVV1 with the addition of the ATC). dCVV is used for
security by the Visa payWave contactless MSD application.

Dynamic Data Authentication – An offline CAM option which protects against

DDA counterfeit and skimming. During the DDA process the ICC uses its RSA Private Key
to sign an UN generated by the CAD.

DDF Directory Dedicated File – An entry point to other ADFs or DDFs (also see DF).

Dynamic Data Object List – List of data objects (tags and lengths) that are
personalized on the ICC and used to generate the ICC‟s RSA digital signature during
DDOL
the DDA or CDA process. The CAD will send the required data object values with the
Internal Authenticate command.

Data Encryption Standard – A cryptography standard defined by the U.S

government (NIST). DES is a symmetric algorithm meaning the keys for each of the
DES
cryptography operations used is the same. DES uses a single length key which is 16
bytes in length.

Developer – Generic term used within this document to identify anyone (merchant,
Developer
integrator, developer, etc…) implementing and certifying and EMV POS Solution.

Page 220 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Dedicated File – A dedicated file (DF) in EMV follows the ISO/IEC 7816-4 definition.
The DF contains an FCI and is mapped onto an ADF or a DDF. It may give access to
DF
Elementary Files (EF) and DFs. The DF at the highest level of the card is the Master
File (MF).

Derivation Key Index/Key Derivation Index – Two digit hexadecimal field located
DKI/KDI on the card issuer host to identify a set of Master DES keys used to generate
cryptograms.

Data Object List – A flexible list of data elements built be the CAD and passed to the
ICC under the ICC‟s direction. To minimize processing within the ICC, such a list is
DOL not TLV-encoded but is a single constructed field built by concatenating several data
elements together. Since the elements of the constructed field are not TLV-encoded,
it is imperative that the ICC knows the format of this field when the data is received.

Dynamic Passcode Authentication – Based on the MasterCard CAP specification

DPA
and is used along with a One Time Password (see CAP).

D-Payment Application Specification – Discover contactless payment card or

device implementation. Also the name of the Discover EMV smartcard test suite used
D-PAS
to certify that EMV devices can process contact and contactless EMV Discover and
Diners transactions.

Derived Unique Key Per Transaction – A key management scheme in which for
DUKPT
every transaction a unique key is used which is derived from a fixed key.

Electronically Erasable Programmable Read Only Memory – Type of memory

used in ICCs to store all the personalization data and other dynamic data specific to
EEPROM
an ICC application. Data in the EEPROM is retained without power but can only be
modified when power is available.

Elementary File – An elementary file (EF) in EMV follows the ISO/IEC 7816-4
definition. The EF is accessed through a specific DF and consists of one or more
EF
records (up to 256 bytes for each record), identifying where the data is stored. An EF
is never used as an entry point to another file.

Europay, MasterCard, Visa – The Integrated Circuit Card (ICC) Specification for
EMV Payment Systems defines the functionality of credit/debit transaction processing at
the CAD level to ensure correct operation and interoperability.

EMVCo – The name of the non-profit organization formed in 1999 between Europay,
EMVCo
MasterCard and Visa that maintains the EMV specifications.

EMV POS Solution – Generic term used within this document to describe any
EMV POS Solution
integrated or standalone EMV implementation being developed and certified.

EMV Tag EMV Tag - See Tag.

EMV Transaction Type – Type of transaction being performed (e.g. Sale, Return,
EMV Transaction Type
etc.).

Encryption – Process whereby plaintext data is scrambled into data non-readable to

ENC
any entity which doesn‟t have the key required to unscramble it (Decryption).

Electronic Point Of Sale – A Point of Sale device equipped with electronic

EPOS equipment for pricing and recording transactions. EPOS are normally installed in
large retailers (e.g. supermarkets).

Page 221 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Easy Test Cards (MasterCard test card suite) – Test cards used for MasterCard
TIP processing. MasterCard ETEC is suitable for any kind of terminal (POS, ATM,
ETEC integrated-POS and others). ETEC are used in conjunction with the MasterCard host
simulator for authorizations. The ETEC are grouped into different subsets, each with a
specific objective to test different EMV criteria and terminal applications.

ExpressPay – Amex contactless payment card or device implementation. Also the

ExpressPay name of the EMV test suite used for Amex EMV contactless transaction certification
of deployed EMV devices.

Fallback – The term used to describe the process and rules relating to using the
Fallback magnetic stripe reader of the CAD to obtain card information when the ICC or EMV
PINPad is inoperable, or no mutually supported AIDs are found.

File Control Information – In EMV FCI is defined as part of a DF and contains

FCI
information needed to select the DF and/or the subsequent EF under it.

Fast Dynamic Data Authentication – In most contactless payment environments,

quick transaction speeds (one second or below) are a business requirement. A DDA
fDDA method called fDDA, has been defined for Visa payWave offline protection against
skimming, counterfeit (in version 00 of fDDA) and man-in-the-middle attacks (in
version 01 of fDDA similar CDA).

Field Identifier – Used in various types of host messages to identify a single data
FID
field.

Floor Limit – The maximum transaction amount that can be locally authorized by the
Floor Limit
merchant without receiving an authorization from the Issuer.

Get Processing Options – Command sent by the CAD to initiate a transaction within
the ICC application. The ICC application returns the CAD the Application Interchange
GPO
Profile (AIP) and the Application File Locator (AFL). Each time a GPO command is
processed the ICC increments the ATC of the application selected by one.

GSM Global System for Mobile Communication

GSMA GSM Association

Hardware Security Module – A secure, tamper evident device used to securely

HSM generating and store keys (symmetric and asymmetric) and for perform cryptographic
functions.

Issuer Authentication – The name given to the process of authenticating the issuer
by the ICC. During the IA process the ICC will authenticate the issuer by validating
IA
the ARPC sent from the issuer to make sure it has not been changed by any
unauthorized entity along the way.

Issuer Action Codes – A set of three data fields, IAC denial, IAC online and IAC
default, defined in EMV, for use during Terminal Risk Management processing. IACs
IAC
are set by the issuer and loaded on to the ICC during the card personalization
process.

Issuer Application Data – Contains proprietary application data that is required by

IAD
the Issuer to be transmitted as part of the online authorization request.

Integrated Chip Card – Refers to a plastic card that contains a small electronic chip.
ICC
Also known as smartcards or chip cards.

Page 222 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Integrated Card Verification Value – An alternate CVV defined for storage on a Visa
EMV chip card. It is calculated using a SVC of „999‟ instead of the SVC encoded on
iCVV
the magnetic stripe image of the chip. iCVV enables issuers to identify fraudulent use
of ICC data in magnetic-stripe read transaction processing.

IDD Issuer Discretionary Data – Data encoded on magnetic stripe by the issuer.

ICC Dynamic Number – A time-variant number generated by the ICC, to be captured

IDN by the CAD. The first 3-8 bytes of the ICC Dynamic Data must be the concatenation
of the length and the value of the ICC Dynamic Number.

IFD Interface Device

Issuer Identification Number – Replaces the previously used Bank Identification

IIN
Number (BIN). See BIN for more information

Instruction Byte of the Command Message – The second byte of 5 consecutive

bytes that create the header in the C-APDU. Instruction code within the instruction
INS
class. The INS is only valid if the least significant bit is „0‟ and the most significant
nibble is neither '6' nor '9'.

Interac – The Association responsible for the development of Canada‟s network of

Interac two shared electronic financial services; Shared Cash Dispensing (ABM) and Interac
Direct Payment (debit at point of sale).

ISO International Organization for Standardization

Issuer Working Key – A Visa key used exclusively to encrypt/decrypt PIN blocks
IWK
being sent between the Issuer and the Visa network.

KEK Key Encryption Key – A key used exclusively to encrypted/decrypt other keys.

Kernel – The part of the PINPad application that contains all the EMV commands
Kernel
used between the CAD and ICC and that has been EMV type approved (Level 2).

Lc Length of data being transmitted.

Lower Consecutive Offline Limit – Issuer-specified preference for the maximum

LCOL number of consecutive offline transactions allowed for the ICC application, before the
transaction should go online (if terminal has online capabilities).

Lower Cumulative Offline Transaction Amount – Issuer-specified preference for

the maximum total amount of offline approved transactions in the supported currency
LCOTA
of the application before the transaction should go online (if terminal has online
capabilities).

Le Maximum length of data expected in response.

Local Master Key – The highest level administrative key, generated in clear in a
LMK HSM. The LMK is used to encrypt all ZMK and application keys (AC, MAC and ENC
keys) used in cryptographic processing by the HSM.

Last Online Application Transaction Counter – A dynamic data field used by the
ICC application. It is set equal to the ATC after every successful online transaction.
LOATC
The LOATC in conjunction with the ATC can be used to detect how many offline
transactions have been conducted by the ICC since the last online transaction.

Page 223 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Longitudinal Redundancy Check – A mathematically calculated value at the end of
LRC data streams that represents the data that precedes it. The LRC is used to ensure
data streams have been received exactly as transmitted.

Message Authentication Code – A hexadecimal value used to provide data integrity.

A MAC is used when transferring data between two systems/entities to ensure the
MAC
original data has not been changed. As speed of this operation is critical, TDES is
used as the MACing algorithm.

Merchant Category Code – A four-digit number assigned to a business by Visa or

MasterCard when the business first starts accepting one of these cards as a form of
MCC
payment. The MCC is used to classify the business by the type of goods or services it
provides.

Master DES Key – Used to derive UDKs which are loaded on to the ICC application
MDK
during personalization. There are three types of MDKs: AC, MAC and ENC keys.

Master File – The peak of the hierarchy of the ICC file structure. It contains
MF information and locations of the Dedicated Files (DF). DFs contain the actual data
files which are called Elementary Files (EF).

Major Industry Identifier – The first digit of the card PAN (or BIN / IIS) is the Major
Industry Identifier (MII), which represents the category of the entity which issued the
MII card.
e.g. Visa uses „4‟ and MasterCard uses „5‟ which are both defined as Banking and
Financial categories

MSI Magnetic Stripe Image

Magnetic Stripe – Strip of magnetic tape, affixed to bank credit and debit cards,
encoded with cardholder identifying information, such as the PAN and card expiration
MSD/MSR
date, allowing for automated handling of transactions. The bank card industry
standard for magnetic stripes allows three separate tracks of encoded data.

MSR Fallback – The term used to describe the process and rules relating to using
MSR Fallback the magnetic stripe reader of the CAD to obtain card information when the ICC or the
EMV PINPad are operable but the Candidate List is empty.

MasterCard Terminal Integration Process – Details the MasterCard processes and

M-TIP test cases that acquirers must successfully perform before a terminal can be certified
and deployed in a production environment.

Near Field Communication – A short-range high frequency wireless communication

technology which enables the exchange of data between devices over a 10
centimeter (around 4 inches) distance. The technology is a simple extension of the
ISO/IEC 14443 proximity-card standard that combines the interface of a smartcard
NFC
and a reader into a single device. An NFC device can communicate with both existing
ISO/IEC 14443 smartcards and readers, as well as with other NFC devices and is
thereby compatible with existing contactless infrastructure already in use for public
transportation and payment. NFC is primarily aimed at usage in mobile phones.

NATC Number of ATC Digits

P1 Parameter 1

P2 Parameter 2

Page 224 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
PayPass PayPass – MasterCard contactless payment card or device implementation.

PayWave PayWave – Visa contactless payment card or device implementation.

Primary Account Number – A 13 to 19 digit number used to identify a debit

PAN
cardholder or a credit account number.

PCB Protocol Control Byte.

Payment Card Industry – Sometimes more specifically used to refer to the Payment
Card Industry Security Standards Council (PCI-SSC). An independent council
PCI originally formed by Amex, Discover, JCB, MasterCard and Visa, with the goal of
managing the on-going evolution of the Payment Card Industry Data Security
Standard (PCI-DSS).

Payment Card Industry Data Security Standard – Standard created by PCI-SSC

(see above in PCI). The standard was created to help payment industry organizations
that process card payments prevent credit card fraud through increased controls
PCI – DSS
around data and its exposure to compromise. The standard applies to all
organizations that hold, process or exchange cardholder information from any card
branded with the logo of one of the card brands.

Payment Card Industry POS Terminal Security – Specification defining the

PCI – PTS physical and logical security requirements for PIN entry devices. See,
www.pcisecuritystandards.org for additional information.

Position of CVC3 – Field defining the location of the CVC3 in the Track-2 data for a
PCVC3
contactless MSD PayPass transaction.

Processing Data Object List – A list of terminal-related data objects (tags and
PDOL lengths), requested by the ICC, to be transmitted in the GET PROCESSING
OPTIONS command.

PED PIN Entry Device – A secure device used by a consumer to enter their PIN.

PIN Encryption Key – The PEK is a key used exclusively to encrypt PIN blocks
PEK between the various Issuer card personalization environments (from Issuer host
through Data Preparation to Personalization).

Personal Identification Number – A 4-12 digit string of numbers entered by the

PIN
cardholder to provide cardholder verification when specified by the CVM.

Personal Identification Number Block – When a cardholder enters his PIN, the
information is first encoded into a plain text PIN block using one of several PIN Block
PIN Block formats defined. Regardless of which format is used, once the PIN Block has been
constructed, the plain text PIN block can be encrypted using a standard algorithm
(when specified by the CVM).

Proprietary Application Identifier Extension – The second segment of the AID

used to identify the specific application on the ICC. Each brand (e.g. Visa Credit,
PIX Cirrus, Plus, Maestro) under a specific scheme (e.g. Visa, MasterCard, Amex) will
normally have a unique PIX to identify the brand under the specific scheme (scheme
is identified by the RID).

Public Key – A key used in RSA that does not have to be kept secret. It is used to
PK reverse any cryptographic operation that is performed using the Private Key. The
Public key has a mathematical link to the Private key which makes them a key pair.

Page 225 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Public Key Infrastructure – A set of hardware, software, people, policies and
procedures needed to create, manage, distribute, use, store and revoke digital
PKI
certificates. A PKI is an arrangement that binds PKs with respective user identities by
means of a CA.

Point of Sale – A type of terminal which is used to process electronic transactions in

POS shops, restaurant etc. The POS may process offline or go online for Authorization by
the Issuer/Scheme when processing a transaction.

Proximity Payment System Environment – Has a fixed name of 2PAY.SYS.DDF01

PPSE and contains a directory of all the contactless payment applications that exist on the
ICC. PPSE is mandatory in all contactless implementations.

Payment System Environment – Has a fixed name of 1PAY.SYS.DDF01 and

contains a directory of all the payment applications that exist on the ICC. Although
PSE
PSE is optional in EMV it is highly recommended to enhance transaction
performance.

PIN Try Counter – Indicates the number of offline PIN tries remaining. The initial
value is set to the PIN Try Limit (PTL). The PTC is decremented by 1 each time an
PTC incorrect offline PIN is entered. The PTC is reset to the PTL value when a correct
offline PIN is entered, when the PIN is changed or when the PIN is unblocked by the
issuer.

PIN Try Limit – The issuer-specified maximum number of consecutive incorrect

PTL
offline PIN tries allowed before the card is blocked.

POS Terminal Security Evaluation Program – MasterCard program to enhance the

security of transactions originating at wireless and IP-enabled POS payment
terminals.
PTS Program
The standards introduced require wireless and IP-enabled POS terminals to support
the encryption of transaction data between the terminal and the acquirer host, using
protocols approved by MasterCard.

PUNATC Position of the UN and the ATC

Personalization Validation Tool – PVT is a tool used by Visa and Visa members to
PVT ensure that a Technical Product (e.g. chip card) has been personalized in such a
manner that it is compliant with the recommendations and the mandates of Visa.

PIN Verification Value – The name given to a 4 digit field coded on the bank card
MSR that can be used to validate the online PIN. The PVV is generated using TDES
PVV algorithm using the last eleven digits of the PAN (excluding the mod 10 check value),
a one digit PIN Verification Key Index (between 1-6) positioned before the PVV on the
MSR and the four left most digits of the PAN.

qVSDC Quick Visa Smart Debit Credit – Part of the Visa contactless payment specification.

R-APDU Response – Application Protocol Data Unit – See APDU.

RFID Radio Frequency Identification.

Reserved for Future Use – Commonly used in technical specifications to represent

RFU
space for a field that may be used in the future for new functionality.

Registered Identification Number – The first part of the AID used to identify the
RID
scheme (e.g. Visa, MasterCard, etc.).

Page 226 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Rivest-Shamir-Adleman – An asymmetric algorithm used for cryptography named
RSA
after its three inventors.

(Static) Signed Application Data – A digital signature generated from critical card
SAD (SSAD) data elements and personalized on the ICC.
The SAD is validated by the terminal during the SDA process.

Store and Forward – A process used when a single host transaction message is
used (i.e. Host Capture) and the transaction has been completed offline (i.e. between
SAF
the ICC and CAD). The transaction is “stored” locally and then “forwarded” to the
host before settlement occurs.

Static Data Authentication – An option for offline CAM which protects against
counterfeit attacks. During the SDA process the terminal will validate the SAD to
SDA
ensure the information on the ICC has not been changed since the ICC was
personalization by the Issuer.

SDAD Signed Dynamic Application Data.

Short File Indicator – Used to identify a file in the commands related to an

SFI application Elementary File (EF). The SFI data object is a binary field with its three
high-order bits set to zero.

Secure Hashing Algorithm – A secure hashing algorithm designed for use with the
SHA -1
digital signatures. The SHA-1 algorithm output is always 20 bytes in length.

Signature Fallback – The term used to identify the fallback of offline PIN to signature
as the CVM for a particular ICC transaction. The ability of an ICC to perform
Signature Fallback signature fallback is indicated in the ICC‟s CVM list.
It is important not to confuse Signature Fallback with MSR Fallback or Technical
Fallback.

Secure PIN Entry Device – Used by cardholders to securely enter their PIN in
privacy. SPEDs safeguard the PIN from the time the cardholder enters the number
SPED
through its processing in the POS system by encrypting the PIN before it leaves the
SPED.

Stand-in Process – The process where a third party entity stands in to authorize an
STIP
online electronic bank transaction on behalf of the Issuer.

Page 227 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Service Code – The three digit code that follows the expiry date on the card‟s Track 2
magnetic stripe. In EMV it is used to identify the technology supported by payment
card being swiped (e.g. chip, MSR). The values for the three digits are as follows:
First digit
1: International interchange OK
2: International interchange, use IC (chip) where feasible
5: National interchange only except under bilateral agreement
6: National interchange only except under bilateral agreement, use IC (chip) where
feasible
7: No interchange except under bilateral agreement (closed loop)
9: Test
Second digit
SVC 0: Normal
2: Contact issuer via online means
4: Contact issuer via online means except under bilateral agreement
Third digit
0: No restrictions, PIN required
1: No restrictions
2: Goods and services only (no cash)
3: ATM only, PIN required
4: Cash only
5: Goods and services only (no cash), PIN required
6: No restrictions, use PIN where feasible
7: Goods and services only (no cash), use PIN where feasible

SW1 Status Byte 1

SW2 Status Byte 2

SWP Single Wire Protocol

Terminal Action Analysis – Following the completion of TRM and the setting of the
TAA TVR the CAD will perform the TAA which involves the CAD analyzing the TRM
processes and requesting the appropriate cryptogram (AAC, ARQC or TC).

Terminal Action Code – A set of three data fields, TAC Denial, TAC Online and TAC
Default, defined in EMV, for use during the Terminal Risk Management processing.
TAC
TACs are set by the schemes and must be loaded per AID to each CAD that process
EMV transactions. Merchants should receive the TACs from their Acquirer.

Tag – Method used to exchange information with the EMV chip. Each EMV Tag is
Tag
assigned a Tag Number denoting the type of information it contains.

TAL Terminal Application Layer

Transaction Certificate – An Application Cryptogram type generated by the chip

TC application in response to a Generate AC command sent by the CAD. A TC is only
generated when the ICC wishes to approve the transaction.

Page 228 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Terminal Check for Implementation – Test suite used for JCB EMV contact
TCI
transaction certification of deployed EMV devices.

Triple Data Encryption Standard – A sophisticated implementation of DES, in which

the procedure for encryption is the same but repeated three times. First, the DES key
is broken into three sub keys. Then the data is encrypted with the first key, the result
TDES
decrypted with the second key and finally encrypted again with the third key. Triple
DES offers much stronger encryption than DES TDES uses a double length key
which is 32 bytes in length.

Transaction Certificate (TC) Data Object List – A CDOL may request a TC Hash
Value to be included in the command data of a GENERATE AC command. The TDOL
is a list of the data objects the CAD should use to generate the TC Hash Value. The
TDOL
ICC may contain the TDOL, however there should also be a default TDOL in the
CAD, specified by the payment system, for use in cases where the TDOL is not
present in the ICC.

Technical Fallback – The process and rules relating to using the magnetic stripe
Technical Fallback reader of the CAD to obtain card information if the ICC or the EMV PINPad is
inoperable.

Terminal Integration Process – A key testing process designed and mandated by

MasterCard to test the CAD, its intermediate connections and the interface with the
TIP
acquirer host system, in conditions that are as close as possible to its final production
environment.

Tag/Length/Value – A variable length data format that uses a label (tag) to uniquely
TLV
identify a field followed by its field value length and then the field value.

TPDU Transport Protocol Data Unit

Terminal Quality Management – MasterCard programme that provides assurance to

acquirers that devices they certify are consistent with the card interface module
TQM
approved by EMVCo. The TQM process ensures that the smart card and contactless
hardware interfaces are EMV Level 1 compliant.

Terminal Risk Management – A process performed by the CAD to determine if the

TRM transactions should be sent online, approved offline or declined offline. The output of
the TRM is the setting of the TVR that is subsequently used in the TAA.

Terminal Status Information – Identifies the functions performed by a CAD during

TSI
transaction processing (e.g. offline data authentication, CVM, CRM, TRM etc.).

TTQ Terminal Transaction Qualifiers

The Terminal Verification Result – An EMV tag containing the status of several
TVR
different EMV checks performed by the PINPad Kernel or the EMV POS Solution.

Upper Consecutive Offline Limit – Issuer-specified preference for the maximum

number of consecutive offline transactions allowed for the ICC application, before a
UCOL
transaction must be approved online. Once this value is reached no offline
transactions are allowed for that application until an online transaction is approved.

Page 229 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved
Title: EMV Implementation Guide Version: 1.2
Prepared by: B2 Payment Solutions Published on: 09/04/14

Term Description
Upper Cumulative Offline Transaction Amount – Issuer-specified preference for
the maximum total amount of offline approved transactions, in the supported
UCOTA application currency, before a transaction must be sent online. Once this amount is
reached no offline transactions are allowed for that application until an online
transaction is approved.

UDOL UN Data Object List – A proprietary MasterCard PayPass tag.

Unique DES Key – A unique key derived using the MDK, PAN and PAN Sequence
UDK Number. The UDKs are loaded onto the ICC application during personalization.
There are three types of UDKs: AC, MAC and ENC keys.

Universal Integrated Circuit Card – The smart card used in GSM network mobile
UICC terminals. The UICC ensures the integrity and security of personal data. The UICC
will typically contain a few hundred kilobytes of personal data.

Unpredictable Number – A value used to provide variability and uniqueness when

generating a cryptogram or during an encryption process.
UN
When used in the CAM process the PINPad generates the UN.
When used for offline encrypted PIN the UN is generated by the chip application.

Visa ICC Specification – The Visa specific implementation of EMV credit/debit

VIS
applications on an ICC. The specification is often referred to as VSDC.

VLP Visa Low Value Payment

Visa Smart Debit Credit – An EMV based ICC application specified by Visa. In
VSDC
many cases this is often used to refer to the VIS specifications.

Zone Master Key – A high level administrative key established manually between
ZMK two entities using key custodians under split knowledge. Once the ZMK is exchanged
it can be used to transfer secret data (e.g. keys) between the two entities.

Page 230 of 230

CONFIDENTIAL
©2015 Total Systems Services, Inc. All rights reserved