EMV Implementation Guide - Magento 2 · This Chase Paymentech EMV Implementation Guide provides insight into EMVCo requirements and outlines the expected EMV transaction flow. However,

Publication date: November 17, 2017 Version 2.4

EMV Implementation Guide

EMV Implementation Guide Legal Notice

© Paymentech, LLC. All rights reserved Page 2 of 279 November 17, 2017

Legal Notice ©2017 by B2 Payment Solutions Inc. developed for Chase Paymentech Inc. All rights reserved. All information contained herein is confidential and propriety to B2 Payment Solutions Inc. and/or Chase Paymentech Inc. It shall not be disclosed, duplicated or used in part or in whole, for any purpose without prior written consent from Chase Paymentech Inc. All trademarks, registered trademarks, product names and logos identified or mentioned herein are the property of Paymentech, LLC, Chase Paymentech Solutions, LLC, Chase Paymentech Europe Limited, or their respective owners.

This edition of the EMV Implementation Guide contains information available at the time of publication and supersedes, in its entirety, all previously published documents by Chase Paymentech.

ALL INFORMATION IS PROVIDED BY Paymentech, LLC, CHASE PAYMENTECH SOLUTIONS, LLC, Chase Paymentech Europe Limited, and their respective affiliates (collectively “Chase Paymentech”) ON AN "AS IS" AND “AS AVAILABLE” BASIS ONLY and without condition, endorsement, guarantee, representation, or warranty of any kind by Chase Paymentech.

This document and all information contained herein are proprietary to Chase Paymentech. Recipient agrees to treat it as such, whether or not any or all parts are protected by patent, trade secret, or copyright. Recipient shall not, under any circumstances disclose this document or the system described to any third party without prior written consent of a duly authorized representative of Chase Paymentech. To satisfy this proprietary obligation, recipient agrees to take appropriate action with its employees or other persons permitted access to this information.

This document may contain references to third party sources of information, hardware, software, products or services (“Third Party Content”). Chase Paymentech does not control and is not responsible for any Third Party Content.

This document is intended to support technical requirements for processing transactions only. It is not intended to be a guarantee that merchants will qualify for the best interchange rates from the payment brands or that merchant’s transactions are in compliance with applicable Payment Brand Rules.

Disclaimer Chase Paymentech does not guarantee or assume responsibility for any typographical, technical or other inaccuracies, errors or omissions in this document. Recipient’s use of this document is at the recipient’s own risk. Chase Paymentech reserves the right to periodically change information contained in this document, however, Chase Paymentech is under no obligation to provide notice of any such changes, revisions, updates, enhancements, or other additions to this document to recipient in a timely manner or at all.

CHASE PAYMENTECH PROVIDES NO REPRESENTATIONS AND WARRANTIES, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING WITHOUT LIMITATION ANY WARRANTY OR CONDITION REGARDING QUALITY, SUITABILITY, MERCHANTABILITY, FITNESS FOR USE OR FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT OR OTHERWISE (REGARDLESS OF ANY COURSE OF DEALING, CUSTOM OR USAGE OF TRADE).

IN NO EVENT WILL CHASE PAYMENTECH BE LIABLE TO ANY PARTY FOR ANY TYPES OF DAMAGES RELATED TO THIS DOCUMENT OR ITS USE, OR PERFORMANCE OR NON-PERFORMANCE OF ANY SOFTWARE, HARDWARE, SERVICE OR ANY THIRD PARTY PRODUCTS AND SERVICES REFERENCED HEREIN INCLUDING WITHOUT LIMITATION ANY DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, EXEMPLARY, PUNITIVE OR AGGRAVATED DAMAGES FOR ANY USE OF THIS DOCUMENT OR THE INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT LIMITATION, ANY LOST PROFITS, LOSS OF BUSINESS OPPORTUNITY, BUSINESS INTERRUPTION, CORRUPTION OR LOSS OF DATA OR PROGRAMS, FAILURE TO TRANSMIT OR RECEIVE DATA OR DOWNTIME COSTS, WHETHER OR NOT SUCH DAMAGES WERE FORESEEN OR UNFORESEEN, AND EVEN IF CHASE PAYMENTECH HAS BEEN EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

EMV Implementation Guide EMVCo LLC


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, China UnionPay and Visa.

This Chase Paymentech EMV Implementation Guide provides insight into EMVCo requirements and outlines the expected EMV transaction flow. However, because EMV rules differ for each card brand and include rules specific to the PIN Pad 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 http://www.emvco.com/.

Within this document all EMV and contactless configurations are generically referred to as an “EMV POS Solution”.

Intended Audience This document is intended for Software Developers, Gateway Providers, Merchants, 3rd Party Developers and Project Managers.

It is intended to provide a basic understanding of how Chase Paymentech handles EMV chip card processing and how best to integrate their products to the Chase Paymentech host.

EMV Implementation Guide Supporting Documentation


Supporting Documentation This document is not intended to cover all details required to board and implement EMV processing, but is meant to supplement information found in the following existing documents and other specifications available on the Chase Paymentech Developer Center.

Chase Paymentech Processing and Interchange Guidelines

Universal Terminal Formats for Host Capture System

Universal Terminal Formats for Terminal Capture System

Universal Terminal Formats Token Reference Guide

PNS ISO Formats for Host and Terminal Capture System

Stratus Online Processing Specification

120-Byte Batch Processing Specification

This guide is intended to provide the minimum requirements to process chip transactions. Developers should also consult the most recent version other EMV documents that provide additional information required for EMV implementation. These documents can be obtained directly from the PIN Pad vendor, EMVCo and the specific card brands (i.e. Visa, MasterCard, etc.).

Other EMV – Integrated Circuit Card Specification for Payment Systems

Visa International – Integrated Circuit Card Specification

Visa Transaction Acceptance Device Guide

Visa Smart Debit/Credit Acquirer Device Validation Toolkit User Guide

MasterCard International – M/Chip Functional Architecture for Debit and Credit

MasterCard U.S. Market Terminal Requirements

Interac Association – IDP Terminal Specifications

Interac Direct Payment (IDP) POS Terminal Specifications Bulletin #1

Interac Terminal Application Certification Guide for U.S. Implementation

AEIPS Terminal Specification

Implementing American Express EMV Acceptance on a Terminal

Discover D-PAS Acquirer Implementation Guide

UnionPay Integrated Circuit Card Specifcation set (available from China UnionPay website)

It is the developer’s responsibility to review the above referenced materials as this supplement is an addition to the standards that are required for EMV compliance. It is recommended that developers review the reference materials before referring to this guide.

EMV Implementation Guide Table of Contents


Table of Contents EMV Implementation Guide ................................................................................................................... 1

Legal Notice ........................................................................................................................................... 2

Disclaimer .............................................................................................................................................. 2

EMVCo LLC ........................................................................................................................................... 3

Intended Audience ................................................................................................................................. 3

Supporting Documentation .................................................................................................................... 4

Table of Contents .................................................................................................................................. 5 Requirements .......................................................................................................................................................................... 11 Best Practices ......................................................................................................................................................................... 15 Tables . ............................................................................................................................................................................ 17

Change Log ......................................................................................................................................... 21

1. Introduction ................................................................................................................................. 24 1.1 Implementation Guide Overview .......................................................................................................................... 24 1.2 EMV Terminal Configurations .............................................................................................................................. 24

1.2.1 Fully Integrated ECR Solution ........................................................................................................................ 25 1.2.2 Partially Integrated ECR Solution ................................................................................................................... 26 1.2.3 Semi-Integrated ECR Solution ....................................................................................................................... 27 1.2.4 Standalone POS Solution (Internal PINPad) .................................................................................................. 29 1.2.5 Standalone POS Solution (External PINPad) ................................................................................................. 30

1.3 Safetech Encryption ............................................................................................................................................. 31 1.4 Safetech Tokenization ......................................................................................................................................... 31 1.5 EMV and Contactless Solution Components ....................................................................................................... 31 1.6 Chase Paymentech Supported Configurations .................................................................................................... 31 1.7 U.S. Debit ............................................................................................................................................................ 33

2. Development Process ................................................................................................................. 38 2.1 Development and Certification ............................................................................................................................. 38 2.2 Technical Profile Questionnaire (TPQ) ................................................................................................................ 41 2.3 Training ................................................................................................................................................................ 43 2.4 Technical Support ................................................................................................................................................ 43 2.5 Development Host Connection Information ......................................................................................................... 44 2.6 Certification Process ............................................................................................................................................ 44 2.7 Card Brand Certification....................................................................................................................................... 47 2.8 Pilot ...................................................................................................................................................................... 48 2.9 Post Rollout Re-Certification ................................................................................................................................ 48 2.10 EMV Contact and Contactless Test Tools ........................................................................................................... 49



Collis Merchant Test Suite .............................................................................................................................................. 51 2.10.1 ICC Solutions Test Suite Bundles for Certification (ICC TS) .......................................................................... 53

2.11 Integrated Solution Validation .............................................................................................................................. 55 3. EMV Overview ............................................................................................................................ 57

3.1 EMV Benefits ....................................................................................................................................................... 57 3.2 Online vs. Offline EMV Transactions ................................................................................................................... 57 3.3 EMV Transaction Steps ....................................................................................................................................... 58

3.3.1 EMV Credit Transaction Set ........................................................................................................................... 58 3.3.2 EMV Debit Transaction Set ............................................................................................................................ 59

3.4 Transaction Processing ....................................................................................................................................... 59 3.4.1 Sale Transactions .......................................................................................................................................... 59 3.4.2 Authorization / Pre-Authorization Transactions .............................................................................................. 60 3.4.3 Incremental Authorization .............................................................................................................................. 60 3.4.4 Completions ................................................................................................................................................... 60 3.4.5 Return ............................................................................................................................................................ 61 3.4.6 Balance Inquiry Transactions ......................................................................................................................... 61 3.4.7 Quick Service Transactions (QSR, QPS, FPS) .............................................................................................. 61

4. Contactless Overview ................................................................................................................. 63 4.1 Contactless Benefits ............................................................................................................................................ 63 4.2 MSD vs EMV Grade ............................................................................................................................................ 63 4.3 Contactless Card Schemes ................................................................................................................................. 63 4.4 EMV Contactless Transaction Sets ..................................................................................................................... 64

5. EMV Transaction Flow ................................................................................................................ 65 5.1 Full EMV Transaction Flow .................................................................................................................................. 65

5.1.1 Full EMV Transaction Flowchart .................................................................................................................... 68 5.2 Partial EMV Transaction Flow .............................................................................................................................. 69

5.2.1 Partial EMV Transaction Flowchart ................................................................................................................ 71 5.3 Contactless Transaction Flow .............................................................................................................................. 73

5.3.1 Contactless Transaction Flowchart ................................................................................................................ 74 6. Chip Processing Guidelines ........................................................................................................ 77

6.1 Tender Processing ............................................................................................................................................... 77 6.1.1 Cashback Transaction Flow ........................................................................................................................... 78 6.1.2 Tip Transaction Flow ...................................................................................................................................... 78 6.1.3 Faster EMV (Quick Chip / M/Chip Fast) Transaction Flow ............................................................................. 79

6.2 EMV Transaction Initiation ................................................................................................................................... 81 6.2.1 Service Code Processing ............................................................................................................................... 81

6.3 Chip Read Flow ................................................................................................................................................... 81 6.3.1 Chip Read Flowchart ...................................................................................................................................... 83

6.4 Fallback Processing ............................................................................................................................................. 84



6.4.1 Fallback Acceptance ...................................................................................................................................... 84 6.4.2 Fallback Not Allowed Scenarios ..................................................................................................................... 85 6.4.3 Fallback Prompting ........................................................................................................................................ 85 6.4.4 Fallback Timeline ........................................................................................................................................... 86 6.4.5 Exception to Fallback ..................................................................................................................................... 86

6.5 Application Selection ........................................................................................................................................... 87 6.5.1 Application Selection Methods ....................................................................................................................... 88 6.5.2 Credit / Debit Selection and U.S. Debit Processing........................................................................................ 89 6.5.3 Final Selection................................................................................................................................................ 93 6.5.4 Cardholder Application Confirmation .............................................................................................................. 94

6.6 Read Data Records ............................................................................................................................................. 94 6.7 Cardholder Language Selection .......................................................................................................................... 95 6.8 Cardholder Prompting .......................................................................................................................................... 96

6.8.1 Card Entry Prompting ..................................................................................................................................... 96 6.8.2 PIN Prompting ................................................................................................................................................ 96 6.8.3 Amount Confirmation Prompting .................................................................................................................... 97

6.9 Processing Restrictions ....................................................................................................................................... 97 6.9.1 Processing Restrictions Steps........................................................................................................................ 97

6.10 Offline Card Authentication .................................................................................................................................. 98 6.10.1 Offline Card Authentication Methods .............................................................................................................. 99

6.11 Cardholder Verification ........................................................................................................................................ 99 6.11.1 Chase Merchant Services (Paymentech) EMV Processing Guidelines Update ........................................... 100 6.11.2 Supported Cardholder Verification Methods (CVM) ..................................................................................... 102 6.11.3 PIN Prompting .............................................................................................................................................. 103 6.11.4 CVM Results Validation (Tag 9F34) ............................................................................................................. 104

6.12 Terminal Risk Management ............................................................................................................................... 104 6.12.1 EMV Floor Limit ............................................................................................................................................ 105 6.12.2 EMV Random Selection ............................................................................................................................... 106

6.13 Data Object Lists ............................................................................................................................................... 106 6.13.1 Dynamic Data Object List (DDOL) ............................................................................................................... 107 6.13.2 Transaction Certificate Data Object List (TDOL) .......................................................................................... 107 6.13.3 Processing Data Object List (PDOL) ............................................................................................................ 108

6.14 Terminal Action Analysis.................................................................................................................................... 108 6.14.1 Issuer Action Codes (IACs) .......................................................................................................................... 108 6.14.2 Terminal Action Codes (TACs)..................................................................................................................... 109

6.15 1st Generate Application Cryptogram ................................................................................................................ 109 6.15.1 Terminal Action Analysis .............................................................................................................................. 109 6.15.2 Card Action Analysis .................................................................................................................................... 110

6.16 EMV Offline Approvals ....................................................................................................................................... 110



6.16.1 Offline Transaction Upload ........................................................................................................................... 111 6.17 Online Response Processing ............................................................................................................................. 111

6.17.1 Partial Authorizations ................................................................................................................................... 112 6.17.2 Referrals ...................................................................................................................................................... 113

6.18 External Authenticate ......................................................................................................................................... 113 6.19 2nd Generate Application Cryptogram ............................................................................................................... 113

6.19.1 Issuer Script Processing .............................................................................................................................. 114 6.20 Transaction Completion Processing .................................................................................................................. 115

6.20.1 Reversal Processing .................................................................................................................................... 115 6.20.2 Card Removal Prompting ............................................................................................................................. 116 6.20.3 Transaction Storage ..................................................................................................................................... 116

7. Chase EMV Parameter Download ............................................................................................ 118 7.1 Chase EMV Download Parameters ................................................................................................................... 118

7.1.1 Certificate of Authority Public Keys (CAPK) ................................................................................................. 119 7.1.2 Fallback Indicator ......................................................................................................................................... 119 7.1.3 EMV Offline Floor Limit ................................................................................................................................ 119 7.1.4 Threshold for Biased Random Selection ...................................................................................................... 120

7.2 PNS ISO Parameter Download Processing ....................................................................................................... 120 7.2.1 PNS ISO Download Notification ................................................................................................................... 120 7.2.2 PNS ISO Parameter Download .................................................................................................................... 120

7.3 UTF Parameter Download Processing .............................................................................................................. 121 7.3.1 UTF EMV Download Notification .................................................................................................................. 121 7.3.2 UTF EMV Parameter Download ................................................................................................................... 122

7.4 Stratus EMV Parameter Download Processing ................................................................................................. 123 8. EMV Contact and Contactless Parameters ............................................................................... 125

8.1 Contact EMV Parameters .................................................................................................................................. 125 8.2 Contactless EMV Parameters ............................................................................................................................ 128

9. Chase Host Message Processing ............................................................................................. 131 9.1 Host Transaction Sets ....................................................................................................................................... 131

9.1.1 Credit Transaction Set ................................................................................................................................. 132 9.1.2 Debit Transaction Set ................................................................................................................................... 134

9.2 Host Message EMV Fields................................................................................................................................. 135 9.2.1 Cardholder Data ........................................................................................................................................... 135 9.2.2 Chip Card Data ............................................................................................................................................ 135 9.2.3 EMV/Contactless PAN Sequence Number .................................................................................................. 136

9.3 Host Message EMV Tags .................................................................................................................................. 137 9.3.1 Authorization Request EMV Tags ................................................................................................................ 138 9.3.2 Authorization Response EMV Tags ............................................................................................................. 140 9.3.3 Reversal EMV Tags ..................................................................................................................................... 141



9.3.4 Settlement EMV Tags .................................................................................................................................. 143 9.4 Host Message Examples ................................................................................................................................... 145

9.4.1 PNS ISO Host Message Examples .............................................................................................................. 146 9.4.2 UTF Host Message Examples...................................................................................................................... 153 9.4.3 Stratus Host Message Examples ................................................................................................................. 163

10. EMV Receipt Guidelines ........................................................................................................... 165 10.1 EMV Receipt Data ............................................................................................................................................. 165 10.2 Receipt Samples ................................................................................................................................................ 167

10.2.1 Credit Card (Online Approved – Signature) ................................................................................................. 168 10.2.2 Credit Card (Online Approved – PIN) ........................................................................................................... 169 10.2.3 Credit Card (Online Approved – Fallback) ................................................................................................... 170 10.2.4 Credit Card (Offline Declined) ...................................................................................................................... 171

11. EMV Report Guidelines ............................................................................................................ 173 11.1 EMV Transaction Report.................................................................................................................................... 173 11.2 EMV Statistics Report ........................................................................................................................................ 175 11.3 Technical Fallback Reports................................................................................................................................ 176

11.3.1 EMV Clerk Technical Fallback Report .......................................................................................................... 176 11.3.2 PINPad Technical Fallback Report .............................................................................................................. 177

11.4 POS Entry Mode Report .................................................................................................................................... 178 11.5 EMV Configuration Report ................................................................................................................................. 179 11.6 EMV Public Key Load Report ............................................................................................................................ 184

12. EMV Contact and Contactless Data Elements .......................................................................... 187 12.1 EMV Contact & Contactless Data Elements Definitions .................................................................................... 187

13. Reference Materials .................................................................................................................. 203 13.1 Answer to Reset ................................................................................................................................................ 203 13.2 EMV Reference Tables ...................................................................................................................................... 204

13.2.1 Application Interchange Profile (Tag 82) ...................................................................................................... 204 13.2.2 Application Priority Indicator (Tag 87) .......................................................................................................... 205 13.2.3 Application Usage Control (Tag 9F07) ......................................................................................................... 206 13.2.4 Cardholder Verification Rule (part of CVM List) ........................................................................................... 207 13.2.5 Cardholder Verification Method Results (Tag 9F34) .................................................................................... 208 13.2.6 Card Verification Results (included in Tag 9F10) ......................................................................................... 209 13.2.7 Cryptogram Information Data (Tag 9F27) .................................................................................................... 211 13.2.8 Terminal Capabilities (Tag 9F33) ................................................................................................................. 212 13.2.9 Additional Terminal Capabilities (Tag 9F40) ................................................................................................ 213 13.2.10 Terminal Verification Results (Tag 95) ......................................................................................................... 215 13.2.11 Transaction Status Indicator (Tag 9B) .......................................................................................................... 217

13.3 EMV Chip Commands ....................................................................................................................................... 218 13.3.1 Application Block .......................................................................................................................................... 219



13.3.2 Application Unblock ...................................................................................................................................... 220 13.3.3 Card Block ................................................................................................................................................... 221 13.3.4 External Authenticate ................................................................................................................................... 222 13.3.5 Generate AC ................................................................................................................................................ 223 13.3.6 Get Challenge .............................................................................................................................................. 225 13.3.7 Get Data ....................................................................................................................................................... 226 13.3.8 Get Processing Options ............................................................................................................................... 227 13.3.9 Internal Authenticate .................................................................................................................................... 228 13.3.10 PIN Change/Unblock .................................................................................................................................... 229 13.3.11 Read Record ................................................................................................................................................ 230 13.3.12 Select ........................................................................................................................................................... 231 13.3.13 Verify ............................................................................................................................................................ 234 13.3.14 EMV Response Codes (SW1 SW2) ............................................................................................................. 235

13.4 BCD to ASCII Conversion .................................................................................................................................. 237 13.5 ASCII Chart ........................................................................................................................................................ 238

14. EMV Testing and Certification Parameters ............................................................................... 239 14.1 Amex Certification Parameters .......................................................................................................................... 239 14.2 Debit Network Alliance Certification Parameters ............................................................................................... 240 14.3 Discover Certification Parameters ..................................................................................................................... 241 14.4 Interac Certification Parameters ........................................................................................................................ 242 14.5 JCB Certification Parameters ............................................................................................................................. 243 14.6 MasterCard Certification Parameters ................................................................................................................. 244 14.7 Visa Certification Parameters ............................................................................................................................ 246 14.8 China UnionPay Certification Parameters ......................................................................................................... 248

15. Glossary of Terms & Acronyms ................................................................................................ 251

16. Appendix ‘A’ - Canadian Processing ......................................................................................... 271 16.1 Interac Account Selection Prompting ................................................................................................................. 271 16.2 Canadian Language Requirements specific to Interac ...................................................................................... 271

16.2.1 Sample Approved Receipt - French ............................................................................................................. 272 16.2.2 Sample Declined Receipt - French ............................................................................................................... 273

16.3 Interac Application Selection .............................................................................................................................. 274 16.3.1 Application Selection Flag “Canadian Flag” (Tag DF62) Processing ........................................................... 274

16.4 Canadian Debit Transaction Set ........................................................................................................................ 277 16.5 Interac Cashback Processing ............................................................................................................................ 278



Requirements 00101 All EMV POS Solutions must support MSR transactions ..................................................................................... 32 00102 Debit on chip enabled EMV POS Solutions must support EMV and MSR debit..................................................... 32 00201 Notify Chase of all PIN Pad kernel configurations being used ............................................................................. 42 00202 Provide PIN Pad Certification Letters of Approval (LOA) ..................................................................................... 42 00203 EMV certification letters must be current ............................................................................................................. 43 00204 EMV Test Tool is required for Card Brand Certification ....................................................................................... 46 00205 qVSDC certification is required for contactless-only Visa EMV POS Solutions ................................................... 47 00206 Multiple certifications required if multiple kernel configurations supported .......................................................... 48 00207 Keep track of the EMV POS Solution certification status ..................................................................................... 49 00208 Chase Paymentech must be notified of changes to EMV functionality ................................................................ 49 00301 Transactions must go online for issuer authorization ........................................................................................... 57 00302 Sale transactions must be Full EMV transactions ................................................................................................ 60 00303 Auth and Pre-Auth transactions must be processed as Full EMV transactions ................................................... 60 00304 Incremental Authorizations must be sent as keyed transactions ......................................................................... 60 00305 Completions without cardholder present require Pre-Authorization chip data...................................................... 61 00307 Credit Returns must be Partial EMV transactions ................................................................................................ 61 00308 Debit Returns must be Full EMV transactions ..................................................................................................... 61 00309 CVM processing must be performed for QSR transactions ................................................................................. 62 00501 MasterCard requires issuer decision be used for 2nd Generate AC chip error .................................................... 67 00601 Total transaction amount must be known before the card is presented ............................................................... 77 00602 Transaction Amount (Tag 9F02) must be set to total transaction amount ........................................................... 77 00603 Cardholder amount confirmation is optional......................................................................................................... 77 00604 Transaction Amount (Tag 9F02) must include the cashback amount .................................................................. 78 00605 Other Amount (Tag 9F03) must contain the cashback amount ............................................................................ 78 00606 Cashback is only allowed for online debit and Discover AIDs.............................................................................. 78 00607 Transaction Type must be set to ‘09’ for MasterCard debit cashback transactions ............................................. 78 00608 Service Code ‘2xx’ and ‘6xx’ must force a chip usage ......................................................................................... 81 00609 Cancel transaction if card accepted but removed before host authorization ........................................................ 82 00610 Reverse and cancel if host approves but card removed before 2nd Gen AC ...................................................... 82 00611 Decline transaction if host declines and card removed before 2nd Gen AC ........................................................ 82 00612 Only one card interface may be active once a read has begun ........................................................................... 82 00613 Service Code ‘2xx’ and ‘6xx’ must be accepted for fallback card swipes ............................................................. 84 00614 Fallback must be cancelled when a card is inserted at fallback card entry .......................................................... 84 00615 Fallback must be cancelled if a non-EMV card is swiped during fallback ............................................................ 84 00618 Fallback transactions must be identified in the host message ............................................................................. 85 00619 Fallback must be cancelled when card is inserted during fallback card entry ...................................................... 85 00620 Service Code ‘2xx’ and ‘6xx’ must be accepted for fallback card swipes ............................................................. 85



00621 Fallback Flag must be downloaded from the Chase host and used ..................................................................... 86 00622 Fallback is not allowed if not supported by card scheme ..................................................................................... 86 00617 Transactions sent as swiped because EMV was not enabled must not be sent as Fallback ............................... 86 00623 Partial Selection must be supported .................................................................................................................... 87 00624 Accept valid AIDs only ......................................................................................................................................... 88 00625 AID list must be loaded into the kernel at kernel initialization .............................................................................. 89 00626 Final Selection application names must be displayed to cardholder .................................................................... 94 00627 Transaction must be cancelled if Cardholder Application Confirmation fails ........................................................ 94 00628 Application Expiration Date must match Track 2 Equivalent Data Expiry Date .................................................... 94 00629 Service Code must not be validated against Track 2 Equivalent Data ................................................................. 95 00630 Merchant prompts and receipts must be in default merchant language ............................................................... 95 00631 Cardholder prompts and receipts should be in selected cardholder language..................................................... 95 00632 If Language Preference Indictor is not present use merchant language .............................................................. 95 00633 AID list must be supported with associated Application Version Numbers .......................................................... 98 00634 All Offline CAM failures must be sent for online authorization ............................................................................. 99 00635 If offline CAM is not performed transaction must go online .................................................................................. 99 00636 All Offline Card Authentication Methods must be supported ................................................................................ 99 00637 If PIN CVM is supported then both Online and Offline PIN must be supported ................................................. 103 00638 Signature CVM must be supported for attended solutions ................................................................................. 103 00639 NO CVM must be supported for unattended solutions with no PIN Pad ............................................................ 103 00640 Maximum number of PIN tries must not exceed PIN Try Counter (Tag 9F17) ................................................... 103 00641 Cardholder must be notified of last offline PIN attempt ...................................................................................... 103 00642 Cardholder must be notified when maximum Offline PIN tries is exceeded ....................................................... 103 00643 Floor Limit must be set to zero ........................................................................................................................... 106 00644 Non-zero EMV Floor Limits must be supported ................................................................................................. 106 00645 Random Selection parameters must ensure transaction is attempted ............................................................... 106 00646 A Default DDOL is required for EMV POS Solutions that support DDA ............................................................. 107 00647 The Visa Default TDOL (if used) must include Transaction Amount only .......................................................... 107 00648 The MasterCard Default TDOL (if used) must include multiple tags .................................................................. 107 00649 Do not set kernel to force transactions online .................................................................................................... 108 00651 Authorization Response Code must be set based on host Response Code ...................................................... 112 00652 Issuer Scripts must be supported in host responses ......................................................................................... 112 00653 Reversal must be sent if cardholder declines partial authorization .................................................................... 113 00654 Transaction Amount (Tag 9F02) must reflect the partially authorized amount ................................................... 113 00655 Partially authorized amount must be sent in the settlement message ............................................................... 113 00656 Referral transactions must be declined .............................................................................................................. 113 00657 Issuer Scripts must be executed for approved and declined transactions ......................................................... 114 00658 Must support Issuer Scripts up to 128 bytes in length ....................................................................................... 114 00659 Handling Issuer Script errors ............................................................................................................................. 115



00660 EMV transaction reversals must include EMV tags ........................................................................................... 116 00661 Last EMV transaction data must be available even if transaction is declined .................................................... 117 00701 Chase EMV Parameters must be downloaded whenever new version is available ........................................... 118 00702 Download EMV parameters within nine Settlement periods of notification ........................................................ 118 00703 Must be capable of storing six CA Public Keys per card brand.......................................................................... 119 01001 Application Name or Label must be printed on the receipt ................................................................................ 166 01002 Transaction amount must be printed on the receipt ........................................................................................... 167 01003 AID must be printed on the receipt .................................................................................................................... 167 01101 EMV Configuration Report is mandatory............................................................................................................ 183 01102 EMV Public Key Load Report is mandatory ....................................................................................................... 185 01601 Canadian EMV POS Solutions must support French cardholder prompting ...................................................... 271 01602 Canadian EMV POS Solutions must support French receipt printing ................................................................ 271



This page intentionally blank



Best Practices BP 00101 Contactless should be supported ......................................................................................................................... 32 BP 00102 U.S. Debit selection method should be configurable ........................................................................................... 37 BP 00103 Select U.S. Common Debit AIDs when present on card ...................................................................................... 37 BP 00104 Allow Cardholder to select AID when more than one funding source .................................................................. 37 BP 00201 Obtain EMV Training before beginning an EMV project ...................................................................................... 43 BP 00202 Budget adequate time for certification ................................................................................................................. 46 BP 00207 Be ready before attempting Card Brand Certification .......................................................................................... 48 BP 00203 Production validation prior to rollout is strongly encouraged ................................................................................ 48 BP 00204 Respond quickly when notified of re-certification requirements ........................................................................... 49 BP 00205 The Collis MTS or ICC Solutions TS are recommended ...................................................................................... 50 BP 00301 Prior/Forced Sale transactions should be Partial EMV transactions .................................................................... 60 BP 00601 If PIN CVM is supported use Table Pay for restaurant tipping ............................................................................. 79 BP 00602 Fallback Prompting should only be allowed for a limited time .............................................................................. 85 BP 00604 When prompting use “No PIN” / “PIN” rather than “Credit” / “Debit” ..................................................................... 91 BP 00605 PIN Preferring and Credit / Debit selection methods should be supported .......................................................... 91 BP 00606 A default application name should be assigned for all AIDs ................................................................................ 93 BP 00607 If multiple languages supported, cardholder should be prompted to select ......................................................... 95 BP 00608 Prompt cardholder to “Leave Card Inserted” ........................................................................................................ 96 BP 00609 PIN CVM is not required .................................................................................................................................... 102 BP 00610 Allow opportunity for customers who don’t know their PIN to continue with the transaction .............................. 102 BP 00611 Terminal Risk Management features should be supported ................................................................................ 105 BP 00612 Generated Offline approval codes should be in the format “E999999” .............................................................. 111 BP 00613 Do not print receipt until the card has been removed ........................................................................................ 116 BP 00614 Sound audible beep while waiting for card to be removed ................................................................................. 116 BP 00901 EMV Tags should be sent in order ..................................................................................................................... 137 BP 00902 Authorization request messages must include all authorization EMV tags ........................................................ 138 BP 00903 Reversal messages should include all reversal EMV tags ................................................................................. 141 BP 00904 Settlement messages should include all settlement EMV tags .......................................................................... 143 BP 01101 EMV Transaction Report should be available for last transaction ...................................................................... 174 BP 01102 EMV Transaction Report includes data element name and tag number ............................................................ 174 BP 01103 EMV Transaction Report information should be stored in journal ...................................................................... 175 BP 01104 EMV Statistics report is recommended .............................................................................................................. 175 BP 01105 EMV Technical Fallback reports are recommended .......................................................................................... 176 BP 01106 POS Entry Mode Report is recommended ......................................................................................................... 178






Tables . EMV Configuration Modes ................................................................................................................................... 32 EMV Configuration Modes – By Terminal Type ................................................................................................... 33 U.S. Common Debit AIDs .................................................................................................................................... 33 U.S. Common Debit Scenarios ............................................................................................................................ 35 Development and Certification Components........................................................................................................ 38 PIN Pad Certification Letters ................................................................................................................................ 42 Certification Process ............................................................................................................................................ 45 Card Brand Certification Test Suites .................................................................................................................... 47 Chase Paymentech Approved EMV Test Tools ................................................................................................... 50 Full EMV vs. Partial EMV Transaction Steps ....................................................................................................... 58 EMV Credit Transaction Set ................................................................................................................................ 59 EMV Debit Transaction Set.................................................................................................................................. 59 Contactless Card Schemes ................................................................................................................................. 63 EMV Contactless Transaction Set ....................................................................................................................... 64 Full EMV Transaction Flow .................................................................................................................................. 65 Partial EMV Transaction Flow .............................................................................................................................. 69 Chip Service Codes Processing .......................................................................................................................... 81 Chip Reader Actions ............................................................................................................................................ 82 Magstripe Reader Actions.................................................................................................................................... 82 Application Identifiers (AID) ................................................................................................................................. 88 Cardholder Approval Indicator (Tag 87 bit-8) ....................................................................................................... 94 Recommended Card Entry Prompting ................................................................................................................. 96 Recommended PIN Entry Prompting ................................................................................................................... 96 Recommended Cardholder Amount Confirmation ............................................................................................... 97 Card Brand Application Version Numbers ........................................................................................................... 98 Credit and Debit Transaction Options for Each Supported AIDs ....................................................................... 100 Chase Merchant Services Transaction Type Mapping to Hosts ........................................................................ 101 Cardholder Verification Methods ........................................................................................................................ 102 (CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 1 ................................................................ 104 (CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 2 ................................................................ 104 (CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 3 ................................................................ 104 Risk Management Requirements ....................................................................................................................... 104 Random Selection Values.................................................................................................................................. 106 Authorization Response Code Values ............................................................................................................... 111 EMV Reversal Types ......................................................................................................................................... 115 Transaction Batch EMV Tag Information Required ............................................................................................ 116 PNS ISO EMV Parameter Fields ....................................................................................................................... 120



EMV Parameter Download Required Indicator ................................................................................................. 121 UTF EMV Parameter Fields ............................................................................................................................... 122 Contact EMV Parameters .................................................................................................................................. 125 Contactless EMV Parameters ............................................................................................................................ 128 Credit Transaction Set ....................................................................................................................................... 132 Debit Transaction Set ........................................................................................................................................ 134 Chip Card Data Field Format ............................................................................................................................. 135 Authorization Request Message EMV Tags ...................................................................................................... 138 Sensitive Data Tags ........................................................................................................................................... 140 Authorization Response Message EMV Tags .................................................................................................... 140 Reversal Message EMV Tags ........................................................................................................................... 141 Settlement Message EMV Tags ........................................................................................................................ 143 ISO Visa Sale Request Message – Raw Data ................................................................................................... 146 ISO Visa Sale Request Message – Formatted .................................................................................................. 146 ISO Visa Sale Response Message – Raw Data ................................................................................................ 147 ISO Visa Sale Response Message – Formatted ................................................................................................ 148 ISO MasterCard Authorization Request Message – Formatted ......................................................................... 149 ISO MasterCard Authorization Response Message – Formatted ...................................................................... 150 ISO MasterCard Reversal Advice Message – Formatted .................................................................................. 151 ISO MasterCard Authorization Reversal Message – Formatted ........................................................................ 152 UTF MasterCard Retail Sale Request Message – Raw Data ............................................................................ 153 UTF MasterCard Retail Sale Request Message – Formatted ............................................................................ 153 UTF MasterCard Retail Sale Response Message – Raw Data .......................................................................... 155 UTF MasterCard Retail Sale Response Message – Formatted ......................................................................... 155 UTF Visa Retail Sale Request Message – Raw Data ........................................................................................ 157 UTF Visa Retail Sale Request Message – Formatted ....................................................................................... 157 UTF Visa Retail Sale Response Message – Raw Data ..................................................................................... 159 UTF Visa Retail Sale Response Message – Formatted ..................................................................................... 159 UTF Visa Reversal Advice Message – Raw Data .............................................................................................. 161 UTF Visa Reversal Advice Message – Formatted ............................................................................................. 161 Stratus Online 7.4 MasterCard Authorization Message – Raw Data ................................................................. 163 Stratus Online 7.4 MasterCard Authorization Message – Formatted ................................................................. 163 EMV Receipt Information ................................................................................................................................... 165 Merchant and Cardholder Receipt Requirements .............................................................................................. 166 EMV Contact & Contactless Data Elements – Sorted by Element Name .......................................................... 187 Basic ATR for T=0 Cards Only .......................................................................................................................... 203 Basic ATR for T=1 Cards Only .......................................................................................................................... 203 Application Interchange Profile (Tag 82) – Byte 1 .............................................................................................. 204 Application Interchange Profile (Tag 82) – Byte 2 .............................................................................................. 204



Application Priority Indicator (Tag 87) – Byte 1 .................................................................................................. 205 Application Usage Control (Tag 9F07) – Byte 1................................................................................................. 206 Application Usage Control (Tag 9F07) – Byte 2................................................................................................. 206 Cardholder Verification Rule – Byte 1 ................................................................................................................ 207 Cardholder Verification Rule – Byte 2 ................................................................................................................ 207 Cardholder Verification Method Results (Tag 9F34) – Byte 1 ............................................................................ 208 Cardholder Verification Method Results (Tag 9F34) – Byte 2 ............................................................................ 208 Cardholder Verification Method Results (Tag 9F34) – Byte 3 ............................................................................ 208 Card Verification Results – Byte 1 ..................................................................................................................... 209 Card Verification Results – Byte 2 ..................................................................................................................... 209 Card Verification Results – Byte 3 ..................................................................................................................... 209 Card Verification Results – Byte 4 ..................................................................................................................... 210 Card Verification Results – Byte 5 ..................................................................................................................... 210 Cryptogram Information Data (Tag 9F27) .......................................................................................................... 211 Terminal Capabilities (Tag 9F33) – Byte 1......................................................................................................... 212 Terminal Capabilities (Tag 9F33) – Byte 2......................................................................................................... 212 Terminal Capabilities (Tag 9F33) – Byte 3......................................................................................................... 212 Additional Terminal Capabilities (Tag 9F40) – Byte 1 ........................................................................................ 213 Additional Terminal Capabilities (Tag 9F40) – Byte 2 ........................................................................................ 213 Additional Terminal Capabilities (Tag 9F40) – Byte 3 ........................................................................................ 213 Additional Terminal Capabilities (Tag 9F40) – Byte 4 ........................................................................................ 214 Additional Terminal Capabilities (Tag 9F40) – Byte 5 ........................................................................................ 214 Terminal Verification Results (Tag 95) – Byte 1 (Offline Data Authentication) ................................................... 215

Terminal Verification Results (Tag 95) – Byte 2 (Processing Restrictions) ........................................................ 215 Terminal Verification Results (Tag 95) – Byte 3 (Cardholder Verification) ......................................................... 215 Terminal Verification Results (Tag 95) – Byte 4 (Terminal Risk Management) .................................................. 216 Terminal Verification Results (Tag 95) – Byte 5 (Transaction Completion)........................................................ 216 Transaction Status Indicator (Tag 9B) – Byte 1 ................................................................................................. 217 Transaction Status Indicator (Tag 9B) – Byte 2 ................................................................................................. 217 APPLICATION BLOCK Command Values......................................................................................................... 219 APPLICATION UNBLOCK Command Values ................................................................................................... 220 CARD BLOCK Command Values ...................................................................................................................... 221 EXTERNAL AUTHENTICATE Command Values .............................................................................................. 222 EXTERNAL AUTHENTICATE Response Codes ............................................................................................... 222 GENERATE AC Command Values .................................................................................................................... 223 GENERATE AC Reference Control Parameter ................................................................................................. 223 Coding of Cryptogram Information Data ............................................................................................................ 224 GET CHALLENGE Command Values ............................................................................................................... 225 GET DATA Command Values ........................................................................................................................... 226



GET PROCESSING OPTIONS Command Values ............................................................................................ 227 INTERNAL AUTHENTICATE Command Values ............................................................................................... 228 PIN CHANGE/UNBLOCK Command Values ..................................................................................................... 229 READ RECORD Command Values ................................................................................................................... 230 READ RECORD Reference Control Parameter ................................................................................................. 230 SELECT Command Values ............................................................................................................................... 231 SELECT Reference Control Parameter (P1) ..................................................................................................... 231 SELECT Command Options Parameter (P2)..................................................................................................... 231 SELECT Response Message Data Field (FCI) of the PSE ................................................................................ 231 SELECT Response Message Data Field (FCI) of the DDF................................................................................ 232 SELECT Response Message Data Field (FCI) of the ADF ................................................................................ 232 VERIFY Command Values ................................................................................................................................ 234 VERIFY Reference Data (P2) ............................................................................................................................ 234 EMV Response Codes (SW1 SW2) ................................................................................................................... 235 Certification Parameters – Amex Credit ............................................................................................................. 239 Certification Parameters – Debit Network Alliance Debit ................................................................................... 240 Certification Parameters – Discover .................................................................................................................. 241 Certification Parameters – Interac Debit ............................................................................................................ 242 Certification Parameters – JCB Credit ............................................................................................................... 243 Certification Parameters – MasterCard Credit ................................................................................................... 244 Certification Parameters – MasterCard Debit .................................................................................................... 245 Certification Parameters – Visa Credit ............................................................................................................... 246 Certification Parameters – China UnionPay ....................................................................................................... 248 Certification Parameters – China UnionPay (cont) ............................................................................................ 249 Glossary of Terms & Acronyms ......................................................................................................................... 251 Interac Account Selection Prompting ................................................................................................................. 271 “Canadian” Application Selection Flag (Tag DF62) ............................................................................................ 274 Application Selection Flag (Tag DF62) – Byte 2 Interpretation .......................................................................... 275 Application Selection Scenarios ......................................................................................................................... 275 Canadian Debit Transaction Set ........................................................................................................................ 277

EMV Implementation Guide Change Log


Change Log The change control table includes the following columns:

Revision – Version number for this release of the specification. Date – Date this Revision was released for integration. By Whom – The author(s) of the edits for this Revision. Description – A description of the edits made in this Revision. ID – Chase Paymentech issue ID used for internal tracking purposes.

Version Date Description Author

1.0 July 2015

Initial guide development and publication B2

2.0 October 2015

Along with content clarification and formatting changes, the following significant changes have been made:

PIN CVM is not mandatory

PIN Bypass is strongly recommended

Offline authorizations are not supported

Fallback processing has been clarified

Tip handling has been clarified to include tip adjustments

Receipt requirements have been updated

Report requirements have been updated

Chase Paymentech

2.1 11/4/16 Section 6.4 Fallback Processing – complete re-write. Chase Paymentech



Version Date Description Author

2.2 1/19/17 “Quick Hits Release” • Quick Chip section added (6.1.3)

• Amount confirm screen clarification

• Removal of Stand-In Processing section (formerly 6.16)

• Corrected AAC decline in Contactless Transaction Flowchart (5.3.1)

• Updated and clarified various Cashback content and requirements (6.1.1)

• Added “debit on EMV POS must be EMV debit” requirement

• Updates regarding floor limits in the parameter download file

• Amount Other update in Canadian Processing

• Added ICC Solutions Test Suite Bundle in certification tools section

• AID tables updated

• Changed references from “BIN” to “IIN”

• Discover contactless values added (section 14)

• Removed all references to Chase Paymentech Test Module (CPTM)

• Misc. formatting, style and reference errors corrected

o Replaced old org and role references with new/current Technical Implementation org and roles

o Corrected list numbering errors

o Corrected page jump hyperlink errors

o Replaced B2 style Change Log with new CTI standard format

o Corrected spelling and grammatical errors

Chase Paymentech

2.3 3/23/17 • Added new section 6.11.1 to help clarify EMV CVM processing requirements and expectations.

• Deleted RQ00306 Completion POS Entry Mode must match Pre-Authorization. It was an incorrect Chase Paymentech specific requirement. Also, it is a redundant requirement that is correctly defined in the DES Supplemental Guide. (Spec Inquiry #61)

Chase Merchant Services

2.4 11/17/17 • Updated to include China UnionPay (CUP) as a new Method of Payment (MOP) throughout document.

Chase Merchant Services




EMV Implementation Guide Introduction


1. Introduction

1.1 Implementation Guide Overview This document is the Chase Paymentech EMV Implementation Guide specific to Point of Sale environments. The information that follows encompasses the Chase Paymentech ISO, UTF and Stratus host environments, which will generically be referred to as the “Chase host” or “Chase Paymentech host” throughout the document.

This document provides guidelines for developing a Chase Paymentech EMV POS Solution:

Terminal Configurations

Chase Paymentech Development Process and Certification Process

EMV Transaction Flow

Chase Paymentech EMV Best Practices

Chase Paymentech EMV Requirements

Host Message EMV Considerations

Receipt and Report Guidelines

This document also includes EMV reference material that could be useful during the development and certification process:

EMV Tag Descriptions

EMV AID Lists

EMV Parameter Configuration

Certificate of Authority Public Key (CAPK) File Format

1.2 EMV Terminal Configurations There are several possible EMV 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 PIN Pad which provides the EMV and contactless functionality. The smartcard reader, PIN entry capability and EMV kernel all reside within the external PIN Pad. There are three supported integrated configurations each of which are detailed in following sections.

Standalone solutions consist of a POS terminal that utilizes a PIN Pad to provide the EMV and contactless functionality. The smartcard reader, PIN entry capability and EMV kernel all reside within the PIN Pad. All standalone solutions must adhere to PCI requirements and require a full EMV certification. There are two supported standalone solutions described later in this section.

Within this document all EMV and contactless configurations are generically referred to as an “EMV POS Solution”.



1.2.1 Fully Integrated ECR Solution In Fully Integrated mode the ECR application controls the transaction, provides the Chase Paymentech host interface and stores the authorization data. The ECR interfaces with an external PIN Pad for card entry (swipe / tap / insert) and EMV kernel functionality. The ECR builds the Chase Paymentech host authorization message and parses the Chase Paymentech response message. This solution provides the most control over 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 – also see Safetech Encryption page 31)

• An EMV certification is required for the complete solution



For Fully Integrated implementations the ECR is within PCI scope (if not using Safetech Encryption and Safetech Tokenization) as the ECR can see non-encrypted card data. An EMV certification of the complete solution is required.

1.2.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 PIN Pad for card entry (swipe / insert / tap) and EMV kernel functionality. The PIN Pad also builds the Chase Paymentech host authorization message and parses the Chase Paymentech response message. However, 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 it does not build the host messages.

• 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 – also see Safetech Encryption page 31)

• An EMV certification is required for the complete system

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 Chase Paymentech hosts as the ECR application can remain consistent and only the PIN Pad logic would need to differ.



For Partially Integrated implementations the ECR is within PCI scope (if not using Safetech Encryption and Safetech Tokenization) as the ECR can see non-encrypted card data. An EMV certification of the complete solution is required.

1.2.3 Semi-Integrated ECR Solution In Semi-Integrated mode the ECR interfaces with a PIN Pad (or terminal) for EMV functionality. The PIN Pad also provides the Chase Paymentech host interface and stores the authorization data. This solution eliminates much of the ECR development as the ECR does not build the host authorization message. The ECR initiates the transaction and utilizes the external PIN Pad to provide the Chase Paymentech host interface, to store the authorization data, for card entry (swipe / insert / tap) and to provide EMV kernel functionality.

• 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 PIN Pad contains the full



payment application

In Semi-Integrated mode the PIN Pad 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 PIN Pad, meaning that host and EMV development would not need to be replicated on each type of ECR supported.

For Semi-Integrated implementations the ECR is not within PCI scope as the transaction is controlled by the external PIN Pad and the ECR does not see cardholder data. An EMV certification of the complete solution is not required as the PIN Pad contains the complete payment application. The PIN Pad requires a full EMV certification.

Semi-Integrated ECR

ECR Application

EMV POS Application

External PINPad

PIN Entry Device

ICC Reader EMV Kernel

HostStore Auth Data

Contactless Kernel

Amex ExpressPay

Discover D-PAS

MasterCard PayPass

Visa payWave

Magnetic Stripe ReaderMagstripe

Host Communication

POSTransaction

Chase Paymentech Host

ECR Interface



1.2.4 Standalone POS Solution (Internal PINPad) In this mode a single standalone POS terminal is used that includes an internal PIN Pad. The POS terminal contains the POS application and utilizes the EMV kernel residing in the internal PIN Pad to provide EMV functionality.

This is often the simplest and most cost effective EMV POS Solution.

Standalone internal PIN Pad implementations are within PCI scope (if not using Safetech Encryption and Safetech Tokenization). An EMV certification of the complete solution is required.



1.2.5 Standalone POS Solution (External PINPad) In this mode a standalone POS terminal controls the transaction, provides the Chase Paymentech host interface and stores the authorization batch data. The POS terminal interfaces with an external PIN Pad 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 add EMV functionality by simply adding an EMV certified PIN Pad.

Standalone external PIN Pad implementations are within PCI scope and an EMV certification of the complete solution is required.



1.3 Safetech Encryption Safetech Encryption is a point-to-point encryption (P2PE) technology that protects the primary account number (PAN) on a payment card from the moment of capture at the point of sale (POS) until it reaches the Chase Paymentech host, without requiring the customer to process, transmit or store unprotected card account data.

Using Safetech Encryption may reduce or eliminate PCI requirements as your EMV POS Solution does not see unencrypted card data. Please contact your Account Representative for more information.

1.4 Safetech Tokenization Safetech Tokenization provides cardholder data security by returning a token in the transaction response message. By returning tokens to merchants, no cardholder data needs to be passed in subsequent transactions as the token serves as a proxy for the original account number. Merchants can also use tokens in lieu of clear card numbers in their internal systems as well.

Using Safetech Tokenization may reduce or eliminate PCI requirements as your EMV POS Solution does not see unencrypted card data. Please contact your Account Representative for more information.

1.5 EMV and Contactless Solution Components All EMV POS Solutions must have the following components:

An EMV capable PIN Pad that is:

EMV Level 1 and Level 2 type approved PCI PTS approved MasterCard TQM (Terminal Quality Management) labeled Chase Paymentech approved (i.e. can be injected by Chase Paymentech or an authorized

provider, and the PIN Pad application has been approved for use by Chase Paymentech)

A receipt printer (if an attended device)

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 page 239

The ability to download Certificate of Authority (CA) Public Key (CAPK) information. The CA Public Key file cannot be hardcoded as it will change. For more information on downloading CAPK information, see page 119.

1.6 Chase Paymentech Supported Configurations The U.S. payment industry is migrating to EMV. Chase Paymentech, along with industry payment partners are committed to this migration. All existing non-EMV applications, at some point, should be upgraded to support EMV.

The migration to EMV is expected to take a considerable amount of time. Cards with a magnetic stripe will continue to be issued and used for the foreseeable future. Therefore, all EMV POS Solutions must continue to support magstripe transactions.



BP 00101 Contactless should be supported Chase Paymentech recommends that all EMV POS Solutions support contactless transactions.

00101 All EMV POS Solutions must support MSR transactions

Chase Paymentech requires that the EMV POS Solution includes support for magstripe only cards and fallback magstripe transactions.

00102 Debit on chip enabled EMV POS Solutions must support EMV and MSR debit

It is optional for clients/merchants to accept debit. Chase Paymentech requires that if debit will be accepted on chip enabled EMV POS Solutions, those devices must be capable of supporting EMV PIN debit and magstripe PIN debit.

The EMV architecture supports several configuration modes for EMV POS Solutions. Currently, Chase Paymentech is an Online-Only acquirer which means that all transactions must go online for authorization.

The following table defines the EMV configuration modes and for each mode identifies whether it is supported by the Chase Paymentech host.

EMV Configuration Modes

Mode Usage Chase Host

Online Only Transactions are always sent to the host for authorization.

Floor Limit processing is not used. Yes

Online with Offline Capabilities

Transactions can be locally authorized, based on Risk Management processing or sent to the Host for authorization.

The EMV Floor Limit must be set to zero; therefore, the EMV POS Solution will behave like an Online-Only solution.

Yes

Offline Only

Transactions are always locally approved.

Used for attended and unattended, cardholder activated devices.

No



Chase Paymentech is an Online-Only acquirer. However, during certification EMV POS Solutions may be required to perform and pass non-zero EMV Floor Limit (Offline) certification test cases. This is to ensure the EMV POS Solution is capable of supporting a non-zero EMV floor limit in the future.

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

EMV Configuration Modes – By Terminal Type

Environment Operation Modes Terminal

Type Chase Host

Attended

Financial Institutions

Online Only 11 Yes Offline with Online Capabilities 12 Yes Offline Only 13 No

Merchant Online Only 21 Yes Offline with Online Capabilities 22 Yes Offline Only 23 No1

Unattended

Financial Institutions

Online Only 14 Yes Offline with Online Capabilities 15 Yes Offline Only 16 No

Merchant Online Only 24 Yes Offline with Online Capabilities 25 Yes Offline Only 26 No1

1 Speak to your Implementation Manager if Offline-Only processing is required.

The EMV 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.

1.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”), which enables merchants and 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”).

U.S. Common Debit AIDs Brand Scheme Common Debit AID

MasterCard US Maestro A0000000042203

Visa Visa Common Debit A0000000980840

Discover Debit A0000001524010

DNA DNA Shared A0000006200620



China UnionPay Debit A000000333010108

In addition to MasterCard and Visa, the Debit Network Alliance (DNA) and other individual debit networks will offer their own U.S. Debit AIDs that will only reside on non-Visa and non-MasterCard branded cards.

Visa, MasterCard, and Discover 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 AID (either the standard Visa AID, the standard Discover AID, the standard MasterCard AID or the Maestro AID).

If a Global AID (Visa, MasterCard, Global Maestro, or Discover) is used to initiate the chip transaction, the transaction will be routed via the appropriate Visa, MasterCard, or Discover credit network. The network used is based on the card IIN.

If a U.S. Common Debit AID is used to initiate a chip transaction, the resulting transaction may also be routed via unaffiliated networks that have executed the necessary access agreement with Visa, MasterCard, or Discover.

For both contact and contactless transactions, EMV POS Solutions should use the standard Application Selection process described for EMV transactions. The merchant may filter the resulting 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 may wish 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 the following two data elements identifies the AID as relating to a U.S. Debit or prepaid program:

Issuer Country Code (Tag 5F55) – Two alpha digits 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, Table 4 below):

a. 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.

b. 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, Table 4 below):

a. 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.

b. For contact transactions the EMV POS Solution should present the remaining Candidate



List choices to the cardholder in accordance with Final Selection processing. c. 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, Table 4 below):

a. 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 of those AIDs from the Candidate List - leaving only one AID for each IIN.

b. For contact transactions, the EMV POS Solution should present the remaining Candidate List choices to the cardholder in accordance with Final Selection processing.

c. 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 multiple U.S. Common Debit AIDs present (Scenario Four, Table 4 below):

a. The EMV POS Solution should assume that each U.S. Common AID relates to a different underlying funding account.

b. The EMV POS Solution should eliminate either of the following from the Candidate List: i. All of the U.S. Common Debit AIDs ii. All of the Global Debit AIDs

c. For contact transactions, the EMV POS Solution should present the remaining Candidate List choices to the cardholder in accordance with Final Selection processing.

d. For contactless transactions, the EMV POS Solution should automatically select the AID in the Candidate List with the highest Application Priority Indicator (Tag 87).

U.S. Common Debit Scenarios

Scenario AID Country Code

Tag 5F55 IIN

Tag 42 Candidate List Choice for the

Merchant One Card accesses single debit funding account

Global Debit AID

A00000000X1010 US XX0000

Merchant may decide which AID to select based on their preferred routing choice: Global AID – may only be routed to

the associated card brand’s credit network (any supported CVM may be used)

U.S. Common Debit AID – may be routed to any of the supported debit networks (any supported CVM may be used)

U.S. Common Debit AID A00000000XXXXX US XX0000

Two Combo card accessing a credit account and a single funding debit account

Global Credit AID A00000000X1010AA01 N/A N/A

Global Credit AID will remain in the Candidate List for cardholder selection as described in EMV.





Tag 5F55 IIN


Merchant

Global Debit AID

A00000000X1010AA02 US XX0000

Merchant should decide on either the Global AID or the U.S. Common Debit AID based on their preferred routing choice: Global AID – may only be routed to


U.S. Common Debit AID – may be routed to any of the supported debit networks (any supported CVM may be used)

U.S. Common Debit AID A00000000XXXXX US XX0000

Three Card accesses two debit funding accounts – Accounts have different IINs

Global Debit AID 1

A00000000X1010AA01 US XX0000

Merchant should choose either the Global AID 1 or the U.S. Common Debit AID 1 based on their preferred routing choice: Global AID 1 – may only be routed to


U.S. Common Debit AID 1 – may be routed to any of the supported debit networks (any supported CVM may be used)

U.S. Common Debit AID 1 A00000000XXXXXAA01 US XX0000

Global Debit AID 2

A00000000X1010AA02 US XY9999

Merchant should choose either the Global AID 2 or the U.S. Common Debit AID 2 based on their preferred routing choice: Global AID 2 – may only be routed to


U.S. Common Debit AID 2 – may be routed to any of the supported debit networks (any supported CVM may be used)

U.S. Common Debit AID 2 A00000000XXXXXAA02 US XY9999

Four Card accesses two debit funding accounts – Accounts have same IINs

Global Debit AID 1

A00000000X1010AA01 US XX0000 Merchant should choose either Global AID 1 and Global AID 2 or U.S. Common Debit AID 1 and U.S. Common Debit AID 2 based on their preferred routing choice: Global AID 1 and 2 – may only be

routed to the associated card brand’s credit network (any supported CVM may be used)

U.S. Common Debit AID 1 and 2 – may be routed to any of the supported debit networks (any

U.S. Common Debit AID 1 A00000000XXXXXAA01 US XX0000

Global Debit AID 2

A00000000X1010AA02 US XX0000





Tag 5F55 IIN


Merchant U.S. Common

Debit AID 2 A00000000XXXXXAA02 US XX0000

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 the Credit / Debit section and U.S. Debit Processing section (see page 89).

BP 00102 U.S. Debit selection method should be configurable Chase Paymentech recommends that the U.S. Debit identification method be configurable to support changes in merchant and acquirer preferences. Both methods will be tested during certification.

BP 00103 Select U.S. Common Debit AIDs when present on card Chase Paymentech recommends that when both U.S. Common Debit and Global AIDs are present for the same funding account, that the Global AIDs be removed from the Candidate List. Using the U.S. Common Debit AID provides the maximum flexibility in debit routing options.

BP 00104 Allow Cardholder to select AID when more than one funding source If more than one funding source is present, the cardholder must be able to choose which account to pay from.

EMV Implementation Guide Development Process


2. Development Process

2.1 Development and Certification Please be aware that implementing an EMV POS Solution is a much more difficult and time consuming process than implementing a traditional magstripe solution. EMV solutions are more complex and are subject to an extended and more rigorous certification process which, in addition to the standard Chase Paymentech certification, includes certification by the card brands and possibly a pilot.

IT IS IMPORTANT THAT YOUR DEVELOPMENT TIMELINES REFLECT THE DEVELOPMENT COMPLEXITY AND THE ADDITIONAL TIME REQUIRED TO COMPLETE THE CERTIFICATION PROCESS.

The table below outlines the development and certification components that will be used when developing an EMV POS Solution with Chase Paymentech. The information that follows encompasses the Sales, Account Executive and Relationship Management team, which will be generically referred to as the “Account Representative” and the Technical Implementation team which will be generically referred to as the “Implementation Manager”.

Development and Certification Components

1. Client Consulting Discovery

Chase will perform a “Discovery” process to define and understand the client’s project business requirements. The team will interface with the client management and business decision makers to determine:

Project timing High level project requirements Connectivity requirements Security implementations Funding windows

In some cases this step may involve more technical discussions on some issues.

2. Contract The Account Representative will initiate the client setup process:

Review contracts (new and existing) o A contract will be put into place for the client development project. o If the client already has a Chase contract, it may be modified or amended to

include the new development. Engage Risk and Credit Add products and features

Assign a Case Number (this number must be referenced on all correspondence).

3. Client Setup The Account Representative will engage the boarding team to configure the client’s business parameters:

Merchant information Products and services Methods of Payment (MOPs) EMV Parameters



4. Implementation Managers The Implementation Manager works with the client to finalize:

Connectivity requirements Products and Services Payment processing options:

o EMV field guidance o Technical Specifications o Special processing requirements

5. Technical Profile Questionnaire

The Technical Profile Questionnaire (TPQ) is completed by the client, with the assistance of their Implementation Manager. The TPQ is used to ensure that the client is implementing a valid, supportable EMV configuration that meets Chase Paymentech requirements.

The TPQ defines EMV information related to the:

Terminal Type Terminal Capabilities Additional Terminal Capabilities PIN Pad Certification Letters

For more information on the Technical Profile Questionnaire see page 41.

6. Technical Implementations The Technical Implementations team will:

Provide detailed test scripts Configure host connectivity Configure test credentials Generate Proof of Readiness (POR) test cases and email them to the client

7. EMV Training EMV projects are considerably more complex than traditional magstripe applications. For this reason, Chase Paymentech highly recommends that first time EMV developers receive EMV training before beginning an EMV development project.

For more information on EMV training, see page 43.

8. EMV Certification Test Tools

The Collis Merchant Test Suite (MTS) contains all required card brand certification test cases, as well as a number of Chase Paymentech specific EMV test cases that must be completed during EMV certification.

For more information about the Collis Merchant Test Suite, see page 49.

Chase Paymentech has also partnered with ICC Solutions to offer the ICC Test Suite Bundles for Certification tools as an option to the Collis MTS for thorough and complete EMV testing and certification.

For more information about ICC Solutions’ Test Suite Bundles for Certification, see page 53.



9. Development and Testing The client develops their EMV POS Solution based on the project information provided to Chase Paymentech and performs standalone testing.

During this process the client can submit their questions into the support email box.

If during development the project goes dormant and Chase has no communication with the client, the project may be closed. If that occurs, the project will have to be reopened by the client when ready to proceed.

After 2 weeks with no client communication, the Chase Implementation Manager will send an email warning that the project may be closed

After 4 weeks with no client communication, the project will be closed until the client is ready to resume

If the project is closed, the client will need to contact their Account Representative to have the project reopened

10. Proof of Readiness (POR) Testing

Proof of Readiness (POR) testing must be performed by the client and reviewed by Chase Paymentech before any formal certification can begin.

The purpose of POR testing is to ensure that the client has host connectivity and is ready to begin self-testing and certification.

POR testing is a simple process that involves running a few magstripe transactions, one EMV transaction for each card brand supported and a single contactless transaction.

At the completion of POR testing Chase Paymentech will review the results. If there are any issues, they will have to be corrected by the client and POR testing will have to be redone.

For more information on POR testing see page 44.

11. Certification Test Case Document

Chase will create a test case document that must be completed by the client to Class “B” certify the EMV POS Solution. This document will include:

Class “B” magstripe certification test cases Chase specific EMV test cases

12. Class “B” Certification The client will execute the magstripe and EMV test cases defined in the Certification Test Case document:

Magstripe test cases

When all test cases have been completed, Chase Paymentech will review the test case results and create an issues document. If there are any issues, the errors will have to be corrected and the failed test cases must be rerun.

Note: This process generally requires multiple passes over a 2-3 month period.

13. Class “B” Certification Letter

Once all Class “B” magstripe and EMV test cases have been passed, Chase Paymentech will issue a Class “B” Certification letter.

At this point, the client may begin to deploy the solution as a magstripe solution only. The deployed solution may include End-to-End Encryption and Tokenization.

Note: The deployed solution cannot include any EMV functionality.



14. EMV Card Brand Certification

EMV Card Brand Certification must be performed once for each combination card brand / kernel configuration supported.

During EMV Card Brand Certification:

The client is responsible for running the card brand EMV test cases Chase Paymentech is responsible for supplying the test case requirements (e.g.

M-TIP) and submitting the test case results for card brand approval

To reduce the time required to complete this process, Chase staggers the start of each EMV Card Brand Certification and provides parallel processing of all brand certifications. While the client is running the next certification test cases, Chase Paymentech will be submitting previously completed card brand test case results for card brand approval.

If any test cases fail, your Implementation Manager will determine, based on the type and complexity of the error, whether only the current brand test cases must be rerun or if all test cases for all card brands must be rerun.

Note: The time required to complete EMV Card Brand Certification varies depending on the number of card brands supported and the complexity of the EMV POS Solution. It is a lengthy process, so be sure the EMV POS Solution is ready before beginning this process. Failed certifications will greatly increase the time required to complete.

15. EMV Certification Letter Once all EMV card brands have been certified, EMV Card Brand Certification is complete and Chase Paymentech will issue an EMV certification letter.

The EMV POS Solution may now be deployed as an EMV capable solution.

16. Pilot Chase Paymentech does not require a pilot before beginning a rollout of an EMV POS Solution; however:

Chase Paymentech does recommend that the rollout begin slowly with a few test locations so results can be analyzed by the client before beginning a full rollout

In some cases MasterCard will require that an End-To-End-Demonstration (ETED) be performed at a pilot location before a full rollout may begin

For more information on pilot and ETED requirements see page 48.

17. Rollout A full rollout of the EMV POS Solution may begin.

Note: EMV certifications are not permanent. For information on an EMV POS Solution recertification requirements, see page 48.

2.2 Technical Profile Questionnaire (TPQ) To ensure that the client is implementing a valid, supportable EMV configuration that meets Chase Paymentech requirements, the client in conjunction with their Implementation Manager, will complete a Technical Profile Questionnaire (TPQ). The information on this form is obtained from the device and PIN Pad information provided by the client.

The TPQ allows Chase Paymentech an opportunity to review the proposed implementation, validate that the configuration is currently supported and document the configuration, including all associated certification documents, for future reference.

To complete the TPQ, the client must supply information relating to the PIN Pad and PIN Pad kernel being implemented. This includes but is not limited to:

PIN Pad Terminal Brand/Model



PIN Pad Software API (Example VeriFone – XPI 5.32)

EMV Co Level I and II Approvals

TQM Label or Action Plan

PCI – PED Approval

Kernel Terminal Capabilities

Kernel Additional Terminal Capabilities

00201 Notify Chase of all PIN Pad kernel configurations being used

Chase Paymentech requires the client to notify their Account Representative of all PIN Pad kernel configurations being used by the EMV POS Solution as all kernel configurations must be documented in the TPQ.

The client will be required to provide the following PIN Pad certification letters for the PIN Pad model and kernel configuration being used. These letters can generally be obtained from the PIN Pad vendor.

PIN Pad and PIN Pad kernel certifications do expire. It is the developer’s responsibility to ensure that the PIN Pad and PIN Pad kernel are current and that none of the certification letters have expired. The following table identifies the required PIN Pad certification letters and their duration.

PIN Pad Certification Letters Letters 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 (one per supported brand)

Typically 2 years after date of approval

MasterCard TQM Letter or TQM Label N/A

PCI PTS Certification Letter

PCI PTS certification expiry is dependent on the PTS version the device was certified under.

Note: PTS 1.0 devices are no longer supported

00202 Provide PIN Pad Certification Letters of Approval (LOA)

Chase Paymentech requires the client to provide all certification Letters of Approval (LOA) for the EMV PIN Pad being implemented. Failure to do this will cause the project to be delayed until the required certification letters have been provided.



00203 EMV certification letters must be current

Chase Paymentech requires that all EMV certification letters be current and not about to expire. An EMV POS Solution will not be certified if any of the certification letters is scheduled to expire within 90 days of the date of certification.

2.3 Training It is important that everyone involved in the development and testing of an EMV project receive EMV training before beginning. Although this is not considered mandatory by Chase Paymentech, it is highly recommended as EMV and contactless solutions are considerably more complex than traditional magstripe solutions. Beginning EMV projects without proper training will lead to extended project timelines and certification issues that could require extensive time and redevelopment to resolve. Chase Paymentech cannot provide low level EMV, contactless or PIN Pad kernel integration support. It is the developer’s responsibility to obtain this information from other third party sources.

There are several external sources where EMV training may be obtained:

http://www.b2ps.com/education

https://www.ul-ts.com/catalog/elearning

www.emv-connection.com

http://www.smartcardalliance.org http://www.acquirer.com

http://www.clear2pay.com

http://www.fime.com

http://www.galitt.us

http://www.iccsolutions.co.uk/emv-in-the-usa/4591022695

Please check with your Implementation Manager for other possible EMV and contactless training options.

BP 00201 Obtain EMV Training before beginning an EMV project Chase Paymentech highly recommends that everyone involved in EMV development and testing receive EMV training prior to beginning an EMV project.

2.4 Technical Support The intent of this document is to provide developers who are familiar with EMV, the necessary information to be self-supporting while developing their EMV POS Solution. Your Implementation Manager can provide some additional EMV implementation information and recommendations. However, Chase Paymentech cannot provide low level EMV, contactless or PIN Pad kernel integration support. It is the developer’s responsibility to obtain this information from other sources:

EMV requirements and guidelines can be obtained from the EMVCo website www.emvco.com

http://www.iccsolutions.co.uk/emv-in-the-usa/4591022695



For PIN Pad kernel technical support, refer to the PIN Pad vendor’s documentation or contact the PIN Pad vendor to inquire about the availability of PIN Pad integration training and support

Chase Paymentech does not recommend or endorse any specific external support service.

2.5 Development Host Connection Information During development and testing it will be necessary to send online EMV transactions to the Chase Paymentech host (or host simulator). Your Implementation Manager will provide the required development configuration information (Terminal IDs, Merchant IDs, IP address (URL), port, etc.).

2.6 Certification Process Chase Paymentech requires a full certification of all EMV, contactless and traditional magstripe transactions before an EMV POS Solution will be certified for rollout as an EMV solution. The certification duration is dependent on the complexity of the EMV POS Solution and the quality of the implementation. It is important to note that if the EMV POS Solution fails certification at any point, the entire certification process may have to be repeated.

EMV certification is an extensive multi-step process which involves completing Chase Paymentech Class “B” certification, which includes both magstripe and EMV testing, and then completing EMV card brand certification for each card brand and kernel configuration supported.

Class “B” certification validates message format adherence to the Chase Paymentech host.

EMV card brand certification validates EMV functionality adherence to the card brands.

EMV certification is extremely rigorous and far more time consuming than a traditional magstripe certification. This additional complexity should be accounted for in your project implementation timelines.

The certification process cannot begin until development and self-testing has been completed. The certification process is performed as per the steps outlined below. All steps must be completed before certification is considered complete.

Chase Paymentech does not charge for certifications. However, any certification fee dictated by the card brands will be passed directly on to the client.



Certification Process

1. Proof of Readiness Testing

Before formal certification can begin, Proof of Readiness (POR) testing must be performed by the client and reviewed by Chase Paymentech, to ensure the EMV POS Solution is ready for certification.

POR testing requires the client to perform:

Several magstripe transactions for specific dollar amounts One EMV contact transaction for each of the card brands supported

(e.g. Visa, MasterCard, Amex, etc.) A single contactless transaction (if supported)

At the completion of POR testing Chase Paymentech will review the results. If there are any issues, the issues will have to be corrected and POR testing must be rerun.

Note: All POR transactions should be approved by the Chase host.

2. Class “B” Magstripe Certification

The client will execute the Class “B” magstripe test cases as defined in the Chase Test Case document.

Tests are run using the Certify platform If assistance is required email your Implementation Manager Test results should be populated into the test case document

When testing is complete, Chase Paymentech will review the certification results and create an issues document. If there are any issues, the errors will need to be corrected and the failed test cases must be rerun.

Note: This process generally requires multiple passes over a 2-3 month period.



Certification Process

3. Card Brand Certification Card Brand Certification must be performed once for each card brand / kernel configuration combination supported.

Once pre-certification has been successfully completed, final card brand certification can be run while connected to the Chase host and the card brand simulators.

The card brand certification process is performed as follows:

1. Chase Paymentech will provide test case documents (e.g. M-TIP) identifying the test cases that must be performed for a specific card brand

The client will execute the required test cases for the specific card brand and submit the results to Chase Paymentech including: o card logs o completed questionnaires o receipts

Chase Paymentech will review the results to ensure they are complete and submit them to the appropriate card brand for approval

To decrease the time required to complete this process, the EMV Card Brand Certification steps will be performed one card brand at a time with the client and Chase Paymentech working in parallel.

The client submits card brand results immediately after completion of each card brand, before beginning testing of the next card brand

While the client tests the next card brand, Chase Paymentech will review and submit the completed card brand test case results for card brand approval

If any test cases fail, Chase Paymentech will determine, based on the type and complexity of the error, whether only the current brand test cases must be rerun or if all test cases for all card brands must be rerun.

For more information on Card Brand Certification see page 47.

If you require additional information, contact your Implementation Manager.

BP 00202 Budget adequate time for certification EMV POS Solutions require considerably more time to certify than traditional magstripe solutions. Please ensure that you budget at least 6-8 weeks to complete Pre-Certification and 3-5 weeks to complete Final (Card Brand) Certification. This time period will vary based on the complexity of the implementation and the number of card brands and kernel configurations being certified.

00204 EMV Test Tool is required for Card Brand Certification

Chase Paymentech requires that an approved EMV Test Tool be used to perform Card Brand Certification. For information about the recommended EMV Test Tools, see page 49.



2.7 Card Brand Certification Card Brand Certification is the final step in the EMV certification process and is performed while connected to EMV Card Brand Simulators. A separate Card Brand Certification must be performed for every card brand and PIN Pad kernel combination being used by the EMV POS Solution.

The following Card Brand Certification Test Suites must be used when performing card brand certification.

Card Brand Certification Test Suites Card Brand EMV Test Suite Contactless Test Suite Amex / JCB* (*JCB processes via American Express in Canada.)

AEIPS ExpressPay

Debit Network Alliance Contact your Certification Analyst n/a

Discover/Diners/JCB* (*JCB processes via Discover in the US.)

D-PAS E2E D-PAS Contactless E2E

China UnionPay D-PAS E2E D-PAS Contactless E2E

Interac Terminal Certification Reader Terminal Interoperability and Confidence Test

MasterCard M-TIP M-TIP

Visa ADVT CDET qVSDC (only required for contactless-only implementations)

Per the Visa Inc. U.S. EMV Chip Terminal Testing Requirements, qVSDC DM test results are no longer required in Visa CCRT when a dual-interface integrated terminal is selected.

The qVSDC DM testing is still required for a standalone contactless-only device.

00205 qVSDC certification is required for contactless-only Visa EMV POS Solutions

Visa requires that a qVSDC certification be completed when implementing a Visa contactless-only EMV POS Solution.

This is in addition to the Visa CDET certification that must be completed for all contactless implementations.

As each Card Brand Certification is completed, the results, including all card logs and receipts must be forwarded to Chase Paymentech. Chase Paymentech will review the results and forward them to the card brands for formal analysis and approval. If multiple PIN Pad kernel configurations are being certified, the certification timeframe will increase accordingly.

If any EMV Card Brand Certification test case fails, EMV Card Brand Certification must be redone for the failing card brand. Depending on the severity and type of failure, it is possible that another entire EMV Card Brand Certification will be required for all card brands supported. Chase Paymentech will



determine what must be done based on the severity of the failure and the complexity of the changes required to correct.

BP 00207 Be ready before attempting Card Brand Certification Card Brand Certification is a time consuming and costly process. If your EMV POS Solution fails Card Brand Certification, it will have to be redone which means additional time and cost. So do not perform Card Brand Certification until you are confident that your EMV POS Solution will pass all test cases.

00206 Multiple certifications required if multiple kernel configurations supported

The card brands require that a card brand certification be performed for every kernel configuration supported. Therefore, multiple certifications may be required for each card brand. One for each kernel configuration supported.

2.8 Pilot Chase Paymentech does not require a pilot before beginning a full rollout of an EMV POS Solution. However, due to the complexity of EMV applications it is recommended that a short pilot be run at a few locations before beginning a rollout. This will help ensure that the EMV POS Solution is properly configured for production and that EMV transactions are being processed and settled properly.

In some situations MasterCard will require that the EMV POS Solution undergo End-to-End Demonstration (ETED) testing. When required:

ETED testing is performed by a MasterCard representative at a pilot site

MasterCard will perform a few live online transactions while connected to the production Chase Paymentech host

MasterCard will analyze the messages and transaction results

When ETED testing is required, it must be completed to MasterCard’s satisfaction before a full rollout may begin.

BP 00203 Production validation prior to rollout is strongly encouraged Although not required Chase Paymentech recommends that a single device or store be tested in production before a rollout, or even a pilot, begins.

2.9 Post Rollout Re-Certification EMV certifications are not permanent. There are a number of reasons that a deployed EMV POS Solution may need to be updated and re-certified after it has been rolled out:

1. Changes to an EMV parameter – other than a parameter that is downloaded from the Chase Paymentech host

2. Expiring certifications (PIN Pad hardware or kernel) – check with your Account



Representative to determine if re-certification is required

3. Inter-operability issues

4. Payment application changes

When a situation occurs that affects your EMV POS Solution, it will be necessary to make the required changes and to re-certify your solution. How quickly this must be completed depends on the reason re-certification is required:

A date may be set by which time the EMV POS Solution must be re-certified using updated EMVCo and/or card brand approved hardware or software

It may be possible to continue using the EMV POS Solution as is, until the next scheduled client modifications are made and a re-certification is required

It is the client’s responsibility to know when EMV certifications are expiring (see page 42).

BP 00204 Respond quickly when notified of re-certification requirements Chase Paymentech recommends that the client act quickly when an EMV POS Solution must be re-certified to meet new regulatory requirements. When regulatory changes are mandated, many deployed solutions will require re-certification and the certification queue will fill quickly.

00207 Keep track of the EMV POS Solution certification status

Chase Paymentech requires the client to ensure that their deployed EMV POS Solutions are using supported EMVCo and/or card brand certified hardware and software. The EMV Migration Forum http://www.emv-connection.com/emv-migration-forum/ has relevant information that can assist in this effort.

00208 Chase Paymentech must be notified of changes to EMV functionality

Chase Paymentech requires the client to notify their Account Representative before a change is made to a deployed EMV POS Solution that will alter the EMV payment functionality.

2.10 EMV Contact and Contactless Test Tools Chase Paymentech mandates that an EMV Test Tool be used to perform EMV Card Brand Certification. These tools simplify the certification process and provide all reports and card logs required by the card brands when submitting certification test case results.

To complete Chase Paymentech certification the EMV Test Tool used must support:

The EMV Card Brand Certification test cases for all card brands supported by the EMV POS Solution

Chase Paymentech currently supports the following EMV test tools for EMV and contactless certification.



Chase Paymentech Approved EMV Test Tools Company Test Tool Description

UL (Underwriters Laboratories) (formerly known as Collis)

Collis Merchant Test Suite (MTS)

For details see Collis Merchant Test Suite below.

ICC Solutions Test Suite Bundles for Certification (TS)

For details see ICC Solutions Test Suite Bundles for Certification (ICC TS) below.

BP 00205 The Collis MTS or ICC Solutions TS are recommended Chase Paymentech recommends that the Collis Merchant Test Suite (MTS) or the ICC Solutions Test Suite Bundles for Certification (TS) be purchased for use during card brand certification and when executing the Chase Paymentech EMV test cases.

By using the Collis MTS or ICC TS, a client can reduce their overall certification timeframe based on the enhanced validation provided.



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 includes all the hardware and software required for contact and contactless EMV certifications and comes in a robust carrying case so the complete MTS kit can be easily taken to wherever you need it.

The Collis MTS 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 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 PIN Pads.

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 testing

License Dongle – Secures access to the software and allows the Collis MTS to be run on any PC

All required accessories such as cables, probes, power supplies etc. 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 Collis BTT software produces reports that can be used for local examination and documentation of the test cases. The reports can also be easily saved and exchanged with other parties involved in the certification process.

Using the Collis 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 E2E • Diners E2E • JCB TCI • UnionPay UCA • Interac Flash™

Collis is constantly updating their products to add functionality, improve usability and to keep pace with ever changing card brand certification requirements. The Collis product roadmap can be found at http://b2ps.com/brochures/collis_roadmap.pdf. More information about the Collis MTS can be found at http://www.b2ps.com/acquirer_merchant.html or email [email protected].

mailto:[email protected]



2.10.1 ICC Solutions Test Suite Bundles for Certification (ICC TS) ICC Solutions Ltd is a global leader in the provision of EMV test tools and services offering the complete set of qualified test suites for card brand accreditation of contact and contactless EMV terminals, (American Express, Discover, Interac, JCB, MasterCard, Visa), in addition to EMVCo type approval. ICC TS stand-alone contact and contactless certification device test tools are used worldwide by Payment Networks, Terminal and Card Vendors, Test Laboratories, Acquirer / Processors and Merchants / Retailers enabling development, quality, assurance and regression testing in addition to formal merchant certifications. The ICC Solutions contact and contactless test suite bundles are qualified by all payment brands to perform EMV Chip Terminal level 3 brand accreditation tests for certification with Chase Paymentech.

What’s included in the Test Suite Bundle?

• Test Software for ALL Brands

• USB Key for activation

• Dual Interface Card Reader

−



ICCSimTMat uses standard EMV chip card form factor ICCSim cards onto which each individual test case is downloaded via the ICCSim card reader prior to running the test. The ICCSim card is also used to capture the transaction log without any need for complex box of electronics, restrictive card paddle, expensive spy hardware or huge deck of cards and is also suitable for creating your own test cards.

Operation of ICCSimTMat to perform EMV chip terminal accreditation testing is very straightforward and can be performed by a non EMV expert. Operational assistance is also included in the purchase price which is provided remotely by phone or email which includes product training conducted over the internet using WebEx available upon request. A user guide with clear step–by–step

instructions is available after installation.

The Test Suite Bundle comprises a single software licence featuring full set of the latest test cases for each ICCSimTMat test suite, 1x Dual I/F ICCSim Card Reader / Writer, full set of ICCSim Cards for each ICCSimTMat test suite plus USB Licence key enabling access to the test suites.

Support & Maintenance (S&M) is included in the purchase price for 12 months which entitles you to receive ICCSimTMat test tool upgrades and test script release updates free of charge for each test suite purchased as well as access to technical support. The Test Suite Bundle software can be installed on multiple computers, however it is only the one having the USB licence key connected at any point in time that is able to perform / run the tests. It is possible to run different test suites in parallel by purchasing additional USB licence keys priced along with additional ICCSim readers. Additional ICCSim cards are available suitable for creating your own test card packs for regression / QA testing or training / confidence testing etc. ICC Solutions Ltd provides powerful, efficient and simple solutions through automated Testing Tools for ease of use for the client.

Further information about ICC Solutions’ products and services can be found at: www.iccsolutions.co.uk/our-products or Email: [email protected]



2.11 Integrated Solution Validation A full certification is not required when certifying solutions that integrate a pre-certified middleware product or when implementing a semi-integrated solution.

In these cases, Chase Paymentech may only require a confidence test be performed. This could be done by running a small number of Chase Paymentech selected card brand test cases (interop test) using an EMV Test Tool (i.e. Collis Merchant Test Suite) or by purchasing a set of test cards and running test cases that will be supplied.

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 EMV test cards are provided by the following vendors:

• B2 Payment Solutions

(http://www.b2ps.com/B2_test_card_sets.html)

• ICC Solutions

(http://www.iccsolutions.co.uk/chip-card-confidence-packs-us/4590572123)

http://www.iccsolutions.co.uk/chip-card-confidence-packs-us/4590572123

EMV Implementation Guide EMV Overview


3. EMV Overview

3.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 personalizes 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 much more difficult than with existing magstripe cards

Lost & stolen cards are more difficult to use as EMV cards can require a PIN to be used

Transactions can be approved offline (if the issuer personalizes the card parameters to allow it)

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

3.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

Request the transaction be sent to the issuer host for online 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. Sale). Even if a transaction is sent for online authorization, the issuer authorization decision returned must be sent to the card for a final authorization decision by the card.

Chase Paymentech is an Online-Only acquirer. This means that all transactions initiated by deployed EMV POS Solutions must go online for authorization.

During certification, Chase Paymentech may run additional non-zero floor limit test cases in special scenarios such as client request.

00301 Transactions must go online for issuer authorization

Chase Payment requires that all transactions go online to the Chase Paymentech host for issuer authorization.



3.3 EMV Transaction Steps 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

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

For information relating to the Full EMV and Partial EMV transaction flows see page 65.

Full EMV vs. Partial EMV Transaction Steps

EMV Transaction Step Full EMV

Partial EMV Comment

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 1st Generate AC Y Y1 Includes Terminal Action Analysis and Card Action Analysis Online Processing Y N

External Authenticate Y N

Some cards do not support this step as they include the Issuer Authentication Data as part of 2nd Generate AC (in CDOL 2 (Tag 8D) – when the AIP is set to support Issuer Authentication (Tag 82 Byte-1 bit-3)

Script Processing (Tag 71) Y N Executes Tag 71 script commands

2nd Generate AC Y N

Some cards include the Issuer Authentication Data as part of the 2nd Generate AC (in CDOL 2 (Tag 8D) - when the AIP is not set to support Issuer Authentication (Tag 82 Byte-1 bit-3))

Script Processing (Tag 72) Y N Executes Tag 72 script commands Card Removal Prompt Y Y

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

3.3.1 EMV Credit Transaction Set The following table lists the EMV credit transactions supported by Chase Paymentech and indicates how each transaction should utilize the EMV chip. Refer to the appropriate host message specification for the most complete list of supported transactions.



EMV Credit Transaction Set

Transaction Transaction

Authorized By EMV

Chip Usage Store EMV

Cryptogram1 Sale / Authorization Issuer / Card Full Required Prior / Forced Sale Call Center Partial2 N/A Pre-Authorization Issuer / Card Full Required3 Completion/Deposit POS Partial or None4 Required5 Authorization Reversal POS Partial or None6 N/A Return POS Partial N/A Balance Inquiry Issuer Full Optional Account Verification Issuer Partial or None N/A Deferred Authorization Issuer Full Required

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.

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

EMV Debit Transaction Set

Transaction Transaction

Authorized By EMV

Chip Usage Store EMV

Cryptogram1 Sale Issuer / Chip Full Required Sale with Cashback Issuer / Chip Full Required Return Issuer / Chip Full Optional Reversal Issuer / Chip Partial or None Optional Balance Inquiry Issuer / Chip Full Optional

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

3.4 Transaction Processing The following sections identify EMV transaction specific processing rules.

3.4.1 Sale Transactions Credit and debit Sale transactions should be processed as Full EMV transactions. Prior Sale and Forced Sale transactions should be processed as Partial EMV transactions.



BP 00301 Prior/Forced Sale transactions should be Partial EMV transactions Chase Paymentech recommends that the Prior/Forced Sale transaction be a Partial EMV transaction and only use the chip to obtain the chip Track 2 data. Once obtained the chip interaction should be terminated by requesting a decline (AAC) at the 1st Generate AC. The transaction should then continue as a magstripe transaction.

00302 Sale transactions must be Full EMV transactions

Chase Paymentech requires that all credit and debit Sale transactions be processed as Full EMV transactions and that the cryptogram requested at the 2nd Generate AC be based on the issuer authorization decision.

3.4.2 Authorization / Pre-Authorization Transactions Authorization and Pre-Authorization transactions are Full EMV transactions performed with the cardholder present.

If a PIN is entered, the receipt should not include a signature line

If a PIN is not entered, the receipt must contain a signature line

00303 Auth and Pre-Auth transactions must be processed as Full EMV transactions

Chase Paymentech requires that Authorization and Pre-Authorization transactions be Full EMV transactions and that the cryptogram requested at the 2nd Generate AC be based on the issuer authorization decision.

3.4.3 Incremental Authorization 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.

00304 Incremental Authorizations must be sent as keyed transactions

Chase Paymentech requires that Incremental Authorizations be sent to the host in keyed format and do not include any other card data obtained from the original Authorization transaction.

3.4.4 Completions Completions (including tip adjustments) are Partial EMV transactions that use EMV data from the original Pre-Authorization transaction. The cardholder is not required to present their card when the Completion is performed.



00305 Completions without cardholder present require Pre-Authorization chip data

Chase Paymentech requires that the Completion request message includes all chip data from the original Pre-Authorization transaction including the final Pre-Authorization cryptogram.

3.4.5 Return The Return transaction processing differs depending on the type of return being performed.

00307 Credit Returns must be Partial EMV transactions

Chase Paymentech requires that Credit Refund transactions be Partial EMV transactions and request a decline (AAC) at the 1st Generate AC to terminate the card interaction.

00308 Debit Returns must be Full EMV transactions

Chase Paymentech requires that Debit Return transactions be Full EMV online transactions and that the cryptogram requested at the 2nd Generate AC be based on the issuer authorization decision. See your Account Representative before implementing this function.

3.4.6 Balance Inquiry Transactions Balance Inquiry transactions are Full EMV transactions as they perform all EMV steps up to and including Issuer Script processing. Because Balance Inquiry transactions do not transfer funds they should not be reversed if the card declines the transaction at the 2nd Generate AC.

3.4.7 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 to determine 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 only include NO CVM. The kernel configuration to be used would be selected at the beginning of each transaction by the EMV POS Solution based on the transaction amount.

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



00309 CVM processing must be performed for QSR transactions Chase Paymentech requires that Cardholder Verification Method (CVM) processing be performed for EMV QSR transactions. If the CVM selected is ‘Signature’, a receipt must be printed regardless of the transaction amount.

If printing a receipt is not desired, using a selectable NO CVM only kernel configuration will allow the transaction to be performed as a NO CVM transaction which does not require a receipt to be printed.

EMV Implementation Guide Contactless Overview


4. Contactless Overview

4.1 Contactless Benefits For the consumer and merchant there are three benefits to contactless transactions:

1. Efficiency – There is no need for consumer verification (i.e. no PIN required) for low value payments. It becomes ‘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 when 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 the technology.

4.2 MSD vs EMV Grade When implementing contactless technology, two current environments must be supported for global acceptance:

MSD – Contactless magstripe cards use the Track 2 with dynamic data embedded within the track data

EMV – contactless or dual interface cards that use EMV technology (i.e. cryptograms) to secure the transaction

4.3 Contactless Card Schemes A number of contactless card schemes have been implemented by the card brands.

Contactless Card Schemes Scheme Specifications Amex ExpressPay ExpressPay 3.0 Card Specification Discover D-PAS D-PAS Contactless Specifications 1.0 Interac Interac Flash 1.4

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

Visa payWave VCPS 2.1 + Updates List

EMV Implementation Guide Contactless Overview


4.4 EMV Contactless Transaction Sets The following table lists the EMV Contactless Form Factor (CFF) transactions supported by Chase Paymentech and indicates how the transaction should utilize the EMV chip.

EMV Contactless Transaction Set

Transaction Transaction Authorized By

CFF Used Interactively

Store EMV Cryptogram1

Online Sale Issuer / CFF2 Yes3 Mandatory Pre-Authorization Issuer / CFF Yes Mandatory4 Completion Terminal No Mandatory5 Authorization Reversal Issuer / Terminal No N/A Return Issuer Yes N/A Reversal Issuer / Terminal No N/A Balance Inquiry Issuer Yes Optional

1 This column indicates whether the final EMV cryptogram (TC – Transaction Certificate) should be stored with an approved transaction. 2 Contactless Form Factor (CFF). 3 The CFF is used interactively only up until the 1st Generate AC or until the magstripe data has been received by the reader. 4 The final EMV cryptogram is required when sending offline approved transactions to the host. After the authorization, the cryptogram can be handled in the same manner as Online Sale transactions. 5 The original Pre-Authorization EMV cryptogram is required when performing the Pre-Authorization Completion.

EMV Implementation Guide EMV Transaction Flow


5. EMV Transaction Flow

5.1 Full EMV Transaction Flow The following table outlines a generic overview of the steps required to perform a Full EMV transaction (e.g. Sale). For Full EMV transactions the card makes the final authorization decision.

Full EMV Transaction Flow

1. Tender Initialization

Transaction type is selected and the transaction amount is determined including:

Tax Tip Cashback

2. Card Entry

Card is inserted an chip initialization is performed:

Validate ATR (Answer To Reset) Set Language Set Terminal Country Code (USA=”840”) Set Transaction Amount (see page 77)

3. Application Selection

A Candidate List is created of AIDs that are mutually supported by both the card and the EMV POS Solution:

U.S. Common Debit selection processing (see page 89) If the Candidate List is empty, fallback processing is performed If only one mutually supported AID is found:

o AID is automatically selected o Cardholder is required to confirm selection if Application Priority Indicator

- Cardholder Approval Indicator (Tag 87 bit-8) is set to ‘1’ If more than one mutually supported AID is found:

o If a U.S. Common Debit AID is present, it may be selected o Otherwise, the cardholder should be prompted to select the application

or, if prompting is not possible, the highest priority AID should be auto-selected

4. Read Data Records

EMV POS Solution reads data records for the AID selected:

Card PAN (Tag 5A) Expiry Date (Tag 5F24) Track 2 Equivalent Data (Tag 57) Card Validation Checks (IIN, MOD10, etc.) Etc.

Card Validation Checks (IIN, MOD10, etc.) are performed on data read.




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 the Issuer Application Data (Tag 9F10), and are transmitted to the issuer as part of the authorization request:

Processing Restrictions o Application Effective Date o Application Expiry Date o Application Version Number o Card Usage Control (based on the AUC Tag 9F07)

Offline Card Authentication (SDA / DDA / CDA) Terminal Risk Management Cardholder Verification (PIN / Signature / NO CVM)

6. Apply Card Discounts

The final transaction amount is determined by applying applicable card discounts based on the type of card presented (if any).

For contact transactions there are two options. The EMV POS Solution can either:

Update Transaction Amount (Tag 9F02) with the new (lower) transaction amount and send the updated tag value to the PIN Pad kernel before the 1st Generate AC.

Leave Transaction Amount (Tag 9F02) set to the original (higher) transaction amount and continue to the 1st Generate AC using the original amount. This means that the amount stored in Transaction Amount (Tag 9F02) will differ from the final transaction amount.

For contactless transactions Transaction Amount (Tag 9F02) cannot be changed during the transaction. This means that the amount stored in Transaction Amount (Tag 9F02) will differ from the final transaction amount.

7. 1st Generate AC

The EMV POS Solution requests an authorization from the chip. The EMV chip will respond with an Application Cryptogram:

Offline Approved (returns TC) Offline Declined (returns AAC) Online Authorization Required (returns ARQC)

8. Host Authorization

If online authorization is required, the EMV POS Solution sends the transaction to the Chase Paymentech host for authorization.

If unable to go online, the EMV POS Solution may, based on Floor Limits, locally approve or decline the transaction.

Note: EMV U.S. Debit transactions cannot be approved locally.

9. Transaction Completion Processing

The authorization decision is sent to the EMV chip for final processing including.

Issuer Authentication Data (Tag 91) Issuer Scripts (Tag 71 or Tag 72) Authorization Response Code (Tag 8A) – from the issuer or locally generated

Completion processing includes:

External Authenticate (if an ARPC is returned by the issuer and the AIP Issuer Authentication (Tag 82 Byte-1 bit-3) flag is enabled

Issuer Script Processing (if any) 2nd Generate AC (to determine the final transaction disposition – Approved

(TC) or Declined (AAC))




10. Host Reversal Processing (if required)

If the issuer approves the transaction and any of the following occurred during Transaction Completion Processing (previous step), a reversal must be sent to the Chase Paymentech host:

PIN Pad not available Card removed prior to the completion of processing Chip Malfunction (except MasterCard – see requirement below) Chip declines the transaction (2nd Generate AC) Cardholder cancels transaction

11. 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 (see page 173).

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

13. Receipt Printing

The EMV transaction receipt is printed. The receipt must contain the following EMV information:

Card Entry Indicator (to indicate how cardholder data was obtained) Application Preferred Name (or Application Label) Signature Line (if the CVM was Signature or NO CVM) “Verified by PIN” (if the CVM was one of the PIN types) AID – Application Identifier TVR – Terminal Verification Results TSI – Transaction Status Indicator AC – Application Cryptogram ARC – Application Response Cryptogram

14. Transaction Upload If the transaction was locally authorized it is sent to the host prior to or at settlement.

00501 MasterCard requires issuer decision be used for 2nd Generate AC chip error

MasterCard requires that the transaction be approved or declined based on the issuer authorization decision returned in the host response when a chip malfunction occurs at the 2nd Generate AC.



5.1.1 Full EMV Transaction Flowchart

EMV Card Inserted

Set EMV Parameters

OK

Cancel Transaction No

Transaction Successful

EMV POS SolutionCalculates Total

Transaction Amount

Processas non-EMV Transaction

1st Generate ACApproved

TCReturned

Application SelectionBuild AID Candidate List

DeclinedAAC

Returned

Host Authorization

Build host message and send to host and receive response

Go OnlineARQC Returned

Completion Processing• Set ARC Tag 8A• Issuer Authentication• Issuer Script Processing• 2nd Generate AC

Fallback Allowed? Failed

Yes

EMV Chip Authorization

Decision?

Print “Declined”

Receipt

DeclinedAAC

Returned

Print “Approved”

Receipt

Store Transaction

EMV data is saved with transaction

ApprovedTC

Returned

Transaction Unsuccessful

Is IIN Tag 42 present in

Candidate List?Yes

Perform U.S. Common Debit AID Processing

Update Candidate ListOK

Final AID SelectionOK

No

Read Data Records

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

OK

Failed

Failed

Generate Reversal

Was Host Response an

Approval?

Error

Yes

No



5.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 Void). 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.

Partial EMV Transaction Flow

1. Tender Initialization

Transaction type is selected and the base transaction amount is determined including:

Tax Tip Cashback

Note: For transactions such as Reversals or Completions this information may be read from the transaction batch.

2. Card Insertion

Card is inserted and chip initialization is performed:

Validate ATR (Answer To Reset) Set Language Set Terminal Country Code (USA=”840”) Set Transaction Amount (see page 77)

3. Application Selection

A Candidate List is created of AIDs that are mutually supported by both the chip and the EMV POS Solution:

U.S. Common Debit selection processing (see page 89) If the Candidate List is empty, MSR Fallback processing is performed If only one mutually supported AID is found:

o AID is automatically selected o Cardholder is required to confirm selection if Application Priority Indicator

- Cardholder Approval Indicator (Tag 87 bit-8) is set to ‘1’ If more than one mutually supported AID is found:

o If a U.S. Common Debit AID is present, it may be selected o Otherwise, the cardholder should be prompted to select the application

or, if prompting is not possible, the highest priority AID should be auto-selected

4. Read Data Records

EMV POS Solution reads data records for the AID selected:

Card PAN (Tag 5A) Expiry Date (Tag 5F24) Track 2 Equivalent Data (Tag 57) Card Validation Checks (IIN, MOD10, etc.) Etc.

5. Apply Card Discounts

The final transaction amount is determined by applying applicable card discounts based on the type of card presented (if any).

Note: Transaction Amount (Tag 9F02) does not need to be updated as Partial EMV transactions request an AAC at the 1st Generate AC to terminate the card usage.

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

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



Partial EMV Transaction Flow

8. Store Transaction Results The transaction results are stored in the transaction database.

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

10. Receipt Printing

The EMV transaction receipt should be printed. The receipt must contain the following EMV information:

Chip Indicator (to indicate cardholder data was read from a chip) AID Application Preferred Name (or Application Label) Signature Line (always)

11. Transaction Upload If the transaction was locally authorized it is sent to the host prior to or at settlement.



5.2.1 Partial EMV Transaction Flowchart

EMV Card Inserted

Set EMV Parameters

OK

Cancel Transaction No

Transaction Successful

EMV POS SolutionCalculates Total

Transaction Amount

Processas non-EMV Transaction

Force AAC1st Generate AC

Application SelectionBuild AID Candidate List

Fallback Allowed? Failed

Yes

Print “Approved”

Receipt

Store Transaction

No EMV data is stored

Candidate List has IIN Tag 42

Present?Yes

Perform U.S. Common Debit AID Processing to

Update Candidate List

OK

Final AID Selection

OK

No

Read Data Records

OK

Failed

Failed



5.3 Contactless Transaction Flow When a contactless form factor is presented, the Contactless kernel will select a mutually supported application, read the data contained in the contactless form factor for the selected application and make a transaction decision to:

Not accept contactless at all (if amount is over the contactless transaction limit)

Approve offline

Decline offline

Request an online authorization

The contactless form factor 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 limits and conditions, to the payment application for further processing.



5.3.1 Contactless Transaction Flowchart



Contactless

Read Error? Retry?

App/Card Blocked?

Exceed Contactless

Limit?

Exceed CVM Limit?

MSD Card?

ARQC Generated?

AAC Generated?

TC Generated?

Use Contact/MSR

Transaction Completed


Not Accepted Use Contact/MSR

Contactless

Not Accepted

Not Accepted Use Contact/MSR


Transaction Not Completed

Host Authorization

Set CVM Required

N

N

N

N

N

N

N

N

Y N

Y

Y

Y

Y

Y

Y Approved

Y (Declined)

Y

Declined

EMV Implementation Guide Chip Processing Guidelines


6. Chip Processing Guidelines

The transaction process implemented will differ based on the PIN Pad selected and the API the PIN Pad supports. The processes described in this document are based on a “typical” PIN Pad API which combines several EMV transaction steps into a single API command and supports modification of the Transaction Amount (Tag 9F02) during transaction processing.

Please refer to the PIN Pad vendor specifications for specific details on implementing PIN Pad API commands.

6.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 that may be added. Tip may be included as part of the full transaction amount or adjusted later. Refer to page 78 for more information on Tip Processing.

If card discounts are applicable based on the card presented, then card discounting must occur after card entry and before the 1st Generate AC.

Suggested amount confirmation display text can be found on page 97.

For contactless transactions, Transaction Amount (Tag 9F02) cannot be changed once the card has been presented.

00601 Total transaction amount must be known before the card is presented

Chase Paymentech requires that all EMV POS Solutions complete the tendering process before prompting for card entry.

00602 Transaction Amount (Tag 9F02) must be set to total transaction amount

For single message transactions it is required that the Transaction Amount (Tag 9F02) be set to the total transaction amount (including cashback and tip) before performing the 1st Generate AC. It is optional whether applicable card discounts (if any) are applied to Transaction Amount (Tag 9F02).

00603 Cardholder amount confirmation is optional

Chase Paymentech does not require that cardholder confirm transaction amount. However, if a confirmation amount screen is presented and cardholder does not confirm the transaction amount, then the transaction must be cancelled.



6.1.1 Cashback Transaction Flow Cashback is supported for online debit and Discover transactions only, and the cashback amount must be known prior to card entry. Therefore, after card entry completes, the EMV POS Solution must ensure that a debit or Discover card was presented. If not, the transaction must be cancelled.

For cashback transactions:

1. The cardholder must confirm the cashback amount prior to card entry

2. Transaction Amount (Tag 9F02) must include the cashback amount

3. Other Amount (Tag 9F03) must be set to the cashback amount

4. For MasterCard transactions, transaction Type (Tag 9C) must be set to ‘09’ indicating a “Purchase with Cashback”

For Canadian Interac cashback requirements see Appendix “A” (page 278).

00604 Transaction Amount (Tag 9F02) must include the cashback amount

Chase Paymentech requires that the cashback amount be included in the full transaction amount stored in Transaction Amount (Tag 9F02).

00605 Other Amount (Tag 9F03) must contain the cashback amount

Chase Paymentech requires that the cashback amount be stored in Other Amount (Tag 9F03) and sent to the host as part of the authorization message.

00606 Cashback is only allowed for online debit and Discover AIDs

Chase Paymentech requires that the transaction be cancelled if a cashback amount is entered and the AID selected for the transaction is not a debit or Discover AID.

00607 Transaction Type must be set to ‘09’ for MasterCard debit cashback

transactions It is required that Transaction Type (Tag 9C) be set to ‘09’ for all MasterCard purchase with cashback transactions.

6.1.2 Tip Transaction Flow Historically, transactions with tipping are completed by performing a Pre-Authorization for the pre-tip amount and a Completion for the final amount (pre-tip amount + tip amount). This practice does not need to change for an EMV transaction.

There are three basic acceptance models for card-based tip and gratuity payments, all of which are supported by Chase Paymentech.

Tip Allowance – Merchant authorizes for ticket amount only, excluding tip. A receipt is printed for the cardholder to sign and optionally add a tip. Settlement may be adjusted to include the tip.

Counter – When paying at the counter, the cardholder may add a tip to their total as part of the checkout process. The merchant authorizes for the total amount of the transaction including



both the ticket amount, tip amount and cashback amount.

Table Pay – Using portable or wireless terminal solutions the merchant can bring a payment device directly to the cardholder allowing them the opportunity to add a tip amount. The merchant authorizes for the ticket amount plus the actual amount of the tip. This is recommended if the terminal supports PIN CVM.

BP 00601 If PIN CVM is supported use Table Pay for restaurant tipping For environments such as Restaurants that require tipping it is recommended that a Pay at Table solution be implemented so that an EMV purchase transaction with a tip prompt and PIN entry can be used.

6.1.3 Faster EMV (Quick Chip / M/Chip Fast) Transaction Flow “Faster EMV” is term generally used to describe the optimized online-only EMV transaction processing solutions announced separately by American Express (Quick Chip), China UnionPay (Quick Chip), Discover (Quick Chip), MasterCard (M/Chip Fast), and Visa (Quick Chip). These solutions retain the counterfeit protection security features of EMV, while removing issuer validation dependencies which can negatively impact the cardholder perception of transaction time.

The Faster EMV solutions are ideal for multi-lane retailers that support a “swipe-ahead” option for magnetic swipe transactions as the Faster EMV transaction flow will provide a similar user experience. The swipe-ahead option allows a customer to swipe their card prior to the final amount of the transaction being known.

Faster EMV transactions have the following characteristics:

1. Use a pre-determined amount to obtain the 1st Generate AC ARQC prior to determination of the final transaction amount (check with your Chase Implementation Manager for a recommended amount or we recommend using the merchant’s average ticket amount rounded up to the nearest $10). After this all the standard EMV transaction steps are performed including application selection, cardholder verification, processing restrictions, terminal risk management and offline data authentication.

2. The chip card transaction is finalized by requesting a termination cryptogram (AAC) at the 2nd Gen AC with tag 8A set to “Z3” (Unable to go Online), to complete EMV processing. This must be done before the authorization response is received by the terminal. We recommend this be done before the authorization message is sent to the host.

3. The chip card can now be removed from the reader.

4. Once the final transaction amount is known, the terminal authorizes the transaction online. The authorization request message should have:

• the final transaction amount in the Transaction Amount field

• the original pre-determined amount in tag 9F02 of the EMV Data Field (also known as DE55 or Field 55).

The issuer host uses the Transaction Amount to score and approve the transaction and tag 9F02 for cryptogram validation.

5. The terminal indicates whether the transaction was approved or declined according to the issuer’s decision, and captures the cardholder’s signature when necessary.

6. If the host response message contains EMV tags (8A, 71, 72 and/or 91) these can be ignored.

7. Refer to the diagram on the following page for the visual transaction flow.



Prompt to insert card

No

Start Faster EMV Trans

Faster EMVTransaction Flow

Is Final Amount Known?

Auth Amount =Pre-determined Amount

Auth Amount =Final Amount

Yes

Standard EMV ProcessingApplication SelectionGet Processing OptionsRead RecordsProcessing RestrictionsOffline Data AuthenticationCardholder VerificationTerminal Risk Management1st Generate AC

Card Returns ARQC?

Standard EMV Processing

No

Retain chip data for authorization request

Set Authorization Code (Tag 8A) = Z3 (Unable to Go Online )Perform 2nd Generate AC

Prompt to Remove Card

Send Authorization Request Auth Amount = Final Amount

Tag 9F02 = Amount Authorized

Issuer Response = Approve /DeclineDisplay appropriate message

Yes



6.2 EMV Transaction Initiation EMV transaction initiation prepares the PIN Pad to accept an EMV card. A prompt must be displayed on the PIN Pad 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 see page 84.

6.2.1 Service Code Processing When processing the magstripe information, the EMV POS Solution must read and act upon the contents of 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.

Chip Service Codes Processing Service Code Card Type Action Required

2xx International Use Chip

6xx Domestic Use Chip

00608 Service Code ‘2xx’ and ‘6xx’ must force a chip usage

The card brands require that when a card is swiped with Service Code ‘2xx’ or ‘6xx’ (indicating that a chip is present), that the EMV POS Solution prompts for the card to be inserted into the chip reader.

6.3 Chip Read Flow For EMV cards it is mandatory that a chip transaction be attempted before a magstripe or fallback transaction is allowed. If your EMV POS Solution accepts magstripe reads from a device other than a locally attached PIN Pad, 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 magstripe 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 96.

The following table shows the actions that should be taken when issues occur while reading card data from the chip and magstripe.



Chip Reader Actions 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

1st Generate AC Unsuccessful Fallback enabled for AID – Technical Fallback Fallback not enabled for AID – Cancel transaction

1st Generate AC Successful Proceed with EMV transaction

Magstripe Reader Actions Condition Action Read Failed Reject card – Prompt for another card Unknown IIN Reject card – Prompt for another card

EMV Service Code ‘2xx’ or ‘6xx’ If a fallback swipe – Continue with fallback If not a fallback swipe – Force chip read

Non-EMV Service Code (not ‘2xx’ or ‘6xx’) Proceed with magstripe transaction

00609 Cancel transaction if card accepted but removed before host authorization

Chase Paymentech requires that the transaction be cancelled when an EMV card is successfully read but is removed before performing the online authorization.

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

Chase Paymentech requires that the transaction be cancelled if the card is removed before the 2nd Generate AC completes. If the host approved the transaction, a reversal must also be sent to the Chase Paymentech host.

00611 Decline transaction if host declines and card removed before 2nd Gen AC

Chase Paymentech requires that the transaction be declined when a host authorization is performed and the transaction is declined by the issuer, and the card is removed before the 2nd Generate AC completes.

00612 Only one card interface may be active once a read has begun

Chase Paymentech requires that once a read has begun using one of the device interfaces (swipe, contact or contactless), all other card interfaces be deactivated (e.g. when a contact read is being performed the swipe and contactless interfaces should be deactivated).



6.3.1 Chip Read Flowchart

Chip Reader

App Blocked?SW=6283

ATR Error?

Card Blocked?SW=6A81

Empty CandidateList?

Use Mag Stripe(Technical Fallback)

Not Accepted

Use Mag Stripe(MSR Fallback)

Not Accepted

SuccessfulCommand?SW=9000

Proceed with EMV Transaction

Yes

Yes

Yes

Yes

No

No

No

Yes

Mag Stripe Reader

Good Read? No

Yes

Valid BIN?

Yes

Service Code= 2xx or 6xx?

Fallback Active? Try Chip Reader

Normal MSRTransaction

FallbackTransaction

Yes

Yes

No

No

Not AcceptedNo

Not Accepted

No

No

Execute Commands up to and including the

1st Generate AC

Use Mag Stripe(Technical Fallback)Fallback Enabled

For AID?

Transaction Terminated

No

Yes

Was Card Removed?

Transaction TerminatedYes

No



6.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-enabled device. EMV POS Solutions must accept both chip and magstripe 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 the 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 magstripe. 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 primary reasons why fallback occurs. The difference is based on where in the transaction flow it is determined that a chip transaction cannot proceed and that a magstripe transaction must be performed:

Empty Candidate List (no mutually supported AIDs)

Unable to read chip (chip or chip reader failure)

Several terms are used in the U.S. market pertaining to fallback including MSR Fallback and Technical Fallback. Using this nomenclature creates confusion therefore this section will focus on the reason for the fallback rather than on any given name. The term “Fallback” refers to any transaction where the magstripe on a chip card is used to process a transaction on a chip enabled terminal.

00613 Service Code ‘2xx’ and ‘6xx’ must be accepted for fallback card swipes

It is required when in fallback that the magnetic-stripe reader accepts a swiped EMV card and processes it as a non-chip card (i.e. as a standard magstripe card) even though the Service Code is ‘2xx’ or ‘6xx’.

00614 Fallback must be cancelled when a card is inserted at fallback card entry

It is required that while waiting for a fallback card swipe, if an EMV card is inserted or tapped, fallback processing be discontinued and the transaction be proceed as an EMV transaction.

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

It is required that when waiting for a fallback card swipe, if the swiped card does not have a ‘2xx’ or ‘6xx’ Service Code, that fallback be discontinued and the transaction be performed as a traditional magstripe transaction from a chip enabled terminal.

6.4.1 Fallback Acceptance Fallback is used when a chip enabled device is unable to read a chip card due to either a chip read failure or unsupported AID. In these cases the card information must be obtained by reading the magnetic stripe. There are several situations when Fallback occurs:

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 PIN Pad chip reader is malfunctioning



4. When Application Selection returns Empty Candidate List.

00618 Fallback transactions must be identified in the host message

Chase Paymentech requires that the proper values* be used in the host message when a swiped transaction is performed on a chip card from a chip enabled device. *Refer to the host message specification applicable to your implementation.

6.4.2 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. When any of these situations occur, another form of payment is required:

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. The card is removed prematurely – before the transaction has been completed

5. Fallback is not supported by the card brand

6. The Transaction is cancelled at any point

6.4.3 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 either insert or tap the same or a different EMV card.

BP 00602 Fallback Prompting should only be allowed for a limited time Chase Paymentech recommends that when a fallback prompt is displayed, it only be enabled for 60 seconds. After that period, if a card is swiped with an EMV Service Code (‘2xx’ or ‘6xx’), the prompt to use the chip reader should be displayed.

00619 Fallback must be cancelled when card is inserted during fallback card entry

Chase Paymentech requires that fallback processing be discontinued and the transaction proceeds as an EMV transaction, when an EMV card is inserted or tapped while waiting for a fallback card swipe.

00620 Service Code ‘2xx’ and ‘6xx’ must be accepted for fallback card swipes

It is required that when in fallback the EMV POS Solution accepts a swiped EMV card (Service Code ‘2xx’ or ‘6xx’) and processes it as a standard magstripe card.



6.4.4 Fallback Timeline Fallback is a temporary practice that may only be allowed for a limited time, after which fallback transactions may not be permitted. EMV POS Solutions must have the technical capability to allow or disallow fallback transactions by card scheme and must be able to activate/deactivate this capability based on rules established by the card brand and as subsequently directed by Chase Paymentech.

When fallback is discontinued for a card scheme, the EMV chip cards for that scheme may no longer be processed as magstripe cards. At this time, the US has not set a date by when Fallback is no longer allowed.

The Chase EMV Parameter Download includes a Fallback Flag for each card scheme (AID). For more information see page 118.

00621 Fallback Flag must be downloaded from the Chase host and used

Chase Paymentech requires that the Fallback Flag included in the Chase EMV Parameter Download be used by the EMV POS Solution.

00622 Fallback is not allowed if not supported by card scheme

It is required that fallback only be allowed 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.

6.4.5 Exception to Fallback There are exceptional circumstances where a terminal is deployed into the US market that is only partially enabled for EMV. These situations should be rare and only under a waiver facilitated by Chase Paymentech. A common example of a partially enabled terminal is one that was certified for EMV credit but continues to process PIN-Debit through magnetic stripe interface.

If a terminal has in place code that will intentionally ignore the 2XX or 6XX service code on the mag stripe and allow the transaction to be processed as mag stripe, then the terminal is considered partially enabled. In the scenario where the service code is ignored upon swiping a chip card, the terminal is considered non-chip capable for that particular transaction. When this situation occurs, the terminal must dynamically alter its capability indicator and reflect in the authorization request that it is a mag-stripe terminal.

00617 Transactions sent as swiped because EMV was not enabled must not be

sent as Fallback Chase Paymentech requires that if a terminal intentionally ignores the service code and forces a chip card to be processed using its magstripe, the host request message Data Entry Source and/or POS Entry Mode and Terminal Capability Code be set to indicate a magstripe swipe transaction from a non-chip capable terminal.



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

The Application Selection process differs slightly for Canadian Interac transaction processing. For a description of the differences see the Canadian Application Selection section in Appendix “A” page 274.

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 an 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 brand (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)

00623 Partial Selection must be supported

It is required 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 Chase Paymentech.

Application Identifiers (AID) Application Type AID (RID + PIX) RID PIX Amex Credit A00000002501 A000000025 01 ChaseNet Credit A0000000031010 A000000003 1010

Discover Credit A0000001523010 A000000152 3010 Discover US Common Debit A0000001524010 A000000152 4010 Discover Zip Credit A000000324101 A000000324 101 Debit Network Alliance (DNA) Debit A0000006200620 A000000620 0620 China UnionPay Credit A000000333010102 A000000333 010102 China UnionPay Debit A000000333010101 A000000333 010101

China UnionPay Quasi Credit Credit A000000333010103 A000000333 010103 China UnionPay US Common US Debit A000000333010108 A000000333 010108 Interac Debit A0000002771010 A000000277 1010 JCB Credit A0000000651010 A000000065 1010 MasterCard Credit Credit A0000000041010 A000000004 1010 MasterCard International Maestro Debit A0000000043060 A000000004 3060

MasterCard US Maestro Debit A0000000042203 A000000004 2203 Visa Credit Credit A0000000031010 A000000003 1010 Visa Electron Credit A0000000032010 A000000003 2010 Visa Interlink Debit A0000000033010 A000000003 3010 Visa U.S. Common Debit Debit A0000000980840 A000000098 0840

The ChaseNet card is defined as a Visa card and therefore uses the Visa RID (AID and PIX).

00624 Accept valid AIDs only Chase Paymentech requires that EMV POS Solutions only accept AIDs allowed based on the Chase Paymentech merchant agreement. Any AID that has not been approved for use should be rejected by the EMV POS Solution without being sent to the Chase Paymentech host for authorization.

6.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



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 by 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.

00625 AID list must be loaded into the kernel at kernel initialization

It is required that as part of kernel initialization, all AIDs supported by the EMV POS Solution be loaded into the kernel for use during Application Selection.

Implicit Application Selection (PSE) To perform Implicit Application selection, the kernel reads the PSE from the card to obtain the list of AIDs supported by the card. 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.

Explicit Application Selection To perform Explicit Application Selection, the kernel uses the list of 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. If unsuccessful, the AID is not eligible.

6.5.2 Credit / Debit Selection and U.S. Debit Processing For traditional magstripe debit transactions, merchants chose what cardholder verification to use for the transaction. This would be either to:

1. Prompt the cardholder to enter the PIN (commonly referred to as “PIN Preferring Merchants”).

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

During certification, Chase Paymentech may test that the EMV POS Solution is capable of supporting both the “PIN Preferring” and “Credit / Debit” selection methods. Please check with your Implementation Manager to determine if this is a requirement for your implementation.



U.S. Debit Routing 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:

1. Solutions supporting U.S. Debit should have the following kernel configuration:

a. All CVM Config – Terminal Capabilities (Tag 9F33) is set to support all CVMs the merchant wishes to support (e.g. PIN, Signature, NO CVM)

2. 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).

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. If the:

a. Candidate List does not 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 required and the application can continue to Final Selection (page 93).

b. 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 the U.S. Debit section (see page 33). The next processing step depends on the number of AIDs in the Candidate List. If the:

a. Candidate List only contains one AID – Continue to step 4. b. Candidate List contains more than one AID – Perform Final Selection (page 93).

4. If the Candidate List contains only the U.S. Common Debit AID, the following should be performed based on the cardholder verification process supported by the merchant:

a. PIN Preferred Merchants – Set the Terminal Capabilities (Tag 9F33) to All CVM Config. Later during Cardholder Verification the application will prompt for a PIN.

b. Credit / Debit Button Merchants – Prompt the cardholder to select either Credit or Debit.

c. Credit Selected – In this case the transaction will be defined as a NO CVM transaction. As the transaction is over the NO CVM limit, the application should print a signature line on the receipt.

d. Debit Selected – Set the Terminal Capabilities (Tag 9F33) to the All CVM Config and



proceed to the Final Selection step (page 93).

BP 00604 When prompting use “No PIN” / “PIN” rather than “Credit” / “Debit” Chase Paymentech recommends that when using the Cardholder Selection method, the cardholder be presented a “No PIN” / “PIN” prompt rather than the traditional “Credit” / “Debit” prompt.

BP 00605 PIN Preferring and Credit / Debit selection methods should be supported Chase Paymentech recommends that EMV POS Solutions support both the “PIN Preferring” and “Credit / Debit” selections methods.



U.S. Common Debit Processing Flowchart

Chip Reader

Get Candidate List

Do any AIDs have Tags 5F55 & 42?

Compare IIN values in AIDs

Are any of the IINs the same?

Remove Global AIDs with same IIN

Yes

YesIs there more than 1 AID?

Display AID selection to cardholder to select AID

Is AID = US Common Debit AID?

Is Transaction Amount >= Debit NO CVM Limit

Set Terminal Capabilities to All CVM Config

Set Terminal Capabilities to NO CVM Config

Final Selection

No

No

Yes

Yes

Yes No

No

No



6.5.3 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 should be presented to the cardholder for selection.

When presenting Candidate List for selection, the application names may be displayed all on one screen or with one application name per screen, using navigation buttons to traverse the list (e.g. ‘Next’ and ‘Previous’). Regardless of the method used to display the Candidate List, the application names displayed are determined as follows:

1. Display Application Preferred Name (Tag 9F12) if it is stored in a character set supported by the display. This can be determined by checking 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 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 set for the AID selected (either the All CVM Config or the NO CVM Only Config). If the:

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

The kernel can now select the card AID 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.

Brand certification will test that up to five mutually supported applications can be supported in the Candidate List.

BP 00606 A default application name should be assigned for all AIDs Chase Paymentech recommends that a default application name be assigned to each supported AID. These names will be used to display and print the application name when Application Preferred Name (Tag 9F12) and Application Label (Tag 50) are not present or cannot be used.



00626 Final Selection application names must be displayed to cardholder

It is required that the list of application names displayed during Final Selection be displayed to the cardholder.

6.5.4 Cardholder Application Confirmation Cardholder Application Confirmation is only required when the Candidate List contains only one AID and the Application Priority Indicator - Cardholder Approval Indicator (Tag 87 bit-8) is set to ‘1’.

If cardholder confirmation is required, the cardholder must be prompted to confirm that the application may be used. To do this, Application Preferred Name (Tag 9F12) or Application Label (Tag 50) is displayed to the cardholder who must confirm the selection.

Cardholder Approval Indicator (Tag 87 bit-8) Value Action

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

0 The application may be used without prompting the cardholder.

00627 Transaction must be cancelled if Cardholder Application Confirmation fails

It is required that the transaction be cancelled if during Cardholder Application Confirmation the cardholder indicates that the application should not be used.

There is currently no requirement to perform Cardholder Application Confirmation at unattended EMV implementations.

6.6 Read Data Records After the AID has been selected AID card data is read from the chip. During the Read Data record processing the card data must be validated. If any of the validation checks fail, the card should be rejected and the transaction should be terminated.

When performing this validation any field padding (e.g. hex ‘F’) should be stripped before the check is performed.

00628 Application Expiration Date must match Track 2 Equivalent Data Expiry Date

It is required that the Application Expiration Date (Tag 5F24) be the same as the Expiry Date included as part of Track 2 Equivalent Data (Tag 57). If they are different the card must be rejected.



00629 Service Code must not be validated against Track 2 Equivalent Data

It is required that the Service Code (Tag 9F30) not be validated against the Service Code included as part of the Track 2 Equivalent Data (Tag 57).

6.7 Cardholder Language Selection Cardholder Language Selection is only performed if the EMV POS Solution supports more than one language. If required, it is performed after the card has been presented and the AID has been selected. Cardholder Language Selection is performed by reading 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 should be used.

If none of the languages in the Language Preference tag are supported by the EMV POS Solution, the cardholder should be prompted to select one of the EMV POS Solution 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 language should be used for cardholder display and prompting.

BP 00607 If multiple languages supported, cardholder should be prompted to select Chase Paymentech recommends that when the EMV POS Solution supports multiple languages and none of the supported languages matches a language in the Language Preference (Tag 5F2D) list, that the cardholder be prompted to choose one of the EMV POS Solution supported languages.

00630 Merchant prompts and receipts must be in default merchant language

Chase Paymentech requires that all merchant prompting and merchant receipt printing be in the merchant language even if the selected cardholder language is different.

00631 Cardholder prompts and receipts should be in selected cardholder language

Chase Paymentech requires that once selected, all cardholder prompting and cardholder receipt printing be in the selected cardholder language.

00632 If Language Preference Indictor is not present use merchant language

Chase Paymentech requires that when Language Preference Indicator (Tag 5F2D) is not present on the card, that the cardholder be prompted to select one of the languages supported by the EMV POS Solution. If only one language is supported, it may be auto selected.



6.8 Cardholder Prompting This section outlines the Chase Paymentech recommended card entry, PIN entry and amount confirmation prompting. These prompts are not mandated and should be considered as guidelines only.

6.8.1 Card Entry Prompting During the EMV transaction process there are several steps that require PIN Pad prompting to obtain cardholder confirmation or provide instructions to the cardholder. This prompting must be performed in the cardholder language, as determined by the Cardholder Language Selection process.

Chase Paymentech recommends that the following prompts be used for card entry.

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” Chip error (Technical Fallback) “Chip Error, Use Magstripe” MSR Fallback is initiated “Use Magstripe”

BP 00608 Prompt cardholder to “Leave Card Inserted” Chase Paymentech highly recommends that the prompt informing the cardholder to leave the 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 prompts such as “Do Not Remove Card”).

6.8.2 PIN Prompting Several prompts are required during PIN entry to inform the cardholder of the PIN entry status.

Recommended PIN Entry Prompting Prompt Reason Recommended Prompt Text PIN entry required “Enter PIN” Invalid/incorrect PIN entered “Invalid PIN” Only one PIN try remaining before card is blocked “Last PIN Try” PIN tries exceeded and card may be blocked “PIN Tries Exceeded” Correct PIN entered “PIN Accepted”



6.8.3 Amount Confirmation Prompting Chase Paymentech does not require transaction amount confirmation. However, if amount confirmation is presented and there are multiple amounts requiring confirmation, the amount confirmations should be combined into a single screen display.

Recommended Cardholder Amount Confirmation Amount Confirmation Prompt 4-Line Display

Amount confirmation only Amount $xxxx.xx OK?

Cashback only (for multi-line displays can be added to amount confirmation)

Amount $xxxx.xx Cashback $xxxx.xx 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?

6.9 Processing Restrictions Processing Restrictions must be performed to determine if the transaction should be allowed. Failure of any check does not result in the transaction be cancelled. The failed result is logged in the Terminal Verification Results (TVR) 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 all Application Usage Control (Tag 9F07) restrictions are in effect

An Issuer may use Application Usage Control (Tag 9F07) to restrict a card’s use for domestic or international transactions; as well as cash, goods, services or cashback.

6.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 PIN Pad capabilities, this step may be performed by the kernel or the EMV POS Solution. Please refer to the EMV PIN Pad specification to determine your PIN Pad capabilities.

The Processing Restrictions steps are as follows:



1. Check Card Application Version Number (Tag 9F08) to ensure it matches one of the application versions supported by the kernel. Some kernels support a primary and a secondary application version number and others support just the primary version. The table below shows the Application Version Numbers currently supported for each brand.

Card Brand Application Version Numbers

Card Brand Primary Version

Secondary Version

Amex 0x0001 Debit Network Alliance 0x0001 Diners 0x0001 Discover 0x0001 China UnionPay 0x0020 Interac 0x0001 JCB 0x0200 0x0120 MasterCard 0x0002 Visa 0x008C 0x0096

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:

a. Valid at EMV POS Solutions other than ATMs (Byte-1 bit-1) must be ‘1’ b. Valid for domestic use:

i. Issuer Country Code (Tag 5F28) = Terminal Country Code (Tag 9F1A) ii. Goods and Services (Byte-1 bit-6, Byte-1 bit-4) must be ‘1’

c. Valid for international use: i. Issuer Country Code (Tag 5F28) ≠ Terminal Country Code (Tag 9F1A) ii. Goods and Services (Byte-1 bit-7, Byte-1 bit-5) must be ‘1’

3. Verify that Application Effective Date (Tag 5F25) is on or before the current date.

4. Verify that Application Expiration Date (Tag 5F24) is after the current date.

The results of these tests are stored in the Terminal Verification Results (Tag 95).

00633 AID list must be supported with associated Application Version Numbers

It is required that the EMV POS Solution maintains a list of supported AIDs and corresponding Application Version Numbers.

6.10 Offline Card Authentication Offline Card Authentication is performed between the EMV chip and the kernel to ensure 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 PIN Pad EMV specification to determine how this function is performed.

6.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 magstripe transactions as it detects alterations of selected static data elements after personalization. SDA differs from CVV in that it is performed offline by the PIN Pad.

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.

00634 All Offline CAM failures must be sent for online authorization

Chase Paymentech requires that the TAC settings have each of the offline CAM failure TVR bits set to ensure the transaction is selected for online authorization.

00635 If offline CAM is not performed transaction must go online

Chase Paymentech requires that the TAC settings ensure that the transaction is sent for online authorization when offline CAM is not performed and there is no other reason to offline decline the transaction.

00636 All Offline Card Authentication Methods must be supported

Chase Paymentech requires that all three offline Cardholder Authentication Methods be supported (SDA, DDA and CDA).

6.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 CVM priority to be used relative to the capabilities of the PIN Pad and characteristics of the transaction.

If the card does not support CVM processing or if NO CVM is selected, the EMV POS Solution must perform the cardholder verification as specified for magstripe transactions:

Signature for attended devices

NO CVM for unattended devices



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

6.11.1 Chase Merchant Services (Paymentech) EMV Processing Guidelines Update

When processing a transaction using EMV Chip technologies, Chase Merchant Services merchants and integrators must code terminal applications in accordance with EMVCo specifications and in compliance with Card Brand requirements. The following clarifications will ensure that US Debit processing will flow correctly through the Chase Merchant Services host systems when processing via EMV Chip.

Credit and Debit Transaction Options for Each Supported AID To ensure that EMV transactions are submitted to the credit card brands or debit networks properly, the following mapping must be applied to choose the type of Chase transaction to submit when a particular AID is selected following normal EMV processing rules.

Credit and Debit Transaction Options for Each Supported AIDs

AID Brand

US Merchant Transaction Type

Canadian Merchant Transaction Type

EU Merchant Transaction Type

A00000002501 American Express Credit Credit Credit

A0000001523010 Discover Global Credit Credit Credit

A0000000651010 JCB Credit Credit Credit

A0000000031010 Visa Global Credit Credit Credit

A0000000032010 Visa Electron Credit Credit Credit

A0000000033010 Interlink Global Debit Credit Credit

A0000000041010 MasterCard Global Credit Credit Credit

A0000000043060 Maestro Global Debit Canadian Debit Credit

A0000002771010 Interac US Debit Canadian Debit n/a

A0000000980840 Visa US Common Debit US Debit n/a n/a

A0000000042203 Maestro Common Debit US Debit n/a n/a

A0000001524010 Discover US Common Debit US Debit n/a n/a

A0000006200620 DNA US Shared Debit US Debit n/a n/a

A000000333010101 China UnionPay Debit US Debit n/a Credit



A000000333010102 China UnionPay Credit Credit Credit Credit

A000000333010103 China UnionPay Quasi Credit Credit Credit Credit

A000000333010108 China UnionPay US Common US Debit n/a n/a

The Transaction Type refers to the Chase host message to formulate and the appropriate PNS ISO Processing Code, UTF Transaction Code or Stratus MOP Code that must be used.

Chase Merchant Services Transaction Type Mapping to Hosts

Transaction Type

Tandem PNS ISO Bit 3 Processing Code From Account Values

Tandem UTF Transaction Code Stratus Online

Method of Payment (MOP) Code

US Debit 92 21,22,24,25,26, 46, 92 CX, DE

Canadian Debit 97 27, 28, 29, 30, 31, 32, 33, 38, 39, 48, 44, 45, 47, 49, 92

n/a – Canadian Debit processes only to the Tandem Front End

Credit 91 01, 02, 03, 06, 07, 09, 16, 17, 41, 46, 91

AX, CR, CZ, DD, DI, IM, JC, MC, MR, VI, or VR

CVM Limits for each supported AID A merchant’s or integrator’s terminal application must allow for maintenance of unique configuration values for each AID that they support. Among those unique configuration values, the CVM Limit that applies for a given AID must be supported. At this time, the values set for the US Debit AIDs shown above must be set to zero. When a chip read presents a No CVM Method, follow the EMV CVM List processing rules which state the CVM Limit of zero must be considered resulting in a failure of that CVM Method. By requiring this configuration, Chase will prevent issues that could occur from sending a transaction without PIN data to a Debit network that cannot support it.

US EMV Debit PIN Bypass PIN Bypass is a concept of allowing the cardholder to exit from a PIN prompt and continue with an EMV transaction. While this practice is encouraged to allow cardholders to complete transactions in the US market where PIN entry on Credit transactions is new, this is not applicable to US Debit transactions.

If a terminal is processing a transaction with a US Common Debit AID and the cardholder chooses to bypass PIN entry, Chase recommends the merchant or integrator restart the EMV transaction to select a Global AID and format a Credit Type transaction to the Chase Host. The PIN Pad should display a message acknowledging the PIN Bypass choice and prompting for the cardholder to choose to continue as Credit (or displaying the Global AID preferred name or label) or exit.

Selection of a Global AID will present a broader CVM List that will include non-PIN methods that are fully supported in Credit type transactions. This mirrors the “Signature Debit” Credit processing that is commonly done for Magnetic Stripe.



6.11.2 Supported Cardholder Verification Methods (CVM) Cardholder Verification Methods

CVM Description Offline Plaintext

(also known as Clear Text PIN)

The PIN Pad prompts the cardholder for a PIN and transmits the cardholder-entered PIN to the card in the clear. The card then compares the cardholder-entered PIN to the Reference PIN stored secretly in the chip.

Offline Enciphered PIN The PIN Pad prompts the cardholder for a PIN, encrypts it with public key technology and sends it to the card, where it is card decrypted. The card then compares the cardholder-entered PIN to the Reference PIN stored secretly in the chip.

Online PIN The PIN Pad 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 host in the online authorization message.

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

NO CVM

This method operates in the same manner as in the magstripe environment where transaction authorization is independent of cardholder verification.

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 CVM Results (Tag 9F34) to determine if a signature line is required on the receipt. For more information on receipt CVM requirements see page 165.

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 00609 PIN CVM is not required Chase Paymentech recommends that the choice of which Cardholder Verification Methods (Online PIN, Offline Plaintext PIN, Offline Enciphered PIN, Signature and NO CVM) to support is carefully considered and weighed against business needs, environment and risk factors.

BP 00610 Allow opportunity for customers who don’t know their PIN to continue with the transaction

Chase Paymentech recommends some form of PIN Bypass be utilized to allow the transaction to continue in the event the customer does not know (or prefers not to enter) their PIN.



00637 If PIN CVM is supported then both Online and Offline PIN must be supported

Chase Paymentech requires that both Online and Offline PIN CVM be supported when choosing to support PIN.

00638 Signature CVM must be supported for attended solutions Chase Paymentech requires that Signature CVM be supported by all EMV POS Solutions.

00639 NO CVM must be supported for unattended solutions with no PIN Pad

Chase Paymentech requires that unattended EMV POS Solutions with no PIN Pad support NO CVM.

6.11.3 PIN Prompting PIN CVM is not required by Paymentech. If the EMV POS Solution is capable of performing PIN prompting and several rules must be followed:

1. The prompt text displayed for offline and online PIN entry should be identical

2. PIN Bypass is strongly encouraged

3. The PIN Try Counter (Tag 9F17) value must be obtained before Offline 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

5. Both online and offline PIN must be supported

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

00640 Maximum number of PIN tries must not exceed PIN Try Counter (Tag 9F17)

It is required that the number of Offline PIN tries allowed does not exceed the initial PIN Try Counter (Tag 9F17) value.

00641 Cardholder must be notified of last offline PIN attempt

It is required that the cardholder be notified when only one invalid Offline PIN attempt remains before the card is blocked.

00642 Cardholder must be notified when maximum Offline PIN tries is exceeded It is required that the cardholder be notified when the Offline PIN tries have been exceeded.



6.11.4 CVM Results Validation (Tag 9F34) The following details how the CVM result is interpreted.

(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

(CVM) Cardholder Verification Method Results (Tag 9F34) – Byte 2 Value Meaning

00 – 09 Ignore this byte

(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)

6.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 Byte-1 bit-4).

Risk Management Requirements Type Requirement Usage

EMV Floor Limit Checking Mandatory Required for all EMV POS Solutions.

Performed by the EMV kernel.

Random Transaction Selection Mandatory

Required for EMV POS Solutions capable of both offline and online transactions.




Risk Management Requirements Type Requirement Usage

Transaction Velocity Checking Mandatory

Required for EMV POS Solutions capable of offline transactions. Checks if the card’s consecutive offline transaction or cumulative offline spend limit has been exceeded.


New Card Verification Mandatory

Required for EMV POS Solutions capable of offline transactions.


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 00611 Terminal Risk Management features should be supported Chase Paymentech recommends that all EMV Terminal Risk Management features be supported regardless of the offline capabilities of the terminal.

6.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. For deployed production implementations the Chase Paymentech host download will optionally return a PNS/ISO Bit 48 Subtag P6 or UTF Token FL with a floor limit that should override any current setting of floor limit on the device. When a value is not returned in the host download, the device must be set to the default zero floor limit.

Only transactions with amounts below the EMV Floor Limit can be approved by the card offline at the 1st Generate AC. A transaction can also be approved offline at the 2nd Generate AC if the host is unavailable and the transaction amount is below the EMV Floor Limit.

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



00643 Floor Limit must be set to zero

Chase Paymentech requires that the EMV Floor Limit be set to zero. Therefore, the production Chase Paymentech host download used by deployed EMV POS Solutions, will optionally return a Floor Limit record to set in a device. When no Floor Limit record is returned in the host download, the device should default to a zero value.

00644 Non-zero EMV Floor Limits must be supported

Chase Paymentech requires that all EMV POS Solutions be capable of supporting a non-zero EMV Floor Limit.

This capability will be tested during EMV certification to future proof the EMV POS Solution in case Chase Paymentech begins to support non-zero EMV Floor limits in the future.

6.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. The following values should be used for this purpose.

Random Selection Values 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

Most kernels interpret 99% as being 100% but that should be confirmed with your PIN Pad vendor.

00645 Random Selection parameters must ensure transaction is attempted

Chase Paymentech recommends that the Target Percentage, Maximum Target Percentage and Threshold for Biased Random Selection values be set to ensure transactions are always selected to go online.

6.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

6.13.1 Dynamic Data Object List (DDOL) The DDOL (Tag 9F49) 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.

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

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

6.13.2 Transaction Certificate Data Object List (TDOL) The TDOL (Tag 97) 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.

00647 The Visa Default TDOL (if used) must include Transaction Amount only

Chase Paymentech requires that when the EMV POS Solution supports a Default TDOL for Visa that includes Transaction Amount (Tag 9F02) only.

00648 The MasterCard Default TDOL (if used) must include multiple tags

Chase Paymentech requires that when the EMV POS Solution supports a Default TDOL for MasterCard that contains the Transaction Amount (Tag 9F02), Currency Code (Tag 5F2A), Transaction Date (Tag 9A), Transaction Type (Tag 9C), TVR Results (Tag 95) and Unpredictable Number (Tag 9F37) only.



6.13.3 Processing Data Object List (PDOL) The PDOL (Tag 9F38) list sometimes contains the Transaction Amount (Tag 9F02). 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.

6.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.

00649 Do not set kernel to force transactions online

Chase Paymentech requires that the EMV POS Solution not enable/use the kernel “force online” feature to force transactions to go online. Using this kernel feature results in the TVR Merchant Forced Online bit (Byte-3 bit-4) to be set indicating a suspicious transaction.

6.14.1 Issuer Action Codes (IACs) There are three IAC 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 and the corresponding TVR bit are both set to ‘1’, 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) – 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) – 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) – 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.



6.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) (Tag 95).

When a TAC bit and the corresponding TVR bit are both 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 – 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 – 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 – 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.

6.15 1st Generate Application Cryptogram The 1st Generate AC consists of two steps. The first step is performed by 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, offline decline or request online authorization, and then returns the decision to the EMV kernel

6.15.1 Terminal Action Analysis In Terminal Action Analysis the kernel analyzes the IAC, TAC and TVR values and sends a GENERATE AC command requesting the card 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:

a. 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)

b. ARQC – Process the transaction online (this is recommended by Chase Paymentech) c. TC – Approve the transaction offline

3. Provide the transaction data required by the card to perform Card Risk Management

4. Provide transaction data required to calculate the Application Cryptogram (data required by the chip is specified by CDOL1 (Tag 8C) retrieved from the chip during Read Data Records).



6.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 Cryptogram Information Data (CID) (Tag 9F27):

1. AAC (Decline CID=00) Requested – card must respond with:

a. AAC – Declined

2. ARQC (Online authorization CID=80/90) Requested – card may respond with either:

a. ARQC – Go Online (online issuer authorization required) b. AAC – Declined

3. TC (Approval CID=40/50) Requested – card may respond with any of the following:

a. TC – Approved b. ARQC – Online Authorization Required c. AAC – Declined

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). The chip cannot offline approve the transaction (i.e. returns a TC).

6.16 EMV Offline Approvals *NOTE* Chase Paymentech does not support any offline transaction processing in the U.S. EMV Floor Limits are typically set to $0 in the EMV parameter downloads. However, if EMV offline processing is desired, this section outlines the processing steps to be taken.

EMV transactions can be approved offline by the chip at the 1st Generate AC or at the 2nd Generate AC when the host is unavailable. In both cases the transaction amount must be below the EMV Floor Limit.

When a transaction is offline approved by the card (without host authorization), the card returns a final cryptogram called the Transaction Certificate (TC) and the EMV POS Solution should:

1. Set the Authorization Response Code (Tag 8A) to ‘Y1’.

2. Store the cryptogram (TC) and Approval Code in the batch with the transaction details.

3. Send the transaction (including the TC) to the host prior to or at settlement.

The final card decision is reflected in the Cryptogram Information Data and not in the Authorization Response Code.



The following table shows the Authorization Response Code (Tag 8A) values used when processing offline transactions.

Authorization Response Code Values Authorization Response Code Value Offline approved Y1 Offline declined Z1 Unable to go online, offline approved Y3 Unable to go online, offline declined Z3

BP 00612 Generated Offline approval codes should be in the format “E999999” Chase Paymentech recommends offline approval codes generated by the EMV POS Solution begin with an ‘E’ followed by six digits.

6.16.1 Offline Transaction Upload Prior to performing Settlement, all offline approved transactions must be uploaded to the host. Uploading offline approved transactions may be done using the same process used for traditional magstripe transactions with the exception that EMV tags must be included as part of the transaction data.

For host capture implementations the offline approved transactions must be sent to the host individually or in a transaction batch using a capture request message.

For a list of EMV tags that must be uploaded with offline approved transactions see page 143.

6.17 Online Response Processing When a transaction is sent online for authorization the host will return several data elements required by the card for 2nd Generate AC, External Authenticate and 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:

Authorization Response Code (Tag 8A) – If this is not returned by the Chase Paymentech host it must be set based on the host response code.

Host Decision Tag 8A

ASCII Hex Approved 00 0x3030 Declined 05 0x3035

Issuer Authentication Data (Tag 91) – Used for External Authenticate (see page 110) - as returned in the host response message

Issuer Scripts (Tag 71 or Tag 72) – Script commands are forwarded to the card by the EMV



kernel for execution - as returned in the host response message 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)

A maximum of one Issuer Script will be returned in a Chase Paymentech host response message. A host response message will never contain both Tag 71 and Tag 72.

00651 Authorization Response Code must be set based on host Response Code

Chase Paymentech requires that when the Authorization Response Code (Tag 8A) is not present in the host response message, it be set by the EMV POS Solution based on the host response code returned in host response message. This must be done before the 2nd Generate AC is performed.

00652 Issuer Scripts must be supported in host responses

It is required that the EMV POS Solution be capable of extracting an Issuer Script from the host response message and forwarding it to the EMV kernel for execution by the card.

6.17.1 Partial Authorizations 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 EMV kernel

2. Set Authorization Response Code (Tag 8A) = 0x3030 to indicate the transaction was approved

3. Perform an External Authenticate (if required)

4. Perform a 2nd Generate AC

The transaction is now complete and the receipt should be printed using the updated Transaction Amount (Tag 9F02).



00653 Reversal must be sent if cardholder declines partial authorization

Chase Paymentech requires that a host Reversal message be sent for a Partial Authorization when the cardholder declines to continue the transaction using the lower authorized amount. In this case the EMV POS Solution must set the Authorization Response Code (Tag 8A) to 0x3035, request a decline (AAC) at the 2nd Generate AC and send a Reversal message to the Chase Paymentech host.

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

It is required for Partial Authorizations where the lower authorized amount is accepted by the cardholder, that Transaction Amount (Tag 9F02) be updated to reflect the lower authorized amount and sent to the kernel prior to the 2nd Generate AC.

00655 Partially authorized amount must be sent in the settlement message

Chase Paymentech requires that Partial Approval settlement messages include the lower partially authorized amount in Transaction (Tag 9F02).

6.17.2 Referrals Chase Paymentech 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.

00656 Referral transactions must be declined

Chase Paymentech requires that when a Referral response is received, that the transaction be declined by requesting a Decline (AAC) at the 2nd Generate AC.

6.18 External Authenticate External Authenticate is used to validate that 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) indicates that the chip supports Issuer Authentication (Byte-1 bit-3).

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.

6.19 2nd Generate Application Cryptogram The final 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 chip 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:

a. AAC – Decline the transaction (issuer declined the transaction) b. TC – Approve the transaction (issuer approval)

2. Provide the transaction data required to calculate the Application Cryptogram as retrieved from the chip during the initial Read Application Data processing (data required by the chip is specified by CDOL2 (Tag 8D))

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:

a. AAC – Declined

2. TC (Approval requested) – card may respond with either:

a. TC – Approved b. AAC – Declined

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).

6.19.1 Issuer Script Processing If an Issuer Script is returned in the host response message it must be sent to the EMV kernel for execution by the card prior to performing the 2nd Generate AC. Tag 71 scripts will be executed before 2nd Generate AC processing begins and Tag 72 scripts will be executed after the 2nd Generate AC completes.

A host response will never include both Tag 71 and Tag 72 Issuer Scripts. A maximum of one Issuer Script will be returned in each host response message.

00657 Issuer Scripts must be executed for approved and declined transactions

It is required that Issuer Scripts returned in the host response message be sent to the card for execution, regardless of whether the transaction was approved or declined.

00658 Must support Issuer Scripts up to 128 bytes in length It is required that Issuer Scripts up to 128 bytes in length be supported.



00659 Handling Issuer Script errors

It is required that the transaction continues when an error is returned by the kernel during Issuer Script processing. However, 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.

6.20 Transaction Completion Processing Transaction Completion Processing consists of analyzing the 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.

6.20.1 Reversal Processing There are several additional EMV reversal types that must be supported by the EMV POS Solution in addition to the standard reversal processing required by traditional magstripe implementations. The additional reversals are required because Full EMV transactions return the online authorization decision to the card for final authorization.

EMV reversals are required when the transaction was approved by the host but the EMV POS Solution is unable to complete 2nd Generate AC. When generating a reversal for an EMV transaction, EMV tags must be included in the host reversal message. The following table identifies the additional EMV reversal reasons and whether EMV tag data from the first or second Generate AC is required in the reversal message.

EMV Reversal Types Reversal Reason EMV Tags Description

PIN Pad Unavailable 1st Generate AC PIN Pad disconnected or malfunctioning when attempting 2nd Generate AC

Transaction Cancelled 1st Generate AC Transaction is cancelled by the merchant or cardholder (during or after host authorization)

Card Removed 1st Generate AC Cardholder removed card before 2nd Generate AC completes

Chip Error 1st Generate AC

The card returned an error during 2nd Generate AC or External Authenticate processing indicating the chip is malfunctioning

Note: For a chip malfunction at the 2nd Generate AC, MasterCard requires that the transaction disposition be based on the host message authorization decision (Approved/Declined)

Card Decline 2nd Generate AC The card declined the host approved transaction at the 2nd Generate AC



00660 EMV transaction reversals must include EMV tags

Chase Paymentech requires that all EMV host reversal messages 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 performed).

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

BP 00613 Do not print receipt until the card has been removed Chase Paymentech recommends that the receipt not be printed until the cardholder has removed the card. This decreases the incidence of the cardholder forgetting their card.

BP 00614 Sound audible beep while waiting for card to be removed Chase Paymentech recommends that there is an audible beep while waiting for the EMV card to be removed. This decreases the incidence of the cardholder forgetting their card.

6.20.3 Transaction Storage At the completion of a transaction EMV tag information must be stored to ensure it is available for settlement or problem determination and reporting. The table below identifies the EMV tags that should be stored in the transaction batch.

Transaction Batch EMV Tag Information Required Tag Tag Name Comment 9F02 Transaction Amount 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 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



Transaction Batch EMV Tag Information Required Tag Tag Name Comment 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

The table above identifies the EMV tags that should be stored by the EMV POS Solution. This does not represent the EMV tag information that must be sent to the Chase Paymentech host.

00661 Last EMV transaction data must be available even if transaction is declined

Chase Paymentech requires that the final EMV transaction tag data be retained so it can be reprinted if necessary. This applies to both approved and declined EMV transactions.

It is preferred that EMV transaction data be available for every transaction in the batch.

EMV Implementation Guide Chase EMV Parameter Download


7. Chase EMV Parameter Download EMV POS Solutions require additional parameters to process EMV and contactless transactions. It is the client’s responsibility to manage most EMV parameters. However, the Chase Paymentech host does maintain and download several EMV parameters that must be used by the EMV POS Solution.

Different methods are used by the EMV POS Solution to obtain the Chase EMV Parameters depending on host interface being used:

PNS ISO & PNS UTF

Stratus Online and 120-Byte Batch

The sections that follow outline the implementation for each host interface.

00701 Chase EMV Parameters must be downloaded whenever new version is

available Tandem and Stratus SFTP solutions must download the parameter file whenever a new version is available. During certification the client will be required to confirm to Chase Paymentech that the EMV POS Solution includes this functionality.

00702 Download EMV parameters within nine Settlement periods of notification

Chase Paymentech requires that EMV POS Solutions using the PNS ISO or UTF interfaces download EMV parameters within nine settlement periods after being notified that a new parameter download is required. After the 9th settlement period with no download transactions will no longer be performed.

7.1 Chase EMV Download Parameters The Chase Paymentech host maintains and downloads the following EMV parameters. These parameters must be used by the EMV POS Solution:

Certificate of Authority Public Keys – Public Keys issued by each card brand used for Offline Data Authentication and offline PIN validation. There are a maximum of six public keys per card brand.

Fallback Indicator – Flag indicating if fallback is supported for the card brand. There is one flag per card brand.

EMV Offline Floor Limit – Floor limit used to determine when the chip can offline approve an EMV transaction without going online for authorization. There is one EMV Offline Floor Limit for each card brand. Note: Currently the EMV Offline Floor Limits are always set to zero. Therefore the host download may or may not return a Floor Limit value in response messages. When the Floor Limit Subtag or token is not present in the download response message, a default of zero should be used.

Threshold for Biased Random Selection – Used in conjunction with the EMV Floor Limit to determine when a transaction may be authorized offline by the chip without going online for authorization.



7.1.1 Certificate of Authority Public Keys (CAPK) The Certificate of Authority (CA) Public Keys are required by the EMV POS Solution to support Offline Data Authentication (SDA / DDA / CDA) and Offline PIN validation.

It is important that current CA Public Keys are always being used and that expired and revoked keys are removed. Failure to remove expired and revoked keys could result in expired cards being approved. Regulations state that Certificate Authority (CA) Public Key changes must be implemented within six months of notification.

EMV POS Solutions must be capable of storing up to six CA Public Keys per card brand. The total number of CA Public Keys required depends on the number of card brands supported by the EMV POS Solution:

American Express

China UnionPay

Discover

Interac

JCB

MasterCard / Maestro

Visa / Interlink / ChaseNet

The Chase EMV Parameter Download will include CA Public Keys for all card brands supported by Chase Paymentech. It is the responsibility of the EMV POS Solution to ignore CA Public Keys for card brands that are not supported.

00703 Must be capable of storing six CA Public Keys per card brand

Chase Paymentech requires that EMV POS Solutions be capable of storing up to six active CA Public Keys per card brand.

7.1.2 Fallback Indicator The Chase EMV Parameter Download includes a Fallback Indicator for each AID. If the Fallback Indicator indicates fallback is not allowed, then the EMV POS Solution must not allow cards with Service Codes ‘2xx’ or ‘6xx’ to be processed as magstripe cards. If the EMV chip is not functional, and fallback is not allowed, the card may not be used.

7.1.3 EMV Offline Floor Limit The Chase EMV Parameter Download includes one EMV Offline Floor Limit for each RID. This parameter is used to determine the minimum transaction amount that the chip can approve offline, without going online for authorization.

The Chip Floor Limit is currently set to zero for all card brands. If the value is downloaded from the host, it must be used by the EMV POS Solution and it may not be changed at the device. However, if a value is not downloaded, the default of zero should be set.



7.1.4 Threshold for Biased Random Selection The Chase EMV Parameter Download includes one Threshold for Biased Random Selection parameter for each AID. This parameter is used in conjunction with the EMV Offline Floor Limit to determine when a transaction may be approved offline without going online for authorization.

7.2 PNS ISO Parameter Download Processing This section details how the Chase PNS ISO interface manages and downloads parameters to an EMV POS Solution.

For additional information refer to the PNS ISO Formats – Host and Terminal Capture Systems specification.

7.2.1 PNS ISO Download Notification The PNS ISO host response message includes a Download Required Indicator (Bit 48 Subtag ‘D8’) at the completion of the Batch Close and/or Batch Release process.

When the Download Required Indicator is received, it is up to the EMV POS Solution to initiate a Chase EMV Parameter Download. The parameter download does not have to occur immediately, but it must be performed within nine settlement periods. After that time, the EMV POS Solution will be unable to process transactions until a Chase EMV Parameter Download is performed.

Even Terminal IDs that are set up as manual batch release will receive the Download Required Indicator.

7.2.2 PNS ISO Parameter Download PNS ISO EMV parameters are downloaded using the EMV Parameter Download Request (1340) and EMV Parameter Download Response (1350) messages.

The parameter download requires multiple host request/response messages to download all EMV parameters. At the completion of the download, the EMV POS Solution must send a final EMV Parameter Download Request (1340) message to the host identifying the final status of the download.

The following data fields are used by the PNS ISO interface to download EMV parameters.

PNS ISO EMV Parameter Fields Parameter Field Certificate of Authority Public Key Bit 44 Subtag ‘P1’ EMV Fallback Indicator Bit 48 Subtag ‘P5’ EMV Offline Floor Limit Bit 48 Subtag ‘P6’ Biased Random Selection Limit Bit 48 Subtag ‘P6’



To identify the current state of the download from the POS EMV Solution perspective, the EMV Parameter Download Request (1340) message includes an EMV POS Parameter Download Request Status (Subtag ‘C7’) that must be set on all download request messages:

I = Initial download request

S = Subsequent download request

Y = Download completed successfully – Checksums are valid (last request only)

N = Download failed or checksums are not valid (last request only)

The EMV Parameter Download Response (1350) message includes Subtag ‘D9’ that identifies if the download is complete or if additional parameter data is available:

M = More parameter data exists

F = Final download buffer sent

When the final EMV Parameter Download Response (1350) message (Subtag ‘D9’ = “F”) is received, the EMV POS Solution must send a final EMV Parameter Download Request (1340) message indicating the status of the download (Subtag ‘C7’ set to ‘Y’ = Successful or ‘N’ = Failed).

7.3 UTF Parameter Download Processing This section details how the Chase UTF Host Capture System and Terminal Capture System manages and downloads EMV parameters.

For additional information on the UTF message formats refer to the UTF Terminal Capture System and UTF Host Capture System specifications.

For additional information on the Token Data formats refer to the UTF Token Guide.

7.3.1 UTF EMV Download Notification The UTF host response messages include a Download Required Indicator at the completion of the Batch Close and/or Batch Release process.

The following table identifies where the EMV Parameter Download Required flag is sent.

EMV Parameter Download Required Indicator Message Field

UTF - TCS Batch Upload Final Response Field 10

UTF - HCS Batch Release Response Field 11

UTF - HCS Auto Close Transaction response (1st transaction of the day only) ‘DL’ Token



When the Download Required Indicator is received, it is up to the EMV POS Solution to initiate an EMV Parameter Download. The parameter download does not have to occur immediately, but it must be performed within nine settlement periods. After that time, the EMV POS Solution will be unable to process transactions until a Chase EMV Parameter Download is performed.

Even Terminal IDs that are set up as manual batch release will receive the Download Required Indicator.

7.3.2 UTF EMV Parameter Download The UTF interface downloads EMV parameters using a series of EMV Parameter Download Request and EMV Parameter Download Response messages.

The EMV parameter data is sent in the Token Data section of EMV Parameter Download response messages. The following table identifies the tokens used for each EMV parameter.

UTF EMV Parameter Fields Parameter Token Certificate of Authority Public Key ‘PK’ EMV Fallback Indicator ‘FI’ EMV Offline Floor Limit ‘FL’ Biased Random Selection Limit ‘FL’

Downloading EMV parameters requires multiple EMV Parameter Download Request messages. To identify the state of the download each request message must include the Download Status field set as follows:

I = Initial download request

S = Subsequent download request

Y = Download completed successfully – Checksums are valid (last request only)

N = Download failed or checksums are not valid (last request only)

The EMV Parameter Download Response message includes a Parameter Download Status indicator (‘DS’ token) that identifies if the download is complete or if additional parameter data is available. The ‘DS’ token is set as follows:

M = More parameter data exists

F = Final download buffer sent

When the final EMV Parameter Download Response message (‘DS’ Token = “F”) is received, the EMV POS Solution must send a final EMV Parameter Download Request message indicating the final Download Status (‘Y’ = Successful or ‘N’ = Failed).



7.4 Stratus EMV Parameter Download Processing The Stratus interface does not notify EMV POS Solutions when a download is required. Instead the Stratus host will push out a new EMV parameter file monthly. This file will be available for pickup by the EMV POS Solution for a period of three days. It is the responsibility of the EMV POS Solution to retrieve the file while it is available. The EMV POS Solution will use SFTP or TCP/IP to download the file.

For a description of the Stratus EMV parameter file format refer to the Chip EMV® Download specification.

EMV Implementation Guide EMV Contact and Contactless Parameters


8. EMV Contact and Contactless Parameters

8.1 Contact EMV Parameters This section lists the EMV parameters that should be supported by EMV POS Solutions.

For development and certification parameter values see page 239.

Contact EMV Parameters Tag Name Report Label Description

Acquirer ID Acquirer ID ID assigned to the acquirer per scheme.

9F40 Additional Terminal Capabilities

Addl Capability Indicates the data input and output capabilities of the 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: The method used to bypass the PIN prompt may differ based on the PIN Pad being used.

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

9F09 Application Version Number (Primary)

App Ver Num Pri Version number assigned for the application by the payment system.

9F09 Application Version Number (Secondary)

App Ver Num Sec (Optional) Secondary version number assigned for the application by the payment system.

Certificate Authority Public Key Index Number

CAPKx Index Certificate Authority Public Key Index Number

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.

Default DDOL (Dynamic Data Authentication Data Object List)

Default DDOL

Used to construct the Internal Authenticate command if card DDOL is not present on the card.

Padded with trailing zeroes.

Default TDOL (Transaction Certificate Data Object List)

Default TDOL

Used to construct the Internal Authenticate command if card TDOL is not present on the card.

Padded with trailing zeroes.




EMV Random Selection Maximum Percentage

Rand Sel Max

Maximum percentage of transactions having a value more than the EMV Random Selection Threshold that must be sent online. Numeric: 0 to 99

EMV Random Selection Target Percentage

Rand Sel Target

Percentage of transactions having a value greater than the EMV Random Selection Threshold that must be sent online. Numeric: 0 to 99

EMV Random Selection Threshold

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

9F15 Merchant Category Code Merch Cat Code Type of business being performed by the merchant’s 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 – Default

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

Terminal Action Code – Denial

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

Terminal Action Code – Online

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

9F33 Terminal Capabilities Term Capability Identifies the supported hardware, cardholder 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

5F36 Terminal Currency Exponent

Trans Curr Exp

Number of digits to the right of the decimal place in the currency.

e.g. If this parameter value is ‘2’ then 12345 represents 123.45

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




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

9F53 Transaction Category Code Trans Cat Code

MasterCard AIDs only.

May be used to assist with Card Risk Management.

Chase Paymentech values include:

A – Automobile/Vehicle Rental

C – Cash Disbursement

F – Restaurant

H – Hotel/Motel and Cruise Ship Services

O – College/School Expense Hospitalization

R – Retail/All Other Transactions

T – Mail/Telephone Order Preauthorized Order

U – Unique Transaction

X – Transportation

Z – ATM



8.2 Contactless EMV Parameters This section lists the contactless parameters that should be supported by EMV POS Solutions.

For development and certification parameter values see page 239.

Contactless EMV Parameters Tag Name EMV Report ID Description

Contactless CVM Required Limit

CTLS CVM Req Lim

Transaction amount above which a CVM is required 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 Receipt Required Limit

CTLS Recpt Req Lim

Transaction amount above which a contactless transaction must print a receipt. Interac only

Contactless Terminal Capabilities CVM Req

CTLS TermCapCVMR

Used to overwrite Terminal Capabilities when the transaction amount is above the Terminal CVM Required Limit (i.e. CVM is Required).

MasterCard Only

Contactless Terminal Capabilities CVM NotReq

CTLS TermCapCVMN

Used to overwrite Terminal Capabilities when the transaction amount is below the Terminal CVM Required Limit (i.e. NO CVM).

MasterCard Only

Contactless Transaction Limit CTLS Trans Limit Only amounts below this limit may be performed as

contactless transactions.

Default UDOL

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

Enable ExpressPay EMV Enable ExPay EMV

Flag indicating if ExpressPay contactless EMV is supported. Amex only

Enable ExpressPay MSD Enable ExPayMSD

Flag indicating if ExpressPay contactless MSD is 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

Merchant Type Indicator Merchant Type Identifies the Merchant Type. Interac Only



Contactless EMV Parameters Tag Name EMV Report ID Description

9F6D MSD Version Number MSD Version Num

Version number assigned by the payment system for the specific PayPass – Magstripe functionality of the application. MasterCard Only

9F66 Visa TTQ Visa TTQ Visa Only – Terminal Transaction Qualifiers.

EMV Implementation Guide Chase Host Message Processing


9. Chase Host Message Processing This section outlines the information required to process EMV transactions using the Chase Paymentech PNS ISO, UTF and Stratus interfaces. The information includes:

Host Transaction Sets

Host Message EMV Fields

Host Message EMV Tags

Host Message Examples

The information provided in this section is provided for clarity and completeness. The PNS ISO, UTF and Stratus specifications provide more complete and up to date information. Therefore, those specifications should be used when developing an EMV POS Solution.

9.1 Host Transaction Sets Chase Paymentech supports three host interfaces. All three interfaces include EMV transaction support. This section defines the credit / debit transaction sets supported by Chase Paymentech and specifies how the transactions are identified for each of the host interfaces:

PNS ISO

UTF

Stratus Online 7.4 / Stratus 120 Byte Batch

The following tables identify the standard credit and debit transaction sets used to process transactions with the Chase Paymentech hosts. For information relating to the Canadian debit transaction set see page 274.



9.1.1 Credit Transaction Set The following table defines the credit transaction set used for EMV transactions and provides information on how the transaction is identified for each host interface.

Credit Transaction Set Transaction Type

ISO (TCS)1

ISO (HCS)2

UTF (TCS) 1

UTF (HCS)2

Stratus Online (TCS)1

Stratus Batch (TCS)1

Auth Only Authorization 1100

Authorization 1100

Auth Only 02

Auth Only 02

Auth AU

N/A

Sale N/A EFT 1200

Sale 01

Sale 01

N/A Deposit

DP

Prior Sale/ Deposit

Detail Record 1300

Prior Auth (Bit 3 = 17)

EFT 1200


Prior Auth Sale 03

Prior Auth Sale 03

N/A N/A

Offline Posting

Detail Record 1300


1200 Bit 3 = 11

Prior Auth Sale 11

Prior Auth Sale 11

N/A N/A

Refund / Return

Return 1300

Bit 3 = 20

Return 1200

Bit 3 = 20

Credit Return 06

Credit Return 06

N/A Refund

RF

Void / Merchant Reversal

Reversal Advise 1420

Bit 3 – Original

EFT Void 1400

Bit 3 – Original Reversal Advice

46

Void 41

Auth Reversal AR

N/A Auth Only

Reversal Advice 1420

Bit 3 – Original

Auth Only Reversal Advice

46

Partial Void (MasterCard) (Discover)

Auth 1100

Bit 48 (V7) = R

Auth 1100

Bit 48 (V7)=R

Auth Reversal 09

Auth Reversal 09

N/A N/A

Reversal (2nd Gen Chip Decline) (EMV Data Required)


Bit 3 – Original Bit 48 (R3) = 4

EFT Void 1400


Reversal Advice

46 Reason Code =

4

Reversal Advice

46 Reason Code =

4

Auth Reversal AR

N/A Auth Only


Bit 3 – Original Bit 48 (R3)=4



Transaction Type

ISO (TCS)1

ISO (HCS)2

UTF (TCS) 1

UTF (HCS)2



Reversal (EMV Other) (EMV Data Required)


Bit 3 – Original

EFT Void 1400

Bit 3 – Original Reversal Advice

46

Reversal Advice

46

Auth Reversal AR

N/A Auth Only


Bit 3 – Original

EMV Balance Inquiry

Authorization 1100

(zero amount) Bit 3 = 31

Authorization 1100

(zero amount) Bit 3 = 31

Balance Inquiry 16

Balance Inquiry 16

Balance Inquiry BI

N/A

1 Terminal Capture System 2 Host Capture System



9.1.2 Debit Transaction Set The following table shows the debit transaction set used for EMV transactions and information on how the transaction is identified for each host interface.

Debit Transaction Set Transaction Type

ISO (TCS)1

ISO (HCS)2

UTF (TCS) 1

UTF (HCS)2



Auth Only N/A Pre-Auth

1200 N/A Pre-Auth 25 N/A N/A

Sale N/A 1200 N/A 21 Purchase

Authorization PA

N/A

Sale w/Cashback N/A

1200 Processing Code

= 099200 N/A 22

Purchase Authorization

PA N/A

Prior Sale / Completion N/A


= 099200 N/A 26

N/A

N/A

Refund / Return N/A


= 099200 N/A 24

Refund Auth RA

Refund RF


N/A N/A

N/A N/A Purchase Auth

Reversal PR

N/A 1420 46

Refund Reversal N/A 1420 N/A 46

Refund Reversal DR

N/A

Partial Void (MasterCard) (Discover)

N/A N/A N/A N/A N/A N/A

Reversal (2nd Gen Chip Decline) (EMV Data Required)

N/A



EMV Data Not

Required

N/A

Reversal Advice

46

EMV Data Not Required

Purchase Auth Reversal

PR N/A

Reversal (EMV Other) (EMV Data Required)

N/A


EMV Data Not

Required

N/A

Reversal Advice

46

EMV Data Not Required

Purchase Auth Reversal

PR N/A

EMV Balance Inquiry N/A N/A N/A N/A N/A N/A




9.2 Host Message EMV Fields This section contains host message field usage information related to EMV and contactless processing.

The information provided in this section is provided for clarity and completeness. The PNS ISO, UTF and Stratus specifications provide more complete and up to date information. Therefore, those specifications should be used when developing an EMV POS Solution.

9.2.1 Cardholder Data The following rules must be adhered to when sending EMV cardholder data read from the chip to the Chase Paymentech host:

1. If Track 2 data is sent in the host message, the Track 2 data must be populated from Track 2 Equivalent Data (Tag 57).

2. The Track 2 Equivalent Data (Tag 57) uses a ‘D’ to delimit between the end of the cardholder account number and the beginning of the expiry date. In the Chase Paymentech host message the ‘D’ should be replaced with an ‘=’ to match the format used when sending Track 2 data read from a magstripe.

3. If the cardholder account number (PAN) is sent in the host message, the PAN must be populated from Application PAN (Tag 5A).

4. Application PAN (Tag 5A) may be suffixed with one or more trailing ‘F’ (0xF) characters. The trailing ‘F’ characters must not be sent in the host message.

9.2.2 Chip Card Data Chip Card Data sent in EMV request messages and returned in EMV response messages. This field consists of a 3-byte length field followed by a variable number of BER-TLV encoded EMV tag data fields.

Chip Card Data Field Format Total Field

Length Tag Number Tag Length (hex) Tag Value Tag Tag Length

(hex) Tag Value TLV…

3 Bytes (Decimal)

2 or 4 Bytes 2 or 4 Bytes Variable

length tag data

2 or 4 Bytes 2 or 4 Bytes Variable

length tag data

Tag / Length / Value

fields repeat for each tag

Tag Number Size The hex Tag Number is either 2 or 4 bytes in length. To determine the number of bytes used for the Tag Number, check the last bit of byte one and all four bits in byte two, if they are all ‘1’, the tag number is four (4) bytes in length (including the current byte).

Example 1: Tag 9F10 is a 4-byte Tag Number – this is known because the last bit of the first byte (‘9’) and all bits in the second byte (‘F’) are all ones (‘10011111’)



Example 2: Tag 72 is a 1-byte tag number – this is known because the last bit of the first byte (‘7’) and all bits in the second byte (‘2’) are not all ones (‘01110010’)

Tag Length Size The 2 or 4 bytes following the Tag Number contain the Tag Length. To determine the number of bytes used for the Tag Length, check the first bit of byte one. If the first bit is:

‘0’ – bytes 1 and 2 are the actual length of the Tag Value that follows

‘1’ – the next 7 bits are a binary representation of the number of length bytes that follow

Example 1: If the first two length bytes are ‘0C’, the first bit is a zero (‘00001100’), so the tag data starts in the next byte and is 12-bytes in length.

Example 2: If the first two length bytes are ‘82’ and are converted to hex (0x82), the first bit is a one (‘10000010’) and the next 7 bits are ‘0000010’ (decimal 2), so the next two bytes contain the actual tag data length followed by the tag data.

Tag Length Value The Tag Length represents the length of the Tag Value that follows, when in hex format. When the Tag Value is converted to ASCII in the host message, the resulting Tag Value becomes twice as long because it requires two ASCII bytes to represent a single hex byte. Regardless, the Tag Length field should not change. It should always contain the original hex length of the Tag Value that follows.

Example: Tag 9F08 is 8 hex bytes in length and is set to (0x41 0x42 0x43 0x44 0x31 0x32 0x33 0x34). When sending this tag in the host message it must be converted to ASCII. The Tag Length in ASCII is ‘08’ and the Tag Value in ASCII is “4142434431323334”. So the Tag Length field in the host message indicates the Tag Value is 8 bytes in length, but the Tag Value that follows is actually 16 ASCII bytes.

9F08084142434431323334

Chip Card Data Field Example

The following is an example of a Chip Card Data field containing tags (82, 95, 9A and 5F24). The field is prefixed with a 3-byte ASCII decimal length (044) followed by one TLV field for each tag being sent.

04482025C00950502000080009A031410285F2403141231

9.2.3 EMV/Contactless PAN Sequence Number The EMV/Contactless PAN Sequence Number is a two byte field containing the PAN Sequence Number (Tag 5F34) value returned by the chip.

If the chip does not return PAN Sequence Number (Tag 5F34), this field should not be included in the host message.



9.3 Host Message EMV Tags The following sections outline the EMV tags that should be sent for authorization, reversal and settlement request messages as well as the tags that will be returned in the authorization host response message. Tags are shown in the order they should be sent in the host request message.

BP 00901 EMV Tags should be sent in order Chase Paymentech recommends that EMV tags included in host request messages be sent in the order; fixed length tags first, in ascending order by tag number, followed by variable length tags in ascending order by tag number.

This is will help resolve issues identified during certification.



9.3.1 Authorization Request EMV Tags This section outlines the EMV tags (in TLV format) that should be sent in authorization request messages. Tags are shown in the order they should be sent in in the request message.

BP 00902 Authorization request messages must include all authorization EMV tags Chase Paymentech recommends that authorization request messages include all defined authorization EMV tags, regardless of the transaction type or card used.

If a tag is not required, the Chase Paymentech host will ignore it. If a tag has no data, the TLV length must be set and submitted with the Full Tag Length Value.

Example: 9F03 Length 06 Value 000000000000

Authorization Request Message EMV Tags Tag Element Name Comments

82 AIP Application Interchange Profile

95 TVR Terminal Verification Results

9A Terminal Transaction Date

The local date that the transaction was performed.

Format: YYMMDD

9C Transaction Type

Indicates the type of financial transaction, represented by the first two digits of the ISO 8583: 1987 Processing Code.

0x00 = Goods and Services

5F2A Transaction Currency Code

Currency code used for the transaction according to ISO 4217.

840 = U.S. Dollars

9F02 Transaction Amount

Contains the actual transaction amount used by the chip when calculating the cryptogram (amount + cashback + tip + surcharge).

This amount excludes any adjustments (e.g. tips) that were made to the transaction amount after completion of the original EMV transaction.

Two decimals implied.

9F03 Other Amount

Secondary cashback amount.

Mandatory if cashback applies. Zero filled if not supported.


9F09 Terminal Application Version Number

Version number assigned by the payment system for the application.



Authorization Request Message EMV Tags Tag Element Name Comments

9F1A Terminal Country Code

Indicates the country of the terminal, represented according to ISO 3166.

840 = United States

9F1E POS/Terminal Serial Number

A unique and permanent identification number of the chip POS / Terminal assigned by the manufacturer.

Used to track devices regardless of their location.

9F26 Application Cryptogram

Cryptogram returned by the card in response to the 1st Generate AC command

9F27 CID

Cryptogram Information Data which indicates the type of cryptogram generated by the chip card.

00 = AAC (declined) 40/50 = TC (approved) 80/90 = ARQC (go online)

9F33 Terminal Capabilities

Indicates the card data input, CVM and security capabilities of the terminal.

This field must match the value for the EMV kernel configuration being used for the transaction.

9F34 CVM Results Cardholder Verification Method Results

9F35 Terminal Type

Indicates the environment of the terminal, its communications capability and its operational control.

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.

9F37 Unpredictable Number

Value to provide variability and uniqueness to the generation of a cryptogram.

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

9F41 Transaction Sequence Counter

Counter maintained by the POS/Terminal that is incremented by one for each transaction.

9F53 Transaction Category Code

MasterCard/Europay code defining the type of transaction or industry sector in which the merchant operates.

84 Dedicated File Name

Identifies the name of the DF as described in ISO/IEC 7816-4.

Usually the same as AID (Tag 4F).

9F10 Issuer Application Data

Contains proprietary application data for transmission to the issuer in an online transaction.



Some tags hold sensitive data that the card brands dictate must not be passed in authorization messages as tags within the EMV chip data field. These fields are instead populated in equivalent existing sensitive data fields within messages. This ensures that this data remains protected by current PCI Compliance procedures

Sensitive Data Tags Tag Element Name Comments

5F24 Application Expiry Date

Date after which the application expires.

- Sent in Bit 14: Expiration Date

5F34 PAN Sequence Number

Application Primary Account Number (PAN) Sequence Number.

- Sent in Bit 23: Card Sequence Number

5A PAN Application Primary Account Number

- Sent in Bit 2: Cardholder Account Number fields

57 Track 2 Data Track 2 Equivalent Data

- Sent in Bit 35: Track 2 Data

9.3.2 Authorization Response EMV Tags The following tags may be included in host response messages. Tags will only be included if they contain data.

Authorization Response Message EMV Tags Tag Element Name Comments

8A Authorization Response Code

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 response message then the following values should be set in Tag 8A:

‘00’ (0x3030) – if the transaction was approved ‘05’ (0x3035) – if the transaction was declined

71 Issuer Script Template 1

Contains proprietary Issuer Script commands to be executed by the chip before the 2nd Generate AC command.

The Issuer Script must be provided to the EMV kernel for both approved and declined transactions.

72 Issuer Script Template 2

Contains proprietary Issuer Script commands to be executed by the chip after the 2nd Generate AC command completes.

The Issuer Script must be provided to the EMV kernel for both approved and declined transactions.



Authorization Response Message EMV Tags Tag Element Name Comments

91 Issuer Authentication Data

This tag contains the ARPC cryptogram used for online issuer authentication.

This tag must be provided to the EMV kernel so that it can be authenticated by the card.

9.3.3 Reversal EMV Tags This section outlines the EMV tags (in TLV format) that should be sent in the reversal messages.

BP 00903 Reversal messages should include all reversal EMV tags Chase Paymentech recommends that reversal messages include all defined reversal EMV tags, regardless of the transaction type or card used.

If a tag is not required, the Chase Paymentech host will ignore it.

Reversal Message EMV Tags Tag Element Name Comments





Format: YYMMDD

9C Transaction Type

Indicates the type of financial transaction, represented by the first two digits of ISO 8583: 1987 Processing Code.






840 = U.S. Dollars










9F03 Other Amount








840 = United States


A unique and permanent identification number of the chip POS/Terminal assigned by the manufacturer.



Cryptogram returned by the card in response to the 1st Generate AC command

9F27 CID






9F34 CVM Results Cardholder Verification Method Results.

9F35 Terminal Type


This field must match the value for the EMV kernel configuration being used for the transaction













Identifies the name of the DF as described in ISO/IEC 7816-4.

Usually the same as AID (Tag 4F).



9.3.4 Settlement EMV Tags This section outlines the EMV tags (in TLV format) that should be sent in the settlement messages.

BP 00904 Settlement messages should include all settlement EMV tags Chase Paymentech recommends that settlement messages include all defined settlement EMV tags, regardless of the transaction type or card used.

If a tag is not required, the Chase Paymentech host will ignore it.

Settlement Message EMV Tags Tag Element Name Comments


8A Authorization Response Code

Response code that indicates the final approved/declined status of the transaction.

‘00’ (0x3030) – if the transaction was approved ‘05’ (0x3035) – if the transaction was declined

91 Issuer Authentication Data

This tag contains the ARPC cryptogram used for online issuer authentication.




Format: YYMMDD




9C Transaction Type

Indicates the type of financial transaction, represented by the first two digits of ISO 8583: 1987 Processing Code.






840 = U.S. Dollars







9F03 Other Amount








840 = United States


A unique and permanent identification number of the chip POS/Terminal assigned by the manufacturer.



Cryptogram returned by the card in response to the 1st Generate AC command.

9F27 CID









9F34 CVM Results Cardholder Verification Method Results.

9F35 Terminal Type












Identifies the name of the DF as described in ISO/IEC 7816-4. Usually the same as AID (Tag 4F).



9F5B Issuer Script Results

The card records the results of scripts executed because Tag 71 or Tag 72 was received in an authorization response message. These results are sent to the host when the transaction is settled.

Mandatory for settlement if Issuer Script (Tag 71 or Tag 72) was received from the issuer in an authorization response.

9.4 Host Message Examples The following sections contain host EMV request and response message examples for each of the Chase Paymentech supported interfaces.

PNS ISO

PNS UTF

Stratus Online 7.4/ Stratus 120 Byte Batch



In the examples that follow, all PAN values have been blacked out and EMV Tag Numbers have been highlighted in grey.

9.4.1 PNS ISO Host Message Examples

Example #1: Visa Credit Sale - EFT (1200 & 1210) This is an example of a Visa Sale transaction.

The following is the request message sent by the EMV POS Solution.

ISO Visa Sale Request Message – Raw Data 31 32 30 30 70 18 46 80 28 C1 02 16 31 36 34 37 36 31 37 33 39 30 30 31 30 31 30 31 31 39 30 30 39 31 30 30 30 30 30 30 30 30 30 30 30 39 39 39 31 37 30 31 35 38 30 35 31 32 32 30 31 35 30 30 30 30 30 35 31 30 31 30 30 33 37 34 37 36 31 37 33 39 30 30 31 30 31 30 31 31 39 3D 32 32 31 32 32 30 31 31 31 37 35 38 39 38 39 33 38 39 30 30 30 30 30 30 30 30 30 30 30 30 30 36 30 30 32 37 30 30 30 30 30 30 30 34 30 32 34 30 34 30 41 37 31 34 41 30 30 30 30 30 30 30 30 33 31 30 31 30 44 31 30 32 33 36 32 33 39 32 33 36 38 32 30 32 31 38 30 30 39 35 30 35 38 30 38 30 30 30 38 30 30 30 39 41 30 33 31 35 30 35 31 32 39 43 30 31 30 30 35 46 32 41 30 32 30 38 34 30 39 46 30 32 30 36 30 30 30 30 30 30 30 30 30 39 39 39 39 46 30 39 30 32 30 30 38 43 39 46 31 41 30 32 30 38 34 30 39 46 32 31 30 33 31 37 30 31 34 30 39 46 32 36 30 38 43 42 34 31 41 45 32 46 43 33 37 42 44 30 39 41 39 46 32 37 30 31 38 30 39 46 33 33 30 33 45 30 46 38 43 38 39 46 33 34 30 33 35 45 30 30 30 30 39 46 33 35 30 31 32 32 39 46 33 36 30 32 30 30 31 35 39 46 33 37 30 34 43 44 35 41 34 45 34 31 39 46 34 31 30 34 30 30 30 30 30 30 30 35 38 34 30 37 41 30 30 30 30 30 30 30 30 33 31 30 31 30 39 46 31 30 30 37 30 36 30 31 30 41 30 33 41 30 32 30 30 30 30 32 36 41 31 30 32 31 30 30 30 30 30 30 30 30 30 30 37 20 20 20 20 20 20 20 20 20 20 30 36 38 50 31 30 32 38 30 30 30 41 30 30 41 41 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 50 32 30 33 30 37 41 41 30 30 30 30 30 30 30 30 30 30 30 30 30 30 43 38 30 42 39 35 34 31 30 30 32 30 38 30 33 31 52 32 30 32 36 30 30 30 30 30 37 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20

ISO Visa Sale Request Message – Formatted Message Type: 1200 Bit Map – Primary: 7018468028C10216 Bit Element Name Len. Value 02 Primary Acct Number 16 4761739001010119 03 Processing Code 06 009100 04 Amount, Transaction 12 000000000999 12 Time, Local Trans 06 170158 13 Date, Local Trans 08 05122015 18 Merchant Type 04 0000 22 POS Entry Mode 03 051 23 EMV/Ctls PAN Sequence Number 02 01 25 POS Condition Code 02 00 35 Track 2 Data 33 4761739001010119=221220111758989389 37 Retrieval Reference Number 12 000000000006 41 Card Acquirer Terminal ID 03 002 42 Card Acquirer ID 12 700000004024 48 Additional Data, Private Use Subtag Description Len. Value A7 EMV AID 14 A0000000031010 D1 Data Entry Source 02 36 P8 Enhanced Auth Req. No. 02 00



ISO Visa Sale Request Message – Formatted T2 EMV/Ctls Transaction Seq Ctr 06 000006 55 Chip Data 239 Tag Tag Name Len. Value 82 Application Interchange Profile 02 1800 95 Terminal Verification Results(TVR) 05 8080008000 9A Transaction Date 03 150512 9C Transaction Type 01 00 5F2A Transaction Currency Code 02 0840 9F02 Transaction Amount 06 000000000999 9F09 Application Version Number 02 008C 9F1A Terminal Country Code 02 0840 9F21 Transaction Time 03 170140 9F26 Application Cryptogram(AC) 08 CB41AE2FC37BD09A 9F27 Cryptogram Information Data 01 80 9F33 Terminal Capabilities 03 E0F8C8 9F34 Cardholder Ver Method(CVM) Result 03 5E0000 9F35 Terminal Type 01 22 9F36 Application Transaction Counter 02 0015 9F37 Unpredictable Number 04 CD5A4E41 9F41 Transaction Sequence Number 04 00000005 84 Dedicated File (DF) Name 07 A0000000031010 9F10 Issuer Application Data(IAD) 07 06010A03A02000 60 Reserved National 1 026 Subtag Description Len. Value A1 Chase Defined POS Data 021 Attended Terminal Data 02 00 Terminal Location 02 00 Cardholder Attendance 02 00 Card Present Indicator 01 0 Cardholder Activate Terminal(CAT) 02 00 Terminal Entry Capability 02 07 Filler 10 ^^^^^^^^^^ 62 Reserved Private – 2 058 Subtag Description Len. Value P1 POS/VAR Capabilities Data Set 1 028 Hardware / Vendor Identifier 04 000A Software Identifier 04 00AA Hardware Serial Number 20 ^^^^^^^^^^^^^^^^^^^^ P2 POS/VAR Capabilities Data Set 2 030 Element Name Len. Value Primary Bitmap 16 7AA0000000000000 2 - Host Processing Platform 02 0C 3 – Message Format Support 1 02 80 4 – EMV Support 02 B9 5 – Peripheral Information 1 02 54 7 – Communication Information 1 02 10 9 – Industry Information 1 02 02 11 – Class & Compliance Cert. 02 08 R2 Retail Industry Data 026 Invoice Number 06 000007 Trans. Information 20 ^^^^^^^^^^^^^^^^^^^^

The following is the response message returned by the Chase Paymentech host.

ISO Visa Sale Response Message – Raw Data



31 32 31 30 02 00 44 00 0E C1 82 04 30 35 31 32 32 30 31 35 31 37 30 32 30 32 35 39 39 39 30 35 31 30 30 30 30 30 30 30 30 30 30 30 36 30 35 35 35 36 31 30 30 30 30 32 37 30 30 30 30 30 30 30 34 30 32 34 30 38 32 51 38 30 33 30 30 4E 53 31 30 32 56 49 53 32 30 35 30 30 20 30 31 56 31 31 36 54 33 30 35 31 33 32 37 35 37 32 32 30 35 31 39 56 32 30 34 4D 57 34 4D 56 33 31 32 30 30 30 30 30 30 30 30 30 39 39 39 56 39 30 31 34 56 43 30 31 32 56 44 30 32 41 20 38 34 30 30 33 32 38 41 30 32 33 30 33 3039 31 30 41 44 32 39 34 42 46 35 46 46 39 32 45 33 37 41 39 33 30 33 30 30 32 31 48 31 30 31 36 31 33 32 30 30 30 30 30 31 31 30 30 30 30 30 31

ISO Visa Sale Response Message – Formatted Message Type: 1210 Bit Map – Primary: 020044000EC18204 Bit Element Name Len. Value 07 Transaction Date and Time 14 05122015170202 18 Merchant Type 04 5999 22 POS Entry Mode 03 051 37 Retrieval Reference Number 12 000000000006 38 Authorization ID Response 06 055561 39 Response Code 02 00 41 Card Acquirer Terminal ID 03 002 42 Card Acquirer ID 12 700000004024 48 Additional Data, Private Use 082 Subtag Description Len. Value Q8 Enhanced Auth. Response Indicator 03 00N S1 Card Type Information 02 VI S2 Authorization Response Information 05 00^01 V1 ChaseNet/Visa Auth. Inter. Data 16 T305132757220519 V2 ChaseNet/Visa Validation Code 04 MW4M V3 Total Authorization Amount 12 000000000999 V9 ChaseNet/Visa Authorization Source 01 4 VC EMV/Contactless Auth. Res. Cd. 01 2 VD ChaseNet/Visa Card Level Res. Cd. 02 A^ 49 Currency Code, Transaction 03 840 55 Chip Data 032 Tag Tag Name Len. Value 8A Authorization Response Code 02 3030 91 Issuer Authentication Data 10 D294BF5FF92E37A93030 62 Reserved Private – 2 021 Subtag Description Len. Value H1 Host Transaction Reference Info. 016 Julian Day 03 132 Batch Number 06 000001 Transaction Class 01 1 Sequence Number 06 000001

Example #2: MasterCard Authorization (1100 & 1110) This is an example of a MasterCard Authorization transaction. The transaction is approved and an Issue Script is returned.




ISO MasterCard Authorization Request Message – Formatted Message Type: 1100 Bit Element Name Len. Value 02 Primary Acct Number 16 5413330089020011 03 Processing Code 06 009100 04 Amount, Transaction 12 000000002000 12 Time, Local Trans 06 163007 13 Date, Local Trans 08 06102014 18 Merchant Type 04 5999 22 POS Entry Mode 03 051 23 EMV/Ctls PAN Sequence Number 02 03 25 POS Condition Code 02 00 35 Track 2 Data 33 5413330089020011=251260107936080 37 Retrieval Reference Number 12 111101922301 41 Card Acquirer Terminal ID 03 001 42 Card Acquirer ID 11 700000204093 48 Additional Data – Private Use 048 Subtag Description Len. Value A7 EMV/Ctls Trans AID 14 A0000000041010 D1 Data Entry Source 02 36 P2 Device ID, MC Term ID, etc 04 0001 P8 Enhanced Auth Req. No. 02 10 T2 EMV/Ctls Transaction Sequence Ctr 06 009223 55 Chip Data 259 Tag Tag Name Len. Value 82 Application Interchange Profile 02 3000 95 Terminal Verification Results(TVR) 05 0000008000 9A Transaction Date 03 140610 9C Transaction Type 01 00 5F2A Transaction Currency Code 02 0124 9F02 Transaction Amount 06 000000002000 9F03 Amount Other 06 000000000000 9F1A Terminal Country Code 02 0124 9F1E Interface Device Serial Number 08 3832313636343931 9F21 Transaction Time 03 163004 9F26 Application Cryptogram(AC) 08 EAF9B5ACC2A3C201 9F27 Cryptogram Information Data 01 80 9F33 Terminal Capabilities 03 E0B0C8 9F34 Cardholder Ver Method(CVM) Result 03 410302 9F35 Terminal Type 01 22 9F36 Application Transaction Counter 02 0027 9F37 Unpredictable Number 04 41205FB2 9F10 Issuer Application Data(IAD) 32 0210A0000000000000 0000000000000000FF 60 Reserved National 1 Subtag Description Len. Value A1 Chase Defined POS Data 021 Attended Terminal Data 02 00 Terminal Location 02 00 Cardholder Attendance 02 00 Card Present Indicator 01 0 Cardholder Activate Terminal(CAT) 02 00 Terminal Entry Capability 02 07 Filler 10 ^^^^^^^^^^ 62 Reserved Private – 2 Subtag Description Len. Value P1 POS/VAR Capabilities Data Set 1 028 Hardware / Vendor Identifier 04 002E



ISO MasterCard Authorization Request Message – Formatted Software Identifier 04 00DB Hardware Serial Number 20 1234567890^^^^^^^^^^ P2 POS/VAR Capabilities Data Set 2 028 Element Name Len. Value Primary Bitmap 16 6AA0000000000000 2 - Host Processing Platform 02 C4 3 – Message Format Support 1 02 80 5 – Peripheral Information 1 02 C0 7 – Communication Information 1 02 20 9 – Industry Information 1 02 02 11 – Class & Compliance Cert. 02 40 63 Reserved Private – 3 Subtag Description Len. Value R2 Retail Industry Data 26 Invoice Number 06 009223 Trans. Information 20 ^^^^^^^^^^^^^^^^^^^^

The following is response message returned by the Chase Paymentech host. The response includes and Issuer Script (Tag 71) that must be sent to the PIN Pad kernel for processing prior to the 2nd Generate AC.

ISO MasterCard Authorization Response Message – Formatted Message Type: 1110 Bit Element Name Len. Value 07 Transaction Date and Time 14 06102014163030 18 Merchant Type 04 5999 22 POS Entry Mode 03 051 37 Retrieval Reference Number 12 111101922301 38 Authorization ID Response 06 008548 39 Response Code 02 00 41 Card Acquirer Terminal ID 03 001 42 Card Acquirer ID 11 700000204093 48 Additional Data – Private Use Subtag Description Len. Value M1 MasterCard Auth. Interchange Data 17 AMCC0146610610NN^ Q8 Enhanced Auth. Response Indicator 03 00N S1 Card Type Information 02 MC S2 Authorization Response Information 05 00^02 X2 04 TEST 49 Currency Code, Transaction 3 124 55 Chip Data 066 Tag Tag Name Len. Value 71 Issuer Script Template 15 860D842400000886 82878DE3AE9127 8A Authorization Response Code 02 3030 91 Issuer Authentication Data 10 58F5E9A75669F1BA0012 62 Reserved Private – 2 Subtag Description Len. Value H1 21 1560000012000164 X1 04 TEST



Example #3: Reversal Advice / Authorization Reversal (1420 & 1430) The following is the Reversal Advice message sent by the EMV POS Solution.

ISO MasterCard Reversal Advice Message – Formatted Message Type: 1420 Bit Element Name Len. Value 02 Primary Acct Number 16 5413330089020011 03 Processing Code 06 009100 04 Amount, Transaction 12 000000010000 12 Time, Local Trans 06 163945 13 Date, Local Trans 08 06102014 14 Date, Expiration 04 2512 22 POS Entry Mode 03 011 25 POS Condition Code 02 00 37 Retrieval Reference Number 12 111101922604 41 Card Acquirer Terminal ID 03 001 42 Card Acquirer ID 11 700000204093 48 Additional Data – Private Use 048 Subtag Description Len. Value A7 EMV/Ctls Trans AID 14 A0000000041010 D1 Data Entry Source 02 46 P2 Device ID, MC Term ID, etc 04 0001 P8 Enhanced Auth Req. No. 02 10 R1 Customer Defined Data Field 22 ^^^^^^^^^^^^^^^^^^^^^^ R3 Recurring Payment Indicator 01 34 55 Chip Data 259 Tag Tag Name Len. Value 82 Application Interchange Profile 02 3000 95 Terminal Verification Results(TVR) 05 0000008000 9A Transaction Date 03 140610 9C Transaction Type 01 00 5F2A Transaction Currency Code 02 0124 9F02 Transaction Amount 06 000000010000 9F03 Amount Other 06 000000000000 9F1A Terminal Country Code 02 0124 9F1E Interface Device Serial Number 08 3832313636343931 9F21 Transaction Time 03 163941 9F26 Application Cryptogram(AC) 08 7BE6C43156D6D7C1 9F27 Cryptogram Information Data 01 00 9F33 Terminal Capabilities 03 E0B0C8 9F34 Cardholder Ver Method(CVM) Result 03 410302 9F35 Terminal Type 01 22 9F36 Application Transaction Counter 02 0027 9F37 Unpredictable Number 04 FD32C598 9F10 Issuer Application Data(IAD) 32 021060000000000000 0000000000000000FF 60 Reserved National 1 Subtag Description Len. Value A1 Chase Defined POS Data 021 Attended Terminal Data 02 00 Terminal Location 02 00 Cardholder Attendance 02 00 Card Present Indicator 01 0 Cardholder Activate Terminal(CAT) 02 00 Terminal Entry Capability 02 07 Filler 10 ^^^^^^^^^^ 62 Reserved Private – 2 Subtag Description Len. Value



ISO MasterCard Reversal Advice Message – Formatted P1 POS/VAR Capabilities Data Set 1 028 Hardware / Vendor Identifier 04 002E Software Identifier 04 00DB Hardware Serial Number 20 1234567890^^^^^^^^^^ P2 POS/VAR Capabilities Data Set 2 028 Element Name Len. Value Primary Bitmap 16 6AA0000000000000 2 - Host Processing Platform 02 C4 3 – Message Format Support 1 02 80 5 – Peripheral Information 1 02 C0 7 – Communication Information 1 02 20 9 – Industry Information 1 02 02 11 – Class & Compliance Cert. 02 40 90 Original Transaction Data Field Name Len. Value Original Message Type 04 1100 Original Trace Number 08 ^^^^^^^^ Original Transmission Date & Time 12 000000000000 Filler 22 ^^^^^^^^^^^^^^^^^^^^^^

The following is response message returned by the Chase Paymentech host.

ISO MasterCard Authorization Reversal Message – Formatted Message Type: 1430 Bit Element Name Len. Value 07 Transaction Date and Time 14 06102014164037 37 Retrieval Reference Number 12 111101922604 39 Response Code 02 00 41 Card Acquirer Terminal ID 03 001 42 Card Acquirer ID 11 700000204093 48 Additional Data – Private Use Subtag Description Len. Value M1 MasterCard Auth. Interchange Data 17 AMCC0146630610^N^ S1 Card Type Information 02 MC S2 Authorization Response Information 05 00^02 Y5 04 TEST 49 Currency Code, Transaction 03 124 55 Chip Data Tag Tag Name Len. Value 8A Authorization Response Code 02 3030 62 Reserved Private – 2 Subtag Description Len. Value H1 Host Transaction Reference Info 16 1560000012000167 X1 04 TEST



9.4.2 UTF Host Message Examples

Example #1: UTF MasterCard Retail Sale with Issuer Script This is an example of a MasterCard Sale transaction. The transaction is approved and an Issue Script is returned.


In the raw trace below, grey text highlights an EMV Tag and a “^” represents an ASCII space (x’20’).

UTF MasterCard Retail Sale Request Message – Raw Data [STX]L.A0200000027000000003052101001183F011365413330089020011=2512601079360805[FS]20.00[FS]00000000[FS][FS][FS]00410000700000000000000000000[FS][FS][FS][FS][FS][FS][FS]DP0006[FS]P811[FS]P1001900EB168299900[FS]P27AA00000000000000C40BB64200248[FS]RN100007140026[FS]EM25682023000950500000080009A031504279C01005F2A0208409F02060000000020009F03060000000000009F1A0208409F1E0836383239393930309F21031400419F2608EB6B27D35FCEA8F19F2701809F3303E0F8C89F34034103029F3501229F360200279F37044DF88E009F10120210A00000000000000000000000000000FF[FS]PS03[FS]AIA0000000041010[ETX]

UTF MasterCard Retail Sale Request Message – Formatted All fields are required unless marked with an asterisk(*) Formats: X = Alphanumeric; 9 = Numeric Lengths: v indicates variable length Values: “^” = a blank character (‘20’hex); ETX = ‘03’hex; FS = ‘1C’hex; STX =‘02’hex; Component A – Header Information Field Description Form,Len Value 01 Start of Text X,1 ‘02’h 02 System Indicator X,2 L. 03 Routing Indicator X,6 A02000 04 Client Number 9,4 0002 05 Merchant Number 9,12 700000000305 06 Terminal Number 9,3 210 07 Transaction Sequence Flag 9,1 1 08 Sequence Number 9,6 001183 09 Transaction Class X,1 F 10 Transaction Code 9,2 01 11 PIN Capability Code 9,1 1 12 Data Entry Source 9,2 36 Component B – Cardholder Account Information 01 Full Mag Stripe Info X,76v 5413330089020011=2512601079360805 02 FS X,1 ‘1C’h Component C – Transaction Information 01 Transaction Amount X,9v 20.00 02 FS X,1 ‘1C’h 03 Filler – LRR# 9,8 00000000 04 FS X,1 ‘1C’h Component D – Market Specific 01* Market Specific Data Ind. X,1 02 FS X,1 ‘1C’h 03 FS X,1 ‘1C’h



UTF MasterCard Retail Sale Request Message – Formatted Component F – Industry Specific 01 Industry Code 9.3 004 02 Invoice Number 9.6 100007 03 Item Code 9.20 00000000000000000000 Component G – Miscellaneous Information 01 FS X,1 ‘1C’h 02 FS X,1 ‘1C’h 03 FS X,1 ‘1C’h Component H – Address Verification Information 01* Cardholder Street Address X,20v 02* Extended Cardholder Address X,20v 03 FS X,1 ‘1C’h 04* Cardholder ZIP Code X,9v 05 FS X,1 ‘1C’h Component I - Purchasing Card Information 01* Customer Reference Number X,17 02* Local Tax Flag 9,1 03* Filler X,1 04* Destination ZIP Code X,9 05* Sales Tax Amount X,9 06 FS X,1 ‘1C’h Component J – Token Data Token Dev./Pump/Lane/MC Term. X,2 DP Device ID X,2 00 Pump ID X,2 06 FS X,1 ‘1C’h Token Enhanced Auth. Request X,2 P8 Auth Type Request Ind. 9,2 11 FS X,1 ‘1C’h Token POS/VAR Cap. Set 1 Ind. X,2 P1 Hardware Vendor Identifier X,4 0019 Software Identifier X,4 00EB Hardware Serial Number X,20 168299900^^^^^^^^^^^ FS X,1 ‘1C’h Token POS/VAR Cap. Set 2 Ind. X,2 P2 Primary Bit Map X,16 7AA0000000000000 Host Processing Platform X,2 0C Message Format Support X,2 40 EMV Support X,2 BB Peripheral Information X,2 64 Communication Information 1 X,2 20 Industry Information 1 X,2 02 Class & Compliance Cert. X,2 48 FS X,1 ‘1C’h Token POS Retrieval Ref. Num. X,2 RN POS Retrieval Ref. Num. X,12 100007140026 FS X,1 ‘1C’h Token Chip Card Data X,2 EM Chip Card Data Length 9,3 256 Chip Card Data Tag Tag Name Len. Value 82 Application Interchange Profile 02 3000 95 Terminal Verification Results(TVR) 05 0000008000 9A Transaction Date 03 150427 9C Transaction Type 01 00 5F2A Transaction Currency Code 02 840 9F02 Transaction Amount 06 000000002000 9F03 Amount Other 06 000000000000



UTF MasterCard Retail Sale Request Message – Formatted 9F1A Terminal Country Code 02 840 9F1E Interface Device Serial Number 08 3638323939393030 9F21 Transaction Time 03 140041 9F26 Application Cryptogram(AC) 08 EB6B27D35FCEA8F1 9F27 Cryptogram Information Data 01 80 9F33 Terminal Capabilities 03 E0F8C8 9F34 Cardholder Ver Method(CVM) Result 03 410302 9F35 Terminal Type 01 22 9F36 Application Transaction Counter 02 0027 9F37 Unpredictable Number 04 4DF88E00 9F10 Issuer Application Data(IAD) 32 0210A00000000000 00000000000000FF FS X,1 ‘1C’h Token PAN Sequence Number X,2 PS PAN Sequence Number 9,2 03 FS X,1 ‘1C’h Token AID X,2 AI AID X,32v A0000000041010 Component K – End Of Packet 01 ETX X,1 ‘03’h 02 LRC X,1v Calculated

The following is response message returned by the Chase Paymentech host. The response includes and Issuer Script (Tag 71) that must be sent to the PIN Pad kernel for processing prior to the 2nd Generate AC.


UTF MasterCard Retail Sale Response Message – Raw Data [STX]A^01157711700100000003001183APPROVED^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^MC[FS]AMCC0115LR0427^^^5969[FS]02^[FS][FS][FS][FS][FS][FS][FS][FS]Q800N^^^^^^^^^^^^[FS]EM066710F860D84240000082CF597E585C0F1CD8A023030910A9D8956A40067382A0012[FS]RN100007140026[FS][ETX]

UTF MasterCard Retail Sale Response Message – Formatted All fields are required unless marked with an asterisk(*) Formats: X = Alphanumeric; 9 = Numeric Lengths: v indicates variable length Values: “^” = a blank character (‘20’ hex); ETX = ‘03’hex; FS = ‘1C’hex; STX =‘02’hex; Credit Card Authorization Response – Host to Terminal Field Description Form,Len Value 01 Start of Text X,1 ‘02’h 02 Action Code X,1 A 03 Address Verification Resp. Cd. X,1 ^ 04 Authorization/Error Code X,6 011577 05 Batch Number 9,6 117001 06 Retrieval Reference Number 9,8 00000003 07 Transaction Sequence Number 9,6 001183 08 Response Message X,32 APPROVED^^^^^^^^^^^^^^^^^^^^^^^^ 09 Card Type X,2 MC 10 FS X,1 ‘1C’h 11* Interchange Compliance X,40v Authorization Char. Ind. X,1 A BankNet Reference Number X,9 MCC0115LR



UTF MasterCard Retail Sale Response Message – Formatted BankNet Date 9,4 0427 CVC Error Indicator X,1 ^ CVC Status Change X,1 ^ Mag Stripe Quality Ind. X,1 ^ Merchant Category Code 9,4 5969 12 FS X,1 ‘1C’h 13 Authorizing Network ID 9,2 02 14 Authorization Source X,1 ^ 15 FS X,1 ‘1C’h 16 FS X,1 ‘1C’h 17* Optional Data X,120 18 FS X,1 ‘1C’h 19 FS X,1 ‘1C’h 20 FS X,1 ‘1C’h 21 FS X,1 ‘1C’h 22 FS X,1 ‘1C’h 23 FS X,1 ‘1C’h Component J – Token Data Token Auth Type Resp. Ind. X,2 Q8 Auth Type Code X,2 00 Card Type X,1 N *Authorized Amount X,12 ^^^^^^^^^^^^ FS X,1 ‘1C’h Token Chip Card Data X,2 EM Chip Card Data Length 9,3 066 Chip Card Data Tag Tag Name Len. Value 71 Issuer Script 15 860D84240000082C F597E585C0F1CD 8A Authorization Response Code 02 3030 91 Issuer Authentication Data 08 9D8956A40067382A0012 FS X,1 ‘1C’h Token POS Retrieval Ref. Ind. X,2 RN POS Retrieval Ref Num. X,12 100007140026 FS X,1 ‘1C’h Component K – End Of Packet 01 ETX X,1 ‘03’h 02 LRC X,1v Calculated



Example #2: UTF Visa Retail Sale Request This is an example of a purchase reversal transaction that is approved by the host.



UTF Visa Retail Sale Request Message – Raw Data [STX]L.A0200000027000000003052101000085F011364761739001010119=15122011758989389[FS]12.00[FS]00000000[FS][FS][FS]00410009500000000000000000000[FS][FS][FS][FS][FS][FS][FS]DP0006[FS]P811[FS]P1001900EB168299900^^^^^^^^^^^[FS]P27AA00000000000000C40BA64200248[FS]RN100095110341[FS]EM21282025C00950500000080009A031502179C01005F2A0208409F02060000000012009F03060000000000009F1A0208409F21031103579F2608805CAF473D8794C29F2701809F3303E0B8C8031E03009F34031E03009F3501229F360200019F37045B8C88669F100706010A03A00000[FS]PS01[FS]AIA0000000031010[ETX]

UTF Visa Retail Sale Request Message – Formatted All fields are required unless marked with an asterisk(*) Formats: X = Alphanumeric; 9 = Numeric Lengths: v indicates variable length Values: “^” = a blank character (‘20’ hex); ETX = ‘03’hex; FS = ‘1C’hex; STX =‘02’hex; Component A – Header Information Field Description Form,Len Value 01 Start of Text X,1 ‘02’h 02 System Indicator X,2 L. 03 Routing Indicator X,6 A02000 04 Client Number 9,4 0002 05 Merchant Number 9,12 700000000305 06 Terminal Number 9,3 210 07 Transaction Sequence Flag 9,1 1 08 Sequence Number 9,6 000085 09 Transaction Class X,1 F 10 Transaction Code 9,2 01 11 PIN Capability Code 9,1 1 12 Data Entry Source 9,2 36 Component B – Cardholder Account Information 01 Full Mag Stripe Info X,76v 4761739001010119=15122011758989389 02 FS X,1 ‘1C’h Component C – Transaction Information 01 Transaction Amount X,9v 12.00 02 FS X,1 ‘1C’h 03 Filler – LRR# 9,8 00000000 04 FS X,1 ‘1C’h Component D – Market Specific 01* Market Specific Data Ind. X,1 02 FS X,1 ‘1C’h 03 FS X,1 ‘1C’h Component F – Industry Specific 01 Industry Code 9.3 004 02 Invoice Number 9.6 100095 03 Item Code 9.20 00000000000000000000 Component G – Miscellaneous Information 01 FS X,1 ‘1C’h 02 FS X,1 ‘1C’h



UTF Visa Retail Sale Request Message – Formatted 03 FS X,1 ‘1C’h Component H – Address Verification Information 01* Cardholder Street Address X,20v 02* Extended Cardholder Address X,20v 03 FS X,1 ‘1C’h 04* Cardholder ZIP Code X,9v 05 FS X,1 ‘1C’h Component I - Purchasing Card Information 01* Customer Reference Number X,17 02* Local Tax Flag 9,1 03* Filler X,1 04* Destination ZIP Code X,9 05* Sales Tax Amount X,9 06 FS X,1 ‘1C’h Component J – Token Data Token Dev./Pump/Lane/MC Term. X,2 DP Device ID X,2 00 Pump ID X,2 06 FS X,1 ‘1C’h Token Enhanced Auth. Request X,2 P8 Auth Type Request Ind. 9,2 11 FS X,1 ‘1C’h Token POS/VAR Cap. Set 1 Ind. X,2 P1 Hardware Vendor Identifier X,4 0019 Software Identifier X,4 00EB Hardware Serial Number X,20 168299900^^^^^^^^^^^ FS X,1 ‘1C’h Token POS/VAR Cap. Set 2 Ind. X,2 P2 Primary Bit Map X,16 7AA0000000000000 Host Processing Platform X,2 0C Message Format Support X,2 40 EMV Support X,2 BA Peripheral Information X,2 64 Communication Information 1 X,2 20 Industry Information 1 X,2 02 Class & Compliance Cert. X,2 48 FS X,1 ‘1C’h Token POS Retrieval Ref. Num. X,2 RN POS Retrieval Ref. Num. X,12 100095110341 FS X,1 ‘1C’h Token Chip Card Data X,2 EM Chip Card Data Length 9,3 212 Chip Card Data Tag Tag Name Len. Value 82 Application Interchange Profile 02 5C00 95 Terminal Verification Results(TVR) 05 0000008000 9A Transaction Date 03 150217 9C Transaction Type 01 00 5F2A Transaction Currency Code 02 840 9F02 Transaction Amount 06 000000001200 9F03 Amount Other 06 000000000000 9F1A Terminal Country Code 02 840 9F21 Transaction Time 03 110357 9F26 Application Cryptogram(AC) 08 805CAF473D8794C2 9F27 Cryptogram Information Data 01 80 9F33 Terminal Capabilities 03 E0B8C8 9F34 Cardholder Ver Method(CVM) Result 03 1E0300 9F35 Terminal Type 01 22 9F36 Application Transaction Counter 02 0001



UTF Visa Retail Sale Request Message – Formatted 9F37 Unpredictable Number 04 5B8C8866 9F10 Issuer Application Data(IAD) 07 06010A03A00000 FS X,1 ‘1C’h Token PAN Sequence Number X,2 PS PAN Sequence Number 9,2 01 FS X,1 ‘1C’h Token AID X,2 AI AID X,32v A0000000031010 Component K – End Of Packet 01 ETX X,1 ‘03’h 02 LRC X,1v Calculated

The host approves the transaction and sends the following response.


UTF Visa Retail Sale Response Message – Raw Data [STX]A^07764904800100000053000085APPROVED^^^^^^^^^^^^^^^^^^^^^^^^VI[FS]T305048725150284B5GK00596905^^000012.00^[FS]014[FS][FS][FS][FS][FS][FS][FS][FS]Q800N^^^^^^^^^^^^[FS]EM0328A023030910AFF2D9021BE1D94C43030[FS]CR2[FS]RN100095110341[FS]VCA [FS][ETX]

UTF Visa Retail Sale Response Message – Formatted All fields are required unless marked with an asterisk(*) Formats: X = Alphanumeric; 9 = Numeric Lengths: v indicates variable length Values: “^” = a blank character (‘20’ hex); ETX = ‘03’hex; FS = ‘1C’hex; STX =‘02’hex; Credit Card Authorization Response – Host to Terminal Field Description Form,Len Value 01 Start of Text X,1 ‘02’h 02 Action Code X,1 A 03 Address Verification Resp. Cd. X,1 ^ 04 Authorization/Error Code X,6 077649 05 Batch Number 9,6 048001 06 Retrieval Reference Number 9,8 00000053 07 Transaction Sequence Number 9,6 000085 08 Response Message X,32 APPROVED^^^^^^^^^^^^^^^^^^^^^^^^ 09 Card Type X,2 VI 10 FS X,1 ‘1C’h 11 Interchange Compliance X,40v Authorization Char. Ind. X,1 T Transaction ID 9,15 305048725150284 Validation Code X,4 B5GK Authorization Response Code X,2 00 Merchant Category Code 9,4 5969 POS Entry Mode X,2 05 Commercial Card Type X,1 ^ Filler X,1 ^ Total Authorization Amount X,9 000012.00 AVS Response Code X,1 ^ 12 FS X,1 ‘1C’h 13 Authorizing Network ID 9,2 01 14 Authorization Source X,1 4 15 FS X,1 ‘1C’h



UTF Visa Retail Sale Response Message – Formatted 16 FS X,1 ‘1C’h 17* Optional Data X,120 18 FS X,1 ‘1C’h 19 FS X,1 ‘1C’h 20 FS X,1 ‘1C’h 21 FS X,1 ‘1C’h 22 FS X,1 ‘1C’h 23 FS X,1 ‘1C’h Component J – Token Data Token Auth Type Resp. Ind. X,2 Q8 Auth Type Code X,2 00 Card Type X,1 N *Authorized Amount X,12 ^^^^^^^^^^^^ FS X,1 ‘1C’h Token Chip Card Data X,2 EM Chip Card Data Length 9,3 032 Chip Card Data Tag Tag Name Len. Value 8A Authorization Response Code 02 3030 91 Issuer Authentication Data 10 FF2D9021BE1D94C43030 FS X,1 ‘1C’h Token Card Auth. Res. Cd. Ind. X,2 CR ChaseNet/Visa Auth Cd. X,1 2 FS X,1 ‘1C’h Token POS Retrieval Ref. Ind. X,2 RN POS Retrieval Ref Num. X,12 100095110341 FS X,1 ‘1C’h Token ChaseNet/Visa ResCdInd. X,2 VC ChaseNet/Visa Res Cd. X,2 A^ FS X,1 ‘1C’h Component K – End Of Packet 01 ETX X,1 ‘03’h 02 LRC X,1v Calculated



Example #3: UTF Reversal Advice This is an example of a Reversal Advice transaction that is transmitted to the host.


In the raw trace below, a “^” represents an ASCII space (x’20’).

UTF Visa Reversal Advice Message – Raw Data [STX]L.A0200000027000000003052101000085F461465413330089010475[FS]1225[FS]22.22[FS][FS][FS][FS][FS][FS][FS][FS][FS][FS]DP0006[FS]TC01[FS]RR4[FS]P1001900EB168299900^^^^^^^^^^^[FS]P27AA00000000000000C40BA64200248[FS]RN100077093844[FS][ETX]

UTF Visa Reversal Advice Message – Formatted All fields are required unless marked with an asterisk(*) Formats: X = Alphanumeric; 9 = Numeric Lengths: v indicates variable length Values: “^” = a blank character (‘20’ hex); ETX = ‘03’hex; FS = ‘1C’hex; STX =‘02’hex; Component A – Header Information Field Description Form,Len Value 01 Start of Text X,1 ‘02’h 02 System Indicator X,2 L. 03 Routing Indicator X,6 A02000 04 Client Number 9,4 0002 05 Merchant Number 9,12 700000000305 06 Terminal Number 9,3 210 07 Transaction Sequence Flag 9,1 1 08 Sequence Number 9,6 000085 09 Transaction Class X,1 F 10 Transaction Code 9,2 46 11 PIN Capability Code 9,1 1 12 Data Entry Source 9,2 46 Component B – Cardholder Account Information 01 Account Number X,16v 5413330089010475 02 FS X,1 ‘1C’h 03 Expiration Date 9,4 1225 04 FS X,1 ‘1C’h Component C – Transaction Information 01 Transaction Amount X,9v 22.22 02 FS X,1 ‘1C’h 03 FS X,1 ‘1C’h 04 FS X,1 ‘1C’h 05 FS X,1 ‘1C’h 06 FS X,1 ‘1C’h 07 FS X,1 ‘1C’h 08 FS X,1 ‘1C’h 09 FS X,1 ‘1C’h 10 FS X,1 ‘1C’h 11 FS X,1 ‘1C’h Component J – Token Data Token Dev./Pump/Lane/MC Term. X,2 DP Device ID X,2 00 Pump ID X,2 06 FS X,1 ‘1C’h Token Reversal Advice X,2 TC Original Transaction Code X,2 01



UTF Visa Reversal Advice Message – Formatted FS X,1 ‘1C’h Token Reversal Reason. X,2 RR Reversal Reason Code 9,1 4 Token POS/VAR Cap. Set 1 Ind. X,2 P1 Hardware Vendor Identifier X,4 0019 Software Identifier X,4 00EB Hardware Serial Number X,20 168299900^^^^^^^^^^^ FS X,1 ‘1C’h Token POS/VAR Cap. Set 2 Ind. X,2 P2 Primary Bit Map X,16 7AA0000000000000 Host Processing Platform X,2 0C Message Format Support X,2 40 EMV Support X,2 BA Peripheral Information X,2 64 Communication Information 1 X,2 20 Industry Information 1 X,2 02 Class & Compliance Cert. X,2 48 FS X,1 ‘1C’h Token POS Retrieval Ref. Num. X,2 RN POS Retrieval Ref. Num. X,12 100077093844 FS X,1 ‘1C’h Component K – End Of Packet 01 ETX X,1 ‘03’h 02 LRC X,1v Calculated



9.4.3 Stratus Host Message Examples

Example #1: MasterCard Authorization This is an example of a MasterCard Authorization transaction.

The following is the message sent by the EMV POS Solution.


Stratus Online 7.4 MasterCard Authorization Message – Raw Data P74VEMVÔNLINE^^^^^^^^^^^MC5309040390013129^^^01150000096525000000005600840R^^^ÂU^CP24682023000950580009A031406109C0105F2A021249F020656009F030609F1A021249F1E0838323136363439309F1E0838323136363439309F21031639419F26087BE6C43156D6D7C19F270109F3303E0B0C89F34034103029F3501229F3602279F3704FD32C5989F1032210600000000000000000000000000000FFR248142DEVKIOSKR32902365309040390013129=1711000000000000000

Stratus Online 7.4 MasterCard Authorization Message – Formatted All fields are required unless marked with an asterisk(*) All alpha characters should be in UPPERCASE Formats: X = Alphanumeric; 9 = Numeric Lengths: v indicates variable length Values: “^” = a blank character (‘20’hex) Pos Field Name Len. Content 001 Record Type 01 P 002 Format Constant 02 74 004 Format Constant 01 V 005 Merchant’s Order Number 22 EMVÔNLINE^^^^^^^^^^ 027 Method of Payment 02 MC 029 Account Number 19 5309040390013129^^^ 048 Expiry Date 04 0115 052 Transaction Division Number 10 0000096525 062 Transaction Amount 12 000000005600 074 Currency Code 03 840 077 Transaction Type 01 R 078 *Encryption Flag 03 ^^^ 081 *Payment Indicator 01 ^ 082 Action Code 02 AU 084 Reserved for Chase use 01 ^ (must be left blank) 085 Chip EMV Data Variable Format Indicator CP Size of Chip Data 246 Chip Data Tag Description ID Len. Value Application Interchange Profile 82 02 3000 Terminal Verification Results(TVR) 95 05 0000008000 Transaction Date 9A 03 140610 Transaction Type 9C 01 00 Transaction Currency Code 5F2A 02 0124 Transaction Amount 9F02 06 000000005600 Amount Other 9F03 06 000000000000 Terminal Country Code 9F1A 02 0124 Interface Device Serial Number 9F1E 08 3832313636343931 Transaction Time 9F21 03 163941



Stratus Online 7.4 MasterCard Authorization Message – Formatted Application Cryptogram(AC) 9F26 08 7BE6C43156D6D7C1 Cryptogram Information Data 9F27 01 00 Terminal Capabilities 9F33 03 E0B0C8 Cardholder Ver Method(CVM) Result 9F34 03 410302 Terminal Type 9F35 01 22 Application Transaction Counter 9F36 02 0027 Unpredictable Number 9F37 04 FD32C598 Issuer Application Data(IAD) 9F10 32 021060000000000000 0000000000000000FF 331 Retail 2 Data Variable Format Indicator R2 Merchant Category Code 4814 Category Type 2 Terminal ID DEVKIOSK 123 Retail 3 Data Variable Format Indicator R3 POS Capability Code 2 POS Entry Mode 90 Track Indicator 2 Swipe Data Length 6 Swipe Data 5309040390013129=1711000000000000000

EMV Implementation Guide EMV Receipt Guidelines


10. EMV Receipt Guidelines

10.1 EMV Receipt Data The following table outlines EMV information for transaction receipts. The information shown may be printed in any order.

The information in the table below identifies the optional and required EMV specific receipt information requirements.

EMV Receipt Information Field Description

Application Label or Name

(REQUIRED)

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:

Application Preferred Name (Tag 9F12) should be printed if possible If 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, then Application Label (Tag 50) should be printed

The Payment brands mandate either the Application Label or the Application Preferred Name be printed on the receipt

Note: If the Issuer Code Table Index (Tag 9F11) is set to ‘1’, it indicates that the Application Preferred Name is encoded using the Latin character set (i.e. contains standard English alphabetic characters).

Card Entry Mode

(OPTIONAL)

Indicator identifying how the card information was obtained.

Printed Text Usage Chip Card information read from EMV chip

Contactless Card information read by a contactless reader Chip/Swiped Fallback swipe (insert was attempted but failed)

Keyed or Manual Manually entered card number and expiry date

Swiped Card swiped (not Fallback – insert was not attempted)

Transaction Total

(REQUIRED)

The receipt total line must reflect the final transaction amount including any card discounts that may have been applied.

Note: If card discounts were applied, this amount may not match the amount stored in Transaction Amount (Tag 9F02).

Cardholder Verification

(OPTIONAL)

Identifies the Cardholder Verification Method (CVM) used for the transaction:

If a PIN was entered “Verified by PIN” may be printed If NO CVM, “No Signature Required” may be printed If signature was electronically captured, the receipt may state as such



EMV Receipt Information Field Description

Signature

(REQUIRED)

If the CVM includes a signature

A signature line must be printed or A signature may be captured electronically

EMV Tag Data

(OPTIONAL)

Several EMV tag values may be printed on the merchant copy of receipts to assist in problem resolution. These fields must be printed in the order shown and should be identified by their tag name. If not printed at the time of the transaction then it is recommended that the information be stored for later trouble shooting if needed.

Name Tag Description TVR 95 Terminal Verification Results TSI 9B Transaction Status Indicator AC 9F26 Application Cryptogram ARC 8A Application Response Code

EMV Tag Data

(REQUIRED)

The AID is required by EMVCo to be printed on all receipts.

Name Tag Description AID 4F Application Identifier

The cardholder account number should be masked and the expiration date suppressed on all receipts, regardless of the card type or payment brand mandate. This applies to both U.S. and Canadian receipts.

The merchant and cardholder receipts need not contain the same information.

Merchant and Cardholder Receipt Requirements Field Merchant Receipt Cardholder Receipt Application Label Required Required Card Entry Mode Recommended Recommended Transaction Total Required Required Cardholder Verification Recommended Recommended Signature Line Required (if Signature CVM) Not needed EMV Tag Data Recommended Not Recommended AID Required Required

01001 Application Name or Label must be printed on the receipt

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



01002 Transaction amount must be printed on the receipt

Chase Paymentech requires that the receipt includes the final transaction amount including card discounts (if any).

01003 AID must be printed on the receipt

Chase Paymentech requires that all receipts contain “AID”, “TVR”, “AC”, “TSI” and “ARC” labels followed by their tag values. This information must be printed in the order shown.

10.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 receipt 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 all guidelines for non-EMV receipts.

For sample Canadian French receipts see Appendix “A” page 272.



10.2.1 Credit Card (Online Approved – Signature) The following is an example of a receipt for a credit transaction approved online by the host. The CVM used was signature and the Track 2 information was obtained from a contactless EMV card.

Merchant Name Merchant Street City, State Code

Zip Code Phone

Merchant ID: 999999999999 Term ID: 12345678 Ref #: 999 Clerk ID: 01234 Shift #: 2

Sale

xxxxxxxxxxxx8106 VISA CREDIT ENTRY METHOD: Contactless MM/DD/YYYY HH:MM:SS Cust Ref #: 999 Batch #: 999999

Amount: $75.01 ========= Total: $75.01

APPROVED 123456

AID: A0000000031010 TVR: 0000008000 TSI: E800 AC: 0123456789ABCDEF ARC: 00

I AGREE TO PAY THE ABOVE TOTAL AMOUNT ACCORDING TO CARD ISSUER AGREEMENT (MERCHANT AGREEMENT IF CREDIT VOUCHER)

X_________________________________________ Cardholder Signature

MERCHANT COPY / CUSTOMER COPY Footer 1 Footer 2 Footer 3

EMV Receipt Requirements Transaction Type (Sale)

Application Preferred Name (Tag 9F12) is present on card in a supported characters set so it must be printed (VISA CREDIT)

Card Entry Method indicates that card information was obtained from a contactless tap (Contactless)

Application PAN (Tag 5A) must be masked and printed (************8106)

The final authorized transaction amount must be printed (75.01)

EMV Information must be printed in the order shown and identified by the tag names: o AID (A0000000031010) o TVR (0000008000) o TSI (E800) o AC (0123456789ABCDEF) o ARC (00)

Cardholder Verification Method was “Signature” so a Signature Line must be printed

EMV Receipt Best Practices

Merchant and Customer receipt copies should be identical with the exception of the receipt copy indicator



Footer 4

10.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 online PIN and card track data 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.


Zip Code Phone


Sale

xxxxxxxxxxxx8106 VISA Credit ENTRY METHOD: Chip MM/DD/YYYY HH:MM:SS Cust Ref #: 999 Batch #: 999999

Amount: $75.02 ========= Total: $75.02

APPROVED 123456

Verified By PIN

BY ENTERING A VERIFIED PIN, CARDHOLDER AGREES TO PAY ISSUER SUCH TOTAL IN ACCORDANCE WITH ISSUER’S AGREEMENT WITH CARDHOLDER AID: A0000000031010 TVR: 0000008000 TSI: F800 AC: 0123456789ABCDEF ARC: 00

MERCHANT COPY / CUSTOMER COPY Footer 1


Application Preferred Name (Tag 9F12) is not on the chip or present in an unsupported characters set, so the Application Label (Tag 50) must be printed (Visa Credit)


Card Entry Method indicates card was inserted and card information was read from the contact chip (Chip)


EMV Information must be printed in the order shown and identified by the tag names: o AID (A0000000031010) o TVR (0000008000) o TSI (F800) o AC (0123456789ABCDEF) o ARC (00

Transaction is approved so the host approval code must be printed (123456)

Cardholder Verification Method – A PIN was entered so “Verified by PIN” must be printed





10.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 (2xx or 6xx) but there was a chip read error so the card was swiped and the transaction was completed as a Technical Fallback transaction.


Zip Code Phone


Sale

xxxxxxxxxxxx8106 VISA ENTRY METHOD: Chip/Swiped MM/DD/YYYY HH:MM:SS Cust Ref #: 999 Batch #: 999999

Amount: $75.03 ========= Total: $75.03

APPROVED 123456

I AGREE TO PAY THE ABOVE TOTAL AMOUNT ACCORDING TO CARD ISSUER AGREEMENT (MERCHANT AGREEMENT IF CREDIT VOUCHER)

X_________________________________________ Cardholder Signature

MERCHANT COPY / CUSTOMER COPY Footer 1 Footer 2 Footer 3 Footer 4


Application Preferred Name (9F12) and Application Label (Tag 50) cannot be obtained from chip so the BIN table name is printed (VISA)

Track 2 PAN must be masked and printed

Card Entry Method indicates that card information was obtained by swiping the card after a failed chip read (Chip/Swiped)


Card was a fallback swipe so a signature line is printed



EMV Information section (AID, TVR, CVR, TSI and ARC) is not printed as the chip was not used




10.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.


Zip Code Phone


Sale

xxxxxxxxxxxx8106 VISA CREDIT ENTRY METHOD: Chip MM/DD/YYYY HH:MM:SS Cust Ref #: 999 Batch #: 999999

Amount: $75.04 ========= Total: $75.04

Declined

AID: A0000000031010 TVR: 0010008000 IAD: 06010A03A40002 TSI: E800 AC: 0123456789ABCDEF ARC: Z1

EMV Offline Data

Tag 50: Visa Credit

Tag 5F2A:

Tag 5F34: 12

Tag 82: 1234

Tag 8A: Z1

Tag 95: 1234567890

Tag 9A: 140613

Tag 9C: 125025


Application Preferred Name (Tag 9F12) printed (VISA CREDIT)


Card Entry Method indicates card was inserted and card information was read from the contact chip (Chip)


EMV Information must be printed in the order shown and identified by the tag names: o AID (A0000000031010) o TVR (0010008000) o TSI (E800) o AC (0123456789ABEDEF) o ARC (Z1)

Cardholder Verification Method – Not printed as the transaction was declined

EMV Offline Data block (i.e. Tag 50, Tag 5F2A, etc.) is printed in the order shown using the labels shown





Tag 9F02: 75.04

Tag 9F03: 0.00

Tag 9F07: 1234

Tag 9F0D: 1234567890

Tag 9F0E: 1234567890

Tag 9F0F: 1234567890

Tag 9F10: 06010A03A40002

Tag 9F12: VISA CREDIT

Tag 9F1A: 123

Tag 9F26: 0123456789ABCDEF

Tag 9F27: 00

Tag 9F34: 123456

Tag 9F36: 1234

Tag 9F37: 12345678

TAC Default: DC4000A800

TAC Denial: 0010000000

TAC Online: DC4004F800

MERCHANT COPY / CUSTOMER COPY

Footer 1 Footer 2 Footer 3 Footer 4

EMV Implementation Guide EMV Report Guidelines


11. EMV Report Guidelines EMV reports are useful to track and reprint EMV transactions (including associated EMV tag values), to verify the EMV configuration and to track EMV card usage and failure rates:

Chase Paymentech must have a way to confirm that the production terminal configuration matches the configuration that was certified and that all data (e.g. CA Public Keys) are current and accurate

For problem determination the last transaction EMV tag values and terminal configuration are required

The merchant requires a way to track EMV card acceptance and fallback rates

The card associations track fallback rates. It is in Chase Paymentech and the merchant’s best interest to keep fallback rates as low as possible.

11.1 EMV Transaction Report The EMV Transaction Report shows the final EMV data element values for both approved and declined transactions. This is a report that, at a minimum, should be available for the last transaction processed. Chase Paymentech recommends that the report be available for all transactions in the current batch. This report is particularly helpful for chip offline declines as it provides valuable information not available elsewhere.

The following sample shows the recommended report format. Additional information may be printed if desired.

EMV TRANSACTION REPORT

Term ID: 001 Merchant ID: 999999999999 04/30/2015 12:50:00

5A PAN xxxxxxxxxxxx1234

50 Application Label Visa Credit

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

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 01101 EMV Transaction Report should be available for last transaction Chase Paymentech recommends that the EMV POS Solution includes an EMV Transaction Report that prints the EMV data element values. At a minimum, this report should 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.

BP 01102 EMV Transaction Report includes data element name and tag number Chase Paymentech recommends that the EMV Transaction Report show both the data element name and the tag number (if assigned) for each field.



BP 01103 EMV Transaction Report information should be stored in journal Chase Paymentech recommends that the EMV Offline Decline information be stored in the system journal (when available) and retained for six months. This will aid in resolving cardholder inquires relating to why an offline transactions was declined.

11.2 EMV Statistics Report Chase Paymentech recommends that the EMV POS Solution includes an EMV Statistics Report that prints EMV statistics accumulated since the last batch close. This will aid in troubleshooting the POS acceptance device.

The following sample report shows some EMV statistics that should be considered for this report. Other statistics may be added at the client’s discretion.

EMV STATISTICS REPORT

Term ID: 001 Merchant ID: 999999999999

04/30/2015 11:28:00

Period: 04/28/15 23:30:00 04/29/15 10:00:00

Chip Card Read Fail: 010

PIN Entry Error: 005

Offline Funds Decline: 000

Technical Fallback: 003

The statistic counts should reset to zero after each successful settlement.

BP 01104 EMV Statistics report is recommended Chase Paymentech recommends that the EMV POS Solution includes an EMV Statistics Report to shows EMV statistics accumulated since the last batch close.



11.3 Technical Fallback Reports Chase Paymentech recommends that the EMV POS Solution includes two fallback reports to monitor Technical Fallback percentages:

Clerk Technical Fallback Report – Identifies clerks that have a high incidence of fallback transactions

PIN Pad Technical Fallback Report – Identifies PIN Pads 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 PIN Pad that may require servicing.

BP 01105 EMV Technical Fallback reports are recommended Chase Paymentech recommends that the EMV POS Solution includes Technical Fallback reports to identify clerks and PIN Pads with high Technical Fallback rates. The card brands also monitor fallback rates so it is a best practice to keep them as low as possible.

11.3.1 EMV Clerk Technical Fallback Report An EMV report that identifies the percentage of Technical Fallback transactions by clerk 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


04/30/2015 11:28:00

Period: 04/19/15 17:30:00 04/28/15 10:00:00

Threshold%: 5.0%

Clerk Total Tran # Technical Fallback # Technical Fallback % 123456 893 91 10%

987654 1,721 231 13%

Total 2,614 322 12%

This report may be created by a store controller or back office system and contain statistics for multiple terminals. In this case the ‘Term ID’ is not required and should be replaced with a site identifier.



11.3.2 PINPad Technical Fallback Report An EMV report that identifies the percentage of Technical Fallback transactions by PIN Pad will help identify hardware that requires servicing. The report should only identify the PIN Pads that have a Technical Fallback percentage over a defined threshold percentage.

PINPAD TECHNICAL FALLBACK REPORT


04/30/15 11:28:00

Period: 04/09/15 07:30:00 04/29/15 10:00:00

Threshold%: 5.0%

PIN Pad Total Tran # Technical Fallback # Technical Fallback % 123456 455 76 17%

987654 140 92 66%

Total 595 168 28%

This report may be created by a store controller or back office system and include statistics for multiple terminal IDs. In this case the ‘TID’ line is not required and should be replaced with a site identifier. If created for a single terminal ID the report would generally only list one PIN Pad unless the PIN Pad was replaced during the period being printed.



11.4 POS Entry Mode Report The POS Entry Mode report identifies how card information 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


Period: 04/09/15 09:00:00 04/29/15 23:59:00

Transactions: 306

Mode Transactions % of Transactions Chip 112 36%

Contactless 95 31%

Chip / Swiped 20 7%

Swiped 72 24%

Keyed 7 2%

BP 01106 POS Entry Mode Report is recommended Chase Paymentech recommends that the EMV POS Solution includes a POS Entry Mode Report. This report provides good insight into how cardholder data is being obtained.



11.5 EMV Configuration Report The EMV Configuration Report identifies all the EMV parameters required to be configured for the terminal. It is mandatory that this report be included in all EMV POS Solutions. This must be a restricted report with limited or supervisor access. The report can be printed local to the device or optionally at a store or server level. The report must be device or terminal specific.

EMV CONFIGURATION REPORT

Term ID: 001 Merchant ID 999999999999

06/29/15 09:28:00

EMV Kernel Ver 01.00.00.01

Application Ver 01.00.01.09

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 Threshold 0.00

Rand Sel Max% 99

Rand Sel Target% 99

Partial Select Y

AllowFallback Y

Fallback Expiry 31/12/2099

AllowPINBypass N

Acquirer ID 00000

Default DDOL 9F3704



Default TDOL 9F0206 5F2A02 9A03 9C01 9505 9F3704

----- Contactless -----

TAC Default DC 50 84 00 00

TAC Denial 00 00 00 00 00

TAC Online C4 00 00 00 00

CTLS Floor Limit 0.00

CTLS Trans Limit 15.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


CAPK3 Index 0F


CAPK4 Index 10


AID A0000001523010

AID Label Discover Credit

Term Type 22


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

----- Contactless ----- TAC Default DC 00 00 20 00

TAC Denial 00 10 00 00 00

TAC Online FC E0 9C F8 00




----- CAPK ----- CAPK1 Index 5A


CAPK2 Index 5B


CAPK3 Index 5C


CAPK4 Index 5D


AID A0000000041010

AID Label MasterCard Credit

Term Type 22



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

Allow Fallback Y Fallback Expiry 31/12/2099

Allow PIN Bypass N

Acquirer ID 12097

Default DDOL 9F3704

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 Req CVMLim 50.00 MSD Version Num 1

Enable MChip Y

Enable MStripe Y

----- CAPK ----- CAPK1 Index FE


CAPK2 Index F8


CAPK3 Index FA


CAPK4 Index EF


CAPK5 Index F1


AID A0000000031010

AID Label Visa Credit

Term Type 22



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

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




Visa TTQ xx x0 x0 00

----- CAPK ----- CAPK1 Index 95


CAPK2 Index 99


CAPK3 Index 92


CAPK4 Index 94


For a definition of the report field names refer to the EMV and Contactless Parameters section (see page 125).

01101 EMV Configuration Report is mandatory

Chase Paymentech requires that all EMV POS Solutions include an EMV Configuration Report.



11.6 EMV Public Key Load Report The EMV CA Public Key Load report is used to validate that the Certificate of Authority Public Keys (CAPK) loaded by the EMV POS Solution are current and accurate. It is mandatory that this report be included in all EMV POS Solutions. This must be a restricted report with limited or supervisor access. The report can be printed local to the device or optionally at a store or server level. The report must be device or terminal specific.

EMV PUBLIC KEY LOAD REPORT


Card Association: Visa

RID A000000003

KEY INDEX HH

KEY MODULUS HH HH HH HH HH HH HH HH HH HH HH HH HH HH HH HH … HH HH HH HH HH HH HH HH

KEY EXPONENT HH

<This section repeats up to six times per card association >

Card Association: MasterCard

RID A000000003

KEY INDEX HH

KEY MODULUS HH HH HH HH HH HH HH HH HH HH HH HH HH HH HH HH … HH HH HH HH HH HH HH HH

KEY EXPONENT HH

<This section repeats up to six times per card association >



Each card association may have up to six active CA Public Keys at any time. Therefore, the RID / Key Index / Key Modulus / Key Exponent section will repeat up to six times per card association.

01102 EMV Public Key Load Report is mandatory

Chase Paymentech requires that all EMV POS Solutions include an EMV Public Key Load Report.

EMV Implementation Guide EMV Contact and Contactless Data Elements


12. EMV Contact and Contactless Data Elements

12.1 EMV Contact & Contactless Data Elements Definitions

The information in this chapter has been extracted from the EMV 4.3 Book 3 Application Specification.

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)

n x 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.

EMV Contact & Contactless Data Elements – Sorted by Element Name Name Description Source Format Tag Len Acquirer Identifier

Uniquely identifies the acquirer within each payment system. Terminal n 6-11 ‘9F01’ 6

Additional Terminal Capabilities

Indicates the data input and output capabilities of the terminal. Terminal b ‘9F40’ 5

Amount, Authorized (Binary)

Authorized amount of the transaction (excluding adjustments). Terminal b ‘81’ 6



EMV Contact & Contactless Data Elements – Sorted by Element Name Name Description Source Format Tag Len

Amount, Authorized (Numeric)

Authorized amount of the transaction (excluding adjustments). Referred to in this document as “Transaction Amount”.

Terminal n 12 ‘9F02’ 6

Amount, Other (Binary)

Secondary amount associated with the transaction representing a cashback amount. Terminal b ‘9F04’ 6

Amount, Other (Numeric)

Secondary amount associated with the transaction representing a cashback amount. Referred to in this document as “Other Amount”.


Amount, Reference Currency

Authorized amount expressed in the reference currency. Terminal b ‘9F3A’ 4

Application Cryptogram

Cryptogram returned by the ICC in response to the GENERATE AC command. ICC b ‘9F26’ 8

Application Currency Code

Indicates the currency in which the account is managed according to ISO 4217. ICC n 3 ‘9F42’ 2

Application Currency Exponent

Indicates the implied position of the decimal point from the right of the account represented according to ISO 4217.

ICC n 1 ‘9F44’ 1

Application Default Action

Indicates actions for the ICC to take for certain exception conditions. ICC b ‘9F52’ 4

Application Discretionary Data

Issuer or payment system specified data relating to the application. ICC b ‘9F05’ 1-32

Application Effective Date Date from which the application may be used. ICC n 6

YYMMDD ‘5F25’ 6

Application Expiration Date Date after which application expires. ICC n 6

YYMMDD ‘5F24’ 3

Application File Locator (AFL)

Indicates the location (SFI, range of records) of the AEFs related to a given application. ICC Var. ‘94’ <=

252 Application Identifier (AID) – ICC

Identifies the application as described in ISO/IEC 7816-5. ICC b ‘4F’ 5-16

Application Identifier (AID) – Terminal

Identifies the application as described in ISO/IEC 7816-5. Terminal b ‘9F06’ 5-16

Application Interchange Profile

Indicates the capabilities of the card to support specific functions in the application. ICC b ‘82’ 2

Application Label Mnemonic associated with the AID according to ISO/IEC 7816-5. ICC an 1-16 ‘50’ 1-16

Application Preferred Name Preferred mnemonic associated with the AID. ICC an 1-16 ‘9F12’ 1-16

Application Primary Account Number (PAN)

Valid cardholder account number. ICC Cn

<= 19 ‘5A’ <= 10

Application Primary Account Number (PAN) Sequence Number

Identifies and differentiates cards with the same PAN. ICC n 2 ‘5F34’ 1



EMV Contact & Contactless Data Elements – Sorted by Element Name Name Description Source Format Tag Len Application Priority Indicator

Indicates the priority of a given application or group of applications in a directory. ICC b ‘87’ 1

Application Reference Currency

1-4 currency codes used between the terminal and the ICC when the Transaction Currency Code is different from the Application Currency Code; each code is 3 digits according to ISO 4217.

ICC n 3 ‘9F3B’ 2 – 8

Application Selection Indicator

For an application in the ICC to be supported by an application in the terminal, the Application Selection Indicator indicates whether the associated AID in the terminal must match the AID in the card exactly, including the length of the AID or only up to the length of the AID in the terminal. There is only one Application Selection Indicator per AID supported by the terminal.

Terminal

At the discretion

of the terminal. This data is not sent across the interface.

-- var

Application Reference Currency Exponent

Indicates the implied position of the decimal point from the right of the amount, for each of the 1-4 reference currencies represented according to ISO 4217.

ICC n 1 ‘9F43’ 1 – 4

Application Selection Flag

This field is used by Canadian issuers if they want their application to be displayed for a particular service. Also known as the “Canadian Flag”.

ICC b ‘DF62’ 2-32

Application Transaction Counter (ATC)

Counter maintained by the application in the ICC (incrementing the ATC is managed by the ICC). ICC b ‘9F36’ 2

Application Usage Control

Indicates issuer's specified restrictions on the geographic usage and services allowed for the application.

ICC b ‘9F07’ 2

Application Version Number (ICC)

Version number assigned by the payment system for the application. ICC b ‘9F08’ 2

Application Version Number (Terminal)

Version number assigned by the payment system for the application. Terminal b ‘9F09’ 2

Authorization Code

Value generated by the issuer for an approved transaction. Issuer an 6 ‘89’ 6

Authorization Response Code Code that defines the disposition of a message.

Issuer/ Terminal

an 2 ‘8A’ 2

Authorization Response Cryptogram (ARPC)

Cryptogram generated by the issuer and used by the card to verify that the response came from the issuer. This is part of Issuer Authentication Data (Tag 91).

Issuer b N/A 4 or 8

Available Offline Spending Amount

A calculated field used to allow the reader to print or display the amount of offline spend available on the card. The card will not allow this tag to be included in a record to be read by the reader or in the response to GPO unless this tag is personalized with a value of 1.

ICC n 12 ‘9F5D’ 6

Card Additional Processes (Visa)

Indicates card processing requirements and preferences. ICC b ‘9F68’ 4

Card Authentication Related Data (Visa)

Contains the fDDA Version Number and Card Unpredictable Number. Byte 1: fDDA Version Number Byte 2 - 5 : Card Unpredictable Number

ICC b ‘9F69’ var.

5 -16




Card CVM Limit (Visa)

If present, indicates that when the card and reader currencies match and a contactless transaction exceeds this value, a CVM is required by the Card.

ICC n 12 ‘9F6B’ 6

Card Risk Management Data Object List 1 (CDOL1)

List of data objects (tag and length) to be passed to the ICC in the first GENERATE AC command. ICC b ‘8C’ <=

252

Card Risk Management Data Object List 2 (CDOL2)

List of data objects (tag and length) to be passed to the ICC in the second GENERATE AC command. ICC b ‘8D’ <=

252

Card Transaction Qualifiers (Visa)

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 Required bit 6 1 = Go Online if Offline Data Authentication fails and Reader is online capable. bit 5 1 = Terminate if Offline Data Authentication fails and Reader supports contact VSDC. bits 4-1 – RFU Byte 2 bits 8-1 – RFU

ICC b ‘9F6C’ 2

Cardholder Name Indicates cardholder name according to ISO 7813. ICC ans 2-26 ‘5F20’ 2-26

Cardholder Name Extended

Indicates the whole cardholder name when greater than 26 characters using the same coding convention as in ISO 7813.

ICC ans 27-45 ‘9F0B’ 27-45

Cardholder Verification Method (CVM) List

Identifies a method of verification of the cardholder supported by the application. ICC b ‘8E’ <=

252

Cardholder Verification Method (CVM) Results

Indicates the results of the last CVM performed. Terminal b ‘9F34’ 3

Certification Authority Public Key Check Sum

A check value calculated on the concatenation of all parts of the Certification Authority Public Key (RID, Certification Authority Public Key Index, Certification Authority Public Key Modulus, Certification Authority Public Key Exponent) using SHA-1.

Terminal b -- 20

Certification Authority Public Key Exponent

Value of the exponent part of the Certification Authority Public Key. Terminal b -- 1 or 3

Certification Authority Public Key Index

Identifies the certification authority's public key in conjunction with the RID. ICC b ‘8F’ 1

Certification Authority Public Key Index

Identifies the certification authority's public key in conjunction with the RID. Terminal b ‘9F22’ 1



EMV Contact & Contactless Data Elements – Sorted by Element Name Name Description Source Format Tag Len Certification Authority Public Key Modulus

Value of the modulus part of the Certification Authority Public Key. Terminal B --

NCA (<= 248)

Command Template Identifies the data field of a command message. Terminal b ‘83’ var.

Cryptogram Information Data

Indicates the type of cryptogram and the actions to be performed by the terminal. ICC b ‘9F27’ 1

Customer Exclusive Data (CED) (Visa)

Contains data for transmission to the Issuer in MSD transactions with a cryptogram. Customer Exclusive Data is both an implementation and Issuer option. Inclusion of the Customer Exclusive Data in online messages is an option for MSD readers compliant to this specification. Customer Exclusive Data will be updateable via an Issuer script command.

ICC b ‘9F7C’ var. <= 32

CVC3 (Track1) (MasterCard)

The CVC3TRACK1 is a 2-byte cryptogram returned by the card in the response to the COMPUTE CRYPTOGRAPHIC CHECKSUM command.

ICC b ‘9F60’ 2

CVC3 (Track2) (MasterCard)

The CVC3TRACK2 is a 2-byte cryptogram returned by the card in the response to the COMPUTE CRYPTOGRAPHIC CHECKSUM command.

ICC b ‘9F61’ 2

Data Authentication Code

An issuer assigned value that is retained by the terminal during the verification process of the Signed Static Application Data.

ICC b ‘9F45’ 2

DDCARD, TRACK1

If Track 1 Data is present, DDCARD,TRACK1 contains a copy of the discretionary data field of Track 1 Data as returned by the card in the file read using the READ RECORD command during a PayPass – Magstripe transaction (i.e. without UN (Numeric), ATC, CVC3TRACK1 and nUN included).

Terminal ans -- var <= 56

DDCARD, TRACK2

DDCARD,TRACK2 contains a copy of the discretionary data field of Track 2 Data as returned by the card in the file read using the READ RECORD command during a PayPass – Magstripe transaction (i.e. without UN (Numeric), ATC, CVC3TRACK2 and nUN included).

ans -- var <= 8

Dedicated File (DF) Name

Identifies the name of the DF as described in ISO/IEC 7816-4. Usually the same as the AID. ICC b ‘84’ 5-16

Default Dynamic Data Authentication Data Object List (DDOL)

DDOL to be used for constructing the INTERNAL AUTHENTICATE command if the DDOL in the card is not present.

Terminal b -- var.

Default Transaction Certificate Data Object List (TDOL)

TDOL to be used for generating the TC Hash Value if the TDOL in the card is not present. Terminal b -- var.

Directory Definition File (DDF) Name

Identifies the name of a DF associated with a directory. ICC b ‘9D’ 5 – 16

Directory Discretionary Template

Issuer discretionary part of the directory according to ISO/IEC 7816-5. ICC var. ‘73’

var. <= 252



EMV Contact & Contactless Data Elements – Sorted by Element Name Name Description Source Format Tag Len Dynamic Data Authentication Data Object List (DDOL)

List of data objects (tag and length) to be passed to the ICC in the INTERNAL AUTHENTICATE command.

ICC b ‘9F49’ <= 252

Enciphered Personal Identification Number (PIN) Data

Transaction PIN enciphered at the PIN Pad for online verification or for offline verification if the PIN Pad and IFD are not a single integrated device.

Terminal b -- 8

File Control Information (FCI) Issuer Discretionary Data

Issuer discretionary part of the FCI. ICC var. ‘BF0C’ <= 222

File Control Information (FCI) Proprietary Template

Identifies the data object proprietary to this specification in the FCI template according to ISO/IEC 7816-4.

ICC var. ‘A5’ var.

File Control Information (FCI) Template

Identifies the FCI template according to ISO/IEC 7816-4. ICC var. ‘6F’ <=

252

Form Factor Indicator (FFI) (Visa)

Indicates the form factor of the consumer payment device and the type of contactless interface over which the transaction was conducted. The Form Factor Indicator is an Issuer option. If present on the card it must be present in the authorization message.

ICC b ‘9F6E’ 4

Device Type Indicator (MasterCard)

Indicates the form factor of the consumer payment device for contactless transaction. ICC b ‘9F6E’ var 5 -

32

ICC Dynamic Number

Time-variant number generated by the ICC, to be captured by the terminal. ICC b ‘9F4C’ 2 – 8

Integrated Circuit Card (ICC) PIN Encipherment Public Key Certificate

ICC PIN Encipherment Public Key certified by the issuer. ICC b ‘9F2D’ NI

Integrated Circuit Card (ICC) PIN Encipherment Public Key Exponent

ICC PIN Encipherment Public Key Exponent used for PIN encipherment. ICC b ‘9F2E’ 1 or 3

Integrated Circuit Card (ICC) PIN Encipherment Public Key Exponent

Remaining digits of the ICC PIN Encipherment Public Key Modulus. ICC b ‘9F2F’

NPE − NI + 42

Integrated Circuit Card (ICC) PIN Encipherment Public Key Remainder

ICC Public Key certified by the issuer. ICC b ‘9F46’ NI



EMV Contact & Contactless Data Elements – Sorted by Element Name Name Description Source Format Tag Len Integrated Circuit Card (ICC) Public Key Certificate

ICC Public Key Exponent used for the verification of the Signed Dynamic Application Data. ICC b ‘9F47’ 1 to 3

Integrated Circuit Card (ICC) Public Key Remainder

Remaining digits of the ICC Public Key Modulus. ICC b ‘9F48’ NPE − NI + 42

Interface Device (IFD) Serial Number

Unique and permanent serial number assigned to the IFD by the manufacturer. Terminal an 8 ‘9F1E’ 8

Issuer Action Code – Default

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

ICC b ‘9F0D’ 5

Issuer Action Code – Denial

Specifies the issuer's conditions that cause the denial of a transaction without attempt to go online. ICC b ‘9F0E’ 5

Issuer Action Code – Online

Specifies the issuer's conditions that cause a transaction to be transmitted online. ICC b ‘9F0F’ 5

Issuer Application Data

Contains proprietary application data for transmission to the issuer in an online transaction. ICC b ‘9F10’ <= 32

Issuer Authentication Data

Data sent to the card for online issuer authentication. Issuer b ‘91’ 8-16

Issuer Code Table Index

Indicates the code table according to ISO 8859 for displaying the Application Preferred Name. ICC n 2 ‘9F11’ 1

Issuer Country Code

Indicates the country of the issuer according to ISO 3166. ICC n 3 ‘5F28’ 2

Issuer Country Code (Alpha 2)

Issuer Country Code (alpha 2 format) used as part of the Candidate List editing for U.S. Common Debit AIDs.

ICC a 2 ‘5F55’ 2

Issuer Country Code (Alpha 3) Issuer Country Code (alpha 3 format). ICC a 3 ‘5F56’ 3

Issuer Identification Number (IIN or BIN)

Issuer Identification Number – this tag is used as part of the Candidate List editing for U.S. Common Debit AIDs. The acronym IIN may be used interchangeably with BIN.

ICC b ‘42’ 3

Issuer Public Key Certificate Issuer public key certified by a certification authority. ICC b ‘90’ NCA

Issuer Public Key Exponent

Issuer public key exponent used for the verification of the Signed Static Application Data and the ICC Public Key Certificate.

ICC b ‘9F32’ 1 – 3

Issuer Public Key Remainder Remaining digits of the Issuer Public Key Modulus. ICC b ‘92’

NI − NCA +

36

Issuer Script Command Contains a command for transmission to the ICC. Issuer b ‘86’ <=

261 Issuer Script Identifier Identification of the Issuer Script. Issuer b ‘9F18’ 4

Issuer Script Results Indicates the result of the card script processing. Terminal b ‘9F5B’ var.



EMV Contact & Contactless Data Elements – Sorted by Element Name Name Description Source Format Tag Len Issuer Script Template 1

Contains proprietary issuer data for transmission to the ICC before the second GENERATE AC command. Issuer b ‘71’ var.

Issuer Script Template 2

Contains proprietary issuer data for transmission to the ICC after the second GENERATE AC command. Issuer b ‘72’ var.

Issuer URL The URL provides the location of the Issuer’s Library Server on the Internet. ICC ans ‘5F50’ var.

Language Preference

1-4 languages stored in order of preference, each represented by 2 alphabetical characters according to ISO 639. Some values used: “en” – English “es” – Spanish “fr” - French

ICC an 2 ‘5F2D’ 2-8

Last Online Application Transaction Counter (ATC) Register

ATC value of the last transaction that went online. ICC b ‘9F13’ 2

Lower Consecutive Offline Limit

Issuer-specified preference for the maximum number of consecutive offline transactions for this ICC application allowed in a terminal with online capability.

ICC b ‘9F14’ 1

Magstripe Application Version Number (MasterCard)

Version number assigned by the payment system for the specific PayPass – Magstripe functionality of the application.

ICC b ‘9F6C’ 2

Magstripe Application Version Number (MasterCard)

Version number assigned by the payment system for the specific PayPass – Magstripe functionality of the application.

Terminal b ‘9F6D’ 2

Maximum Target Percentage to be used for Biased Random Selection

Value used in terminal risk management for random transaction selection. Terminal -- -- --

Merchant Category Code

Classifies the type of business being done by the merchant, represented according to ISO 8583:1993 for Card Acceptor Business Code.


Merchant Identifier

When concatenated with the Acquirer Identifier, uniquely identifies a given merchant. Terminal ans 15 ‘9F16’ 15

Message Type Indicates whether the batch data capture record is a financial record or advice. Terminal n 2 -- 1




MSD Offset (Visa)

• 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 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 calculated and inserted into Track 2 Equivalent Data for MSD transactions without a cryptogram. • 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 1 = Offset from the beginning of Track2 Equivalent Data to the first digit of the CVV placeholder

ICC b ‘9F67’ 1

PayPass – Magstripe Indicator

Indicates for each AID whether the PayPass – Magstripe profile is supported or not by the PayPass reader. Its value is implementation-specific.

Terminal -- -- --

Personal Identification Number (PIN) Pad Secret Key

Secret key of a symmetric algorithm used by the PIN Pad to encipher the PIN and by the card reader to decipher the PIN if the PIN Pad and card reader are not integrated.

Terminal -- -- --

PIN Try Counter Number of PIN tries remaining. ICC b ‘9F17’ 1

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


Processing Options Data Object List (PDOL)

Contains a list of terminal resident data objects (tags and lengths) needed by the ICC in processing the GET PROCESSING OPTIONS command.


Service Code Service code as defined on Tracks 1 and 2. ICC n 3 ‘5F30’ 2

Short File Identifier (SFI)

Identifies the SFI to be used in the commands related to a given AEF or DDF. The SFI data object is a binary field with the three high order bits set to zero.

ICC b ‘88’ 1

Signed Dynamic Application Data

Digital signature on critical application parameters for dynamic data authentication. ICC b ‘9F4B’ NIC

Signed Static Application Data

Digital signature on critical application parameters for static data authentication. ICC b ‘93’ NI

Static Data Authentication Tag List

List of tags of primitive data objects defined in this specification whose value fields are to be included in the Signed Static or Dynamic Application Data.

ICC -- ‘9F4A’ var.

Target Percentage to be used for Random Selection





Terminal Action Code – Default

Specifies the acquirer’s conditions that cause a transaction to be rejected if it might have been approved online, but the terminal is unable to process the transaction online.

Terminal b -- 5

Terminal Action Code – Denial

Specifies the acquirer’s conditions that cause the denial of a transaction without attempt to go online. Terminal b -- 5

Terminal Action Code – Online

Specifies the acquirer’s conditions that cause a transaction to be transmitted online. Terminal b -- 5

Terminal Capabilities

Indicates the card data input, CVM and security capabilities of the terminal. Terminal b ‘9F33’ 3

Terminal Country Code

Indicates the country of the terminal, represented according to ISO 3166. Terminal n 3 ‘9F1A’ 2

Terminal Contactless Floor Limit (Visa, MasterCard)

Indicates the transaction amount limit for the related AID above which transactions must be authorized online.

Terminal n 12 -- 6

Terminal Contactless Transaction Limit (Visa, MasterCard)

Indicates the transaction amount limit for the related AID above which the selection of the AID on the card is not allowed. It is permitted to attempt the transaction over another interface.

Terminal n 12 -- 6

Terminal CVM Required Limit (Visa, MasterCard)

If a contactless transaction exceeds this value, a CVM is required by the Reader. Online PIN and Signature are CVMs defined for Visa. Online PIN, Signature and NO CVM are CVMs defined for MasterCard.

Terminal n 12 -- 6

Terminal Contactless Floor Exceeded Flag (MasterCard)

Indicates for the related AID if the Terminal Contactless Floor Limit is exceeded. Terminal -- -- --

Terminal Contactless Transaction Limit Exceeded Flag (MasterCard)

Indicates for the related AID if the Terminal Contactless Transaction Limit is exceeded. Terminal -- -- --

Terminal CVM Required Limit Exceeded Flag (MasterCard)

Indicates for the related AID if the Terminal CVM Required Limit is exceeded. Terminal -- -- --

Terminal Floor Limit

Indicates the floor limit in the terminal in conjunction with the AID. Terminal b ‘9F1B’ 4

Terminal Identification

Designates the unique location of a terminal at a merchant. Terminal an 8 ‘9F1C’ 8

Terminal Risk Management Data

Application-specific value used by the card for risk management purposes. Terminal b ‘9F1D’ 1-8




Terminal Transaction Qualifiers

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 '0' – Reader is Online Capable 3 '1' – Online PIN supported '0' – Online PIN not supported 2 '1' – Signature supported '0' – Signature not supported 1 – RFU 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 8-1 – RFU Byte 4 8-1 – RFU

Terminal b ‘9F66’ 4

Terminal Type Indicates the environment of the terminal, its communications capability and its operational control. Terminal n 2 ‘9F35’ 1

Terminal Verification Results

Status of the different functions as seen from the terminal. Terminal b ‘95’ 5

Threshold Value for Biased Random Selection


Track 1 Data (MasterCard)

The Track 1 Data may be present in the file read using the READ RECORD command during a PayPass – Magstripe transaction. The PayPass reader copies the required digits of the UN (Numeric), CVC3TRACK1, ATC and nUN into the 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.

ICC ans ‘56’ var. <= 76

Track 1 Number of ATC Digits (NATCTRACK1)

The value of NATCTRACK1 represents the number of digits of the ATC to be included in the discretionary data field of the Track 1 Data.

ICC b ‘9F64’ 1



EMV Contact & Contactless Data Elements – Sorted by Element Name Name Description Source Format Tag Len Track 1 Discretionary Data

Discretionary part of Track 1 according to ISO/IEC 7813. ICC an ‘9F1F’ var.

Track 2 Equivalent Data

Contains the data elements of the Track 2 according to ISO/IEC 7813, excluding start sentinel, end sentinel and LRC, as follows: Primary Account Number Field Separator (hex ‘D’) Expiration Date (YYMM) Service Code Discretionary Data (defined by individual payment systems) Pad with hex ‘F’ if needed to ensure whole bytes.

ICC

b

n, <= 40 b

n 4 n 3

n, var.

‘57’ <= 40

Track 2 Data (MasterCard)

The Track 2 Data is present in the file read using the READ RECORD command during a PayPass – Magstripe transaction. The PayPass reader copies the required digits of the UN (Numeric), CVC3TRACK2, 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.

ICC b ‘9F6B’ var. <= 19

Track 2 Bitmap for CVC3 (PCVC3TRACK2)(MasterCard)

PCVC3TRACK2 indicates to the PayPass reader the positions in the discretionary data field of the Track 2 Data where the qTRACK2 CVC3TRACK2 digits have to be copied.

ICC b ‘9F65’ 2

Track 2 Bitmap for UN and ATC (PUNATCTRACK2) (MasterCard)

PUNATCTRACK2 indicates to the PayPass reader the positions in the discretionary data field of the Track 2 Data where the nUN UN (Numeric) digits and tTRACK2 ATC digits have to be copied.

ICC b ‘9F66’ 2

Track 2 Number of ATC Digits (NATCTRACK2)

The value of NATCTRACK2 represents the number of digits of the ATC to be included in the discretionary data field of the Track 2 Data.

ICC b ‘9F67’ 1

Transaction Amount

Clearing amount of the transaction, including tips and other adjustments. Terminal n 12 -- 6

Transaction Certificate (TC) Hash Value

Result of a hash function specified in Book 2, Annex B3.1 of the EMVCo Specifications. Terminal b ‘98’ 20

Transaction Certificate Data Object List (TDOL)

List of data objects (tag and length) to be used by the terminal in generating the TC Hash Value. ICC b ‘97’

var. <= 252

Transaction Currency Code

Indicates the currency code of the transaction according to ISO 4217. Terminal n 3 ‘5F2A’ 2

Transaction Currency Exponent

Indicates the implied position of the decimal point from the right of the transaction amount represented according to ISO 4217.

Terminal n 1 ’5F36’ 1

Transaction CVM (MasterCard)

Data object used to indicate to the terminal the outcome of the CVM Selection function. Possible values are: NO CVM Signature Online PIN The coding of the value is implementation-specific.

Terminal -- -- --




Transaction Date Local date that the transaction was authorized. Terminal n 6 YYMMDD ‘9A’ 3

Transaction Outcome (MasterCard)

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.

Declined – The PayPass reader has found that the transaction is not acceptable with the selected card 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 magstripe) may be available.

End Application – The PayPass reader experienced an application error (e.g. missing data)

The coding of the value is implementation-specific.

Terminal -- -- --

Transaction Personal Identification Number (PIN) Data

Data entered by the cardholder for the purpose of the PIN verification. Terminal b ‘99’ var.

Transaction Reference Currency Code

Code defining the common currency used by the terminal in case the Transaction Currency Code is different from the Application Currency Code.

Terminal n 3 ‘9F3C’ 2

Transaction Reference Currency Exponent

Indicates the implied position of the decimal point from the right of the transaction amount, with the Transaction Reference Currency Code represented according to ISO 4217.

Terminal n 1 ‘9F3D’ 1

Transaction Sequence Counter

Counter maintained by the terminal that is incremented by one for each transaction. Terminal n 4-8 ‘9F41’ 2 – 4

Transaction Status Information

Indicates the functions performed in a transaction. Terminal b ‘9B’ 2

Transaction Time Local time that the transaction was authorized. Terminal n 6

HHMMSS ‘9F21’ 3

Transaction Type

Indicates the type of financial transaction, represented by the first two digits of ISO 8583:1987 Processing Code.

Terminal n 2 ‘9C’ 1

Unpredictable Number

Value to provide variability and uniqueness to the generation of a cryptogram. Terminal b ‘9F37’ 4




Unpredictable Number Data Object List (UDOL) (MasterCard)

The UDOL is the DOL that specifies the data objects to be included in the data field of the COMPUTE CRYPTOGRAPHIC CHECKSUM command. The UDOL must at least include the UN (Numeric). The UDOL is not mandatory for the card. There will always be a Default UDOL, including as its only entry the tag and length of the UN (Numeric) (Tag '9F6A').


Unpredictable Number (Numeric) (MasterCard)

Unpredictable number generated by the PayPass reader during a PayPass – Magstripe Transaction. The UN (Numeric) is passed to the card in the data field of the COMPUTE CRYPTOGRAPHIC CHECKSUM command. The (8-nUN) most significant digits must be set to zero.

Terminal n ‘9F6A’ 8

Upper Consecutive Offline Limit

Issuer-specified preference for the maximum number of consecutive offline transactions for this ICC application allowed in a terminal without online capability.

ICC b ‘9F23’ 1

VLP Available Funds (Visa)

A counter that may be decremented (for LV or CTTA the funds may be added to CTTA) by the Amount Authorized when an offline low-value qVSDC transaction takes place.

ICC n 12 ‘9F79’ 6

VLP Funds Limit (Visa) Value to which VLP Available Funds is reset. ICC n 12 ‘9F77’ 6

VLP Reset Threshold (Visa)

If the Amount Authorized is greater than VLP Available Funds minus this threshold, the card requests online processing.

ICC n 12 ‘9F6D’ 6

VLP Single Transaction Limit (Visa)

Limit for a single transaction. ICC n12 ‘9F78’ 6




EMV Implementation Guide Reference Materials


13. Reference Materials

Some of the information in this chapter has been extracted from the EMV 4.3 specifications.

13.1 Answer to Reset 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

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

TA3 ‘10’ to ‘FE’ Returns IFSI, which indicates initial value for information field size for ICC and IFSC of 16-254 bytes

TB3 m.s. nibble ‘0’ – ‘4’ l.s. nibble ‘0’ – ‘5’

BWI = 0 to 4 CWI = 0 to 5

TCK Check character



13.2 EMV Reference Tables The following tables are provided as reference material to assist in understanding the EMV processes.

13.2.1 Application Interchange Profile (Tag 82) Application Interchange Profile (Tag 82) – Byte 1

b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 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

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









13.2.2 Application Priority Indicator (Tag 87) 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

X X X X Order in which the application is to be listed or selected. Ranging from 1 – 15, with 1 being the highest priority



13.2.3 Application Usage Control (Tag 9F07) 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

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



13.2.4 Cardholder Verification Rule (part of CVM List) 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)

0 X X X X X Reserved for future use by the EMV specification Range 000110-011101

0 1 1 1 1 0 Signature (paper) 0 1 1 1 1 1 No CVM required.

1 0 X X X X Reserved for future use by the EMV specification Range 100000-101111


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



13.2.5 Cardholder Verification Method Results (Tag 9F34) 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)

0 X X X X X Reserved for future use by the EMV specification Range 000110-011101

0 1 1 1 1 0 Signature (paper) 0 1 1 1 1 1 No CVM required



1 1 1 1 1 1 This value is not available for use

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

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)



13.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 will differ.

Card Verification Results – Byte 1 b8 b7 b6 b5 b4 b3 b2 b1 Meaning

X X Application Cryptogram Type returned in 2nd GENERATE AC 0 0 AAC

0 1 TC 1 0 2nd GENERATE AC Not Requested 1 1 Reserved for future use X X Application Cryptogram Type returned in 1st 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

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


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




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

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



13.2.7 Cryptogram Information Data (Tag 9F27) Cryptogram Information Data (Tag 9F27)

b8 b7 b6 b5 b4 b3 b2 b1 Meaning X X Application Cryptogram Type returned in 2nd 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



13.2.8 Terminal Capabilities (Tag 9F33) 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

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

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



13.2.9 Additional Terminal Capabilities (Tag 9F40) 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

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


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



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

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



13.2.10 Terminal Verification Results (Tag 95) 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

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

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 – PIN Pad not present or not working

1 PIN entry required – PIN Pad present but PIN was not entered 1 Online PIN entered 0 Reserved for future use 0 Reserved for future use



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

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



13.2.11 Transaction Status Indicator (Tag 9B) 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

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




13.3 EMV Chip Commands

The information in this chapter has been extracted from the EMV 4.3 Book 3 Application Specification.

This section contains commands 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)

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 235.

13.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.

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

Data Message Authentication Code (MAC) data component Coding according to the secure messaging specified in Book 2

Le Not present



13.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.

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

Data Message Authentication Code (MAC) data component; coding according to the secure messaging specified in Book 2

Le Not present



13.3.3 Card Block The CARD BLOCK command is a post-issuance command that permanently disables 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.

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

Data Message Authentication Code (MAC) data component; coding according to the secure messaging specified in Book 2

Le Not present



13.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.

EXTERNAL AUTHENTICATE Command Values Code Value CLA '00'

INS '82' P1 '00' P2 '00' Lc 8-16 Data Issuer Authentication Data Le Not present

EXTERNAL AUTHENTICATE Response Codes Code Value 6300 Indicates “Issuer authentication failed” 9000 Indicates the command was successfully executed



13.3.5 Generate AC The GENERATE AC command sends transaction-related data to the ICC, which computes and returns a cryptogram.

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'

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 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.

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



13.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.

GET CHALLENGE Command Values Code Value CLA '00'

INS '84' P1 '00' P2 '00' Lc Not present Data Not present Le '00'



13.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)

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'



13.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).

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:

'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



13.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

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.

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.



13.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.

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'

P2

'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 PIN value '01' – reserved for each payment scheme '02' – reserved for each payment scheme

Lc Number of data bytes

Data Enciphered PIN data component, if present and MAC data component; coding (according to the secure messaging specified in Book 2)

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.

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.



13.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.

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'

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 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



13.3.12 Select The SELECT command is used to select the ICC PSE, DDF or ADF corresponding to the submitted file name or AID.

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'

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

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.

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



SELECT Response Message Data Field (FCI) of the PSE Tag Value Presence '9F11' Issuer Code Table Index O 'BF0C' FCI Issuer Discretionary Data O

'XXXX' (Tag constructed according to Book 3, Annex B)

One or more additional proprietary data elements from an application provider, issuer or IC card supplier or EMV-defined tags that are specifically allocated to 'BF0C'

O

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 application provider, issuer or IC card supplier or EMV-defined tags that are specifically allocated to 'BF0C'

O

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



SELECT Response Message Data Field (FCI) of the ADF Tag Value Presence


1 or more additional proprietary data elements from an application provider, issuer or IC card supplier or EMV-defined tags that are specifically allocated to 'BF0C'

O



13.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.

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

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 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’)



13.3.14 EMV Response Codes (SW1 SW2) 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 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



EMV Response Codes (SW1 SW2) SW1 SW2 Description 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



13.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:

a. ’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:

a. ‘0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x32 0x33 0x34 0x35’ (Hex) b. ‘000000012345’ (ASCII)



13.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

EMV Implementation Guide EMV Testing and Certification Parameters


14. EMV Testing and Certification Parameters

14.1 Amex Certification Parameters 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 Acq 9F06 Application Identifier (AID) A00000002501

Default AID Label American Express 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.001 EMV Random Selection Threshold 0.001 EMV Random Selection Maximum % 99 EMV Random Selection Target % 99 Partial Name Selection Flag Y Allow Fallback Flag Y1 Allow PIN Bypass N

9F09 Application Version Number (Prim.) 0x0001 9F09 Application Version Number (Sec.) -

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

1 Downloaded as part of the Chase EMV Parameter Download



14.2 Debit Network Alliance Certification Parameters Certification Parameters – Debit Network Alliance Debit

Tag Description DNA Debit 9F35 Terminal Type Kernel config 9F33 Terminal Capabilities Kernel config 9F40 Additional Terminal Capabilities Kernel config 9F15 Merchant Category Code Assigned by Acq 9F06 Application Identifier (AID) A0000006200620

Default AID Label DNA Debit 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 AC A0 00 TAC – Denial 00 00 00 00 00 TAC – Online FC 50 BC F8 00


9F09 Application Version Number (Prim.) - 9F09 Application Version Number (Sec.) -

Contactless TAC – Default N/A TAC – Denial N/A TAC – Online N/A Contactless Floor Limit N/A Contactless CVM Required Limit N/A Contactless Transaction Limit N/A




14.3 Discover Certification Parameters Certification Parameters – Discover

Tag Description Discover Credit

Discover US Debit

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 Acq Assigned by Acq 9F06 Application Identifier (AID) A0000001523010 A0000001524010

Default AID Label Discover Credit Discover Debit 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 00 00 20 00 DC 00 00 20 00 TAC – Denial 00 10 00 00 00 00 10 00 00 00 TAC – Online FC E0 9C F8 00 FC E0 9C F8 00

9F1B Terminal Floor Limit (EMV) 0.00* 0.00* EMV Random Selection Threshold 000 000 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 Y Y Acquirer ID Assigned by Acq Assigned by Acq

9F09 Application Version Number (Prim.) 0x0001 0x0001 9F09 Application Version Number (Sec.) 0x0001 0x0001

Contactless Contactless Floor Limit 0.00 - Contactless CVM Required Limit 20.00 - Contactless Transaction Limit 100.00 -

Terminal Transaction Qualifier Defined by HW Vendor -




14.4 Interac Certification Parameters Certification Parameters – Interac Debit

Tag Description Interac 9F35 Terminal Type Kernel config 9F33 Terminal Capabilities Kernel config 9F40 Additional Terminal Capabilities Kernel config 9F15 Merchant Category Code Assigned by Acq 9F06 Application Identifier (AID) A0000002771010

Default AID Label Interac 9F1A Terminal Country Code 124 5F2A Transaction Currency Code 124 5F36 Transaction Currency Exponent 2

Default DDOL 9F3704 97 Default TDOL - TAC – Default FC 50 F8 A8 F0 TAC – Denial 10 10 58 00 00 TAC – Online FC F8 E4 B8 70



Contactless TAC – Default 00 00 00 00 00 TAC – Denial 00 00 00 00 00 TAC – Online 00 00 00 00 00 Merchant Type Indicator 03 Terminal Option Status E0 00 Contactless Floor Limit $100.00 Contactless Receipt Required Limit $50.00 Contactless Transaction Limit $80.00




14.5 JCB Certification Parameters 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 Acq 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


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 -




14.6 MasterCard Certification Parameters Certification Parameters – MasterCard Credit

Tag Description MasterCard

Credit 9F35 Terminal Type Kernel config 9F33 Terminal Capabilities Kernel config 9F40 Additional Terminal Capabilities Kernel config 9F15 Merchant Category Code Assigned by Acq 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 9F02065F2A029A039C0195059F3704

TAC – Default FC 50 B8 A0 00 TAC – Denial 00 00 00 00 00 TAC – Online FC 50 B8 F8 00



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

9F1B Contactless Floor Limit 10.00 Contactless CVM Required Limit 25.00 Contactless Transaction Limit 50.00

9F33 Contactless Terminal Capabilities CVM Req Kernel config

9F33 Contactless Terminal Capabilities CVM NotReq Kernel config




Certification Parameters – MasterCard Debit

Tag Description International

Maestro U.S.

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 Acq Assigned by Acq 9F53 Transaction Category Code ‘R’ ‘R’ 9F06 Application Identifier (AID) A0000000043060 A0000000042203

Default AID Label Maestro DEBIT 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 9F02065F2A029A039C0195059F3704

9F02065F2A029A039C0195059F3704

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.001 0.001 EMV Random Selection Threshold 0.001 0.001 EMV Random Selection Maximum % 99 99 EMV Random Selection Target % 99 99 Partial Name Selection Flag Y Y Allow Fallback Flag Y1 Y1 Allow PIN Bypass N N

9F09 Application Version Number (Prim.) 0x0002 0x0002 9F09 Application Version Number (Sec.) - -

Contactless 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 Enable MChip Y Y Enable MStripe Y Y Contactless Floor Limit 0.00 0.00 Contactless CVM Required Limit 0.00 0.00 Contactless Transaction Limit 0.00 0.00

Contactless Terminal Capabilities CVM Req Kernel config Kernel config

Contactless Terminal Capabilities CVM NotReq Kernel config Kernel config




14.7 Visa Certification Parameters The Visa parameters are used for ChaseNet.

Certification Parameters – Visa Credit

Tag Description Visa

Credit Visa

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 Acq Assigned by Acq 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 9F0206 9F0206 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.001 0.00 EMV Random Selection Threshold 0.001 0.00 EMV Random Selection Maximum % 99 99 EMV Random Selection Target % 99 99 Partial Name Selection Flag Y Y Allow Fallback Flag Y1 Y Allow PIN Bypass N Y

9F09 Application Version Number (Prim.) 0x008C 8C 9F09 Application Version Number (Sec.) 0x0096 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.00 0.00 Contactless CVM Required Limit 0.00 0.00 Contactless Transaction Limit 0.00 0.00

9F66 Visa TTQ Terminal Terminal 1 Downloaded as part of the Chase EMV Parameter Download



Tag Description Debit

International Visa

Interlink U.S.

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 Acq Assigned by Acq Assigned by Acq 9F06 Application Identifier (AID) A0000000031010 A0000000033010 A0000000980840

Default AID Label VISA DEBIT INTERLINK 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 9F0206 9F0206 9F0206 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.001 0.001 0.001 EMV Random Selection Threshold 0.001 0.001 0.001 EMV Random Selection Maximum % 99 99 99 EMV Random Selection Target % 99 99 99 Partial Name Selection Flag Y Y Y Allow Fallback Flag Y1 Y1 Y1 Allow PIN Bypass N N N

9F09 Application Version Number (Prim.) 0x008C 0x008C 0x008C 9F09 Application Version Number (Sec.) 0x0096 0x0096 0x0096

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.00 0.00 - Terminal CVM Required Limit 0.00 0.00 - Contactless CVM Required Limit 0.00 0.00 -

9F66 Visa TTQ Terminal Terminal Terminal 1 Downloaded as part of the Chase EMV Parameter Download



14.8 China UnionPay Certification Parameters Certification Parameters – China UnionPay

Tag Description CUP Credit

CUP Debit


Default AID Label UnionPay CREDIT UnionPay DEBIT 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 N/A N/A TAC – Default D8 40 00 A8 00 D8 40 00 A8 00 TAC – Denial 00 10 00 00 00 00 10 00 00 00 TAC – Online D8 40 04 F8 00 D8 40 04 F8 00

9F1B Terminal Floor Limit (EMV) 0.001 0.001 EMV Random Selection Threshold 000 000 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 Y Y Acquirer ID Assigned by Acq Assigned by Acq


Contactless Contactless Floor Limit 0.00 0.00 Contactless CVM Required Limit $100 CDA / $25 USA $100 CDA / $25 USA Contactless Transaction Limit 99999999999 99999999999

9F66 Terminal Transaction Qualifier Terminal Terminal 1 Downloaded as part of the Chase EMV Parameter Download



Certification Parameters – China UnionPay (cont)

Tag Description CUP Quasi Credit

CUP US Common


Default AID Label UnionPay QUASICREDIT

UnionPay COMMON

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 N/A N/A TAC – Default D8 40 00 A8 00 D8 40 00 A8 00 TAC – Denial 00 10 00 00 00 00 10 00 00 00 TAC – Online D8 40 04 F8 00 D8 40 04 F8 00

9F1B Terminal Floor Limit (EMV) 0.00* 0.00* EMV Random Selection Threshold 000 000 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 Y Y Acquirer ID Assigned by Acq Assigned by Acq


Contactless Contactless Floor Limit 0.00 0.00 Contactless CVM Required Limit $100 CDA / $25 USA $100 CDA / $25 USA Contactless Transaction Limit 99999999999 99999999999

9F66 Terminal Transaction Qualifier Terminal Terminal 1 Downloaded as part of the Chase EMV Parameter Download

EMV Implementation Guide Glossary of Terms & Acronyms


15. Glossary of Terms & Acronyms Glossary of Terms & Acronyms

Term Description

AAC

Application Authentication Cryptogram – An Application Cryptogram type generated by the chip application in response to the Generate AC command (First or Second) sent by the CAD. An AAC is generated to indicate that the transaction should be declined.

ABM Automated Banking Machine – Unattended, customer-operated device used to dispense and/or deposit cash and conduct other customer operated services (also known as ATM – Automated Teller Machine)

AC Application Cryptogram – AC is a generic term given to describe an application cryptogram such as TC, AAC, ARQC and ARPC.

ADA

Application Default Action – Visa and Amex proprietary data element indicating issuer-specified action for the ICC to take for certain exception conditions.

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.

ADF Application Dedicated File – The ADF contains application specific data for a specific AID (also see DF).

ADVT

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 certification which follows the device’s previous EMV level 1 (Hardware) and EMV level 2 (EMV kernel) certifications completed by the device vendor. This test suite is supported by the Collis and ICC Solutions testing tools.

AEIPS American Express Integrated Circuit Card Payment Specification – EMV test suite used for Amex EMV contact transaction certification of deployed EMV devices. This test suite is supported by the Collis and ICC Solutions testing tools.

AFL

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 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.

AID

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 (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.



Glossary of Terms & Acronyms Term Description

AIP Application Interchange Profile – The AIP contains details of the ICC’s capabilities to support specific security functions in the application (e.g. SDA/DDA/CDA, Cardholder Verification etc.).

APDU Application Protocol Data Unit – APDU is the command message sent from the interface device (in the CAD) and the response message returned by the ICC to the interface device.

API Application Program Interface – A specification defining the communication protocol and commands used to interact with a device.

ARC

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:

Y1 – Offline Approved Z1 – Offline Declined Y3 – Unable to go online (offline approved) Z3 – Unable to go online (offline declined)

ARPC

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 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.

ARQC

Authorization Request Cryptogram – A cryptogram used for a process called Online Card Authentication. The cryptogram is generated by the ICC in response to the FIRST GENEREATE AC command when the transaction requires online 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.

ASF Application Selection Flag – Used by Interac during the Application Selection process enabling automatic selection of an application without using the highest API thus allowing for different priorities between SCD and IDP.

ASI

Application Selection Indicator – The Application Selection Indicator indicates whether the associated AID in the CAD must exactly match the AID in the ICC (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.

ATC Application Transaction Counter – The ATC counts the number of transactions 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.

ATR Answer To Reset – An ATR is sent from the ICC to the CAD (after the supply voltage, the clock and reset signal) containing various information related to the transmission protocol supported by the ICC.

AUC Application Usage Control – The AUC details the ICC’s processing restrictions. These restrictions relate to the geographical settings (domestic vs international) and the support for specific services (e.g. cash, cashback, 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.

BIN

Bank Identification Number – The BIN is the first six digits of the PAN and is used to identify the issuer of the card. It is comprised of a Major Industry Identifier (MII) (1st digit) and an Issuer Identifier (up to 5 digits). The acronym IIN may be used interchangeably with BIN.

CA Certificate Authority – A CA is a trusted central administration that issues, revokes and expires certificates. A CA is responsible for ensuring that the identity of the user requesting the certificate is legitimate.

CAA

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 or ARQC). CAA is performed by the ICC after the ICC completes the CRM process and sets the CVR.

CAD Card Acceptance Device – Any device capable of reading and processing data from a magstripe, ICC (contact or contactless interfaces) or manual entry keyboard for the purpose of performing a payment transaction.

CAM Card Authentication Method – CAM is the name given to the process of 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 Candidate List – The list of AIDs that are mutually supported by the ICC and EMV POS Solution.

CAP

Card Authentication Program – CAP is a One Time Password application created by MasterCard. CAP uses chip cryptography similar to the MasterCard payment 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.

CAPK Certificate Authority Public Key – RSA Public key assigned by a card brand used by an EMV kernel to decrypt chip information signed with a card brand private key.




CAPK File Certificate Authority Public Key File – A file containing the current card brand assigned RSA public keys, key indexes and expiry dates. The file is downloaded to the EMV kernel.

CAT

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.

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.

CCD

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. When CCD is incorporated into an ICC specification, issuers of multi-branded cards can achieve the benefits of the common issuer support system.

CCRT Chip Compliance Reporting Tool – A Visa web portal that allows an acquirer to load or enter certification test results (e.g. from a Visa ADVT certification).

CDA

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. 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.

CDET Contactless Device Evaluation Toolkit – Tool kit used for Visa contactless transaction certification of deployed EMV devices. This test suite is supported by the Collis and ICC Solutions testing tools.

CDOL1

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 CAD will send these data object values to the ICC with the First Generate AC command.

CDOL2

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. The CAD will send these data object values to the ICC with the Second Generate AC command.




Checksum Checksum – A computed numeric value that represents a data element. Used to ensure that the data has not been changed.

CIAC

Card Issuer Actions Codes – CIAC specifies the ICC conditions that cause a transaction to be approved off-line, sent online or declined if the CAD cannot go online. 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).

CID Cryptogram Information Data – CID Indicates the type of cryptogram (AAC, TC and 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.).

CLA Class Byte of the Command Message – CLA is the first byte of five consecutive 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'.

CLF Contactless Frontend – Circuitry in the CAD which manages the analogue contactless communication and the communication protocol layer of the contactless transmission link to exchange data with the UICC.

CNP Card Not Present – CNP transactions are transactions that are conducted over an open network (e.g. telephone, Internet, mail order) where a physical card is not present and therefore the MSD or ICC data cannot be obtained and used.

CPA

Common Payment Application – CPA is a CCD-compliant application specification developed by EMVCo. CPA enables a single application implementation to be personalized with the same data elements and tags, including common Risk Management controls, for all brands and schemes that support EMV.

CPLC

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 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.

CPS Card Personalization Specification – Specification that defines the card brand personalization requirements and chip card rules.

CPV Card Personalization Validation – Card Personalization Validation is a process to 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.

CRL Certificate Revocation List – A list of certificates that have been revoked and therefore, should no longer be trusted or used.




CRM

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 of the CRM process is the setting of the CVR which is subsequently used in the Card Action Analysis.

CRT Chinese Remainder Theorem

Cryptogram

Cryptogram – A numeric value used to validate data integrity. Cryptograms are calculated by processing and signing specific data elements using a common 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

CSU

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 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.

CTQ Card Transaction Qualifiers – A card value defining what actions will take place at the POS when a transaction occurs.

CTTAL

Cumulative Total Transaction Amount Limit – Visa proprietary tag 9F54 specifying the maximum total amount of offline transactions in the designated currency or designated and secondary currency allowed for the card application before a transaction is sent online.

CTTAUL

Cumulative Total Transaction Amount Upper Limit – Visa proprietary tag 9F5C specifying the maximum total amount of offline transactions in the designated 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.

CUP China UnionPay – Also known as UnionPay or by its abbreviation, CUP, is a Chinese financial services corporation that issues the UnionPay Integrated Circuit Card that is an EMV compatible method of payment.

CV Rule

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 verification should be used, under which conditions and the action to take if the CV Rule is unsuccessful.

CVC – 1 Card Verification Code 1 – CVC1 is the name given to the three digit field coded on the MSR of a MasterCard branded card. The value is generated using TDES from the PAN, expiry date and Service Code.




CVC – 2

Card Verification Code 2 – CVC2 is the name given to the three digit field printed on the signature panel of a MasterCard branded card. The value is generated using TDES from the PAN, Expiry Date and Service Code ‘000’. CVC2 is used for CNP to prove the presence of a legitimate card.

CVC – 3

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 COMPUTE CRYPTOGRAPHIC CHECKSUM command. CVC3 is used by MasterCard for the security of the PayPass contactless MSD application.

CVM Cardholder Verification Method – Method by which a cardholder is identified during an ICC transaction (e.g. PIN or Signature).

CVN Cryptogram Version Number – Informs the issuer about the algorithm and data used for the Application Cryptogram computation during online transactions (in the authorization request) and after transaction completion in the clearing record.

CVR Card Verification Results – Proprietary data field used to report transaction-processing information to the issuer (e.g. successful PIN validation, previous transaction information, script results, etc.).

CVV – 1 Card Verification Value 1 – Name given to the three digit field coded on the MSR of a Visa branded card. The value is generated using TDES from the PAN, expiry date and Service Code.

CVV – 2

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 PAN, Expiry Date and Service Code. CVV2 is used for CNP to prove the presence of a legitimate card.

dCVV Dynamic Card Verification Value – The process of generating a dynamic CVV (using the same algorithm as CVV1 with the addition of the ATC). dCVV is used for security by the Visa payWave contactless MSD application.

DDA Dynamic Data Authentication – An offline CAM option which protects against 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).

DDOL

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 the DDA or CDA process. The CAD will send the required data object values with the Internal Authenticate command.

DES

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 cryptography operations used is the same. DES uses a single length key which is 16 bytes in length.




Developer Developer – Generic term used within this document to identify anyone (merchant, integrator, developer, etc.) implementing and certifying and EMV POS Solution.

DF

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 Elementary Files (EF) and DFs. The DF at the highest level of the card is the Master File (MF).

DHS

Dynamic Host Service – A real time server option whereby clients or vendors can send requests via IP, with minimal non-critical information, for DHS to determine if the card is foreign-issued and if so, its supported currency. If eligible for DCC, the response would contain all of the information needed to provide a choice to the consumer and process the transaction.

DKI/KDI Derivation Key Index/Key Derivation Index – DKI is a two digit hexadecimal field located on the card issuer host to identify a set of Master DES keys used to generate cryptograms.

DOL

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 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.

DPA Dynamic Passcode Authentication – Based on the MasterCard CAP specification and is used along with a One Time Password (see CAP).

D-PAS

D-Payment Application Specification – Discover contactless payment card or device implementation. Also the name of the Discover EMV smartcard test suite used to certify that EMV devices can process contact and contactless EMV Discover transactions. This test suite is supported by the Collis and ICC Solutions testing tools.

DUKPT Derived Unique Key Per Transaction – A key management scheme in which for every transaction a unique key is used which is derived from a fixed key.

EEPROM

Electronically Erasable Programmable Read Only Memory – Type of memory used in ICCs to store all the personalization data and other dynamic data specific to an ICC application. Data in the EEPROM is retained without power but can only be modified when power is available.

EF

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 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.

EMV Europay, MasterCard, Visa – The Integrated Circuit Card (ICC) Specification for Payment Systems defines the functionality of credit / debit transaction processing at the CAD level to ensure correct operation and interoperability.




EMVCo EMVCo – The name of the non-profit organization formed in 1999 between Europay, MasterCard and Visa that maintains the EMV specifications.

EMV POS Solution EMV POS Solution – Generic term used within this document to describe any integrated or standalone EMV implementation being developed and certified.

EMV Tag EMV Tag - See Tag.

EMV Transaction Type EMV Transaction Type – Type of transaction being performed (e.g. Sale, Return, etc.).

ENC Encryption – Process whereby plaintext data is scrambled into data non-readable to any entity which doesn’t have the key required to unscramble it (Decryption).

EPOS Electronic Point Of Sale – A Point of Sale device equipped with electronic equipment for pricing and recording transactions. EPOS are normally installed in large retailers (e.g. supermarkets).

ETEC

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, 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

ExpressPay – Amex contactless payment card or device implementation. Also the name of the EMV test suite used for Amex EMV contactless transaction certification of deployed EMV devices. This test suite is supported by the Collis and ICC Solutions testing tools.

Fallback Fallback – The term used to describe the process and rules relating to using the magnetic-stripe reader of the CAD to obtain card information when the ICC or EMV PIN Pad is inoperable, or no mutually supported AIDs are found.

FCI File Control Information – In EMV FCI is defined as part of a DF and contains information needed to select the DF and/or the subsequent EF under it.

fDDA

Fast Dynamic Data Authentication – In most contactless payment environments, quick transaction speeds (one second or below) are a business requirement. A DDA 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 to CDA).

FID Field Identifier – Used in various types of host messages to identify a single data field.

Floor Limit Floor Limit – The maximum transaction amount that can be locally authorized by the merchant without receiving an authorization from the Issuer.




GPO

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 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

HSM Hardware Security Module – A secure, tamper evident device used to securely generate and store keys (symmetric and asymmetric) and for performing cryptographic functions.

IA

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 the ARPC sent from the issuer to make sure it has not been changed by any unauthorized entity along the way.

IAC

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 are set by the issuer and loaded on to the ICC during the card personalization process.

IAD Issuer Application Data – Contains proprietary application data that is required by the Issuer to be transmitted as part of the online authorization request.

ICC Integrated Chip Card – Refers to a plastic card that contains a small electronic chip. Also known as smartcards or chip cards.

iCVV

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 the magstripe image of the chip. iCVV enables issuers to identify fraudulent use of ICC data in magstripe read transaction processing.

IDD Issuer Discretionary Data – Data encoded on magstripe by the issuer.

IDN ICC Dynamic Number – A time-variant number generated by the ICC, to be captured 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

IIN Issuer Identification Number – Replaces the previously used Bank Identification Number (BIN). See BIN for more information. The acronym IIN may be used interchangeably with BIN.




INS

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 class. The INS is only valid if the least significant bit is ‘0’ and the most significant nibble is not '6' or '9'.

Interac Interac – The Association responsible for the development of Canada’s network of two shared electronic financial services; Shared Cash Dispensing (ABM) and Interac Direct Payment (debit at point of sale).

ISO International Organization for Standardization

IWK Issuer Working Key – A Visa key used exclusively to encrypt/decrypt PIN blocks being sent between the Issuer and the Visa network.

KEK Key Encryption Key – A key used exclusively to encrypt / decrypt other keys.

Kernel Kernel – The part of the PIN Pad application that contains all the EMV commands used between the CAD and ICC and that has been EMV type approved (Level 2).

Lc Length of data being transmitted.

LCOL Lower Consecutive Offline Limit – Issuer-specified preference for the maximum number of consecutive offline transactions allowed for the ICC application, before the transaction should go online (if terminal has online capabilities).

LCOTA

Lower Cumulative Offline Transaction Amount – Issuer-specified preference for the maximum total amount of offline approved transactions in the supported currency of the application before the transaction should go online (if terminal has online capabilities).

Le Maximum length of data expected in response.

LMK Local Master Key – The highest level administrative key, generated in the clear by an HSM. The LMK is used to encrypt all ZMK and application keys (AC, MAC and ENC keys) used in cryptographic processing by the HSM.

LOATC

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. 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.

LRC Longitudinal Redundancy Check – A mathematically calculated value at the end of data streams that represents the data that precedes it. The LRC is used to ensure data streams have been received exactly as transmitted.

MAC

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 original data has not been changed. As speed of this operation is critical, TDES is used as the MACing algorithm.




MCC

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 payment. The MCC is used to classify the business by the type of goods or services it provides.

MDK Master DES Key – Used to derive UDKs which are loaded on to the ICC application during personalization. There are three types of MDKs: AC, MAC and ENC keys.

MF Master File – The peak of the hierarchy of the ICC file structure. It contains information and locations of the Dedicated Files (DF). DFs contain the actual data files which are called Elementary Files (EF).

MII

Major Industry Identifier – The first digit of the card PAN (or BIN / IIN) is the Major Industry Identifier (MII), which represents the category of the entity which issued the card.

E.g. Visa uses ‘4’ and MasterCard uses ‘5’ which are both defined as Banking and Financial categories.

MSI Magnetic Stripe Image

MSD/MSR

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 date, allowing for automated handling of transactions. The bank card industry standard for magnetic stripes allows three separate tracks of encoded data.

MSR Fallback MSR Fallback – The term used to describe the process and rules relating to using the magnetic-stripe reader of the CAD to obtain card information when the ICC or the EMV PIN Pad are operable but the Candidate List is empty.

M-TIP

MasterCard Terminal Integration Process – Details the MasterCard processes and test cases that acquirers must successfully perform before a terminal can be certified and deployed in a production environment. This test suite is supported by the Collis and ICC Solutions testing tools.

NFC

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 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




P2PE Point to Point Encryption – A standard for encrypting cardholder data (usually the PAN) to protect sensitive data.

PAN Primary Account Number – A 13 to 19 digit number used to identify a debit cardholder or a credit account number.

PayPass PayPass – MasterCard contactless payment card or device implementation.

payWave payWave – Visa contactless payment card or device implementation.

PCB Protocol Control Byte

PCI

Payment Card Industry – Sometimes more specifically used to refer to the Payment Card Industry Security Standards Council (PCI-SSC). An independent council 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).

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 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.

PCI – PTS Payment Card Industry PIN Terminal Security – Specification defining the physical and logical security requirements for PIN entry devices. Go to www.pcisecuritystandards.org for additional information.

PCVC3 Position of CVC3 – Field defining the location of the CVC3 in the Track-2 data for a contactless MSD PayPass transaction.

PDOL Processing Data Object List – A list of terminal-related data objects (tags and 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.

PEK PIN Encryption Key – The PEK is a key used exclusively to encrypt PIN blocks between the various Issuer card personalization environments (from Issuer host through Data Preparation to Personalization).

PIN Personal Identification Number – A 4-12 digit string of numbers entered by the cardholder to provide cardholder verification when specified by the CVM.




PIN Block

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 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).

PIX

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, 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).

PK Public Key – A key used in RSA that does not have to be kept secret. It is used to 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.

PKI

Public Key Infrastructure – A set of hardware, software, people, policies and procedures needed to create, manage, distribute, use, store and revoke digital certificates. A PKI is an arrangement that binds PKs with respective user identities by means of a CA.

POS Point of Sale – A type of terminal which is used to process electronic transactions in shops, restaurant etc. The POS may process offline or go online for Authorization by the Issuer/Scheme when processing a transaction.

PPSE Proximity Payment System Environment – Has a fixed name of 2PAY.SYS.DDF01 and contains a directory of all the contactless payment applications that exist on the ICC. PPSE is mandatory in all contactless implementations.

PSE

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 is optional in EMV it is highly recommended to enhance transaction performance.

PTC

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 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.

PTL PIN Try Limit – The issuer-specified maximum number of consecutive incorrect offline PIN tries allowed before the card is blocked.

PTS Program

POS Terminal Security Evaluation Program – MasterCard program to enhance the security of transactions originating at wireless and IP-enabled POS payment terminals.

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

PVT Personalization Validation Tool – PVT is a tool used by Visa and Visa members to 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.

PVV

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 algorithm using the last eleven digits of the PAN (excluding the mod 10 check value), a one digit PIN Verification Key Index (number 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

RFU Reserved for Future Use – Commonly used in technical specifications to represent space for a field that may be used in the future for new functionality.

RID Registered Identification Number – The first part of the AID used to identify the scheme (e.g. Visa, MasterCard, etc.).

RSA Rivest-Shamir-Adleman – An asymmetric algorithm used for cryptography named after its three inventors.

SAD (SSAD)

(Static) Signed Application Data – A digital signature generated from critical card data elements and personalized on the ICC.

The SAD is validated by the terminal during the SDA process.

SAF

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 the ICC and CAD). The transaction is “stored” locally and then “forwarded” to the host before settlement occurs.

SDA

Static Data Authentication – An option for offline CAM which protects against counterfeit attacks. During the SDA process the terminal will validate the SAD to ensure the information on the ICC has not been changed since the ICC was personalization by the Issuer.

SDAD Signed Dynamic Application Data.

SFI Short File Indicator – Used to identify a file in the commands related to an application Elementary File (EF). The SFI data object is a binary field with its three high-order bits set to zero.

SHA -1 Secure Hashing Algorithm – A secure hashing algorithm designed for use with the digital signatures. The SHA-1 algorithm output is always 20 bytes in length.




Signature Fallback

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 is indicated in the ICC’s CVM list.

It is important not to confuse Signature Fallback with MSR Fallback or Technical Fallback.

SPED

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 through its processing in the POS system by encrypting the PIN before it leaves the SPED.

STIP Stand-in Process – The process where a third party entity stands in to authorize an online electronic bank transaction on behalf of the Issuer.

SVC

Service Code – The three digit code that follows the expiry date on Track 2. 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: 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

TAA Terminal Action Analysis – Following the completion of TRM and the setting of the TVR the CAD will perform the TAA which involves the CAD analyzing the TRM processes and requesting the appropriate cryptogram (AAC, ARQC or TC).




TAC

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. 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 Tag – Method used to exchange information with the EMV chip. Each EMV Tag is assigned a Tag Number denoting the type of information it contains.

TAL Terminal Application Layer

TC Transaction Certificate – An Application Cryptogram type generated by the chip 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.

TCI Terminal Check for Implementation – Test suite used for JCB EMV contact transaction certification of deployed EMV devices.

TDES

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 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.

TDOL

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 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 Technical Fallback – The process and rules relating to using the magnetic-stripe reader of the CAD to obtain card information if the ICC or the EMV PIN Pad is inoperable.

TIP

Terminal Integration Process – A key testing process designed and mandated by MasterCard to test the CAD, its intermediate connections and the interface with the acquirer host system, in conditions that are as close as possible to its final production environment.

TLV Tag/Length/Value – A variable length data format that uses a label (tag) to uniquely identify a field followed by its field value length and then the field value.

TPDU Transport Protocol Data Unit

TQM

Terminal Quality Management – MasterCard program that provides assurance to acquirers that devices they certify are consistent with the card interface module approved by EMVCo. The TQM process ensures that the smart card and contactless hardware interfaces are EMV Level 1 compliant.




TRM Terminal Risk Management – A process performed by the CAD to determine if the 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.

TSI Terminal Status Information – Identifies the functions performed by a CAD during transaction processing (e.g. offline data authentication, CVM, CRM, TRM etc.).

TTQ Terminal Transaction Qualifiers

TVR The Terminal Verification Result – An EMV tag containing the status of several different EMV checks performed by the PIN Pad kernel or the EMV POS Solution.

UCOL

Upper Consecutive Offline Limit – Issuer-specified preference for the maximum number of consecutive offline transactions allowed for the ICC application, before a transaction must be approved online. Once this value is reached no offline transactions are allowed for that application until an online transaction is approved.

UCOTA

Upper Cumulative Offline Transaction Amount – Issuer-specified preference for the maximum total amount of offline approved transactions, in the supported 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.

UDK Unique DES Key – A unique key derived using the MDK, PAN and PAN Sequence Number. The UDKs are loaded onto the ICC application during personalization. There are three types of UDKs: AC, MAC and ENC keys.

UICC Universal Integrated Circuit Card – The smart card used in GSM network mobile terminals. The UICC ensures the integrity and security of personal data. The UICC will typically contain a few hundred kilobytes of personal data.

UN

Unpredictable Number – A value used to provide variability and uniqueness when generating a cryptogram or during an encryption process.

When used in the CAM process the PIN Pad generates the UN.

When used for offline encrypted PIN the UN is generated by the chip application.

VIS Visa ICC Specification – The Visa specific implementation of EMV credit / debit applications on an ICC. The specification is often referred to as VSDC.

VLP Visa Low Value Payment

VSDC Visa Smart Debit Credit – An EMV based ICC application specified by Visa. In many cases this is often used to refer to the VIS specifications.




ZMK Zone Master Key – A high level administrative key established manually between 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.

EMV Implementation Guide Appendix ‘A’ - Canadian Processing


16. Appendix ‘A’ - Canadian Processing

16.1 Interac Account Selection Prompting When processing a Canadian Interac card, the cardholder must be prompted to select the account type the funds should be debited from. The Account Selection prompt must be presented in the cardholder language after Amount Confirmation and before PIN Entry.

Interac Account Selection Prompting

Account English Short Name

French Short Name1

Chequing CHQ CHQ Savings SAV EP

1 EMV POS Solutions deployed in Canada must support displaying the Interac Account Selection Prompt in French

The debit account type selected for the transaction, must be sent to the Chase Paymentech host in the request message and must be printed on the receipt (“Chequing” or “Savings”).

16.2 Canadian Language Requirements specific to Interac EMV POS Solutions being deployed in Canada must:

1. Support both English and French

2. Perform cardholder prompting in the preferred cardholder language (see page 95)

3. Print the customer receipt in the preferred cardholder language (see page 272)

01601 Canadian EMV POS Solutions must support French cardholder prompting

Chase Paymentech all EMV POS Solutions deployed in Canada support French prompting and that cardholder prompting be performed in the cardholder’s preferred language (English/French).

01602 Canadian EMV POS Solutions must support French receipt printing

Chase Paymentech requires that all EMV POS Solutions being deployed in Canada support French receipt printing and that the customer receipt be printed in the cardholder’s preferred language (English/French).



16.2.1 Sample Approved Receipt - French The following is an example of a receipt for a credit EMV purchase transaction approved online by the host. The CVM used was online PIN and the card track data was obtained by reading the EMV chip.

NOM DU MARCHAND RUE EU MERCHAND

VILLE, CODE DE PROVINCE CODE POSTAL 123-456-7890

ID MERCHAND: 999999999999 ID TERM: 12345678 No Ref: 999 ID Commis: 01234 Schedule: 2 NO TPS:123456789

Achat

xxxxxxxxxxxx8106 VISA METHODE ENTR: CHIP MM/DD/YYYY HH:MM:SS NO. Fact #: 999 NO. REF CLI: 999 NO. LOT #: 999999 Montant: $75.01 ========= Total: $75.01

APPROUVE 123456

VERIFIE EN NIP

EN ENTRANT UN NIP VERIFIE, DETENTEUR CONSENT A PAYER A EMETTEUR UN TEL TOTAL EN ACCORD AVEC L’ENTENTE DE L’EMETTEUR DETENTEUR DE CARTE AID: A0000000031010 TVR: 0000008000 TSI: F800 AC: 0123456789ABCDEF ARC: 00

COPY DU MERCHANT / COPY CLIENT Footer 1 Footer 2 Footer 3

EMV Receipt Requirements Transaction Type (Achat) Application Preferred Name (Tag 9F12)

is on the chip in a supported character set, so it is printed (VISA)


Card Entry Method indicates card was inserted and card information was read from the contact chip (CHIP)


EMV Information must be printed in the order shown and identified by the tag names: o AID (A0000000031010) o TVR (0000008000) o TSI (F800) o AC (0123456789ABCEDF) o ARC (00)


Cardholder Verification Method – A PIN was entered so “VERIFIE EN NIP” must be printed





16.2.2 Sample Declined Receipt - French The following is an example of a receipt for a credit EMV purchase transaction declined online by the host. The CVM used was Signature and the Track 2 PAN was obtained by reading the EMV chip.

NOM DU MARCHAND RUE EU MERCHAND

VILLE, CODE DE PROVINCE CODE POSTAL 123-456-7890

ID MERCHAND: 999999999999 ID TERM: 12345678 No Ref: 999 ID Commis: 01234 Schedule: 2 NO TPS:123456789

Achat

xxxxxxxxxxxx8106 VISA METHODE ENTR: CHIP MM/DD/YYYY HH:MM:SS NO. Fact #: 999 NO. REF CLI: 999 NO. LOT #: 999999 Montant: $75.02 ========= Total: $75.02

REFUSE

AID: A0000000031010 TVR: 0000008000 TSI: E800 AC: 0123456789ABCDEF ARC: 05

COPY DU MERCHANT / COPIE CLIENT Footer 1 Footer 2 Footer 3 Footer 4

EMV Receipt Requirements Transaction Type (Achat) Application Preferred Name (Tag 9F12)

is on the chip in a supported character set, so it is printed (VISA)


Card Entry Method indicates card was inserted and card information was read from the contact chip (CHIP)


EMV Information must be printed in the order shown and identified by the tag names: o AID (A0000000031010) o TVR (0000008000) o IAD (06010A03A40002) o TSI (E800) o ARC (05)

Transition was declined so Cardholder Verification Method is not printed





16.3 Interac Application Selection For Interac card processing the Application Selection process differs slightly from the process used for other U.S. domestic debit cards:

1. Credit / Debit Selection and U.S. Debit Processing is not performed (see page 89)

2. Application Selection Flag “Canadian Flag” processing must be performed

16.3.1 Application Selection Flag “Canadian Flag” (Tag DF62) Processing

EMV POS Solutions supporting Interac must support Application Selection Flag (ASF) processing. This processing is performed after Implicit / Explicit Application Selection has completed and before Final Selection begins.

During Application Selection Flag processing, the EMV POS Solution must check for the presence of the Issuer Country Code (Tag 5F56) and the Application Selection Flag (Tag DF62) in either of the following locations:

1. When the card and EMV POS Solution both support the Payment System Environment (PSE):

a. Check the optional Directory Discretionary Template (Tag 73) of an Application Definition File (ADF) directory entry in the Payment System Directory

2. Otherwise:

a. Check the optional File Control Information (FCI) Issuer Discretionary Template (Tag BF0C) of the ADF

If the Application Selection Flag (Tag DF62) is not present, and the Candidate List contains more than one mutually supported application, then the Candidate List must be presented to the cardholder for Application Selection.

The Application Selection Flag (Tag DF62) is be interpreted as follows.

“Canadian” Application Selection Flag (Tag DF62) Byte Usage Format Value

Byte 1 ABM Binary Bit 8 = 1: Use as Primary application at ABM Bit 7 = 1: Use as Secondary application at ABM Bit 6 – 1: RFU

Byte 2 ABM Binary Bit 8 = 1: Use as Primary application at POS Bit 7 = 1: Use as Secondary application at POS Bit 6 – 1: RFU

Byte 3 RFU

This interpretation of the Issuer Country Code and Application Selection Flag occurs after the list of mutually supported applications has been built. The EMV POS Solution must then interrogate the card for the presence of the ASF and Issuer Country Code to create two sub-lists; a Primary sub-list and a Secondary sub-list.



Creating Application Sub-lists – Step 1 If Tag 5F56 is not present, the PIN Pad adds the application (AID) to the Primary sub-list

If Tag 5F56 is not present but Tag DF62 is present, the PIN Pad adds the application to Primary sub-list

If Tag 5F56 is present for the application in question and value does not equal “CAN”, the PIN Pad adds application to Primary sub-list

If Tag 5F56 is present and is equal to “CAN”, the PIN Pad interrogates the chip card for the presence of Tag DF62 – Application Selection Flag

Creating Application Sub-lists – Step 2 If the ASF data element is present, the PIN Pad will use it to determine if the application is intended for use as Primary Application, a Secondary Application or if it should not be used. This is determined by the ASF Byte 2 value.

Application Selection Flag (Tag DF62) – Byte 2 Interpretation Bit 8 Bit 7 Value

0 0 Application ignored – not added to Primary or Secondary sub-list 1 0 Add application to Primary sub-list 0 1 Add application to Secondary sub-list

1 1 Add application to Primary sub-list

Application Selection Scenarios The following table outlines the various Application Selection Flag scenarios.

Application Selection Scenarios

Scenario Tag 5F56

Issuer Country Code

Tag DF62 – Byte 1 (ABM)

Application Selection Flag

Tag DF62 Byte 2 (POS) Application

Selection Flag

POS Candidate List

1 “CAN” Bit 8 = 1 Bit 8 = 1 Primary sub-list 2 “CAN” All zeros Bit 8 = 1 Primary sub-list 3 “CAN” All zeros Bit 7 = 1 Secondary sub-list 4 “CAN” Bit 8 = 1 All zeros N/A 5 Not Present Present Present Primary sub-list

6 Not “CAN” N/A N/A Primary sub-list

Once the mutually supported applications have been categorized as Primary and Secondary, the PIN Pad will present one of the lists for Application Selection and cardholder confirmation.

1. If the Primary sub-list is not empty, the Primary sub-list is presented.

2. If the Primary sub-list is empty, but the Secondary sub-list is not empty, the Secondary is presented.

3. If both the Primary and Secondary sub-lists are empty, the transaction must be terminated.



If during selection the sub-list being presented (Primary or Secondary) becomes empty (e.g. all applications in the sub-list are blocked), the transaction must be terminated.

Automatic Application Selection If there is only one mutually supported application in the sub-list being used, the PIN Pad checks Bit-8 of the Application Priority Indicator (Tag 87) for that application to see if cardholder confirmation is required. If Bit-8 is:

‘0’ – The application is selected automatically and cardholder confirmation is not required

‘1’ – Cardholder confirmation is required to select the application

If there is only one mutually-supported application, the EMV POS Solution must check the Cardholder Approval Indicator (Tag 87 bit-8) to determine if Cardholder Application Confirmation is required. For more information on this process see page 94.



16.4 Canadian Debit Transaction Set This section defines the Canadian debit transaction set supported by Chase Paymentech and specifies how the transactions are identified for each of the Chase host interfaces:

PNS ISO

UTF

Stratus Online / Stratus Batch (not supported)

Canadian Debit Transaction Set Transaction Type

ISO (TCS)1

ISO (HCS)2

UTF (TCS) 1

UTF (HCS)2



Auth Only N/A Pre-Auth

1200 N/A

Pre-Auth 30 (Future)

N/A N/A

Sale N/A 1200 N/A 27 N/A N/A

Sale w/Cashback N/A


= 099700 N/A 28 N/A N/A

Prior Sale / Completion

N/A


= 179700 (Future)

N/A 31

(Future) N/A N/A

Offline Posting N/A


= 119700 N/A

36 Sale 37 Return

N/A N/A

Refund / Return N/A


= 209700 N/A 29 N/A N/A


N/A 1400 N/A 44 Void Sale

N/A N/A 45 Void Return




16.5 Interac Cashback Processing When performing an Interac transaction with cashback the following rules apply:

1. Transaction Amount (Tag 9F02) must include the total amount (Sale Amount + Cashback Amount)

2. Other Amount (Tag 9F03) must be present and set to zeros.



END OF DOCUMENT

Documents

EMV Implementation Guide - Magento 2 · This Chase Paymentech EMV Implementation Guide provides insight into EMVCo requirements and outlines the expected EMV transaction flow. However,