PayPass. Test Cases for Level 2 Terminal Testing

Transcription

1 PayPass Test Cases for Level 2 Terminal Testing

2 Copyright The information contained in this manual is proprietary and confidential to MasterCard International Incorporated (MasterCard) and its members. This material may not be duplicated, published, or disclosed, in whole or in part, without the prior written permission of MasterCard. Media This document is available in both electronic and printed format. MasterCard Worldwide - CCoE Chaussée de Tervuren, 198A B-1410 Waterloo Belgium Fax:

3 Table of Contents Using this Manual...1 Scope...1 Audience...1 Language Use...1 Document Word Usage...1 Related Publications...2 Abbreviations...2 Notations...4 Summary of changes Introduction Terminal Vendor Testing Process Test Case Template Description Overview Test Cases Common Test Cases...1 C : Protocol Activation - Activate contactless interface...1 C : Pre-Process - Reader clears Terminal Contactless Transaction Limit exceeded flag...1 C : Pre-Process - Reader clears Terminal Contactless Floor Limit exceeded flag...2 C : Pre-Process - Reader clears Terminal CVM Required Limit exceeded flag...2 C : Pre-Process - Reader sets Terminal Contactless Transaction Limit exceeded flag...3 C : Pre-Process - Reader sets Terminal Contactless Floor Limit Exceeded flag...4 C : Pre-Process - Reader sets Terminal CVM Required Limit Exceeded flag...5 C : Pre-Process - Reader does not set Terminal Contactless Transaction Limit...6 C : Pre-Process - Reader does not set Terminal Contactless Floor Limit Exceeded...7 C : Pre-Process - Reader does not set Terminal CVM Required Limit Exceeded...8 C : Pre-Process - Contactless transaction limit exceeded for all AIDs...9 C : Pre-Process - Limits have the same value (implicit test) C : PPSE - First command C : PPSE - Syntax of command Message C : PPSE - Data Field Returned in the Response Message C : PPSE - Additional data objects C : PPSE - SW <> C : PPSE - Mandatory data missing in response C : PPSE - Incorrectly formatted FCI C : Building candidate list - Matching ADF name C : Building candidate list - ADF Name entries longer C : Building candidate list - Ordering of the final candidate list C : Building candidate list - API b8 = C : Building candidate list - No priority (API set to 0) C : Building candidate list - Duplicate priorities C : Building candidate list - No priority C : Building candidate list - Next Highest priority C : Building candidate list - Candidate list for final application selection is empty C : Building candidate list - Candidate list is empty - API bit 8 = C : FINALSELECT - Data Field in the response message C : FINALSELECT - Format 'ans' (App. Label and App. preferred Name) C : FINALSELECT - Language Supported by PayPass reader i

4 Table of Contents C : FINALSELECT - PayPass reader uses language With Highest Preference C : FINALSELECT - Store data for later use C : FINALSELECT - Additional Data objects returned in the Response Message C : FINALSELECT - No optional data C : FINALSELECT - SW <> 9000 and only one mutual application C : FINALSELECT - SW <> 9000 and only 3 mutual application C : FINALSELECT - Accept format errors for Selection data objects C : FINALSELECT - Verification of DF Name fails C : GetPO - No PDOL C : GetPO - Amount and Transaction Details present before application activation C : GetPO - Syntax of response message: Format C : GetPO - Syntax of response message: Format C : GetPO - Ignore additional data objects C : GetPO - Reader ignores 4th byte of AFL C : GetPO - PDOL tag is not a reader resident data object C : GetPO - SW <> 9000 & C : GetPO - SW = M/Chip C : GetPO - SW = M/Chip - Combined test C : GetPO - SW = Mag Stripe C : GetPO - Mandatory data objects missing in format 1 & format 2: AIP C : GetPO - Mandatory data objects missing in format 1 & format 2: AFL C : GetPO - Verification of response message fails C : GetPO - AFL with an incorrect SFI C : GetPO - AFL with an incorrect starting record number C : GetPO - AFL with an incorrect ending record number C : ReadRecord - Each entry in the AFL (Combined test) C : ReadRecord - Each entry in the AFL (Not pre-defined AFL) C : ReadRecord - Record Data Format C : ReadRecord - Mapping of data objects into records C : ReadRecord - Store data elements C : ReadRecord - ISO Padding - padding between Data object C : ReadRecord - Padding: padding between Data object with FF C : ReadRecord - Padding: padding between Data object C : ReadRecord - ReadRecord - Proprietary data (M/Chip) C : ReadRecord - Proprietary data (Mag Stripe) C : ReadRecord - Record size in the range from 1 to 254 bytes C : ReadRecord - SFI range 1-10 (Non-pre-defined AFL) C : ReadRecord - SW <> C : ReadRecord - Incorrect record template C : ReadRecord - Proprietary data ignored by Terminal in SFI 1 to C : ReadRecord - Reader data objects in card response C : ReadRecord - Duplication of primitive data objects C : DOL - Object List consistency (1) C : DOL - Concatenation C : DOL - PDOL Requests Amount, Authorized & Amount, Other C : DOL - Card requesting 9F28 tag C : DOL - Unknown tag C : DOL - Data not yet available C : DOL - Tag with length= C : DOL - Known tag, missing in card C : DOL - Shorter data object length, numeric format C : DOL - Shorter data object length, other format C : DOL - Longer data object length, other format C : DOL - Longer data object length, numeric format C : DOL - Constructed tag C : Data Object Management - Length field - 1 byte C : Data Object Management - Length field - 2 bytes C : Data Object Management - Unique IFD and Terminal Country Code for each AID C : Data Object Management - Terminal Contactless Transaction Limit for each AID ii

5 Table of Contents C : Data Object Management - Terminal Contactless Floor Limit present for each AID C : Data Object Management - Terminal CVM Required Limit present for each AID C : Data Object Management - Support of data object during application activation C : Data Object Management - Separate instance of data object for each AID C : Data Object Management - with minimum length - Application identifier C : Data Object Management - with maximum length Application Identifier C : Miscellaneous - PayPass reader Support of Local Language C : Miscellaneous - PayPass reader Display of Messages in Local Language C : Miscellaneous - PayPass reader Support of Relevant Character Set C : Miscellaneous - Display For Attendant in Attended Terminal C : Miscellaneous - Capability of PayPass Reader Printer C : Miscellaneous - PayPass reader uses local language when no match is found C : Miscellaneous - PayPass reader Displays Message in Supported Language PayPass Mag Stripe Test Cases G : PPSE - Mandatory data objects missing: ADF Name G : FINALSELECT - Direct selection of application G : FINALSELECT - Incorrectly formatted FCI G : FINALSELECT - Mandatory data objects missing G : GetPO - RFU bit set in AIP - Mag Stripe G : GetPO - Mag Stripe reader accepts M/Chip card G : ReadRecord - Files containing multiple records (Non-pre-defined AFL) G : ReadRecord - 4 m.s. bytes same as PayPass Mag Stripe value G : ReadRecord - Optional Data Objects G : ReadRecord - Verifying PCVC3TR1, PUNATCTR1 and NATCTR1 are present G : ReadRecord - Verifying qtrack G : ReadRecord - Verifying ktrack1 - ttrack G : ReadRecord - Verifying nun G : ReadRecord - Verifying qtrack G : ReadRecord - Verifying PAN and Expiration Date in Track 1 Data G : ReadRecord - Storing recognized data objects-optional data G : ReadRecord - Copying process - Track 1 format error G : ReadRecord - Not verify service code in Track 1 data or Track 2 data G : ReadRecord - Missing data objects: Track 2 Data G : ReadRecord - Missing data objects: PUNATCTRACK G : ReadRecord - Missing data objects: PCVC3TRACK G : ReadRecord - Missing data objects: NATCTRACK G : ReadRecord - All mandatory data objects missing G : ReadRecord - PCVC3TRACK1 or PUNATCTRACK1 or NATCTRACK1 missing G : ReadRecord - Copying process - Track 2 format error G : ReadRecord - Data Object incorrectly formatted: PUNATCTRACK G : ReadRecord - Data Object incorrectly formatted: PCVC3TRACK G : ReadRecord - Data Object incorrectly formatted: NATCTRACK G : ReadRecord - Copying process - Track 1 format error G : ReadRecord - Data Object incorrectly formatted: Track 1 Data G : ReadRecord - Data Object incorrectly formatted: PUNATCTRACK G : ReadRecord - Data Object incorrectly formatted: PCVC3TRACK G : ReadRecord - Data Object incorrectly formatted: NATCTRACK G : ReadRecord - Data Object incorrectly formatted: UDOL G : ReadRecord - ktrack2 < ttrack G : ReadRecord - nun > G : ReadRecord - qtrack2 < G : ReadRecord - qtrack1 < G : ReadRecord - ktrack1 - ttrack1 is not equal to nun G : ReadRecord - ktrack1 < ttrack G : ReadRecord - PAN discrepancy in Track 1 and Track G : ReadRecord - PAN & Expiration Date discrepancy in Track 1 and Track G : ReadRecord - Expiration Date discrepancy in Track 1 and Track G : Processing restrictions - AVN assigned by the payment system iii

6 Table of Contents G : Processing restrictions - AVN (card) present and supported G : Processing restrictions - AVN (card) present and not recognized G : Processing restrictions - AVN (card) not present G : CCC - No UDOL G : CCC - UDOL G : CCC - Unpredictable Number G : CCC - Generating an Unpredictable Number (nun = 0) G : CCC - Response contains only mandatory data objects G : CCC - Response contains mandatory and optional data objects G : CCC - Response contains mandatory, optional and additional data objects G : CCC - SW <> '9000' G : CCC - Mandatory card data object missing G : CCC - CVC3TRACK2, ATC missing G : CCC - CVC3TRACK1 missing G : CCC - No response to the CCC command G : CCC - Response not correctly formatted G : TrackComputation - Correctly builds discretionary data G : TrackComputation - Copying CVC3TRACK G : TrackComputation - Copying UN into Track 2 Data G : TrackComputation - Copying ATC to Track 2 Data G : TrackComputation - Copying nun G : TrackComputation - Copying CVC3TRACK G : TrackComputation - Copying UN into Track 1 Data G : TrackComputation - Copying ATC to Track 1 Data G : TrackComputation - Track 1 - nun at the end G : Completion - Data record with correct DDCARD,TRACK1, DDCARD,TRACK G : Completion - Optional data missing G : Completion - Data record with correct Third Party Data G : Completion - Mag Stripe Optional data missing G : Completion - Mag Stripe Optional data present G : Completion - Mag Stripe Optional data present G : DOL - UDOL - with maximum length G : Data Object Management - With minimum length G : Data Object Management - With maximum length G : Data Object Management - CVMlist not stored G : Refund - Data record G : Refund - Combined PayPass M/Chip Test Cases M : Pre-Process - CVM and Floor limits do not impact Mag Stripe transactions M : PPSE - Mandatory data missing: ADF Name, API M : FINALSELECT - SW <> Combined test M : FINALSELECT - Mandatory data objects missing M : FINALSELECT - Incorrectly formatted FCI M : GetPO - Valid PDOL M : GetPO - All bits in TVR and CVM results are set to 0b (1) M : GetPO - All bits in TVR are set to 0b (2) M : GetPO - All bits in TVR are set to 0b (3) M : GetPO - All bits in TVR are set to 0b (4) M : GetPO - All bits in TVR are set to 0b (5) M : GetPO - All bits in TVR are set to 0b (6) M : GetPO - Retrieval of AIP and AFL M : GetPO - AIP B2b8=1 and PayPass - Mag Stripe indicator not set M : GetPO - AIP B2b8=0 and PayPass - Mag Stripe indicator not set M : GetPO - RFU bit set in AIP - MChip M : GetPO - AFL with an incorrect number of records participating in ODA M : GetPO - Padding in format 1 response M : GetPO - Padding in format 2 response M : ReadRecord - Pre-defined AFL - no ODA iv

7 Table of Contents M : ReadRecord - Pre-defined AFL - SDA M : ReadRecord - Pre-defined AFL - CDA M : ReadRecord - Pre-defined AFL Online only M : ReadRecord - Files containing multiple records (Non-M/Chip profile AFL) M : ReadRecord - Length of Mandatory Data Objects: PAN M : ReadRecord - Padding of Data Objects: Track 2 equivalent Data M : ReadRecord - Mandatory data - SDA tag list not in SFI2 - record M : ReadRecord - Length coded on 2 bytes and data less than M : ReadRecord - Data objects processing (Unrecognized Data Objects) M : ReadRecord - Mandatory data missing - PAN M : ReadRecord - Mandatory data missing - CDOL M : ReadRecord - Mandatory data missing - Application Expiration Date M : ReadRecord - Mandatory data missing - SDA tag list M : ReadRecord - Duplication of data objects (MChip) M : Processing restrictions - AVN, AUC and Expired Application M : Processing restrictions - Processing the Year M : Processing restrictions - Calculation, Storage, and Display Date-Dependant Fields For Year M : Processing restrictions - Calculation of Dates M : Processing restrictions - Current Date is later than Application Expiration Date M : Processing restrictions - Current date is later than expiration date(leap year date) M : Processing restrictions - Current Date is equal to the Application Expiration Date M : Processing restrictions - Current Date equal to expiration date(leap year) M : Processing restrictions - Current Date is earlier than Application Expiration Date M : Processing restrictions - Current date is earlier than expiration date M : Processing restrictions - Current Date is earlier than Application Effective Date M : Processing restrictions - Current Date is equal to Application Effective Date M : Processing restrictions - Current Date is later than Application Effective Date(implied) M : Processing restrictions - Effective date out of range M : Processing restrictions - Expiration Date out of range M : Processing restrictions - PayPass reader Checks Presence of card in Exception file M : Processing restrictions - TVR Set if Match is Found in Exception File M : Processing restrictions - AVN assigned by the payment system M : Processing restrictions - AVN same M : Processing restrictions - Card and PayPass reader AVN are different M : Processing restrictions - AVN missing M : Processing restrictions - AUC missing M : Processing restrictions - AUC valid at ATM and other than ATM M : Processing restrictions - ICC match with TCC,'Valid for domestic goods set to 1 in AUC' M : Processing restrictions - ICC match with TCC,'Valid for domestic services set to 1 in AUC' M : Processing restrictions - No match with ICC and TCC 'Valid for international goods set to 1 in AUC' M : Processing restrictions - No match with ICC and TCC 'Valid for international services set to 1 in AUC' M : Processing restrictions - No match with ICC and TCC 'Valid for international goods not set to 1 in AUC' M : Processing restrictions - No match with ICC and TCC 'Valid for international services not set to 1 in AUC' M : Processing restrictions - ICC match with TCC,'Valid for domestic goods not set to 1 in AUC' M : Processing restrictions - ICC match with TCC,'Valid for domestic services not set to 1 in AUC' M : Processing restrictions - AUC set to 'Not valid for other than ATM' M : Processing restrictions - AUC set to 'Valid for other than ATM' M : Terminal Risk Management - Terminal Risk Management bit in AIP M : CVM selection - Cardholder Verification is supported in the AIP M : CVM selection - Supported CVM M : CVM selection - CVM condition-always M : CVM selection - Condition not satisfied M : CVM selection - Condition If supported and code not supported (Online PIN) v

8 Table of Contents M : CVM selection - Condition If supported and code not supported (Signature) M : CVM selection - no condition satisfied and no more CVRs M : CVM selection - If Transaction is under X value when the transaction amount = X M : CVM selection - If Transaction is over X value when transaction amount = X M : CVM selection - If Transaction is under Y value when the transaction amount = Y M : CVM selection - If Transaction is over Y value when the transaction amount = Y M : CVM selection - If unattended Cash and transaction is not cash M : CVM selection - If manual cash, and transaction is not manual cash M : CVM selection - CVM processing fails and CVR indicates to proceed with next rule M : CVM selection - If unattended Cash and transaction is not cash M : CVM selection - If manual cash, and transaction is not manual cash M : CVM selection - If purchase with cashback, and transaction is not purchase with cashback M : CVM selection - RFU bit setting in CVM List M : CVM selection - CVM processing fails and no more CVRs in the CVM List M : CVM selection - CVM processing fails and CVR indicates to not proceed with next rule M : CVM selection - Condition satisfied and Code is supported (No CVM) M : CVM selection - Condition satisfied and Code not supported (No CVM) M : CVM selection - Condition satisfied and Code not supported (No CVM) M : CVM selection - Condition satisfied and Code is supported (signature) M : CVM selection - Condition satisfied and Code is supported (PIN Online) M : CVM selection - Condition satisfied and Code not supported (Online PIN) M : CVM selection - Condition satisfied and Code not supported (Online PIN) M : CVM selection - Condition satisfied and non-paypass Code M : CVM selection - Condition satisfied and non-paypass Code M : CVM selection - Condition satisfied and Code not supported (signature) M : CVM selection - Condition satisfied and Code not supported (signature) M : CVM selection - Functions not specified in the AIP: Cardholder verification M : CVM selection - CVM Results Set With Method Code and Condition Code of Last CVM Performed M : CVM selection - CVM Results Set With Method Code and Condition Code of Last CVM Performed (5) M : CVM selection - CVM Results Set With Method Code and Condition Code of Last CVM Performed (3) M : CVM selection - CVM processing succeeds (2) M : CVM selection - CVM processing succeeds (3) M : CVM selection - CVM processing succeeds -No CVM M : CVM selection - ICC Data required by the CVM Condition Code is missing M : CVM selection - CVM List is not present in the ICC M : CVM selection - CVM List with no Cardholder Verification Rules M : CVM selection - Condition Code outside the range of understood codes M : CVM selection - condition satisfied and Code not understood b7= M : CVM selection - condition satisfied and Code not understood b7= M : CVM selection - Condition satisfied and Code is "Fail CVM" - b7= M : CVM selection - Condition satisfied and CVM Code is Fail CVM b7= M : TAA - TVR and IAC-Denial check requests a TC (implied) M : TAA - TAC Denial processing bit set to 0b M : TAA - TAC Online Processing bit set to 0b M : TAA - Reader has online capability, TVR and IAC-Online Codes check requests a TC (implied) M : TAA - Reader has not online capability, TVR and IAC default check requests a TC M : TAA - TAC Default processing bit set to 0b & PayPass reader has no online capability M : TAA - Requests a TC on first GenAC M : TAA - TVR and IAC-Denial/Online check requests a ARQC (implied) M : TAA - TAC Denial processing bit set to 0b and IAC online to 1b M : TAA - Reader has online capability, TVR and IAC-Online check requests an ARQC M : TAA - Online only terminal requests an ARQC when not matching TAC-Online or IAC-Online M : TAA - TAC Online Processing bit set to 1b M : TAA - Requests an ARQC on first GenAC vi

9 Table of Contents M : TAA - IAC-Denial is not present in the ICC M : TAA - IAC-Online is not present in the ICC M : TAA - IAC-Default is not present in the ICC and the PayPass reader is offline only M : TAA - TVR and IAC-Denial check requests an AAC M : TAA - TAC Denial processing bit set to 1b M : TAA - Reader has not online capability, TVR and IAC-Default check requests an AAC M : TAA - TAC Default processing bit set to 1b & PayPass reader has no online capability M : TAA - Requests a AAC at first GenAC M : GenerateAC - CDOL1 for the first GenAC M : GenerateAC - No CDA request when DA selected is not CDA M : GenerateAC - No CDA request when CDA failed M : GenerateAC - No ODA to be performed M : GenerateAC - PayPass reader completes transaction when card indicated approval M : GenerateAC - Syntax of response message: Format M : GenerateAC - Syntax of response message: Format M : GenerateAC - Retrieval of CID M : GenerateAC - CID - TC M : GenerateAC - CID- ARQC M : GenerateAC - CID- AAC M : GenerateAC - RAPDU with an TC in first GenAC M : GenerateAC - Response template when CDA - mandatory items - CID M : GenerateAC - Response template when CDA not requested - mandatory items - CID M : GenerateAC - Response template when CDA - mandatory items - ATC M : GenerateAC - Response template when CDA not requested - mandatory items - ATC M : GenerateAC - Response template when CDA not requested - mandatory items - AC M : GenerateAC - Response template when CDA not requested - optional items - IAD M : GenerateAC - Response template when CDA requested - optional items - IAD M : GenerateAC - Proprietary data objects M : GenerateAC - If CDA performed - data record contain valid Application Cryptogram M : GenerateAC - SW <> M : GenerateAC - Mandatory data object - CID missing M : GenerateAC - Mandatory data object - AC missing M : GenerateAC - Mandatory data object - ATC missing M : GenerateAC - Mandatory data objects missing, format 1, TC response M : GenerateAC - Mandatory data objects missing, format 2, TC response M : GenerateAC - Response template tag missing - CDA not supported M : GenerateAC - Mandatory data is missing when CDA generation requested M : GenerateAC - Additional data objects in SDAD calculation - CDA M : GenerateAC - Incorrect response M : GenerateAC - Incorrect format - CDA generation requested M : GenerateAC - ARQC in format 1 without CDA M : GenerateAC - Reversal Used M : GenerateAC - Card responds with a AAC on first GenAC M : GenerateAC - AAC in format 1 or M : GenerateAC - Offline only and ARQC M : GenerateAC - AAC not digitally signed M : GenerateAC - TC not in format M : GenerateAC - Cryptogram at a higher level than requested (1) M : GenerateAC - CID - AAR M : GenerateAC - Padding in format 1 response M : GenerateAC - Padding in format 2 response M : SDA - PayPass reader shall be able to store 6 CA Index per RID M : SDA - Bit Length of all Moduli M : SDA - Value of Certification Authority Public Key Exponent M : SDA - Value of Issuer Public Key Exponent M : SDA - Algorithm For SDA M : SDA - Issuer Identifier with length between 3 to 8 digits M : SDA - Relationship Between the Lengths of the CA, Issuer, and ICC Public Keys M : SDA - Upper bound for size of moduli vii

10 Table of Contents M : SDA - Rules for Processing the records identified by the AFL M : SDA - Rules for Processing the Input Data M : SDA - Rules for Processing the Input Data(2) M : SDA - Proprietary data participating in SDA M : SDA - Hash Result of SDA calculated with a long string of data M : SDA - Certification Revocation List update, removal M : SDA - Certification Revocation List update, addition M : SDA - Issuer Public Key Remainder not needed M : SDA - Processing AIP during Offline SDA M : SDA - Card supports SDA and Not CDA M : SDA - Card supports SDA, DDA and does not support CDA generation M : SDA - Mandatory Data Objects for SDA M : SDA - Non recognized data object participating in ODA M : SDA - Calculation of Dates Associated With SDA M : SDA - SSAD data set to FF M : SDA - SSAD value set to 1 byte value other than FF M : SDA - SSAD has length M : SDA - no ODA supported by the reader M : SDA - SDA Tag List -Contains only AIP M : SDA - ODA - Functions not specified in the AIP M : SDA - Unknown CA Public Key M : SDA - Set TVR when mandatory SDA objects missing M : SDA - Combined test M : SDA - Issuer Public Key Remainder missing M : SDA - Rules for Processing the records identified in AFL M : SDA - Length of Issuer Public Key Certificate M : SDA - Recovered Data Trailer not equal to 'BC' M : SDA - Recovered Data Header not equal to '6A' M : SDA - Certificate Format not equal to '02' M : SDA - Difference between calculated Hash Result and recovered Hash Result M : SDA - Issuer Identifier does not match leftmost 3-8 PAN digits M : SDA - Certificate Expiration Date earlier than today's date M : SDA - Non-TLV coded proprietary data participating in ODA M : SDA - RID, CA Public Key Index and Certificate Serial Number not valid M : SDA - Issuer Public Key Algorithm not recognized M : SDA - Signed Static Application Data Length not OK M : SDA - Recover Data Trailer not equal to 'BC'-SSAD M : SDA - Recover Data Header not equal to '6A'-SSAD M : SDA - Certificate Format not equal to '03'-SSAD M : SDA - SDA Tag List in SDA M : SDA - Difference between calculated Hash Result and recovered Hash Result-SSAD M : SDA - PayPass reader terminates when SDA failed M : CDA - GenAC Reference Control Parameter M : CDA - CDA is the ODA to be performed M : CDA - CDA is the ODA to be performed - SDA must not be performed M : CDA - Unpredictable Number generated by the PayPass reader M : CDA - CDA not performed when card returns ARQC M : CDA - Rules for Processing the Input Data M : CDA - Rules for Processing the Input Data(2) M : CDA - Proprietary data participating in offline CDA generation M : CDA - Non recognized data object participating in ODA M : CDA - Rules for Processing the records identified by the AFL - SFI in range M : CDA - Hash Result of ICC Public Key calculated with a long string of data M : CDA - Issuer Identifier with length between 3 to 8 digits (2) M : CDA - Bit Length of All Moduli M : CDA - PDOL in CDA M : CDA - Values of CDOL1 for Transaction Data hash M : CDA - Non-TLV coded proprietary data participating in ODA M : CDA - Value of CA Public Key Exponent viii

11 Table of Contents M : CDA - Value of Issuer Public Key Exponent M : CDA - Value of ICC Public Key Exponent M : CDA - Success when 9F 4B data length < 128bytes and length coded on 2 bytes M : CDA - Success when 9F 4B data length > 128bytes and length coded on 2 bytes M : CDA - Upper bound for size of moduli M : CDA - PayPass reader shall be able to store 6 CA Index per RID M : CDA - Relationship Between the Lengths of the CA, Issuer, and ICC Public Keys M : CDA - Algorithm for CDA M : CDA - Issuer Public Key Remainder not needed M : CDA - ICC Public Key Remainder not needed M : CDA - no CDA request if ARQC M : CDA - Length of Issuer Public Key Certificate M : CDA - Recovered Issuer Data Trailer not equal to 'BC' M : CDA - Recovered ICC Data Trailer not equal to 'BC' M : CDA - Recovered Issuer Data Header not equal to '6A' M : CDA - Certificate Format not equal to '02' M : CDA - Calculated Hash Result <> recovered Issuer Hash Result (2) M : CDA - Calculated Hash Result <> recovered ICC Hash Result M : CDA - Issuer Application Data M : CDA - Issuer Identifier does not match leftmost 3-8 PAN digits M : CDA - Issuer Certificate Expiration Date earlier than today's date M : CDA - ICC Certificate Expiration Date earlier than today's date M : CDA - RID, CA Public Key Index and Certificate Serial Number not valid M : CDA - RID, CA Public Key Index and Certificate Serial Number not valid (2) M : CDA - Issuer Public Key Algorithm not recognized M : CDA - Length of ICC Public Key Certificate M : CDA - Recovered ICC Data Header not equal to '6A' M : CDA - ODA - Functions not specified in the AIP M : CDA - Certificate Format not equal to '04'-ICC Certificate M : CDA - SDA Tag List Contains AFL M : CDA - Recovered PAN is not equal to read PAN-ICC Certificate M : CDA - ICC Public Key Algorithm not recognized M : CDA - SDAD Length M : CDA - Recovered Data trailer not equal to BC-SDAD M : CDA - Recovered Data header not equal to 6A-SDAD M : CDA - Recovered Signed Data Format not equal to 05-SDAD M : CDA - Recovered CID different from CID obtained after GenAC (1) M : CDA - Compare hash result-sdad M : CDA - Compare Transaction Data Hash Code-SDAD M : CDA - Unknown CA Public Key M : CDA - Set TVR when mandatory CDA objects missing M : CDA - Response template tag missing - CDA supported M : CDA - Issuer Public Key Remainder missing M : CDA - ICC Public Key Remainder missing M : CDA - Rules for Processing the records identified by the AFL - SFI in range M : CDA - Certification Revocation List update, removal M : CDA - Certification Revocation List update, addition M : CDA - No CDA generation when AAC M : CDA - CDA failed when ICC responded with TC (1) M : CDA - ICC responds with AAR with SDAD M : CDA - ICC responds with AAR without SDAD M : CDA - ICC Dynamic Data M : Completion - MChip Optional data present in Offline Transaction M : Completion - MChip - Optional data present in Online Transaction M : Completion - PayPass reader transmits data record M : Completion - MChip - Optional data not present (Offline Transaction) M : Completion - MChip - Optional data not present (Online Transaction) M : DOL - Data Elements are Initialized in PayPass reader M : DOL - Unpredictable Number (Tag 9F 37) in CDOL ix

12 Table of Contents M : DOL - CDOL1 - Authorized Amount M : DOL - Clock local date and Time M : DOL - longer data object length, compressed numeric format M : Data Object Management - Optional Data Objects M : Data Object Management - with minimum length M : Data Object Management - with maximum length (2) M : Data Object Management - with maximum length (1) M : Data Object Management - with maximum length (3) M : Data Object Management - PayPass reader Displays Error Message if Verification Process fails M : Integrated terminal features - Amount Entry Separate From PIN Entry M : Integrated terminal features - online request message when ARQC M : Integrated terminal features Digit PIN (Online PIN) M : Integrated terminal features - Protection of Values of Entered PIN M : Integrated terminal features - Data Printed on Receipt M : Integrated terminal features - Protection of PIN During Online PIN Verification M : Integrated terminal features - Application Used Identified on Receipt M : Integrated terminal features - Protection of Captured Transactions M : Integrated terminal features - PayPass reader Prints Receipt With Line for Cardholder Signature M : Integrated terminal features - PIN entry when Online PIN selected as CVM M : Combined test - GetPO and GenAC with different response format M : Combined test - SDA and Record length coded on 1 or 2 bytes M : Combined test - SDA and Record length of proprietary file coded on 1 or 2 bytes M : Combined test - GetPO and GenAC with different response format, CDA M : Combined test - CDA and Record length coded on 1 or 2 bytes M : Combined test - CDA and Record length of proprietary file coded on 1 or 2 bytes M : Combined test - Combined functions M : Combined test - Valid PDOL, SDA, SIGNATURE, GetPO, GenAC in format M : Combined test - PDOL empty, SDA, Paper Signature, No Issuer Authentication, GenAC Format M : Combined test - PDOL empty, SDA, Plaintext PIN, No Issuer Authentication, GenAC Format M : Combined test - TVR byte checking: Online Only, TRM, AUC M : Combined test - TVR byte checking: Offline Capable, no TRM, no AUC M : Combined test - TVR byte checking: Offline Capable, TRM, AUC M : Combined test - GetPO Format 2, SDA, Plaintext PIN, No Issuer Authentication, GenAC Format M : Combined test - GetPO Format 1, SDA, Paper Signature, No Issuer Authentication, GenAC Format M : Combined test - GetPO Format 2, TRM, SDA, CDA, EncPIN, GenAC Format M : Combined test - CDA, Keys remainder missing, Proprietary Data and EMV data M : Miscellaneous - CDOL1 - Additional Terminal Capabilities M : Miscellaneous - CDOL1 - Terminal Capabilities M : Miscellaneous - CDOL1 - Terminal Type M : Miscellaneous - Coding of Bits and Bytes RFU - Capabilities M : Miscellaneous - Coding of Bits and Bytes RFU - IAC and TAC set to M : Miscellaneous - Generation of Unpredictable Number M : Miscellaneous - Coding of Bits and Bytes RFU - IAC set to M : Refund - No Processing restrictions M : Refund - No Terminal Risk Management M : Refund - No CVM selection M : Refund - No TAA M : Refund - No ODA M : Refund - Combined x

13 Using this Manual Using this Manual This chapter contains information that helps you understand and use this document. Scope This document lists the test cases used for the PayPass Terminal Type Approval Level 2 (for both PayPass Mag Stripe and PayPass M/Chip). Audience This document is intended for use by terminal vendors who want to obtain approval for their PayPass implementation. Language Use The spelling of English words in this manual follows the convention used for U.S. English as defined in Webster s New Collegiate Dictionary. MasterCard is incorporated in the United States and publishes in the United States. Therefore, this publication uses U.S. English spelling and grammar rules. An exception to the above spelling rule concerns the spelling of proper nouns. In this case, we use the local English spelling. Document Word Usage When a test deals with Refund, the document explicitely mentions a Refund transaction. When a test deals with Payment, the document mentions either Payment transaction or Transaction. 1

14 Introduction Related Publications The following publications contain information related to the contents of this manual. MC v2.1 MS v3.3 EMV 4.2b EMV BOOK 1 EMV BOOK 2 EMV BOOK 3 EMV BOOK 4 AN2 VTG PayPass - MChip Reader Card Application Interface Specification (V2.1) (April, 2010) PayPass Mag Stripe Technical Specifications, Version 3.3 December EMVCo Type Approval Terminal Level 2 Test Cases v4.2b, Feb 4, 2010 Integrated Circuit Card Specification for Payment Systems: Application Independent ICC to Terminal Interface Requirements. Version 4.2, June 2008 Integrated Circuit Card Specification for Payment Systems: Security & Key Management. Version 4.2, June 2008 Integrated Circuit Card Specification for Payment Systems: Application Specification. Version 4.2, June 2008 Integrated Circuit Card Specification for Payment Systems: Cardholder, Attendant and Acquirer Interface Requirements. Version 4.2, June 2008 MasterCard PayPass Application #2, January 30, 2008 PayPass Vendor Testing Process v1.2 September 2009 ICS PayPass M/Chip ICS v2.1 Abbreviations The following abbreviations are used in this manual, (see also Chapter 1 PayPass List): Abbreviation AAC AAR AC ADF AEF AFL AID AIP an Description Application Authentication Cryptogram Application Authorization Referral Access Application Definition File Application Elementary File Application File Locator Application Identifier Application Interchange Profile Alphanumeric 2

15 Using this Manual Abbreviation Description API Application Priority Indicator ARQC Authorization Request Cryptogram ATC Application Tranaction Counter AUC Application Usage Control b Binary CA Public Key Certificatiuon Authority Public Key CCC Compute Cryptographic Checksum CDA Combined DDA/AC generation CDOL Card Risk Management Data Object List CID Cryptogram Information Data CVC Card Validation Code CVM Cardholder Verification Method CVR Cardholder Verification Results DDA Dynamic Data Authentication DDF Directory Definition File DF Definition File DOLs Data Object Lists EMV Europay MasterCard Visa FCI File Control Information FCI File Control Information hex. Hexadecimal IAC Issuer Action Code ICC Integrated Circuit Card Id Identification IIN Issuer Identification Number ISO International Organization for Standardization LT Lower Tester (device used to test the terminal: either a card or a probe) M/C MasterCard M/Chip MasterCard Chip n Numeric NCA Length of the Certificate Authority Public Key Modulus P1 Parameter 1 P2 Parameter 2 PAN Primary Account Number PDOL Processing Data Object List 3

16 Introduction Abbreviation PIN PK Certificate PPSE RFU RID SDA TAC TC TDOL TRM TSI TVR UDOL UN Description Personal Identification Number Public Key Certificate PayPass Payment System Environment Reserved for Future Use Registered Application Provider Identifier Static Data Authentication Terminal Authentication Code Transaction Certificate Transaction Certificate Data Object List Tertminal Risk Management Transaction Status Information Terminal Verification Results Unprdictable Number Data Object List Unpredictable Number Notations The following notations apply: Notation Description 0 to 9 and A to F 16 hexadecimal digits. Values expressed in hexadecimal form are enclosed in single quotes (i.e. _ ). 1001b abcd Binary notation. Values expressed in binary form are followed by a lower case b. an or ans string. # Number. [ ] xx Optional part. Any value. 4

17 Using this Manual Summary of changes The differences between version October 2009 and are the following: a) Alignment with [MC v2.1] (29 changes) b) Alignment with [EMV 4.2b] (14 changes) c) Test coverage improvement (17 changes, 1 major) d) Renamed tests Below are some more details. a) Alignment with [MC v2.1] Test Name Change Impact C Test Case update for Refund potential C Test Case update for Refund potential C Test removed since it was for EntryPoint None C Test Case update for Refund potential C Test Case update for Refund potential C Test Case update for Refund potential C Test Case update for Refund potential C Test Case update for Refund potential C Test Case update for Refund potential G Test Case update for Refund potential G Test Case update for Refund potential G Test Case update for Refund potential G Test Case update for Refund potential G Test Case update for Refund potential G Test Case update for Refund potential G Test Case update for Refund potential G New test for Refund potential G New test for Refund potential M Test Case update for Refund potential M Test Case update for Refund potential 5

18 Introduction M Test Case update for Refund potential M Test Case update for Refund potential M Test update (Merchant Custom Data) potential M New test for Refund potential M New test for Refund potential M New test for Refund potential M New test for Refund potential M New test for Refund potential M New test for Refund potential b) Alignment with [EMV 4.2b] Test Name Change Impact C Sub-cases 4, 5, 6 added to test the GetPO format 2 with a reserved EMV data item C Test Case aligned with the EMVCo related test (2CL ISO padding). C Test Case aligned with the EMVCo related test (2CL ISO padding). C Test Case aligned with the EMVCo related test (2CL ISO padding). potential potential potential potential C New test case about SFI 1 to 30 potential C Test case reviewed to better test the 2 bytes length field M New test (GetPO - Padding in format 1 response) M New test (GetPO - Padding in format 2 response) M New test (GenerateAC - Padding in format 1 response) M New test (GenerateAC - Padding in format 2 response) M New test (CDA-Iss Public Key Remnder missing) previously tested in M M New test (CDA-ICC Public Key Remnder missing) previously tested in M M New test case about ICC Dynamic Data length, as per EMV 4.2b potential potential potential potential potential potential potential potential 6

19 Using this Manual c) Test coverage improvement Test name Change Impact G New sub case (Track1 with separator) potential G Test case reviewed (sub cases 3 and 4) potential G New test (Mag Stripe data record with optional data present) G Test was reviewed to include min and max length for all data record objects potential potential M TVR B3b7 now checked potential M TVR B3b7 now checked potential M TVR B3b7 now checked potential M TVR B3b7 now checked potential M TVR B3b7 now checked potential M TVR B3b7 now checked potential M TVR B3b7 now checked potential M TVR B3b7 now checked potential M New key lengths (144, 176) tested potential M New sub case for maximum key sizes major M New key length (144, 176) tested potential M Test case reviewed to include min and max length for all data record objects M Test case reviewed to include min and max length for all data record mandatory objects potential potential d) Renamed tests Previous test name New test name C M C M C M C C C C

20 Introduction C C G G C G G G G G G G C G C G G G C M M M C M M M M M M M M M M M M M M M M M C M C M

21 Introduction 1 Introduction This chapter contains an introduction to the testing process. 1.1 Terminal Vendor Testing Process The Vendor Testing Guide [VTG] document describes the process PayPass terminal vendors must follow for their products to be approved by MasterCard. One of the steps of this process is the Terminal Type Approval Level 2 (TTA L2). The objective of TTA L2 is to ensure the MasterCard PayPass application embedded in the terminal is compliant with requirements as defined in [MC V2.1] or [MS V3.3]. The compliance of a terminal to the application requirements is verified by executing tests specified by tests cases. A test case: covers a specific objective (for example: ensure that if, in the course of normal processing, the terminal recognises that data returned by the card is incorrectly formatted, then the terminal terminates processing.). refers to a specific requirement from the PayPass specifications. defines the conditions (card & terminal state) that must be met before the tests can be started. defines the procedure to execute the tests defines the criteria that allow a test to be considered as successful. 1-1

22 Introduction 1.2 Test Case Template Description Overview This paragraph describes the Test Case template used in this document. Test Case number and name Test objective Optional implementation needed to run this test Specification section Card configuration required for this test Test procedure Condition of test validation C SELECT PPSE Data Field Returned in the Response Message To ensure that the terminal ignores the presence of data objects returned in the SELECT PPSE response data that are not defined in [M/C PROFILE]. [PPSE] [MS V3.3]: Exception Processing [MC V2.1]: Exception Processing [EMV 4.2b]: N/A The terminal and LT have at least one mutually-supported application. The FCI Issuer Discretionary Data data object in the FCI of the PPSE contains a single directory record and the contents of this directory record correspond to one of the applications supported by the terminal. FCI of PPSE contains data objects that are not defined in [M/C PROFILE]. Application in LT is selected and transaction is performed with LT. The terminal issues a SELECT command with AID identical to the ADF Name in the directory record returned in the FCI of the PPSE. 1-2

23 Introduction Test Case Categories The test cases are split into three categories: Common: test cases used to validate functionality common to PayPass M/chip and PayPass Mag Stripe (for example: PPSE selection). The identifier of these tests starts with a C (example: C ) PayPass Mag Stripe: test cases used to validate PayPass Mag Stripe specific functionality (for example: CCC tests). The identifier of these tests starts with a G (example: G ) PayPass M/Chip: test cases used to validate PayPass M/Chip specific functionality (for example: generateac tests). The identifier of these tests starts with a M (example: M ) For the TTA L2 of a PayPass Mag Stripe terminal, the following test case categories will be executed: Common and PayPass Mag Stripe categories. For the TTA L2 of a PayPass M/Chip terminal, the following test case categories will be executed: Common PayPass Mag Stripe and PayPass M/Chip categories. 1-3

24 Introduction Naming convention Test Cases names are like Xyy-zzzz (e.g.: C ). Below is a description of the naming details: o o X is a letter identifying whether the test is: - common C - PayPass MagStripe G - PayPass M/Chip C yy indicates a transaction stage. This could be a command (e.g.: Final Select ) or a process (e.g.: Track calculation). Below is the list of the transaction stage identifiers used in this document. Transaction stage ID Description Transaction stage ID Description (Xyy-zzzz) (Xyy-zzzz) 00 Protocol Activation 21 CVM selection 01 Pre-Process 22 TAA 02 PPSE 23 GenerateAc 03 Building candidate list 24 SDA 04 FINALSELECT 25 CDA 05 GetPO 27 Completion 06 ReadRecord 30 DOL 07 Processing restrictions 31 Data Object Management 10 CCC 32 Integrated terminal features 11 Track Computation 33 Combined test 20 Terminal Risk Management 34 Miscellaneous 40 Refund o zzzz is an arbitrary number permitting to order the tests For more details about the applicability conditions listed in this document, please refer to [ICS]. 1-4

25 2 Test Cases 2.1 Common Test Cases C : Protocol Activation - Activate contactless interface To ensure that the reader powers up contactless interface and informs cardholder to start transaction. [MCHIP] [MC v2.1]: [3.3 - Protocol activation] [ ] Amount is such as the Terminal Contactless Transaction Limit Exceeded flag is not set for one AID Application is selected and processed until completion Reader shall inform cardholder to present the card C : Pre-Process - Reader clears Terminal Contactless Transaction Limit exceeded flag To ensure that the reader clears the Terminal Contactless Transaction Limit flag for each AID during Pre-Processing. [MCHIP] [MC v2.1]: [3.2 Pre-Processing] [ ] MasterCard application in LT has highest priority - 1st transaction: run an Unsuccessful transaction where amount is above Terminal Contactless Transaction Limit for all AIDs - 2nd transaction: Set Amount, Authorized less than Terminal Contactless Transaction Limit for at least one AID supported by reader Second transaction shall continue until completion. A-1

26 C : Pre-Process - Reader clears Terminal Contactless Floor Limit exceeded flag To ensure that the reader clears the Terminal Contactless Floor Limit flag for each AID during Pre-Processing. [MCHIP] [MC v2.1]: [3.2 Pre-Processing] [ ] * AIP of LT indicates TRM supported (AIP byte 1 bit 4 = 1). * MasterCard application in LT has highest priority - 1st transaction: run a successful transaction where amount is above Terminal Contactless Floor Limit for all AIDs - 2nd transaction: Amount is less than Terminal Contactless Floor Limit for MasterCard AID * The PayPass reader shall set TVR B4b8=1 for first transaction and TVR B4b8=0 for second transaction * Both transactions continue until completion. C : Pre-Process - Reader clears Terminal CVM Required Limit exceeded flag To ensure that the reader clears the Terminal CVM Required Limit flag for each AID during Pre-Processing. [MCHIP] [MC v2.1]: [3.2 Pre-Processing] [ ] * MasterCard application in LT has highest priority * LT requests Terminal Capabilities (9F33) to be sent in PDOL * AIP of LT indicates CVM supported (AIP byte 1 bit 5 = 1). - 1st transaction: run a successful transaction where amount is above Terminal CVM Required Limit for all AIDs - 2nd transaction: Amount is less than Terminal CVM Required Limit for MasterCard AID - 1st transaction: In GetPO command, Terminal Capabilities (9F33) shall indicate CVM Required as per the ICS - 2nd transaction: In GetPO command, Terminal Capabilities (9F33) shall indicate "no CVM Required" as per the ICS. 2

27 C : Pre-Process - Reader sets Terminal Contactless Transaction Limit exceeded flag To ensure that the reader sets the Terminal Contactless Transaction Limit Exceeded Flag when Amount is greater or equal to Terminal Contactless Transaction Limit. To ensure the reader removes from the candidate list all applications for which the Contactless Transaction Limit Exceeded Flag has been set. [MCHIP] [MC v2.1]: [3.2 Pre-Processing] [ & ] * Terminal Contactless Transaction Limits are as follows: for MasterCard AID for Maestro AID for Test AID * PPSE response returned by LT is such as the AID priorities are 1) MasterCard 2) Maestro 3) Test. Case 01: Amount used for transaction is Case 02: Amount used for transaction is Maestro AID returned by LT is extended. Case 03: Amount used for transaction is Case 04: Amount used for transaction is Case 05: Amount used for transaction is Case 06: Amount used for transaction is Cases 01, 03: Maestro AID is selected in Final select because Terminal Contactless Transaction Limit Exceeded Flag is set for the MasterCard AID Case 02: Maestro extended AID is selected in Final select because Terminal Contactless Transaction Limit Exceeded Flag is set for the MasterCard AID Cases 04, 05, 06: Test AID is selected in Final select because Terminal Contactless Transaction Limit Exceeded Flag is set for the MasterCard and Maestro AIDs. 3

28 C : Pre-Process - Reader sets Terminal Contactless Floor Limit Exceeded flag To ensure that the reader sets the Terminal Contactless Floor Limit Exceeded Flag when Amount is greater than the Terminal Contactless Floor Limit [MCHIP] [MC v2.1]: [3.2 Pre-Processing] [ & ] * Terminal Contactless Floor Limits are as follows: for MasterCard AID for Maestro AID * Terminal contactless transaction limit are set such that AID which has highest priority is selected for transaction. Case 01: MasterCard AID has the highest priority Amount used for transaction is Case 02: MasterCard AID has the highest priority Amount used for transaction is Case 03: Maestro AID has the highest priority Amount used for transaction is 9.01 Case 04: Maestro AID has the highest priority Amount used for transaction is and is extended. * Transaction continues until completion. * The PayPass reader shall set TVR B4b8=1 (Transaction Exceeds Floor Limit) 4

29 C : Pre-Process - Reader sets Terminal CVM Required Limit Exceeded flag To ensure that the reader sets the Terminal CVM Required Limit Exceeded Flag when Amount is greater or equal to the Terminal CVM Required Limit [MCHIP] [MC v2.1]: [3.2 Pre-Processing] [ ] * Terminal CVM Required Limits are as follows: for MasterCard AID for Maestro AID * LT requests Terminal Capabilities (9F33) to be sent in PDOL * LT returns AIP indicating that CVM is requested * LT returns CVM list such as Online PIN if supported, Signature if supported, nocvm always * Terminal contactless transaction limit are set such that AID which has highest priority is selected for transaction. Case 01: MasterCard AID has the highest priority and is extended Amount used for transaction is Case 02: MasterCard AID has the highest priority Amount used for transaction is Case 03: MasterCard AID has the highest priority Amount used for transaction is Case 04: Maestro AID has the highest priority Amount used for transaction is Case 05: Maestro AID has the highest priority Amount used for transaction is Case 06: Maestro AID has the highest priority Amount used for transaction is * Transaction continues until completion. * In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities CVM Required" as per the ICS. * CVM results byte 3 is 00 (unknown) as per

30 C : Pre-Process - Reader does not set Terminal Contactless Transaction Limit To ensure that the reader does not set the Terminal Contactless Transaction Limit Exceeded Flag when Amount is less than Terminal Contactless Transaction Limit. [MCHIP] [MC v2.1]: [3.2 Pre-Processing] [ & ] * Terminal Contactless Transaction Limits are as follows: for MasterCard AID for Maestro AID for Test AID * PPSE response returned by LT is such as the AID priorities are 1) MasterCard 2) Maestro 3) Test. Case 01: Amount used for transaction is Case 02: Amount used for transaction is Case 03: Amount used for transaction is Maestro AID is extended. Case 01 Master Card AID is selected in final select. Case 02 Maestro AID is selected in Final select. Case 03 Maestro extended AID is selected in Final select. 6

31 C : Pre-Process - Reader does not set Terminal Contactless Floor Limit Exceeded To ensure that the reader does not set the Terminal Contactless Floor Limit Exceeded Flag when Amount is less than or equal to Terminal Contactless Floor Limit [MCHIP] [MC v2.1]: [3.2 Pre-Processing] [ & ] * Terminal Contactless Floor Limits are as follows: for MasterCard AID for Maestro AID * Terminal contactless transaction limit are set such that AID which has highest priority is selected for transaction. Case 01: MasterCard AID has the highest priority Amount used for transaction is Case 02: MasterCard AID has the highest priority Amount used for transaction is Case 03: Maestro AID has the highest priority Amount used for transaction is 9.00 Case 04: Maestro AID has the highest priority Amount used for transaction is 8.99 * Transaction continues until completion. * The PayPass reader shall not set the Terminal Contactless Floor Limit Exceeded Flag (TVR B4b8= 0). 7

32 C : Pre-Process - Reader does not set Terminal CVM Required Limit Exceeded To ensure that the reader does not set the Terminal CVM Required Limit Exceeded Flag when Amount is less than the Terminal CVM Required Limit [MCHIP] [MC v2.1]: [3.2 Pre-Processing] [ ] * Terminal CVM Required Limits are as follows: for MasterCard AID for Maestro AID * LT requests Terminal Capabilities (9F33) to be sent in PDOL * LT returns AIP indicating that CVM is requested * LT returns CVM list such as Online PIN if supported, Signature if supported, nocvm always * Terminal contactless transaction limit are set such that AID which has highest priority is selected for transaction. Case 01: MasterCard AID has the highest priority Amount used for transaction is Case 02: Maestro AID has the highest priority Amount used for transaction is Case 03: MasterCard AID has the highest priority and is extended Amount used for transaction is 1.00 * Transaction continues until completion. * In GetPO command, Terminal Capabilities (9F33) shall indicate the "No CVM" required. * CVM results byte 3 is 00 (unknown) as per

33 C : Pre-Process - Contactless transaction limit exceeded for all AIDs To ensure that the reader does not power up the contactless interface and continues with Completion function when terminal contactless transaction limit is exceeded for all AIDs. [MCHIP] and [NOPROPSELECTBEFORE] and [NOPROPSELECTAFTER] [MC v2.1]: [3.3 - Protocol activation] [ ] Amount, Authorized is greater than terminal contactless transaction limit for all AIDs Reader shall not inform the cardholder to present the card. Transaction outcome shall be set to 'End application'. 9

34 C : Pre-Process - Limits have the same value (implicit test) 10 To ensure that the reader correctly behaves when the limits have the same value. [MCHIP] [MC v2.1]: [3.2 Pre-Processing & [ ] & [ ]] * Reader configuration is such as the AID "test" is selected when the Contactless transaction limit is exceeded for Maestro or MasterCard AIDs in the conditions below. * For the AID "Test", the Contactless transaction limit and contactless floor limit and Terminal CVM required limit are set to the maximum value so the amount is always below these values. Case 01: * Contactless transaction limit = contactless floor limit ("Common limit"). * Terminal CVM required limit is lower than the Common limit. * Tests are performed with MasterCard and Maestro and with amount below or above or equal to the common limit. Amount is above the CVM limit. Case 02: * Contactless transaction limit = CVM required limit ("Common limit"). * Terminal contactless floor limit is lower than the Common limit. * Tests are performed with MasterCard and Maestro and with amount below or above or equal to the Common limit. Amount is above the contactless floor limit. Case 03: * Contactless floor limit = CVM required limit ("Common limit"). * Terminal contactless transaction limit is greater than the Common limit. * Tests are performed with MasterCard and Maestro and with amount below or above or equal to the Common limit. Amount is lower than the transaction limit. Case 04: * Contactless floor limit = CVM limit = contactless transaction limit ("Common limit"). * Tests are performed with MasterCard and Maestro and with amount below or above or equal to the common limit. Application in LT is selected and transaction is processed with LT Case 01: Below the "common limit": AID "MasterCard" or "Maestro" is selected. Transaction continues until completion. The PayPass reader shall not set TVR B4b8 (Transaction Floor Limit NOT exceeded). In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities "CVM Required" as per the ICS. At or above the "common limit": AID "Test" is selected. Transaction continues until completion. The PayPass reader shall not set TVR B4b8 (Transaction Floor Limit NOT exceeded). In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities "no CVM Required". Case 02: Below the "common limit": AID "MasterCard" or "Maestro" is selected. Transaction continues until completion. The PayPass reader shall set TVR B4b8 (Transaction Floor Limit exceeded). In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities "no CVM Required". At or above the "common limit": AID "Test" is selected. Transaction continues until completion. The PayPass reader shall not set TVR B4b8 (Transaction Floor Limit NOT exceeded). In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal

35 Capabilities "no CVM Required". Case 03: Below the "common limit": AID "MasterCard" or "Maestro" is selected. Transaction continues until completion. The PayPass reader shall not set TVR B4b8 (Transaction Floor Limit not exceeded). In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities "no CVM Required". At the "common limit": AID "MasterCard" or "Maestro" is selected. Transaction continues until completion. The PayPass reader shall not set TVR B4b8 (Transaction Floor Limit not exceeded). In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities "CVM Required" as per the ICS. Above the "common limit": AID "MasterCard" or "Maestro" is selected. Transaction continues until completion. The PayPass reader shall set TVR B4b8 (Transaction Floor Limit exceeded). In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities "CVM Required" as per the ICS. Case 04: Below the "common limit": AID "MasterCard" or "Maestro" is selected. Transaction continues until completion. The PayPass reader shall not set TVR B4b8 (Transaction Floor Limit not exceeded). In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities "no CVM Required". At or above the "common limit": AID "Test" is selected. Transaction continues until completion. The PayPass reader shall not set TVR B4b8 (Transaction Floor Limit NOT exceeded). In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities "no CVM Required". C : PPSE - First command To ensure the PayPass reader NOT supporting the proprietary selection method does not send any command before PPSE. [NOPROPSELECTBEFORE] [MC v2.1]: [3.4 Application Selection] Application in LT is selected and transaction is processed with LT The LT receives a SELECT command with a data field having the value "2PAY.SYS.DDF01". 11

36 C : PPSE - Syntax of command Message To ensure the PayPass reader assigns the value "2PAY.SYS.DDF01" to the data field of the SELECT PPSE command. [MS v3.3]: [SELECT PPSE] [1.2.1] [MC v2.1]: [2.6 SELECT] [2.6.2 Command Message] LT response to select PPSE is '90 00' with response data. The LT receives a SELECT PPSE command with a data field having the value "2PAY.SYS.DDF01". C : PPSE - Data Field Returned in the Response Message To ensure the PayPass reader is able to recognize the SELECT PPSE returned data field. [MS v3.3]: [SELECT PPSE] [1.2.2] [MC v2.1]: [2.6.3 Data Field Returned in the Response Message] [Table 2.20-Table 2.24] * The PayPass reader and LT have at least one mutually supported application. * The FCI Issuer Discretionary Data object in the FCI of the PPSE contains a single directory record and the contents of this directory record correspond to one of the applications supported by the PayPass reader. Case 01: FCI of PPSE contains all mandatory data fields without optional data. Case 02: FCI of PPSE contains all mandatory data fields with an optional data Application in LT is selected and transaction is performed with LT. The PayPass reader issues a SELECT command with AID identical to the ADF Name in the directory record returned in the FCI of the PPSE. 12

37 C : PPSE - Additional data objects To ensure that the PayPass reader ignores the presence of proprietary data objects returned in the SELECT PPSE response. [MS v3.3]: [1.3 Building the Candidate List] [ ] [MC v2.1]: [3.4.1 Building the Candidate List] [ ] LT contains a PPSE. Case 01: FCI (tag 6F) of PPSE contains additional proprietary data fields. Case 02: FCI Issuer discretionary Data (tag BF0C) of PPSE contains proprietary data field: tag 5F 50 with any length and any value. Case 03: FCI (tag 6F) of PPSE contains Issuer Country Code data object. Case 04: FCI Issuer discretionary Data (tag BF0C) of PPSE contains Issuer Country Code data object. Case 05: FCI Issuer discretionary Data (tag BF0C) of PPSE contains data fields: '5F54' Bank Identifier Code (BIC), '5F53' International Bank Account Number (IBAN), '5F55' Issuer Country Code', '5F56' Issuer Country Code, and '42' Issuer Identifier Number. Case 06: FCI Proprietary Template (tag A5) of PPSE contains additional data fields (88 tag) Case 07: FCI Proprietary Template (tag BF 0C) of PPSE contains proprietary data field: tag 9F 28(Entry point tag). Test to be performed for 4 different values. Case 08: directory entry (tag 61) of PPSE contains additional data field (9F26 tag). Application in LT is selected and transaction is performed with LT *The reader shall ignore the unrecognized or additional EMV data objects. *The reader shall perform the application selection process with PPSE. 13

38 C : PPSE - SW <> 9000 To ensure that if card returns status other than 90 00' in response to the SELECT PPSE command, the PayPass reader must terminate the transaction [NOPROPSELECTAFTER] or [NO MCHIP] [MS v3.3]: [1.3 Building the Candidate List] [ ] [MC v2.1]: [3.4.1 Building the Candidate List] [ & ] LT returns status other than to SELECT PPSE command. Case 01: LT returns status value '63 00' in response to SELECT PPSE Case 02: LT returns status value '63 Cx' in response to SELECT PPSE Case 03: LT returns status value '69 83' in response to SELECT PPSE Case 04: LT returns status value '69 84' in response to SELECT PPSE Case 05: LT returns status value '69 85' in response to SELECT PPSE Case 06: LT returns status value '6A 83' in response to SELECT PPSE Case 07: LT returns status value '6A 88' in response to SELECT PPSE Case 08: LT returns status value '62 83' in response to SELECT PPSE Case 09: LT returns status value '64 00' in response to SELECT PPSE Case 10: LT returns status value '65 00' in response to SELECT PPSE Case 11: LT returns status value '90 01' in response to SELECT PPSE Case 12: LT returns status value '6A 82' in response to SELECT PPSE Case 13: LT returns status value 'AA BB' in response to SELECT PPSE Case 14: LT returns status value '6A 81' in response to SELECT PPSE The following are Refund transactions: Case 15: LT returns status value '6A 82' in response to SELECT PPSE Case 16: LT returns status value '62 83' in response to SELECT PPSE Case 17: LT returns status value '69 83' in response to SELECT PPSE Case 18: LT returns status value '6A 81' in response to SELECT PPSE Application in LT is selected and transaction is processed with LT * The PayPass reader shall terminate the transaction * Transaction outcome shall be set to "End application" 14

39 C : PPSE - Mandatory data missing in response To ensure that the reader correctly behaves when any mandatory data from tables 2.20 or 2.21 is missing in the PPSE response. [NOPROPSELECTAFTER] or [NO MCHIP] [MS v3.3]: [1.3 Building the Candidate List] [ ] [MC v2.1]: [3.4.1 Building the Candidate List] [ ] Perform several tests: Case 01: SELECT PPSE response does not contain FCI Template tag Case 02: SELECT PPSE response does not contain DF Name tag Case 03: SELECT PPSE response does not contain FCI Proprietary Template tag Case 04: SELECT PPSE response does not contain FCI Issuer Discretionary Data tag Case 05: PPSE returns only one application. 61 tag is missing but all other data elements (from table 2.22) are present. Transaction shall be terminated. If Reader supports M/Chip, Transaction outcome shall be set to "End application". C : PPSE - Incorrectly formatted FCI To ensure that if the FCI of PPSE is incorrectly formatted, the PayPass reader terminates the transaction [NOPROPSELECTAFTER] or [NO MCHIP] [MS v3.3]: [1.3 Building the Candidate List] [ ] [MC v2.1]: [4.2 Exception Processing] [ ] LT contains PPSE. Case 01: FCI template of LT returned in response to SELECT PPSE with bad tag '6A' Case 02: FCI template '6F' of LT returned in response to SELECT PPSE has a bad length and value field has the correct length Case 03: FCI of LT returned in response to SELECT PPSE contains DF Name with bad tag '85' Case 04: FCI of LT returned in response to SELECT PPSE contains DF Name with bad length and value field has the correct length Case 05: FCI of LT returned in response to SELECT PPSE contains SFI Dir File Data Object with value field longer (+1) than specified in the length field If device under test is M/Chip then transaction outcome shall be set to End application else transaction shall be terminated. 15

40 C : Building candidate list - Matching ADF name To ensure the PayPass reader adds to the candidate list all applications supported by the PayPass reader that exactly match an ADF Name in an FCI Issuer Discretionary Data directory entry. [MS v3.3]: [1.3 Building the Candidate List] [ ] [MC v2.1]: [3.4.1 Building the Candidate List] [ ] LT returns several ADF names. At least one ADF name matches one of the AIDs in the PayPass reader PayPass reader shall issue SELECT command with AID same as the ADF of the card which has highest priority C : Building candidate list - ADF Name entries longer To ensure the PayPass reader adds all applications to the candidate list, when ADF Name in an FCI Issuer Discretionary Data directory entry, identical up to and longer than an AID in the PayPass reader. [MS v3.3]: [1.3 Building the Candidate List] [ ] [MC v2.1]: [3.4.1 Building the Candidate List] [ ] Case 01: LT returns two Maestro AIDs (with different extension) in such a way it is identical up to and longer than PayPass reader AID. Case 02: LT returns two MasterCard AIDs (with different extension) in such a way it is identical up to and longer than PayPass reader AID. Case 03: LT returns two Test AIDs (with different extension) in such a way it is identical up to and longer than PayPass reader AID. The PayPass reader issues a SELECT command with highest priority AID 16

41 C : Building candidate list - Ordering of the final candidate list To ensure that, after building the candidate list using application selection with PPSE, the PayPass reader orders the final candidate list with the highest priority application listed first. [MULTIAPPLI] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.2 Final Selection] [ ] * LT and PayPass reader have several mutually supported applications (at least 3). * In the directory entries returned in the FCI of the PPSE, bit b8 of the Application Priority Indicator for all applications is set to 0b. * Applications have different priorities. The PayPass reader shall generate a SELECT command with data field containing the AID of the application having the highest priority. C : Building candidate list - API b8 = 1 To ensure that, after building the candidate list using application selection with PPSE, the PayPass reader removes from the candidate list those applications for which bit b8 = 1b in the Application Priority Indicator. [MULTIAPPLI] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.1 Building the Candidate List] [ ] * LT and PayPass reader have several mutually supported applications (at least 3). * In the directory entries returned in the FCI of the PPSE, bit b8 of the Application Priority Indicator for one of the applications is set to 0b and for all other applications is set to 1b. The PayPass reader shall generate a SELECT command with data field containing the AID of the application for which the directory entry had bit b8 of the Application Priority Indicator set to 0b. 17

42 C : Building candidate list - No priority (API set to 0) To ensure that, after building the candidate list using application selection with PPSE, when some of the applications have a Priority Indicator set to 0000b and others different from 0000b set to 1b and in the order encountered in the card. [MULTIAPPLI] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.1 Building the Candidate List] [ ] * LT and PayPass reader have several mutually supported applications (at least 3). * In the directory entries returned in the FCI of the PPSE, two applications have a Priority Indicator set to 0000b, and one application has a Priority Indicator different from 0000b. For all applications, Application Priority Indicator b8 is "0". * LT responds with "6A82" to each Select AID command The PayPass reader shall generate 3 SELECT commands in the order specified below: 1) Data field containing the AID of the application having priority indicator different from 0000b. 2 ) Data field containing the AID of the application having priority indicator set to 0000b - first AID encountered in the card 3 ) Data field containing the AID of the application having priority indicator set to 0000b - second AID encountered in the card 18

43 C : Building candidate list - Duplicate priorities To ensure that the PayPass reader orders the application having the same priority in the order in which they were listed in the PPSE. [MULTIAPPLI] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.1 Building the Candidate List] [ ] * LT and PayPass reader have several mutually supported applications (at least 6). Some of them have an extended AID. * In the directory entries returned in the FCI of the PPSE, bit b8 of the Application Priority Indicator is set to 0b. * At least 2 applications (A1 & A2) have the same priority 1. * At least 2 applications (B1 & B2) have the priority 2. * At least 2 applications (C1 & C2) have the priority 0. * LT returns C1 then A1 then B1 then A2 then C2 then B2. * LT returns 6A82 to all the Final Select commands The PayPass reader shall generate a Final SELECT command for all the AIDs present in the candidate list, in this order: A1, A2, B1, B2, C1 and C2. C : Building candidate list - No priority To ensure that when no priority sequence is specified in the card the PayPass reader orders the final candidate list in the order the applications were encountered on the card. [MULTIAPPLI] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.1 Building the Candidate List] [ ] * LT and PayPass reader have several mutually supported applications (at least 3). * In the directory entries returned in the FCI of the PPSE, bit b8 of the Application Priority Indicator for all other applications is set to 0b. * Applications have no assigned priorities, i.e. API value is 00 The PayPass reader shall generate a SELECT command with data field containing the AID of the first application encountered on the card. 19

44 C : Building candidate list - Next Highest priority To ensure that if the selected application returned status different from 90 00, the PayPass reader selects the application with second priority from the list of application mutually supported by card and PayPass reader and not requiring cardholder confirmation. [MULTIAPPLI] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.2 Final Selection] [ ] * LT and PayPass reader have three mutually supported applications * LT applications have an Application Priority Indicator different from 00 * Application with highest priority in the list of mutually supported applications requires Cardholder confirmation * LT returns status different from 9000 to the SELECT command sent to select Application with second highest priority in the list of mutually supported applications * The PayPass reader shall send a FINAL SELECT command for the application with second highest priority in the list of mutually supported application * Since LT returns status words different from 9000 to the first FINAL SELECT, the reader shall send another FINAL SELECT command for the application with third highest priority in the list of mutually supported application * The PayPass reader shall process the transaction until completion. 20

45 C : Building candidate list - Candidate list for final application selection is empty To ensure that the reader initializes an empty candidate list. To ensure that, after SELECT PPSE method, if no directory entries that match applications supported by the PayPass reader are found, the PayPass reader must terminate the transaction [NOPROPSELECTAFTER] or [NO MCHIP] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4 Application Selection] [ , ] No directory entry in the FCI Issuer Discretionary Data in the FCI of the PPSE matches applications supported by the PayPass reader during SELECT PPSE processing. Case 01:ADF Name are shorter than AID supported by the PayPass reader but identical up to and including the last character Case 02:ADF Name are the same length as that of the AID supported by the PayPass reader but different in value If device under test is M/Chip then transaction outcome shall be set to End application else transaction shall be terminated. C : Building candidate list - Candidate list is empty - API bit 8 =1 To ensure that, when all mutually supported applications prohibit selection without cardholder assistance ("bit 8=1" Application Priority Indicator), then the PayPass reader terminates the transaction since the final candidate list is empty. [NOPROPSELECTAFTER] or [NO MCHIP] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4 Application Selection] [ , ] Case 01: LT and PayPass reader have several (at least 3) mutually supported applications. In the directory entries returned in the FCI of the PPSE, bit b8 of the Application Priority Indicator for all of the applications is set to 1b. Case 02: LT and PayPass reader have only one mutually supported application. b8 of Application Indicator returned by LT equals 1. The PayPass reader terminates the transaction. 21

46 C : FINALSELECT - Data Field in the response message To ensure that the PayPass reader recognizes the data object returned in the data field of the Final SELECT ADF response message. [MS v3.3]: [1.2.2 Data Field Returned in the Response Message] [MC v2.1]: [4.3.1 FCI and SW1-SW2 Processing] [ ] [EMV 4.2b]: [2CA ] * LT contains an ADF * FCI of ADF contains all mandatory fields: FCI template ( 6F ), DF Name ( 84 ), FCI Proprietary Template ( A5 ) * FCI of ADF contains all optional data objects: Application Priority Indicator ( 87 ), PDOL ( 9F38 ), Language Preference ( 5F 2D ), Issuer Code Table Index ( 9F 11 ), Application Preferred Name ( 9F 12 ), Application Label ( 50 ) and FCI issuer Discretionary Data ( BF 0C ) containing: '9F6E' PayPass Third Party Data, 9F 4D '5F54' Bank Identifier Code (BIC), '5F53' International Bank Account Number (IBAN), '5F55' Issuer Country Code (alpha 2), '5F56' Issuer Country Code (alpha 3), and '42' Issuer Identifier Number. Application in LT is selected and transaction is performed with LT. The PayPass reader shall send a GetPO command with command data consistent with any PDOL present in FCI of ADF. C : FINALSELECT - Format 'ans' (App. Label and App. preferred Name) To ensure that the PayPass reader supports the 'ans' format of the Application Label and Application preferred Name. [MS v3.3]: [Inherits from EMV] [MC v2.1]: [ Inherits from EMV] [EMV 4.2b]: [2CL ] LT contains an ADF Case 01: FCI of ADF contains Application Label and Application preferred Name with ans format and a 'space' character Case 02: FCI of ADF contains Application Label and Application preferred Name with ans format and a '&' character Application in LT is selected and transaction is performed with LT. The PayPass reader shall accept the card. 22

47 C : FINALSELECT - Language Supported by PayPass reader To ensure that the PayPass reader has parameters initialized so that it can identify what language(s) are supported to process the card's Language Preference [LANGUAGE_SELECTION] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [4.3 Functions Used in Transaction Processing] [ ] Case 01: LT language preference (coded in lower case) matches one language supported by the PayPass reader Case 02: LT language preference (coded in lower case) matches all languages supported by the PayPass reader (if supporting multiple languages) Case 03: LT language preference (coded in lower case) matches one language supported by the PayPass reader, additionally the LT contains another language preference (coded in lower case) not supported by the PayPass reader Case 04: LT language preference (coded in upper case) matches one language supported by the PayPass reader Case 05: LT language preference (coded in upper case) matches all languages supported by the PayPass reader (if supporting multiple languages) Case 06: LT language preference (coded in upper case) matches one language supported by the PayPass reader, additionally the LT contains another language preference (coded in upper case) not supported by the PayPass reader * The PayPass reader shall process the transaction until completion. * The languages supported by the PayPass reader shall be used if matched by LT in Language Preference 23

48 C : FINALSELECT - PayPass reader uses language With Highest Preference To ensure that the PayPass reader compares the card's Language Preference with the languages supported in the PayPass reader at the beginning of the transaction and uses the language with the highest preference in the messages displayed to the cardholder if a match is found. [LANGUAGE_SELECTION] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [4.3 Functions Used in Transaction Processing] [ ] * The PayPass reader shall process the transaction until completion. * The messages for the cardholder shall be displayed in the Language with highest priority supported by both LT and PayPass reader C : FINALSELECT - Store data for later use To ensure that, when selecting the MasterCard proximity payment application, if any of the data objects DF name, Application Label, Language Preference, Issuer Code Table Index, Application Preferred Name or PayPass Third Party Data are present in the FCI then the PayPass reader extracts them from FCI and store them for later use during the transaction processing. [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [4.3.1 FCI and SW1-SW2 Processing] [ ] * The FCI Proprietary Template of the SELECT ADF response message includes the optional data objects Application Label, Language Preference, Application Preferred Name, PayPass Third Party Data and Issuer Code Table Index data objects. (Can be performed in several tests) * Test must be performed for both PayPass Mag Stripe and PayPass M/Chip. * CDOL1 requests Language Preference (PayPass M/Chip) * UDOL requests Language Preference (PayPass MagStripe) * The PayPass reader shall process the transaction until completion. * GenerateAC (PayPass M/Chip) or CCC (PayPass MagStripe) command sends the correct value for Language Preference * DFname, Application label, Application Preferred Name, PayPass Third Party Data and Issuer Code Table Index data objects sent in data record shall be same as returned by Card. 24

49 C : FINALSELECT - Additional Data objects returned in the Response Message To ensure that the PayPass reader ignores any additional tags returned in the FCI of the selected ADF that is not described in the specifications. [MS v3.3]: [1.2.2 Data Field Returned in the Response Message] [MC v2.1]: [4.3.1 FCI and SW1-SW2 Processing] [ ] [EMV 4.2b]: [2CA ] LT and PayPass reader have at least one mutually supported application. Case 01: FCI (tag 6F) of ADF contains additional proprietary data fields within the FCI template Case 02: FCI Issuer discretionary Data (tag BF0C) of ADF contains proprietary data field: tag '9F 7E' with max length and any value Case 03: In the Select ADF response, LT returns the Issuer Country Code data object ( 5F55 ) under the FCI (tag 6F ) instead of the FCI proprietary template (tag A5 ) Case 04: FCI Issuer discretionary Data (tag BF0C) of ADF contains Issuer Country Code data object ( 5F55 ). Application in LT is selected and transaction is performed with LT. * The reader shall ignore the unrecognized or additional EMV data objects * The reader shall accept the card and process the transaction until completion C : FINALSELECT - No optional data To ensure that the PayPass reader accepts the absence of optional data in the FCI of the selected ADF. [MS v3.3]: [5.4 Data Object Dictionary] [ ] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CA ] * LT and PayPass reader have at least one mutually supported application. * FCI of ADF contains all mandatory but no optional data fields: FCI template ( 6F ), DF Name ( 84 ), FCI Proprietary Template ( A5 with a length of 00 ) (Application Label is an optional data) Application in LT is selected and transaction is performed with LT. The PayPass reader shall send a GetPO command with data field consistent with no PDOL supplied by the card. 25

50 C : FINALSELECT - SW <> 9000 and only one mutual application To ensure that, if the PayPass reader receives a response status other than '9000' in response to the SELECT command, then it terminates the transaction when the candidate list contains only one mutually supported application. [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.2 Final Selection] [ ] * LT and PayPass reader has only one mutually supported application * In the FCI Proprietary Template in the applications' FCI, bit b8 of the Application Priority Indicator is set to 0b. Perform test for cases where LT returns the following status bytes after final selection: Case 01: '6283'. Case 02: '6700'. Case 03: '6A81'. Case 04: '6A82'. Case 05: '6A86'. Case 06: '6E00'. Case 07: '6D00'. Case 08: '6F00' PayPass reader shall terminate the transaction 26

51 C : FINALSELECT - SW <> 9000 and only 3 mutual application To ensure that if the card returns a status different from '90 00' to the SELECT command of chosen application, the PayPass reader removes the application from the list of mutually supported applications and switches back to the final application selection process. [MULTIAPPLI] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.2 Final Selection] [ ] * There are three matching AIDs between LT and reader. * Applications have different priorities. * LT returns status different from '90 00' after final selection. Case 01: LT returns status value of '62 83' in response to SELECT on final selection. Case 02: LT returns status value of '63 00' in response to SELECT on final selection. Case 03: LT returns status value of '63 Cx' in response to SELECT on final selection. Case 04: LT returns status value of '69 83' in response to SELECT on final selection. Case 05: LT returns status value of '69 84' in response to SELECT on final selection. Case 06: LT returns status value of '69 85' in response to SELECT on final selection. Case 07: LT returns status value of '6A 81' in response to SELECT on final selection. Case 08: LT returns status value of '6A 82' in response to SELECT on final selection. Case 09: LT returns status value of '6A 83' in response to SELECT on final selection. Case 10: LT returns status value of '6A 88' in response to SELECT on final selection. Case 11: LT returns status value of '90 01' in response to SELECT on final selection. Case 12: LT returns status value of '64 00' in response to SELECT on final selection. Case 13: LT returns status value of '65 00' in response to SELECT on final selection. The following are Refund transactions: Case 14: LT returns status value of '62 83' in response to SELECT on final selection. Case 15: LT returns status value of '69 84' in response to SELECT on final selection. Case 16: LT returns status value of '6A 82' in response to SELECT on final selection. Case 17: LT returns status value of '65 00' in response to SELECT on final selection. Application Selection using PPSE. * PayPass reader shall remove the application from the candidate list and shall switch back to the final selection process after the card answered to final SELECT with status different from '90 00'. * The candidate list generated during the second selection process shall no longer contain the application used during the above final SELECT. 27

52 C : FINALSELECT - Accept format errors for Selection data objects The PayPass reader accepts application selection data objects from the ICC with format errors, when processing FINAL SELECT. [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CE ] * LT shall contain the following data objects with the specified value, resulting in a format error: * FCI of an ADF of FINAL SELECT contains Application Label = F 7F 7F. * FCI of an ADF of FINAL SELECT contains Language Preference = '23 33'. * FCI of an ADF of FINAL SELECT contains Issuer Code Table Index = F1. * FCI of an ADF of FINAL SELECT contains Application Preferred Name = F 7F 7F. Application in LT is selected with PPSE and transaction is processed with LT. The PayPass reader shall process the transaction until completion. 28

53 C : FINALSELECT - Verification of DF Name fails To ensure that, if the DF Name returned in the FCI in the data field of the SELECT response message is not the same as the AID specified in the data field of the SELECT command message, then the PayPass reader shall remove the application from the candidate list. Candidate list is built via PPSE - case of multi-application PayPass reader. [MULTIAPPLI] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.2 Final Selection] [ ] * Candidate list is built via PPSE: PPSE card response includes several applications and SW=9000. * The DF Name returned in the FCI Template data object of the SELECT ADF response message is not the same as the AID specified in the data field of the SELECT ADF command message. Perform tests for cases where: Case 01: PayPass reader AID and DF Name are the same length and different. Case 02: PayPass reader AID is shorter than DF Name but they are identical up to and including the last character of the PayPass reader AID. Case 03: PayPass reader AID is longer than DF Name but they are identical up to and including the last character of the DF Name. Application selection process is performed by the LT. The PayPass reader shall remove the application from the candidate list and send a SELECT command for the next supported application. 29

54 C : GetPO - No PDOL To ensure that, when the PDOL is not provided by the card, the PayPass reader constructs the data field of the GetPO command message as a template introduced by the tag '83' with a length field set to zero. [MS v3.3]: [3.4.1 GetPO] [ ] [MC v2.1]: [4.3.2 GetPO] [ & ] PDOL is not returned in the FCI of the selected ADF. The PayPass reader issues a GetPO command with a data field consisting of a template introduced by the tag '83' with no value field and with length field having the value zero. 30

55 C : GetPO - Amount and Transaction Details present before application activation To ensure that PayPass reader provides Amount and Transaction details before application activation. [MCHIP] [MC v2.1]: [5.4 Data Object Management] [ ] * Transaction is initiated in such a way that all data elements below are different from zero: - Amount Authorized (Binary) - Amount Authorized (Numeric) - Amount other (Binary) - Amount Other (Numeric) - Transaction Category Code - Transaction Currency Code - Transaction Currency Exponent - Transaction Date - Transaction Time - Transaction Type * PDOL requests all data objects listed above. Case 01: Transaction performed with MasterCard AID Case 02: Transaction performed with Maestro AID * PayPass Reader shall provide valid data in PDOL Response at GetPO In PayPass, the only valid values for Transaction Type are: 00 (Purchase of goods or services). '20' (Refund) 31

56 C : GetPO - Syntax of response message: Format 1 To ensure that the PayPass reader is able to recognize the data field returned by GetPO command, encoded according to format 1. [MS v3.3]: [2.3.3 Data Field Returned in the Response Message] [MC v2.1]: [2.4.3 Data Field Returned in the Response Message] [EMV 4.2b]: [2CA ] * CDOL/ UDOL requests AIP Case 01: Response to GetPO contains valid AIP and AFL encoded with format 1 (Template 80) Case 02: Response to GetPO contains valid AIP and AFL encoded with format 1 (Template 80), Tag 80 length is coded on 2 bytes (81 xx) Case 03: Response to GetPO contains valid AIP and AFL encoded with format 1 (Template 80), Tag 80 length is coded on 2 bytes (81 xx). AFL as a length such that total length is greater than 128 bytes. Application in LT is selected and transaction is performed with LT. * The PayPass reader shall accept the card and process the transaction until completion. * Value of AIP in GenerateAC/CCC command shall be in accordance with the value sent back by the LT. * LT shall receive READ RECORD commands in accordance to AFL 32

57 C : GetPO - Syntax of response message: Format 2 To ensure that the PayPass reader is able to recognize the data field returned by GetPO command, encoded according to format 2. [MS v3.3]: [2.3.3 Data Field Returned in the Response Message] [MC v2.1]: [2.4.3 Data Field Returned in the Response Message] [EMV 4.2b]: [2CA ] * CDOL/UDOL requests AIP Case 01: Response to GetPO contains valid AIP and AFL encoded with format 2 (Template 77) Case 02: Response to GetPO contains valid AIP and AFL encoded with format 2 (Template 77). Tag 77 length is coded on 2 bytes (81 xx) where xx is less than 128. Case 03: Response to GetPO contains valid AIP and AFL encoded with format 2 (Template 77). Tag 77 length is coded on 2 bytes (81 xx) where xx is greater than 128. Case 04: Response to GetPO contains valid AIP, AFL and reserved EMV data (tag '9F30', with a length of 10 bytes) encoded with format 2 (Template '77'). Case 05: Response to GetPO contains valid AIP, AFL and reserved EMV data (tag '9F24', with a length of 50 bytes) encoded with format 2 (Template 77). Tag '77' length is coded on 2 bytes (81 xx). Case 06: Response to GetPO contains valid AIP, AFL and reserved EMV data (tag '9F28', with a length of 150 bytes) encoded with format 2 (Template '77'). Tag '77' length is coded on 2 bytes (81 xx). Application in LT is selected and transaction is performed with LT. * The PayPass reader shall accept the card and process the transaction until completion. * Value of AIP in GenerateAC/CCC command shall be in accordance with the value sent back by the LT. * LT shall receive READ RECORD commands in accordance to AF 33

58 C : GetPO - Ignore additional data objects To ensure that the PayPass reader ignores all data objects other than the AIP and AFL in the value field of the Response Message Template data object in the data field of the GetPO response message. [MS v3.3]: [2.3.3 Data Field Returned in the Response Message] [MC v2.1]: [4.3.2 GetPO] [ ] GetPO response message contains additional data objects other than AIP and AFL. Response is in format 2. Case 01: Additional data objects in case of Mag Stripe Purchase transaction. Case 02: Additional data objects in case of M/Chip Purchase transaction. Case 03: Additional data objects in case of Mag Stripe Refund transaction. Case 04: Additional data objects in case of M/Chip Refund transaction. Application in LT is selected and transaction is performed with LT. The PayPass reader shall accept the card and process the transaction until the end. C : GetPO - Reader ignores 4th byte of AFL To ensure the reader ignores the fourth byte of each entry in the record in case of Mag Stripe transaction. [MCHIP] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] Case 01: AFL has the value Case 02: AFL has the value , The PayPass reader shall process the transaction until completion. 34

59 C : GetPO - PDOL tag is not a reader resident data object To ensure that if the tag of any data object identified in the PDOL does not belong to a PayPass reader resident data object then the PayPass reader shall provide a data element with the length specified and a value of all hexadecimal zeros. [MS v3.3]: [3.4.1 GetPO] [ ] [MC v2.1]: [4.3.2 GetPO] [ ] PDOL requests a Data Element which has the ICC as source. LT has provided this Data Element previously. Application selection process is performed by the LT. * The PayPass reader shall provide a data element with the length specified and a value of hexadecimal zeros. * The PayPass reader shall use the concatenated list as value field of the data object with tag '83'. 35

60 C : GetPO - SW <> 9000 & 6985 To ensure that the PayPass reader terminates transaction if status in response to GetPO command is different from '90 00' and '69 85' [MS v3.3]: [3.3 Exception Processing] [3.3.2 Status Bytes] [MC v2.1]: [4.2 Exception Processing] [4.2.3 Status Bytes] * Case 01: LT returns status value '67 00' in response to GetPO * Case 02: LT returns status value '6A 86' in response to GetPO * Case 03: LT returns status value '6E 00' in response to GetPO * Case 04: LT returns status value '6D 00' in response to GetPO * Case 05: LT returns status value '6F 00' in response to GetPO * Case 06: LT returns status value '62 83' in response to GetPO * Case 07: LT returns status value '63 00' in response to GetPO * Case 08: LT returns status value '63 Cx' in response to GetPO * Case 09: LT returns status value '69 83' in response to GetPO * Case 10: LT returns status value '69 84' in response to GetPO * Case 11: LT returns status value '90 01' in response to GetPO * Case 12: LT returns status value '6A 81' in response to GetPO * Case 13: LT returns status value '6A 82' in response to GetPO * Case 14: LT returns status value '6A 83' in response to GetPO * Case 15: LT returns status value '6A 88' in response to GetPO * Case 16: LT returns status value '65 00' in response to GetPO * Case 17: LT returns status value '64 00' in response to GetPO * Case 18: LT returns status value 'EF EF' in response to GetPO The following are Refund transactions: * Case 19: LT returns status value '62 83' in response to GetPO * Case 20: LT returns status value '63 00' in response to GetPO * Case 21: LT returns status value '6A 81' in response to GetPO * Case 22: LT returns status value '6A 82' in response to GetPO Application in LT is selected and transaction is started with LT. If device under test is M/Chip then transaction outcome shall be set to End application else transaction shall be terminated. 36

61 C : GetPO - SW = M/Chip To ensure that the PayPass M/Chip reader accepts a failed status '6985' in response to GetPO command, and understands it as failed processing and switches back to the application selection phase [MCHIP] and [MULTIAPPLI] [MC v2.1]: [4.3.2 GetPO] [ ] * LT have three mutually supported applications Tests shall be performed for Purchase and Refund * LT Applications have: Application 1 has the Application Priority Indicator b8 set to 1, Application 2 has the Application Priority Indicator b8 set to 0 and Application 3 has the Application Priority Indicator b8 set to 0 * Application 2 of LT has a priority value greater than Application 3 * LT returns status '6985' in response to GetPO of the application 2 * Application Selection is performed and transaction is processed with LT. * The PayPass reader returns to the final selection process after the GetPO '69 85' response * The PayPass reader shall process the transaction with Application 3. 37

62 C : GetPO - SW = M/Chip - Combined test To ensure that if the card returns a status '69 85' to the GETPO command, the PayPass reader removes the application from the list of mutually supported applications and switches back to the final application selection process. [MCHIP] and [MULTIAPPLI] [MC v2.1]: [4.3.2 GetPO] [ ] * Reader supports MasterCard and Maestro and Test AIDs. * Amount is smaller than the Contactless limit of MasterCard and Maestro AIDs. * Amount is greater than the Contactless limit of Test AID. * Amount is greater than MasterCard CVM limit. * Amount is smaller than Maestro CVM limit. * Amount is smaller than MasterCard floor limit. * Amount is greater than Maestro floor limit. * Application and related priorities returned by LT are: 1) Maestro with extended AID 2) Test 3) MasterCard with extended AID 4) Maestro * LT returns PDOL including the Terminal Capabilities tag Case 01: LT returns '69 85' in response to the first GetPO. Case 02: LT returns '69 85' in response to the first and second GetPO. Application Selection using PPSE * PayPass reader shall send a FINAL SELECT for the Maestro extended AID. * The terminal capabilities sent in GetPO must be instantiated with the terminal capabilities - no CVM required * PayPass reader shall remove the Maestro extended AID application from the candidate list upon reception of the 6985 status words and shall then switch back to the final selection process. * PayPass reader shall then send a FINAL SELECT for the MasterCard with extended AID. * The terminal capabilities sent in GetPO must be instantiated with the terminal capabilities - CVM required Case 01: The transaction goes until completion. TVR shall indicate "amount NOT over floor limit". Case 02: PayPass reader shall remove the MasterCard with extended AID application from the candidate list upon reception of the status words and shall then switch back to the final selection process. * PayPass reader shall then send a FINAL SELECT for the Maestro AID. * The terminal capabilities sent in GetPO must be instantiated with the terminal capabilities - no CVM required * The transaction goes until completion. The TVR shall indicate "amount over floor limit". 38

63 C : GetPO - SW = Mag Stripe To ensure that the PayPass reader terminates the transaction when LT returns SW '6985' to GetPO command. [NO MCHIP] and [MULTIAPPLI] [MS v3.3]: [3.3 Exception Processing] [3.3.2 Status Bytes] [MC v2.1]: [N/A] * LT and PayPass reader have three mutually supported applications * The AIP has bit b8 in byte 2 set to 0b ("Mag Stripe profile supported"). * LT Applications have: Application 1 has the Application Priority Indicator b8 set to 1, Application 2 has the Application Priority Indicator b8 set to 0 and Application 3 has the Application Priority Indicator b8 set to 0 * Application 2 of LT has a priority value greater than Application 3 * LT returns status '6985' in response to GetPO of the application 2 Application Selection is performed and a transaction is processed with LT. The PayPass reader shall terminate the transaction C : GetPO - Mandatory data objects missing in format 1 & format 2: AIP To ensure that the PayPass reader terminates the transaction if mandatory AIP is missing in a response to GetPO command [MS v3.3]: [3.4.1 GetPO] [ ] [MC v2.1]: [4.3.2 GetPO] [ ] [EMV 4.2b]: [2CL ] Length of AFL is 4 bytes. Case 01: LT response to GetPO is in format 1 and the AIP value is missing. Case 02: LT response to GetPO is in format 2, and the AIP value is missing from the TLV data object.(82 00) Case 03: LT response to GetPO is in format 2, the AIP TLV data object is missing in its entirety Transaction outcome shall be set to "End application" 39

64 C : GetPO - Mandatory data objects missing in format 1 & format 2: AFL To ensure that PayPass reader terminates the transaction if mandatory AFL is missing in a response to GetPO command [MS v3.3]: [3.4.1 GetPO] [ ] [MC v2.1]: [4.3.2 GetPO] [ ] The AIP has bit b8 in byte 2 set to 0b (""M/Chip profile not supported""). Case 01: LT response to GetPO is in format 1, and the AFL value is missing. Case 02: LT response to GetPO is in format 2, and the AFL value is missing from the TLV data object. (94 00) Case 03: LT response to GetPO is in format 2, the AFL TLV data object is missing in its entirety. * PayPass reader shall terminate the transaction * Transaction outcome shall be set to "End application" 40

65 C : GetPO - Verification of response message fails To ensure that if the response message of the GetPO command is not correctly formatted then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.1 GetPO] [ ] [MC v2.1]: [4.3.2 GetPO] [ ] Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. Case 01: GETPO response template '77' of LT has a bad tag '70' Case 02: GETPO response template '77' of LT has a bad length and value field has the correct length Case 03: GETPO response template '80' of LT has a bad tag '70' Case 04: GETPO response template '80' of LT has a bad length and value field has the correct length Case 05: GETPO response template '77' of LT contains AFL with bad Tag '74' Case 06: GETPO response template '77' of LT contains AIP with bad length field '03' and correct length in the value field Case 07: GETPO response template '77' of LT do not contains AIP Transaction outcome shall be set to "End Application" C : GetPO - AFL with an incorrect SFI To ensure that the PayPass reader terminates the transaction if an SFI in the AFL has a value of 0 or 31 [MS v3.3]: [3.4.1 GetPO] [ ] [MC v2.1]: [4.3.2 GetPO] [ ] Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. Case 01: SFI in AFL is 0 Case 02: SFI in AFL is 31 If device under test is M/Chip then transaction outcome shall be set to End application else transaction shall be terminated. 41

66 C : GetPO - AFL with an incorrect starting record number To ensure that if, in the course of normal processing, the PayPass reader recognizes that data returned by the card is incorrectly formatted, then the PayPass reader terminates processing when the AFL has an invalid syntax - Case of PayPass M/Chip PayPass reader [MS v3.3]: [3.4.1 GetPO] [ ] [MC v2.1]: [4.3.2 GetPO] [ ] AFL is starting record of 0 Application in LT is selected and transaction is performed with LT. Transaction outcome shall be set to "End application" C : GetPO - AFL with an incorrect ending record number To ensure that the PayPass reader terminates the transaction if a start record number in AFL has a value greater than the ending record [MS v3.3]: [3.4.1 GetPO] [ ] [MC v2.1]: [4.3.2 GetPO] [ ] * Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. * Start record number in AFL has a value greater than ending record Transaction outcome shall be set to "End application" 42

67 C : ReadRecord - Each entry in the AFL (Combined test) To ensure that the PayPass reader is able to interpret the AFL and send READ RECORD commands for each record between the starting record number and the ending record number, inclusively. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data, Read M/Chip Application Data] [ , ] * AFL is not a pre-defined AFL. * Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. Case 01: AFL with a length of 128 bytes. Case 02: GetPO response from LT is in format 1 and contains an AFL with 62 entries (length of 248 bytes). The LT shall receive a sequence of READ RECORD commands according to the AFL. 43

68 C : ReadRecord - Each entry in the AFL (Not pre-defined AFL) To ensure that the PayPass reader is able to interpret the non-pre-defined AFL and send READ RECORD commands for each record between the starting record number and the ending record number, inclusively. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data, Read M/Chip Application Data] [ , ] * AFL is not a pre-defined AFL. * Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. Case 01: The AFL refers to file 1 - records 1 to 5. Case 02: The AFL refers to file 1 - records 1 to 5, file 2 - records 2 to 3, and file 3 - records 3 to 3. Case 03: The AFL refers to file 1 - records 3 to 3, file 2 - records 2 to 2, and file 5 - records 3 to 3. Perform this one for Purchase and Refund transactions. Case 04: The AFL refers to file 2 - records 3 to 5, file 2 - records 6 to 6, and file 2 - records 1 to 2. Case 05: The AFL refers to file 3 - records 1 to 2, file 2 - records 2 to 3, and file 1 - records 3 to 3. Perform this one for Purchase and Refund transactions. Case 06: The AFL refers to file 3 - records 1 to 1. The LT shall receive a sequence of READ RECORD commands according to the AFL. 44

69 C : ReadRecord - Record Data Format To ensure that the PayPass reader is able to extract data read in record from template 70. [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CI ] * Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. * Tests shall be performed with pre-defined and non-pre-defined AFL. * Mandatory Data Elements (PAN, Expiration Date, CDOL1, SDA Tag list for M/Chip, Track 2 data, PUNATC track2, PCVC3 track2, and NATC track2 for Mag Stripe) are located in a record within template 0x70. The PayPass reader shall process the transaction until completion. C : ReadRecord - Mapping of data objects into records To ensure that the PayPass reader accepts any mapping of data object into records. [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CA ] * Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. * Tests shall be performed with pre-defined and non-pre-defined AFL. * Whenever it is possible, data objects of LT are mapped into different records organization (and AFL is in accordance) (for instance Track 2 Equivalent Data can be located in file with any SFI value) * Data objects of LT are ordered differently within records (for instance mandatory data object Expiration Date, PAN, CDOL1 (in case of M/Chip) and UDOL (in case of Mag Stripe) can be ordered differently) Read Application Data phase is performed with the LT for all conditions above * The PayPass reader shall perform Read Application Data phase correctly and process the transaction until completion. * Data objects shall be stored with the good value in the PayPass reader (whenever it is possible to have access to their value) 45

70 C : ReadRecord - Store data elements To ensure that the PayPass reader stores all data elements read during the Read Application Data phase. [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CJ ] * Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. * CDOL1/UDOL requests all data elements read in file referenced in AFL, Except CDOL1/UDOL. * CDOL1 requests Signed Static Application Data, tag '93' (PayPass M/Chip only) The following AFL combinations are tested: Case 01: The AFL of the LT refers to file 1 - records 1 to 5. Case 02: The AFL of the LT refers to file 1 - records 1 to 5, file 2 - records 2 to 3, and file 3 - records 3 to 3. Case 03: The AFL of the LT refers to file 1 - records 3 to 3, file 2 - records 2 to 2, and file 5 - records 3 to 3. Case 04: AFL is a pre-defined AFL The LT shall receive in the GenerateAC/CCC data field, correct values for data elements stored during the Read Application Data phase. 46

71 C : ReadRecord - ISO Padding - padding between Data object To ensure that a PayPass reader ignores the padding, if there are padding bytes 0x00 or 0xFF between 2 Data Elements in a Template. [MS v3.3]: [5.4 Data Object Dictionary] [ ] [MC v2.1]: [Annex A Data Objects Dictionary] [EMV 4.2b]: [2CL ] * Length of padding bytes is included in the template length * The Read Record and GetPO tests below shall be performed for PayPass Mag Stripe and PayPass M/Chip. * The Read Record tests below shall be performed with pre-defined and non-pre-defined AFL. Case 01: A record template '70' of LT contains two data objects with a padding of 50 bytes with a value of '00' in between Case 02: A record template '70' of LT contains two data objects with a padding 0000 before the first data object Case 03: A record template '70' of LT contains two data objects with a padding of 200 bytes with a value of '00' after the second data object Case 4: A GetPO response template '77' contains AFL and AIP with a padding 0000 in between Case 5: A GetPO response template '77' contains AFL and AIP with a padding of 50 bytes with a value of '00' after the two objects Case 6: A GetPO response template '77' contains AFL and AIP with a padding 0000 before the two objects Case 7: A record template '70' contains a padding of 251 bytes with a value of '00' The PayPass reader shall process the transaction until completion. 47

72 C : ReadRecord - Padding: padding between Data object with FF This test is for backward compatibilities, to ensure that a PayPass reader ignores the padding, if there are padding bytes 0xFF between 2 Data Elements in a Template. [MS v3.3]: [5.4 Data Object Dictionary] [ ] [MC v2.1]: [Annex A Data Objects Dictionary] [EMV 4.2b]: [2CL ] * Length of padding bytes is included in the template length * The Read Record and GetPO tests below shall be performed for PayPass Mag Stripe and PayPass M/Chip. * The Read Record tests below shall be performed with pre-defined and non-pre-defined AFL. Case 01: A record template '70' of LT contains two data objects with a padding FFFF in between Case 02: A record template '70' of LT contains two data objects with a padding of 50 bytes with a value of 'FF' before the first data object Case 03: A record template '70' of LT contains two data objects with a padding FFFF after the second data object Case 04: A FCI template '6F' of the SELECT ADF response of LT contains DF Name and FCI proprietary template with a padding of 50 bytes with a value of 'FF' in between Case 05: A FCI template '6F' of the SELECT ADF response of LT contains DF Name and FCI proprietary template with a padding FFFF before DF Name Case 06: A FCI template '6F' of the SELECT ADF response of LT contains DF Name and FCI proprietary template with a padding FFFF after FCI proprietary template but within the FCI proprietary template (length of padding is part of FCI proprietary template) Case 07: A GetPO response template '77' of LT contains AFL and AIP with a padding of 200 bytes with a value of 'FF' in between Case 08: A GetPO response template '77' of LT contains AFL and AIP with a padding FFFF after the two objects Case 09: A GetPO response template '77' of LT contains AFL and AIP with a padding FFFF before the two objects The PayPass reader shall process the transaction until completion. 48

73 C : ReadRecord - Padding: padding between Data object To ensure that a terminal ignores the non ISO padding, if there are padding with bytes 0x00 between 2 Data Elements in a Template [MS v3.3]: [5.4 Data Object Dictionary] [ ] [MC v2.1]: [Annex A Data Objects Dictionary] [EMV 4.2b]: [2CL ] * Length of padding bytes is included in the template length * The Read Record and GetPO tests below shall be performed for PayPass Mag Stripe and PayPass M/Chip. * The Read Record tests below shall be performed with pre-defined and non-pre-defined AFL. Case 01: A FCI template '6F' of the SELECT ADF response of LT contains DF Name and FCI proprietary template with a padding 0000 in between Case 02: A FCI template '6F' of the SELECT ADF response of LT contains DF Name and FCI proprietary template with a padding of 200 bytes with a value of '00' before DF Name Case 03: A FCI template '6F' of the SELECT ADF response of LT contains DF Name and FCI proprietary template with a padding 0000 after FCI proprietary template, but within the FCI proprietary template (length of padding is part of FCI proprietary template) Case 04: A FCI proprietary template 'A5' of the SELECT ADF response of LT contains Application Label and Language Preference with a padding 0000 in between Case 05: A FCI proprietary template 'A5' of the SELECT ADF response of LT contains Application Label and Language Preference with a padding of 200 bytes with a value of '00' before DF Name Case 06: A FCI proprietary template 'A5' of the SELECT ADF response of LT contains Application Label and Language Preference with a padding 0000 after last data (length of padding is part of FCI proprietary template) The PayPass reader shall process the transaction until completion. 49

74 C : ReadRecord - ReadRecord - Proprietary data (M/Chip) To ensure that, if the PayPass M/Chip reader encounters a proprietary data object during read application data processing, then the PayPass reader does not store it. [MCHIP] [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] Case 01: M/Chip transaction: Read Record contains a proprietary data object (EMV tag 9F0B (Cardholder name extended) and NOT the tag 5F20 (Cardholder name)) and CDOL1 requests this proprietary data object. Case 02: M/Chip transaction: Read Record contains a proprietary data object (9F 55 and 9F 56) and CDOL1 requests this proprietary data object * The PayPass reader shall process the transaction until completion. * The PayPass reader shall not store the data objects listed in the conditions field and shall therefore fill CDOL with hexadecimal zeroes C : ReadRecord - Proprietary data (Mag Stripe) To ensure that, if the PayPass reader encounters a proprietary data object during read application data processing, then the PayPass reader does not store it. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] Case01: Mag Stripe transaction: Read Record contains a proprietary data object (EMV tag 9F0B (Cardholder name extended) and NOT the tag 5F20 (Cardholder name)) and UDOL requests this proprietary data object. Case02: (Reader does not support PayPass M/Chip) Read Record contains terminal data object Unpredictable Number. UDOL requests this data object. Data returned is such as nun is zero. * The PayPass reader shall process the transaction until completion. * The PayPass reader shall not store the data objects listed in the conditions field and shall therefore use the values below in the DOL instead: Case 1: Hexadecimal zeroes since the data objects are proprietary Case 2: (Reader does not support PayPass M/Chip) the value of the Unpredictable Number data object returned in the UDOL must be different from the value returned by the LT. Case 2: it is acceptable (and even mandated in [MC v2.0] section ) to abort the transaction when the card returns a terminal data object. 50

75 C : ReadRecord - Record size in the range from 1 to 254 bytes To ensure that the PayPass reader is able to read data in file with record size in range from 1 to 254 bytes using READ RECORD commands. [MS v3.3]: [Inherits of EMV] [MC v2.1]: [Inherits of EMV] [EMV 4.2b]: [2CI ] * Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. * AFL is not a pre-defined AFL. * A record containing the template and length equals 01 ( ). * A Data Element with 'average length' is located in a single record (for instance Signed Static Application Data or CDOL1). * A Data Element with maximum length (Total length including Tag and Length and Template is 254) is located in a single record (for instance CDOL1/UDOL) * The PayPass reader shall process the transaction until completion. 51

76 C : ReadRecord - SFI range 1-10 (Non-pre-defined AFL) To ensure that if the AFL is not a pre-defined AFL, then the PayPass reader reads application data as specified in section 10.2 of [EMV BOOK 3]. To ensure that the PayPass reader is able to read data in file with SFI in range 1 to 10 (0x01 to 0x0A) using READ RECORD command. [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CI ] * Perform the tests for both PayPass Mag Stripe and PayPass M/Chip. For PayPass Mag Stripe the data object used will be the PCVC3TRACK2. For PayPass M/Chip the data object used will be the PAN. * AFL is not a pre-defined AFL. Case 01: The data object is located in file with SFI 01. Case 02: The data object is located in file with SFI 02. Case 03: The data object is located in file with SFI 03. Case 04: The data object is located in file with SFI 04. Case 05: The data object is located in file with SFI 05. Case 06: The data object is located in file with SFI 06. Case 07: The data object is located in file with SFI 07. Case 08: The data object is located in file with SFI 08. Case 09: The data object is located in file with SFI 09. Case 10: The data object is located in file with SFI 10. The PayPass reader shall process the transaction until completion. 52

77 C : ReadRecord - SW <> 9000 To ensure that the PayPass reader rejects the transaction if status in response to READ RECORD command sent is different from '90 00' [MS v3.3]: [2.4.4 Status Bytes for READ RECORD Command] [MC v2.1]: [4.2 Exception Processing] [4.2.3 Status Bytes] * * Tests shall be performed for PayPass Mag Stripe and PayPass M/Chip. * LT returns the following status value in response to READ RECORD during the Read Application Data phase: * Case 01: LT returns status value '6283' in response to READ RECORD * Case 02: LT returns status value '63 00' in response to READ RECORD * Case 03: LT returns status value '63 Cx' in response to READ RECORD * Case 04: LT returns status value '69 83' in response to READ RECORD * Case 05: LT returns status value '69 84' in response to READ RECORD * Case 06: LT returns status value '69 85' in response to READ RECORD * Case 07: LT returns status value '6A 81' in response to READ RECORD * Case 08: LT returns status value '6A 82' in response to READ RECORD * Case 09: LT returns status value '6A 88' in response to READ RECORD * Case 10: LT returns status value '6A 83' in response to READ RECORD * Case 11: LT returns status value '64 00' in response to READ RECORD * Case 12: LT returns status value '65 00' in response to READ RECORD * Case 13: LT returns status value '90 01' in response to READ RECORD * Case 14: LT returns status value '6A 86' in response to READ RECORD * Case 15: LT returns status value '6D 00' in response to READ RECORD * Case 16: LT returns status value '6E 00' in response to READ RECORD * Case 17: LT returns status value '6F 00' in response to READ RECORD The following cases are for Refund transactions: * Case 18: LT returns status value '6283' in response to READ RECORD * Case 19: LT returns status value '69 83' in response to READ RECORD * Case 20: LT returns status value '6A 82' in response to READ RECORD * Case 21: LT returns status value '90 01' in response to READ RECORD The PayPass reader shall terminate the transaction. 53

78 C : ReadRecord - Incorrect record template To ensure that the PayPass reader terminates the processing if record template does not parse correctly [MS v3.3]: [inherits from EMV] [MC v2.1]: [inherits from EMV] [EMV 4.2b]: [2CL ] Record template returned in response to READ RECORD during read application data does not parse correctly: Case 01: Record of LT returned in response to READ RECORD of an AEF file has a bad length and value field has the correct length Case 02: Record of LT returned in response to READ RECORD of an AEF has a bad tag '74' Case 03: Record of LT returned in response to READ RECORD of an AEF has no template, but directly a primitive data object CDOL1 Case 04: Record of LT returned in response to READ RECORD of an AEF file has a good length and value field has this length+1 Case 05: LT returns incorrect response to RR: 'AA EF'. Transaction outcome shall be set to "End application" 54

79 C : ReadRecord - Proprietary data ignored by Terminal in SFI 1 to 30 To ensure that the PayPass reader does not terminate the transaction and ignores proprietary data present in File referenced in AFL, for SFI in range 1 to 30. [MS v3.3]: [3.4.2 Read Application Data] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] [EMV 4.2b]: [2CI ] Terminal requests at first GENERATE AC a TC or an ARQC LT responds with ARQC Case 01: A Proprietary Data (Tag '9F 7E') is stored in the '70'template of a File with SFI 2, and AFL reference this file. This data is not signed. Case 02: A Proprietary Data (Tag '9F 7E') is stored in the '70'template of a File with SFI 12, and AFL reference this file. This data is not signed. Case 03: A Proprietary Data (Tag '9F 7E') is stored in the 70 template of a File with SFI 22, and AFL reference this file. This data is not signed. The PayPass reader shall process the transaction until completion. C : ReadRecord - Reader data objects in card response To ensure that, PayPass reader terminates the transaction if card response contains the data objects which are reader as source. [MCHIP] [MS v3.3]: [NA] [MC v2.1]: [4.2.2 Data Objects] [ ] Perform the following tests for Purchase and Refund transactions: Case 01: Mag Stripe transaction: Read Record contains a reader data object Amount, Authorized with value different from zero. Case 02: Mag Stripe transaction: Read Record contains reader data object Unpredictable Number. Data returned is such as nun is zero. Case 03: M/Chip transaction: Read Record contains reader data objects (including Amount, authorized and Unpredictable Number). Amount returned by the LT is different from amount entered by the user. * Reader shall terminate the transaction after read records. 55

80 C : ReadRecord - Duplication of primitive data objects To ensure that, if the PayPass reader encounters more than one occurrence of a single primitive data object during read application data processing, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.2.2 Data Objects] [ ] Case 01: Mag Stripe transaction, AFL is the pre-defined Mag Stripe AFL( ), PCVC3_tr2 duplication occurs in the same record Case 02: Mag Stripe transaction, AFL is not pre-defined Mag Stripe AFL, UDOL duplication occurs in the same record Case 03: Mag Stripe transaction, AFL is not pre-defined Mag Stripe AFL, Tr2 duplication occurs in separate records Case 04: Mag Stripe transaction, AFL is the pre-defined Mag Stripe AFL( ), NATC_Tr2 duplication occurs in the same record Case 05: Mag Stripe transaction, AFL is the pre-defined Mag Stripe AFL( ), PUNATC_tr1 duplication occurs in the same record Case 06: Mag Stripe transaction, AFL is the pre-defined Mag Stripe AFL( ), AVNcard duplication occurs in the same record Case 07: M/Chip transaction, AFL is the pre-defined SDA AFL, duplication occurs in the same record Case 08: M/Chip transaction, AFL is the pre-defined SDA AFL, duplication occurs in separate records Case 09: M/Chip transaction, AFL is not pre-defined SDA/CDA AFL, duplication occurs in the same record Case 10: M/Chip transaction, AFL is not pre-defined SDA/CDA AFL, duplication occurs in separate records The PayPass reader shall terminate the transaction. 56

81 C : DOL - Object List consistency (1) To ensure that the data objects requested by PDOL are available during Initiate Application Processing, and remain consistent throughout the transaction. [MCHIP] [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] The PDOL of LT contains the following: - Terminal Country Code - Transaction Date * For M/Chip transaction, In addition to the default values the CDOL1 of LT contain the following: - Terminal Country Code - Transaction Date Application in LT is selected and transaction is performed with LT. * The PayPass reader shall process the transaction until completion. * The GetPO command shall transmit meaningful values for: Terminal Country Code, Transaction Date. * The first GenerateAC command shall transmit identical values with the GetPO command for: Terminal Country Code, Transaction Date 57

82 C : DOL - Concatenation To ensure that the PayPass reader concatenates a list of data elements in the sequence in which the corresponding data objects appear in the DOL. [MS v3.3]: [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ & ] * The LT has previously sent the DOL to the PayPass reader. * The DOL contains the tags of several data objects (at least 3) which are known to the PayPass reader. Perform a test for each of the following DOLs: - PDOL (common test) - UDOL (Mag Stripe) - CDOL1 (M/Chip) Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Within the data field of a command message containing the DOL-related data, the PayPass reader orders the data elements in the same order that the corresponding data objects appeared in the DOL. C : DOL - PDOL Requests Amount, Authorized & Amount, Other To ensure that PayPass reader correctly processes a PDOL request for Amount, Authorized & Amount, Other. [MCHIP] [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] Transaction amount is greater than zero. Case 01: PDOL requests Amount, Authorized in numeric format (tag '9F 02') Case 02: (not applicable if EntryPoint supported) PDOL requests Amount, Authorized in binary format (tag '81) Case 03: PDOL requests Amount, Other in numeric format (tag '9F 03') Case 04: PDOL requests Amount, Other in binary format (tag '9F 04') GetPO command contains the transaction amount consistent with the PDOL. 58

83 C : DOL - Card requesting 9F28 tag To verify that whenever the tag of any data object identified in the PDOL is unknown to the PayPass reader, the reader provides a data element with the length specified and a value of all hexadecimal zeroes. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] PDOL requests an Entry point data object (9F 28, Contactless Application Capabilities Type). Application in LT is selected and transaction is processed with LT The LT shall receive a GetPO with data field containing the hexadecimal zeroes. C : DOL - Unknown tag To ensure that, if the tag of any data object identified in the DOL is unknown to the PayPass reader, the PayPass reader provides a data element with the length specified and a value of all hexadecimal zeroes. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] Case 01: The PDOL of LT contains a Data Object with an unknown tag to the PayPass reader(common test) Case 02: The CDOL1 of LT contains a Data Object with an unknown tag to the PayPass reader(m/chip test) Case 03: The UDOL of LT contains a Data Object with an unknown tag to the PayPass reader.(mag Stripe test) Application in LT is selected and transaction is performed with LT (in particular the DOL processing). The LT shall receive the DOL with portion of the DOL field representing the Data Object filled with hexadecimal zeroes (portion has the same length as the Data Object in DOL). 59

84 C : DOL - Data not yet available To ensure that if PDOL is present in the FCI of selected ADF and if it contains a Data Element which is not present in the PayPass reader, the PayPass reader sends a GetPO command with a PDOL containing a Data Element with the tag and length specified and a value of all hexadecimal zeroes. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] PDOL is sent back by the LT in FCI of selected ADF and it contains a Data Element which cannot be provided by the PayPass reader at the moment the ARC (tag '8A'). Application in LT is selected and transaction is processed with LT * LT shall receive a GetPO command with a data field containing a data object with Tag '83'. * Data Object in PDOL which cannot be provided at the moment shall be replaced in template '83' with a Data Element of same length and a value of hexadecimal zeroes. C : DOL - Tag with length=0 To ensure that, if the tag of any data object identified in the DOL has a length field coded 00 then the PayPass reader considers the tag as not present. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] Perform a test for each of the following DOLs: - PDOL (common test) - UDOL (Mag Stripe) - CDOL1 (M/Chip) Application in LT is selected and transaction is performed with LT (in particular the DOL processing). The reader shall not send any value in the DOL for the data object having the length field coded 00 in the DOL request. 60

85 C : DOL - Known tag, missing in card To ensure that, if the tag of any data object identified in the DOL is known to the PayPass reader and the optional static data object requested in the DOL is absent from the card, then the PayPass reader provides a data element with the length specified and a value of all hexadecimal zeroes. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] * The LT has previously sent the DOL to the PayPass reader. * The DOL contains a tag which is known to the PayPass reader but representing an optional static data object absent from LT. Perform a test for each of the following DOLs: - UDOL (Mag Stripe) - CDOL1 (M/Chip) Application in LT is selected and transaction is performed with LT (in particular the DOL processing). The LT shall provide a data element with the length specified and a value of all hexadecimal zeros. C : DOL - Shorter data object length, numeric format To ensure that, if the length specified in the DOL entry is less than the length of the actual data object, the PayPass reader truncates the leftmost bytes of the data element if the data object has numeric (n) format. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] Case 01: The PDOL of LT contains a data object which has numeric format and a length shorter than actual Data Object Length(Common test) Case 02: The CDOL1 of LT contains a data object which has numeric format and a length shorter than actual Data Object Length(M/Chip test) Case 03: The UDOL of LT contains a data object which has numeric format and a length shorter than actual Data Object Length(Mag Stripe test) Application in LT is selected and transaction is performed with LT (in particular the DOL processing). The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly truncated (portion has the same length as the Data Object in DOL). This sub case cannot be tested for Mag Stripe V3.3 reader since there is no numeric data object length greater than 1 byte. 61

86 C : DOL - Shorter data object length, other format To ensure that, if the length specified in the DOL entry is less than the length of the actual data object, the PayPass reader truncates the rightmost bytes of the data for any format other than numeric. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] * The LT has previously sent the DOL to the PayPass reader. * The DOL contains a data object which has a format other than numeric and a length shorter than actual Data Object Length. Perform a test for each of the following DOLs, for formats an, ans and b: - PDOL (common test) - UDOL (Mag Stripe) - CDOL1 (M/Chip) Application in LT is selected and transaction is performed with LT (in particular the DOL processing). The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly truncated (portion has the same length as the Data Object in DOL). 62

87 C : DOL - Longer data object length, other format To ensure that, if the length specified is greater than the actual data, the PayPass reader pads the actual data with trailing hexadecimal zeroes for any other format than numeric or compressed numeric. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] * The LT has previously sent the DOL to the PayPass reader. * The DOL contains a data object which has a format other than numeric or compressed numeric and a length longer than actual Data Object Length. Perform a test for each of the following DOLs, for formats an, ans and b: - PDOL (common test) - UDOL (Mag Stripe) - CDOL1 (M/Chip) Application in LT is selected and transaction is performed with LT (in particular the DOL processing). The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly padded with trailing hexadecimal zeroes (portion has the same length as the Data Object in DOL). C : DOL - Longer data object length, numeric format To ensure that, if the length specified is greater than the actual data, the PayPass reader pads the actual data with leading hexadecimal zeroes if the data has numeric format. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] Case 01: The PDOL of LT contains a data object which has numeric format and a length longer than actual Data Object Length(common) Case 02: The CDOL1 of LT contains a data object which has numeric format and a length longer than actual Data Object Length(M/Chip) Case 03: The UDOL of LT contains a data objects which has numeric format and a length longer than actual Data Object Length(Mag Stripe test) Application in LT is selected and transaction is performed with LT (in particular the DOL processing). The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly padded with leading hexadecimal zeroes (portion has the same length as the Data Object in DOL) 63

88 C : DOL - Constructed tag To verify that whenever the tag of any data object identified in the DOL represents a constructed data object, the IUT provides a data element with the length specified and a value of all hexadecimal zeroes. [MS v3.3]: [5 Data Objects] [5.2 DOL Handling] [ ] [MC v2.1]: [5.2 DOL Handling] [ ] Case 01: The PDOL of LT contains a constructed Data Object Case 02: The CDOL1 of LT contains a constructed Data Object Case 03: The UDOL of LT contains a constructed Data Object Application in LT is selected and transaction is performed with LT (in particular the DOL processing). The LT shall receive the DOL with portion of the DOL field representing the Data Object filled with hexadecimal zeroes (portion has the same length as the Data Object in DOL). C : Data Object Management - Length field - 1 byte To ensure that PayPass reader is able to support Data Object with Length on 1 byte (b8 = 0). [MS v3.3]: [5.4 Data Object Dictionary] [ ] [MC v2.1]: [Annex A Data Objects Dictionary] LT contains Data Objects to be read with length on one byte (Language Preference for instance). The PayPass reader correctly manages the Data Object received with length coded on 1 byte. 64

89 C : Data Object Management - Length field - 2 bytes To ensure that PayPass reader is able to support Data Object with Length on 2 bytes (81 xx). [MS v3.3]: [5.4 Data Object Dictionary] [ ] [MC v2.1]: [ Annex A Data Objects Dictionary] [EMV 4.2b]: [2CE ] LT contains Data Object with length coded on 2 bytes: Case 01: LT contains a constructed template '70' with a length <128 bytes and the length is coded on two bytes, containing a primitive data object with a length < 128 bytes and the length is coded on two bytes. Case 02: LT contains a constructed template '70' with a length >127 bytes, containing a primitive data object with a length < 128 bytes and the length is coded on two bytes. Case 03: LT contains a constructed template '70' with a length >127 bytes, containing a primitive data object with a length > 127 bytes. The PayPass reader shall process the transaction until completion and correctly manage the Data Object received with length coded on 2 bytes. C : Data Object Management - Unique IFD and Terminal Country Code for each AID To ensure that the PayPass reader has unique IFD Serial Number and Terminal Country Code. [MCHIP] [MC v2.1]: [5.4 Data Object Management] [ ] * Both LT and PayPass reader contains MasterCard and Maestro AID * Perform 2 transactions with MasterCard and Maestro AIDs respectively * PDOL requests IFD Serial Number and Terminal Country Code in both transactions * PayPass reader shall return the same value for IFD Serial Number and Terminal Country Code in both transactions. * User shall check that the device tool environment does not permit to configure these data objects for each AID. 65

90 C : Data Object Management - Terminal Contactless Transaction Limit for each AID To ensure that PayPass reader has separate instances of Terminal Contactless Transaction Limit flags for each AID [MCHIP] and [MULTIAPPLI] [MC v2.1]: [5.4 Data Object Management] [ ] * Both LT and PayPass reader contain MasterCard and Maestro AID * Transaction performed with the Amount which is greater than Terminal Contactless Transaction Limit of MasterCard AID and is less than Terminal Contactless Transaction Limit of Maestro AID * Application Priority of MasterCard is higher than Maestro s * PayPass Reader shall send Maestro AID in Final Selection C : Data Object Management - Terminal Contactless Floor Limit present for each AID To ensure that PayPass reader has separate instances of Terminal Contactless Floor Limit flags for each AID [MCHIP] and [MULTIAPPLI] [MC v2.1]: [5.4 Data Object Management] [ ] * AIP of LT indicates TRM supported (AIP byte 1 bit 4 = 1). * Both LT and PayPass reader contain MasterCard and Maestro AIDs * Amount is the same for all cases below and is such as it is: - greater than the Terminal Contactless floor limit of MasterCard AID - less than the Terminal Contactless floor limit of Maestro AID Case 01: - MasterCard AID priority is higher than Maestro one Case 02: - Maestro AID priority is higher than MasterCard one Case 01: * TVR B4b8 shall be set to 1 when transaction performed with MasterCard AID Case 02: * TVR B4b8 shall be set to 0 when transaction performed with Maestro AID 66

91 C : Data Object Management - Terminal CVM Required Limit present for each AID To ensure that PayPass reader has separate instances of Terminal CVM Required Limit flags for each AID [MCHIP] [MC v2.1]: [5.4 Data Object Management] [ ] * Both LT and PayPass reader contain MasterCard and Maestro AID * amount is greater than the Terminal CVM Required limit of MasterCard AID and less than the Terminal CVM Required limit of Maestro AID * For all AIDs LT returns AIP indicating that CVM is requested Case 01: - MasterCard AID priority is higher than Maestro one - in Select MasterCard response, LT requests Terminal Capabilities (9F33) to be sent in PDOL Case 02: - in Select Maestro response, LT requests Terminal Capabilities (9F33) to be sent in PDOL - Maestro AID priority is higher than MasterCard one Case 01: * In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities CVM Required as per the ICS Case 02: * In GetPO command, Terminal Capabilities (9F33) shall indicate the Terminal Capabilities NO CVM Required as per the ICS 67

92 C : Data Object Management - Support of data object during application activation To ensure that the PayPass reader supports the data objects listed in section during application activation. [MCHIP] [MC v2.1]: [5.4 Data Object Management] [ ] Case 01: M/Chip transaction * CDOL1 request the following data objects for M/Chip transaction -Cardholder Verification Method (CVM) Results -Terminal Capabilities -Terminal Verification Results -Unpredictable Number Case 02: Mag Stripe transaction UDOL requests Unpredictable Number Application in LT is selected and transaction is processed with LT Case 01: * PayPass reader shall return requested data in GenerateAC command with the values set accordingly * Transaction outcome and Transaction CVM data objects shall be set accordingly Case 02: * PayPass reader shall return UN in CCC command * DDCARD, TRACK1 and DDCARD, TRACK2 shall be set as returned by the card. 68

93 C : Data Object Management - Separate instance of data object for each AID To ensure that the data objects listed in the section has separate instance for each AID supported by PayPass reader. [MCHIP] [MC v2.1]: [5.4 Data Object Management] [ ] * PayPass Mag Stripe: the reader is configured in such a way that the values below are different for MasterCard and Maestro applications. You should store these values as you will need to check them after the test. If the device tool environment does not permit to do so then the test has failed. - Default UDOL - Mag Stripe Application Version number - PayPass Mag Stripe Indicator - Terminal Contactless Transaction Limit * PayPass M/Chip: Please configure the reader in such a way that the values below are different for MasterCard and Maestro applications. You should store these values as you will need to check them after the test. If the device tool environment does not permit to do so then the test has failed. - Additional Terminal Capabilities - Application Version Number - Merchant Category Code - Merchant Custom Data - Terminal Action Codes - Terminal Type - Terminal Capabilities No CVM Required - Terminal Capabilities CVM Required - Terminal Contactless Transaction Limit - Terminal Contactless Floor Limit - Terminal CVM Required Limit * Transaction is performed with 2 different amounts with greater than CVM limit and less than CVM limit. * PDOL requests the data objects listed above (except default UDOL, TACs and MagStripe Indicator) Application in LT is selected and transaction is processed with LT * The device tool environment shall permit to configure different values for MasterCard and Maestro applications. * The values sent in the first PDOL must be the ones configured for the MasterCard application. * The values sent in the second PDOL must be the ones configured for the Maestro application 69

94 C : Data Object Management - with minimum length - Application identifier To ensure the PayPass reader correctly behaves when the variable length data objects have minimum length (for instance Application identifier). [MS v3.3]: [5.4 Data Object Dictionary] [ ] [MC v2.1]: [Annex A Data Objects Dictionary] LT returns the following in response to PPSE: - Application Identifier (4F) with length of 5 bytes (PIX length is 0 byte) The selected application is such as the FINAL SELECT includes the following items: - Dedicated Name (84) with length of 5 bytes * The PayPass reader shall use the same 5 bytes AID returned in the PPSE response for FINAL SELECT * Application selection process will correctly complete and PayPass reader will send a correct GetPO command. Typically this test will use the AID Test defined in the Terminal Vendor Guide present on PayPass.com. C : Data Object Management - with maximum length Application Identifier To ensure the PayPass reader correctly behaves when the variable length data objects have maximum length (for instance Application Identifier). [MS v3.3]: [5.4 Data Object Dictionary] [ ] [MC v2.1]: [Annex A Data Objects Dictionary] a) LT returns the following in response to PPSE: - An Application Identifier (4F) with length of 16 bytes (PIX length is 11 bytes) b) The selected application is such as the FINAL SELECT includes the following item: - Dedicated Name (84) with length of 16 bytes (AID with PIX extension may be used) * PayPass reader shall continue the transaction successfully * The PayPass reader shall use the same 16 bytes AID returned in the PPSE response for FINAL SELECT 70

95 C : Miscellaneous - PayPass reader Support of Local Language To ensure that the PayPass reader supports the local language which is the language of common usage in the PayPass reader's locality or region [DISPLAY] [MS v3.3]: [Inherits from EMV] [MC v2.1]: [ Inherits from EMV] [EMV 4.2b]: [2CO ] LT has Language Preference set according to the PayPass reader's locality or region Case 01: LT language Preference is coded with lower case characters Case 02: LT language Preference is coded with upper case characters * The PayPass reader shall process the transaction until completion. * The message displayed shall be in the language of common usage in the PayPass reader's locality or region C : Miscellaneous - PayPass reader Display of Messages in Local Language To ensure that the PayPass reader displays the messages to the attendant in the language of common usage in the PayPass reader's locality or region [ATTENDED] and [DISPLAY] [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CO ] * The PayPass reader shall process the transaction until completion. * The message displayed for the attendant shall be in the language of common usage in the PayPass reader's locality or region 71

96 C : Miscellaneous - PayPass reader Support of Relevant Character Set To ensure that the PayPass reader displays the messages using the relevant character set defined in the corresponding part of ISO 8859 [DISPLAY] and [CHARACTERSET_X] [MS v3.3]: [Inherits from EMV Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CO ] * The PayPass reader supports at least one Issuer Code Table Index Case 01: LT returns language preference in which one of the language is supported by the PayPass reader Case 02: LT returns language preference in which all of the languages are supported by the PayPass reader (if multiple) Case 03: LT returns language preference in which one of the language is supported by the PayPass reader and second language is not supported by the PayPass reader Case 04: LT has Spanish as language preference Case 05: LT has Chinese (Mandarin) as language preference * The PayPass reader shall process the transaction until completion. * The languages supported by the PayPass reader and the LT shall be used with relevant character set C : Miscellaneous - Display For Attendant in Attended Terminal To ensure that if the PayPass reader is attended, it has a display for the attendant [ATTENDED] [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CM ] NA Visual inspection by the tester is required PayPass reader shall have a display for the attendant 72

97 C : Miscellaneous - Capability of PayPass Reader Printer To ensure that if present, the printer shall be able to print 20 characters per line [PRINT] [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CM ] * 10 bytes (20 characters) AID in LT. For example, 'A ' AID shall be printed correctly on the receipt C : Miscellaneous - PayPass reader uses local language when no match is found To ensure that the PayPass reader compares the card's Language Preference with the languages supported in the PayPass reader at the beginning of the transaction and uses local language if no match is found and PayPass reader supports several Languages [DISPLAY] and [LANGUAGE_SELECTION] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [4.3 Functions Used in Transaction Processing] [ ] LT have Language Preference value with no matching language with PayPass reader * The PayPass reader shall process the transaction until completion. * PayPass reader shall use the Local language. 73

98 C : Miscellaneous - PayPass reader Displays Message in Supported Language To ensure that the PayPass reader uses the language it supports if no match is found with card supported Languages and PayPass reader supports only one Language (Language of common usage in the region) [DISPLAY] and [NO_LANGUAGE_SELECTION] [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CO ] LT have Language Preference value with no matching language with PayPass reader * The PayPass reader shall process the transaction until completion. * The messages for the Cardholder shall be displayed in the PayPass reader supported Language (Language of common usage in the region) 74

99 2.2 PayPass Mag Stripe Test Cases G : PPSE - Mandatory data objects missing: ADF Name To ensure that if mandatory ADF Name is missing in an ADF Directory entry of the Payment System Directory, PayPass reader must terminate the transaction. [MULTIAPPLI] and [NO MCHIP] [MS v3.3]: [1.3 Building the Candidate List] [ ] [MC v2.1]: [N/A] * PayPass reader and Payment System Directory of LT contains two ADF Directory entry in PPSE * First ADF Directory entry does not contain ADF Name data object (entire data missing: TLV) Application selection process is performed by the LT PayPass reader shall terminate the transaction. G : FINALSELECT - Direct selection of application To ensure that, if the PayPass reader only supports one application and supports direct selection of this application, then the PayPass reader immediately issues the SELECT command with the appropriate AID and does not apply the application selection mechanism described in the specifications. [DIRECTSELECTION] and [NO MCHIP] [MS v3.3]: [1.1 Introduction] [] [MC v2.1]: [N/A] * The PayPass reader issues a single SELECT command. * The data field of the SELECT command has the same value as the AID of the application supported by the PayPass reader. Transaction shall complete normally. 75

100 G : FINALSELECT - Incorrectly formatted FCI To ensure that, if the Select AID FCI is not correctly formatted then the PayPass reader shall remove the application from the candidate list. [MULTIAPPLI] and [NO MCHIP] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [N/A] * LT and PayPass reader have several mutually supported applications (at least 2). * Candidate list is built via PPSE: PPSE card response includes several applications and SW=9000. * FCI of ADF template returned in response to SELECT ADF does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...). Application selection process is performed by the LT. The PayPass reader shall remove the application from candidate list and select the next application in candidate list G : FINALSELECT - Mandatory data objects missing To ensure that, if a data element, classified as mandatory, expected to be returned by the card is missing then the PayPass reader removes the directory entry from the candidate list and proceeds with next entry [NO MCHIP] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [N/A] * LT and PayPass reader have several mutually supported applications (at least 2). Case 01: LT response to final SELECT does not contain the FCI Data object 6F (entire data missing: TLV; LT returns only 9000 ) Case 02: LT response to final SELECT does not contain the DF Name Data object 84 (entire data missing: TLV) Case 03: LT response to final SELECT does not contain FCI Proprietary Template Data object (entire data missing: TLV) PayPass reader removes the directory entry from the candidate list and proceeds with next entry in the candidate list. 76

101 G : GetPO - RFU bit set in AIP - Mag Stripe To ensure that the PayPass reader is able to process the AIP when RFU bits are set. [MS v3.3]: [5.1 Data Object Format] [MC v2.1]: [5.1 Data Object Format] [ ] * Response to GetPO contains valid AIP and AFL * AIP is 58 0F * Issuer certificate is not returned by LT * IAC denial is returned by LT with value FF FF FF FF FF * PayPass Mag Stripe transaction shall complete successfully. * PayPass Reader shall not display anything related to CVM or Data authentication. G : GetPO - Mag Stripe reader accepts M/Chip card To ensure that PayPass Mag Stripe PayPass reader accepts PayPass M/Chip card. [NO MCHIP] [MC v2.1]: [1.2 M/Chip Profile and Mag Stripe Profile] * Reader parameter PayPass Mag Stripe indicator is set for MasterCard AID * MasterCard has highest priority * AIP byte 2, bit 8 = 1 (PayPass M/Chip profile is supported) PayPass Mag Stripe transaction shall complete correctly. 77

102 G : ReadRecord - Files containing multiple records (Non-pre-defined AFL) To ensure that if the AFL is not a pre-defined AFL, then the PayPass reader reads application data as specified in section 10.2 of [EMV BOOK 3]. [MS v3.3]: [Read Application Data] [3.4.2] [MC v2.1]: [N/A] [4.3.3 Read Mag Stripe Application Data] [ ] * AIP of LT indicates M/Chip profile not supported (AIP byte 2 bit 8 = 0). * AFL is not a pre-defined AFL. * One Mandatory Data Element (PCVC3TRACK2 for instance) is located in first record of a file. * Another Mandatory Data Element (NATCTRACK2 for Instance) is located in second record of same file. The PayPass reader shall process the transaction until completion. G : ReadRecord - 4 m.s. bytes same as PayPass Mag Stripe value To ensure that, if the value of the four most significant bytes of AFL is the standard PayPass Mag Stripe AFL then the PayPass reader shall not interpret the AFL and shall only read the first record in the file with SFI 01. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] Case 01: AFL is the standard PayPass Mag Stripe AFL. Perform this test for Purchase and Refund transactions. Case 02: AFL is the standard PayPass M/Chip SDA AFL Case 03: AFL is the standard PayPass M/Chip CDA AFL. Perform this test for Purchase and Refund transactions. Case 04: The AFL contains two entries. The first entry AFL is the standard PayPass Mag Stripe AFL. The second entry in the AFL has the value ' '. Immediately after receiving a GetPO command the LT receives a single READ RECORD command. The command has the syntax: 00 B2 01 0C

103 G : ReadRecord - Optional Data Objects To ensure that the PayPass reader accepts presence or absence of optional Data Objects. [MS v3.3]: [Read Application Data] [3.4.2] [MC v2.1]: [N/A] [4.3.3 Read Mag Stripe Application Data] [ ] * AIP of LT indicates M/Chip profile not supported (AIP byte 2 bit 8 = 0). * Test is made for the presence and the absence of all Optional Data Objects coming from card (source = ICC in Table A-1 Data Elements Dictionary) and read with READ RECORD. * Presence of Mandatory data Object listed is not tested. Case 01: no optional data objects are present. Case 02: all optional data objects are present. The PayPass reader shall process the transaction until completion. G : ReadRecord - Verifying PCVC3TR1, PUNATCTR1 and NATCTR1 are present To ensure that, if Track 1 Data is included in the data returned from the card, then the PayPass reader also verifies that PCVC3TRACK1, PUNATCTRACK1 and NATCTRACK1 are returned. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data, Track 1 Bit Map for CVC3 (PCVC3TRACK1), Track 1 Bit Map for UN and ATC (PUNATCTRACK1) and Track 1 Number of ATC Digits (NATCTRACK1). The PayPass reader shall process the transaction until completion. 79

104 G : ReadRecord - Verifying qtrack1 If the Track 1 Data is available, then the PayPass reader must verify that the number of bits in PCVC3TRACK1 is greater than or equal to 3 (i.e. qtrack1 >= 3). [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects as well as data objects Track 1 Data, Track 1 Bit Map for CVC3 (PCVC3TRACK1), Track 1 Bit Map for UN and ATC (PUNATCTRACK1) and Track 1 Number of ATC Digits (NATCTRACK1). * Data returned by LT are such that the qtrack1 is greater than and equal to 3. * Please run at least 4 tests with different values of qtrack1. The PayPass reader shall process the transaction until completion. G : ReadRecord - Verifying ktrack1 - ttrack1 If the Track 1 Data is available, then the PayPass reader must verify that ktrack1 - ttrack1 is equal to nun. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data, Track 1 Bit Map for CVC3 (PCVC3TRACK1), Track 1 Bit Map for UN and ATC (PUNATCTRACK1) and Track 1 Number of ATC Digits (NATCTRACK1). * Data returned by LT are such that ktrack1 - ttrack1 are different. * Please run at least 4 tests with different values of nun(i.e,ktrack1 - ttrack1 are different) The PayPass reader shall process the transaction until completion. 80

105 G : ReadRecord - Verifying nun The PayPass reader must verify that nun is less than or equal to 8. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all mandatory data objects. * Data returned by LT are such that the copied nun digit is different from the digit previously present at this position in the discretionary data. * Please run at least 4 tests with different values of nun The PayPass reader shall process the transaction until completion. G : ReadRecord - Verifying qtrack2 To ensure that the PayPass reader verifies that the number of bits in PCVC3TRACK2 is greater than or equal to 3 (i.e. qtrack2 >= 3). [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all mandatory data objects. * Data returned by LT are such that the qtrack2 >= 3 * Please run at least 4 tests with different values of qtrack2(i.e., different PCVC3TRACK2) The PayPass reader shall process the transaction until completion. 81

106 G : ReadRecord - Verifying PAN and Expiration Date in Track 1 Data If the Track 1 Data is returned from the card, then the PayPass reader must verify that the PAN and Expiration Date included in the Track 1 Data are the same as the PAN and Expiration Date included in the Track 2 Data. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data, Track 1 Bit Map for CVC3 (PCVC3TRACK1), Track 1 Bit Map for UN and ATC (PUNATCTRACK1) and Track 1 Number of ATC Digits (NATCTRACK1). * PAN in Track 1 Data is the same length as PAN in Track 2 Data and all the digits agree. * All of the bytes of Expiration Date in Track 1 Data agree with the corresponding bytes of Expiration Date in Track 2 Data. The PayPass reader shall process the transaction until completion. G : ReadRecord - Storing recognized data objects-optional data To ensure that the PayPass reader stores recognized optional data objects for later use in the transaction processing. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all mandatory data objects, UDOL, Track 1 Data, PUNATCTRACK1, PCVC3TRACK1 and NATCTRACK1. * The UDOL identifies the data objects Unpredictable Number (UN), Track 1 Data, PUNATCTRACK1, PCVC3TRACK1 and NATCTRACK1. The PayPass reader issues a CCC command with data field comprising the value of the data element Track 1 Data, Track 1 Bit Map for UN and ATC (PUNATCTRACK1), Track 1 Bit Map for CVC3 (PCVC3TRACK1) and Track 1 Number of ATC Digits (NATCTRACK1). 82

107 G : ReadRecord - Copying process - Track 1 format error To ensure that during the PayPass - Mag Stripe transaction, the PayPass reader does not validate the individual data elements returned in the Track 1 Data and Track 2 Data. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] [EMV 4.2b]: Track 1 sent by the card contains some validation error in individual data object. Perform several tests including at least the following ones: Case 01: Service Code = 989 (Track1 and Track2) Case 02: Expired date (Track1 and Track2) Case 03: Name field without separator (Track1 only) Case 04: Name field with separator (Track1 only) The PayPass reader shall continue the transaction until completion. 83

108 G : ReadRecord - Not verify service code in Track 1 data or Track 2 data To ensure that during the Mag Stripe transaction, the PayPass reader shall not validate the values 2 and 6 in the first digit of the service code present in Track 1 Data or Track 2 Data to determine if a contact chip transaction is required [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] Case 01: Service code value in Track 1 is '100' (International) Case 02: Service code value in Track 1 is '221' (International/ICC) Case 03: Service code value in Track 1 is '543' (National) Case 04: Service code value in Track 1 is '662' (National/ICC) Case 05: Service code value in Track 1 is '774' (Private) Case 06: Service code value in Track 2 is '126' (International) Case 07: Service code value in Track 2 is '245' (International/ICC) Case 08: Service code value in Track 2 is '577' (National) Case 09: Service code value in Track 2 is '601' (National/ICC) Case 10: Service code value in Track 2 is '760' (Private) Application in LT is selected and transaction is performed with LT. The PayPass reader shall not check the first digit of the Service Code and complete transaction successfully. The data record shall be as defined in the specifications. Especially the data record shall not include any PayPass Mag Stripe Transaction CVM to be passed to the terminal. Information in parenthesis for each sub cases gives the description of Service Code - first digit 84

109 G : ReadRecord - Missing data objects: Track 2 Data To ensure that if, on conclusion of read application data processing, any of the mandatory data objects are not present then the PayPass reader terminates the transaction. Track2 data is missing. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] Case 01: The first record in the file with SFI 01 contains the data objects PUNATCTRACK2, PCVC3TRACK2 and NATCTRACK2. Track2 is missing. Perform this test for Purchase and Refund transactions. Case 02: Same as Case 01 plus Track2 is returned in the Select ADF BF0C Case 03: Same as Case 01 plus Track2 is returned in the Select PPSE BF0C Case 04: Same as Case 01 plus AFL is not the pre-defined one and the 3 data objects are returned in several records. The PayPass reader shall terminate the transaction. G : ReadRecord - Missing data objects: PUNATCTRACK2 To ensure that if, on conclusion of read application data processing, any of the mandatory data objects are not present then the PayPass reader terminates the transaction. PUNATCTRACK2 is missing. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * The first record in the file with SFI 01 contains the data objects Track 2 Data, PCVC3TRACK2 and NATCTRACK2. Perform tests for Purchase and Refund transactions. The PayPass reader shall terminate the transaction. 85

110 G : ReadRecord - Missing data objects: PCVC3TRACK2 To ensure that if, on conclusion of read application data processing, any of the mandatory data objects are not present then the PayPass reader terminates the transaction. PCVC3TRACK2 is missing. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * The first record in the file with SFI 01 contains the data objects Track 2 Data, PUNATCTRACK2 and NATCTRACK2. The PayPass reader shall terminate the transaction. G : ReadRecord - Missing data objects: NATCTRACK2 To ensure that if, on conclusion of read application data processing, any of the mandatory data objects are not present then the PayPass reader terminates the transaction. NATCTRACK2 is missing. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * The first record in the file with SFI 01 contains the data objects Track 2 Data, PUNATCTRACK2 and PCVC3TRACK2 The PayPass reader shall terminate the transaction. 86

111 G : ReadRecord - All mandatory data objects missing To ensure that if, on conclusion of read application data processing, any of the mandatory data objects are not present then the PayPass reader terminates the transaction when no mandatory data object is present. [MS v3.3]: [3.4.2 Read Application Data] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 does not contain any data object. The PayPass reader shall terminate the transaction. 87

112 G : ReadRecord - PCVC3TRACK1 or PUNATCTRACK1 or NATCTRACK1 missing To ensure that, if Track 1 Data is included in the data returned from the card and any of PCVC3TRACK1, PUNATCTRACK1 and NATCTRACK1 is not available, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] Case 01 (PCVC3TRACK1 missing): The first record in the file with SFI 01 contains all the mandatory data as well as the data objects Track 1 Data, PUNATCTRACK1 and NATCTRACK1. AFL is the standard PayPass Mag Stripe AFL. Case 02 (PUNATCTRACK1 missing): The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data, PCVC3TRACK1 and NATCTRACK1. AFL is NOT the standard PayPass Mag Stripe AFL. Case 03 (NATCTRACK1 missing): The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data, PCVC3TRACK1 and PUNATCTRACK1. AFL is the standard PayPass Mag Stripe AFL. Case 04 (PCVC3TRACK1 & PUNATCTRACK1 missing): The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data and NATCTRACK1. AFL is the standard PayPass Mag Stripe AFL. Case 05 (PCVC3TRACK1 & NATCTRACK1 missing): The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data and PUNATCTRACK1. AFL is the standard PayPass Mag Stripe AFL. Case 06 (PUNATCTRACK1 & NATCTRACK1 missing): The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data and PCVC3TRACK1. AFL is the standard PayPass Mag Stripe AFL. Case 07 (PCVC3TRACK1 & PUNATCTRACK1 & NATCTRACK1 missing): The first record in the file with SFI 01 contains all the mandatory data objects and the data object Track 1 Data. AFL is NOT the standard PayPass Mag Stripe AFL. The PayPass reader shall terminate the transaction. 88

113 G : ReadRecord - Copying process - Track 2 format error To ensure that During the Mag Stripe transaction, if in the course of copying the dynamic data, the PayPass reader is not able to localize the discretionary data field due to one or more format error in the Track 1 data or Track 2 data (e.g. missing separator), then the PayPass reader must terminate processing immediately. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] Track 2 sent by the card does not include the needed separator so that the discretionary data field cannot be localized. The PayPass reader shall terminates the transaction G : ReadRecord - Data Object incorrectly formatted: PUNATCTRACK2 To ensure that if, in the course of normal processing, the PayPass reader recognizes that data returned by the card is incorrectly formatted, it terminates processing when the Track 2 Bit Map for UN and ATC (PUNATCTRACK2) data object is formatted incorrectly. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects. * Track 2 Bit Map for CVC3 (PCVC3TRACK2) has the value '1C00' (giving qtrack2 = 3) and Track 2 Number of ATC Digits (NATCTRACK2) = 0 (giving ttrack2 = 0). * Tests performed for cases where: Case 01: Track 2 Bit Map for UN and ATC (PUNATCTRACK2) has a length of 1 byte and the value '00' (giving ktrack2 = 0) Case 02: Track 2 Bit Map for UN and ATC (PUNATCTRACK2) has a length of 3 bytes and the value '000000' (giving ktrack2 = 0). Application in LT is selected and transaction is performed with LT. The PayPass reader shall terminate the transaction. 89

114 G : ReadRecord - Data Object incorrectly formatted: PCVC3TRACK2 To ensure that if, in the course of normal processing, the PayPass reader recognizes that data returned by the card is incorrectly formatted, it terminates processing when the Track 2 Bit Map for CVC3 (PCVC3TRACK2) data object is formatted incorrectly. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] AFL is the standard PayPass Mag Stripe AFL The first record in the file with SFI 01 contains all the mandatory data objects. Track 2 Bit Map for UN and ATC (PUNATCTRACK2) has the value '0000' (giving ktrack2 = 0) and Track 2 Number of ATC Digits (NATCTRACK2) = 0 (giving ttrack2 = 0). Tests performed for cases where: Case 01: Track 2 Bit Map for CVC3 (PCVC3TRACK2) has a length of 1 byte and the value 'E0' (giving qtrack2 = 3). Case 02: Track 2 Bit Map for CVC3 (PCVC3TRACK2) has a length of 3 bytes and the value '0000E0' (giving qtrack2 = 3). Application in LT is selected and transaction is performed with LT. The PayPass reader shall terminate the transaction. 90

115 G : ReadRecord - Data Object incorrectly formatted: NATCTRACK2 To ensure that if, in the course of normal processing, the PayPass reader recognizes that data returned by the card is incorrectly formatted, it terminates processing when the Track 2 Number of ATC Digits (NATCTRACK2) data object is formatted incorrectly. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] AFL is the standard PayPass Mag Stripe AFL The first record in the file with SFI 01 contains all the mandatory data objects. Track 2 Bit Map for CVC3 (PCVC3TRACK2) has the value '1C00' (giving qtrack2 = 3) and Track 2 Bit Map for UN and ATC (PUNATCTRACK2) has the value '0000' (giving ktrack2 = 0). Tests performed for cases where: Case 01: Track 2 Number of ATC Digits (NATCTRACK2) has a length of 0 bytes. Case 02: Track 2 Number of ATC Digits (NATCTRACK2) has a length of 2 bytes and the value 0 (giving ttrack2 = 0). Application in LT is selected and transaction is performed with LT. The PayPass reader shall terminate the transaction. G : ReadRecord - Copying process - Track 1 format error To ensure that During the Mag Stripe transaction, if in the course of copying the dynamic data, the PayPass reader is not able to localize the discretionary data field due to one or more format error in the Track 1 data or Track 2 data (e.g. missing separator), then the PayPass reader must terminate processing immediately. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] Track 1 sent by the card does not include the needed separator so that the discretionary data field cannot be localized. The PayPass reader shall terminate the transaction 91

116 G : ReadRecord - Data Object incorrectly formatted: Track 1 Data To ensure that if, in the course of normal processing, the PayPass reader recognizes that data returned by the card is incorrectly formatted, it terminates processing when the Track 1 Data data object is formatted incorrectly. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data, Track 1 Bit Map for UN and ATC (PUNATCTRACK1), Track 1 Bit Map for CVC3 (PCVC3TRACK1) and Track 1 Number of ATC Digits (NATCTRACK1). * Track 1 Data has a length of 77 bytes. Application in LT is selected and transaction is performed with LT. The PayPass reader shall terminate the transaction. 92

117 G : ReadRecord - Data Object incorrectly formatted: PUNATCTRACK1 To ensure that if, in the course of normal processing, the PayPass reader recognizes that data returned by the card is incorrectly formatted, it terminates processing when the Track 1 Bit Map for UN and ATC (PUNATCTRACK1) data object is formatted incorrectly. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects. * Track 2 Bit Map for CVC3 (PCVC3TRACK2) has the value '1C00' (giving qtrack2 = 3), Track 2 Bit Map for UN and ATC (PUNATCTRACK2) has the value '0000' (giving ktrack2 = 0) and Track 2 Number of ATC Digits (NATCTRACK2) = 0 (giving ttrack2 = 0). * Track 1 Bit Map for CVC3 (PCVC3TRACK1) has the value 'E ' (giving qtrack1 = 3) and Track 1 Number of ATC Digits (NATCTRACK1) = 0 (giving ttrack1 = 0). Tests performed for cases where: Case 01: Track 1 Bit Map for UN and ATC (PUNATCTRACK1) has a length of 5 bytes and the value ' ' (giving ktrack1 = 0) Case 02: Track 1 Bit Map for UN and ATC (PUNATCTRACK1) has a length of 7 bytes and the value ' ' (giving ktrack1 = 0). Application in LT is selected and transaction is performed with LT. The PayPass reader shall terminate the transaction. 93

118 G : ReadRecord - Data Object incorrectly formatted: PCVC3TRACK1 To ensure that if, in the course of normal processing, the PayPass reader recognizes that data returned by the card is incorrectly formatted, it terminates processing when the Track 1 Bit Map for CVC3 (PCVC3TRACK1) data object is formatted incorrectly. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects. * Track 2 Bit Map for CVC3 (PCVC3TRACK2) has the value '1C00' (giving qtrack2 = 3), Track 2 Bit Map for UN and ATC (PUNATCTRACK2) has the value '0000' (giving ktrack2 = 0) and Track 2 Number of ATC Digits (NATCTRACK2) = 0 (giving ttrack2 = 0). * Track 1 Bit Map for UN and ATC (PUNATCTRACK1) has the value ' ' (giving ktrack1 = 0).and Track 1 Number of ATC Digits (NATCTRACK1) = 0 (giving ttrack1 = 0). Tests performed for cases where: Case 01: Track 1 Bit Map for CVC3 (PCVC3TRACK1) has a length of 5 bytes and the value ' E0' (giving qtrack1 = 3). Case 02: Track 1 Bit Map for CVC3 (PCVC3TRACK1) has a length of 7 bytes and the value ' E0' (giving qtrack1 = 3). Application in LT is selected and transaction is performed with LT. The PayPass reader shall terminate the transaction. 94

119 G : ReadRecord - Data Object incorrectly formatted: NATCTRACK1 To ensure that if, in the course of normal processing, the PayPass reader recognizes that data returned by the card is incorrectly formatted, it terminates processing when the Track 1 Number of ATC Digits (NATCTRACK1) data object is formatted incorrectly. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects. * Track 2 Bit Map for CVC3 (PCVC3TRACK2) has the value '1C00' (giving qtrack2 = 3), Track 2 Bit Map for UN and ATC (PUNATCTRACK2) has the value '0000' (giving ktrack2 = 0) and Track 2 Number of ATC Digits (NATCTRACK2) = 0 (giving ttrack2 = 0). * Track 1 Bit Map for CVC3 (PCVC3TRACK1) has the value 'E ' (giving qtrack1 = 3) and Track 1 Bit Map for UN and ATC (PUNATCTRACK1) has the value ' ' (giving ktrack1 = 0). Tests performed for cases where: Case 01: Track 1 Number of ATC Digits (NATCTRACK1) has a length of 0 bytes. Case 02: Track 1 Number of ATC Digits (NATCTRACK1) has a length of 2 bytes and the value 0 (giving ttrack1 = 0). Application in LT is selected and transaction is performed with LT. The PayPass reader shall terminate the transaction. 95

120 G : ReadRecord - Data Object incorrectly formatted: UDOL To ensure that if, in the course of normal processing, the PayPass reader recognizes that data returned by the card is incorrectly formatted, it terminates processing when the Unpredictable Number Data Object List (UDOL) data object is formatted incorrectly. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.2 Data Objects] [ ] AFL is not empty. The AFL contains a reference to a record containing an Unpredictable Number Data Object List (UDOL) data object. All mandatory data objects are present in the LT. Tests performed for cases where: Case 01: UDOL contains a single entry comprising the tag but not the length of the Unpredictable Number (Numeric). Case 02: UDOL contains one or more entries, but none for the Unpredictable Number (Numeric). Application in LT is selected and transaction is performed with LT. The PayPass reader shall terminate the transaction. G : ReadRecord - ktrack2 < ttrack2 To ensure that, if ktrack2 < ttrack2, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * LT returns all mandatory data objects. * Data returned by LT are such that ktrack2 - ttrack2 <=8 and qtrack2>=3 * Please run at least 4 tests with different values of ktrack2 and ttrack2 such that ktrack2 < ttrack2 The PayPass reader terminates the transaction. 96

121 G : ReadRecord - nun > 8 To ensure that, if nun is greater than 8, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * LT returns all mandatory data objects. * Data returned by LT are such that ktrack2 >= ttrack2 and qtrack2>=3 * Please run at least 4 tests with different values of nun such that nun > 8 * One of the tests will include the Track1 data objects. ktrack1 ttrack1 =nun (=ktrack2 - ttrack2), qtrack1>=3. The PayPass reader terminates the transaction. G : ReadRecord - qtrack2 < 3 To ensure that, if qtrack2 < 3, the PayPass reader terminates the transaction. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * LT returns all mandatory data objects. * Data returned by LT are such that ktrack2 >= ttrack2 and nun<=8 * Please run at least 3 tests with different values of qtrack2 such that qtrack2 < 3 * One of the tests will include the Track1 data objects. ktrack1 ttrack1 =nun (=ktrack2 - ttrack2). The PayPass reader terminates the transaction. 97

122 G : ReadRecord - qtrack1 < 3 To ensure that, if qtrack1 < 3, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * LT returns all the mandatory data objects as well as the data objects Track 1 Data, PCVC3TRACK1, PUNATCTRACK1 and NATCTRACK1. * Data returned by LT are such that ktrack2 >= ttrack2, nun<=8, ktrack1- ttrack2=nun and qtrack2>=3. * Please run at least 3 tests with different values of qtrack1 such that qtrack1 < 3 The PayPass reader terminates the transaction. G : ReadRecord - ktrack1 - ttrack1 is not equal to nun To ensure that, if ktrack1 - ttrack1 is not equal to nun, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * LT returns all the mandatory data objects as well as the data objects Track 1 Data, PCVC3TRACK1, PUNATCTRACK1 and NATCTRACK1. * Data returned by LT are such that the ktrack1 >= ttrack1, nun<=8, qtrack1>=3 and qtrack1>=3 * Please run at least 4 tests with different values of ktrack1,ttrack1 such that ktrack1 - ttrack1 is different from nun The PayPass reader terminates the transaction. 98

123 G : ReadRecord - ktrack1 < ttrack1 To ensure that, if ktrack1 < ttrack1, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * LT returns all the mandatory data objects as well as the data objects Track 1 Data, PCVC3TRACK1, PUNATCTRACK1 and NATCTRACK1. * Data returned by LT are such that ktrack2 - ttrack2=nun= ktrack1 ttrack1, qtrack2>=3 and qtrack1>=3 * Please run at least 4 tests with different values of ktrack1,ttrack1 such that ktrack1 < ttrack1 The PayPass reader terminates the transaction. 99

124 G : ReadRecord - PAN discrepancy in Track 1 and Track 2 To ensure that, if the Track 1 Data is returned from the card and the PAN included in the Track 1 Data is not the same as the PAN included in the Track 2 Data, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * LT returns all the mandatory data objects as well as the data objects Track 1 Data, PCVC3TRACK1, PUNATCTRACK1 and NATCTRACK1. Expiration Date in Track 1 Data is the same as Expiration Date in Track 2 Data. * Data returned by LT are such that ktrack2 >= ttrack2, nun<=8, ktrack1- ttrack2=nun, qtrack2>=3 and qtrack1>=3. Test for cases where: Case 01: Number of bytes of PAN in Track 1 Data (LengthPAN1) is less than the number of digits of PAN in Track 2 Data (LengthPAN2) and the first LengthPAN1 bytes of the PAN in Track 1 Data agree with the first LengthPAN1 digits of the PAN in Track 2 Data. Case 02: Number of bytes of PAN in Track 1 Data (LengthPAN1) is greater than the number of digits of PAN in Track 2 Data (LengthPAN2) and the first LengthPAN2 bytes of the PAN in Track 1 Data agree with the first LengthPAN2 digits of the PAN in Track 2 Data. Case 03: Number of bytes of PAN in Track 1 Data (LengthPAN1) is the same as the number of digits of PAN in Track 2 Data (LengthPAN2) and none of the bytes in the PAN in Track 1 Data agree with the corresponding digits in the PAN in Track 2 Data. Case 04: Number of bytes of PAN in Track 1 Data (LengthPAN1) is the same as the number of digits of PAN in Track 2 Data (LengthPAN2) and only the first byte of the PAN in Track 1 Data disagrees with the first digit of the PAN in Track 2 Data; the other bytes/digits agree. Case 05: Number of bytes of PAN in Track 1 Data (LengthPAN1) is the same as the number of digits of PAN in Track 2 Data (LengthPAN2) and first the byte of the PAN in Track 1 Data agrees with the first digit of the PAN in Track 2 Data; the other bytes/digits disagree. Perform this test for Purchase and Refund transactions The PayPass reader terminates the transaction. 100

125 G : ReadRecord - PAN & Expiration Date discrepancy in Track 1 and Track 2 To ensure that, if the Track 1 Data is returned from the card and the PAN and Expiration Date included in the Track 1 Data are not the same as the PAN and Expiration Date included in the Track 2 Data, then the PayPass reader terminates the transaction. (PAN and Expiration Date) [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data, PCVC3TRACK1, PUNATCTRACK1 and NATCTRACK1. * Number of bytes of PAN in Track 1 Data is the same as the number of digits of PAN in Track 2 Data and none of the bytes/digits agree; none of the bytes of Expiration Date in Track 1 Data agree with the corresponding digits of Expiration Date in Track 2 Data. The PayPass reader terminates the transaction. 101

126 G : ReadRecord - Expiration Date discrepancy in Track 1 and Track 2 To ensure that, if the Track 1 Data is returned from the card and the Expiration Date included in the Track 1 Data is not the same as the Expiration Date included in the Track 2 Data, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.3 Read Mag Stripe Application Data] [ ] * Tests shall be performed with pre-defined and non-pre-defined AFL. * LT returns all the mandatory data objects as well as the data objects Track 1 Data, PCVC3TRACK1, PUNATCTRACK1 and NATCTRACK1. * PAN in Track 1 Data is the same as PAN in Track 2 Data. * Data returned by LT are such that ktrack2 >= ttrack2, nun<=8, ktrack1- ttrack2=nun, qtrack2>=3 and qtrack1>=3. Test for cases where: Case 01: The first byte of Expiration Date in Track 1 Data disagrees with the first digit of Expiration Date in Track 2 Data; the other bytes/digits agree. Case 02: The first two bytes of Expiration Date in Track 1 Data disagree with the first two digits of Expiration Date in Track 2 Data; the other bytes/digits agree. Case 03: The first three bytes of Expiration Date in Track 1 Data disagree with the first three digits of Expiration Date in Track 2 Data; the other byte/digits agree. Case 04: None of the bytes of Expiration Date in Track 1 Data agree with the corresponding digits of Expiration Date in Track 2 Data. The PayPass reader terminates the transaction. 102

127 G : Processing restrictions - AVN assigned by the payment system To ensure that the PayPass reader maintains an Application Version Number assigned by the payment system. [MS v3.3]: [3.4.3 Application Version Number Checking] [ ] [MC v2.1]: [4.3.4 Mag Stripe Application Version Number Checking] [ ] * UDOL requests Application Version Number (9F 6D). * Test is made for all applications supported by the PayPass reader (except Maestro) plus one application having an extended AID. * The PayPass reader shall process the transaction until completion. * LT shall receive the value of application version number for the selected application. G : Processing restrictions - AVN (card) present and supported To ensure that, if Application Version Number (card) is present in the card and the PayPass reader supports the application version of the card then the PayPass reader uses the appropriate code and/or commands to deal with the card. [MS v3.3]: [3.4.3 Application Version Number Checking] [ ] [MC v2.1]: [4.3.4 Mag Stripe Application Version Number Checking] [ ] Application Version Number (card) is present in the card and identifies an application version supported by the PayPass reader: * UDOL requests Application Version Number (9F 6D). * The PayPass reader shall process the transaction until completion. * The PayPass reader shall provide the latest application version number value ( 0001 ) in the CCC command. 103

128 G : Processing restrictions - AVN (card) present and not recognized To ensure that, if Application Version Number (card) is present in the card and the PayPass reader does not recognize the application version of the card, then the PayPass reader uses its most recent version to deal with the card. [MS v3.3]: [3.4.3 Application Version Number Checking] [ ] [MC v2.1]: [4.3.4 Mag Stripe Application Version Number Checking] [ ] * Application Version Number (card) is present in the card and identifies an application version not recognized by the PayPass reader. Make at least one test with the value * The first record in the file with SFI 01 contains all mandatory data objects and UDOL. * The UDOL identifies the data objects Unpredictable Number (UN) and Application Version Number (PayPass reader). * The PayPass reader shall process the transaction until completion. * The PayPass reader issues a CCC command with data field containing the latest value of the data element Application Version Number (PayPass reader). * The value of the Application Version Number (PayPass reader) data element is that of the most recent version:

129 G : Processing restrictions - AVN (card) not present To ensure that, if Application Version Number (card) is not present in the card then the PayPass reader assumes that the PayPass reader and card application versions are compatible. [MS v3.3]: [3.4.3 Application Version Number Checking] [ ] [MC v2.1]: [4.3.4 Mag Stripe Application Version Number Checking] [ ] * Application Version Number is not present in the ICC. * The first record in the file with SFI 01 contains all mandatory data objects and UDOL. * The UDOL identifies the data objects Unpredictable Number (UN) and Application Version Number (PayPass reader). * The PayPass reader shall process the transaction until completion. * The PayPass reader issues a CCC command with data field containing the value of the data element Application Version Number (PayPass reader). * The value of the Application Version Number (PayPass reader) data element is that of the most recent version: G : CCC - No UDOL To ensure that, when the UDOL is not provided by the card, the PayPass reader shall construct the data field of the CCC command message using the Default PayPass reader UDOL data object. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] The AFL does not contain a reference to a record containing a UDOL data object. Case 01: pre-defined AFL Case 02: non pre-defined AFL The PayPass reader issues a CCC command to the LT with data field having the value of the Unpredictable Number (UN) generated by the PayPass reader. 105

130 G : CCC - UDOL To ensure that the PayPass reader supports UDOL. [MS v3.3]: [5.2 DOL Handling] [ ] [MC v2.1]: [ ] * The AIP has bit b8 in byte 2 set to 0b ("Only magnetic-stripe profile supported"). * Application data in LT contains a valid UDOL, including at least the Unpredictable Number tag. Application in LT is selected and transaction is performed with LT. The PayPass reader shall issue a CCC command with data field coded according to the UDOL. G : CCC - Unpredictable Number To ensure that the PayPass reader is able to generate an unpredictable number [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] A minimum of 4 transactions are performed for each case below. case 01: UDOL requests Unpredictable Number case 02: card does not return any UDOL so the default UDOL is used Unpredictable Number shall be different at each transaction 106

131 G : CCC - Generating an Unpredictable Number (nun = 0) To ensure that the PayPass reader generates an Unpredictable Number (UN) of length 8 digits of which the 8-nUN most significant digits are set equal to 0.(nUN=0) [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] Case 01: * AFL is the standard PayPass Mag Stripe AFL * The UDOL identifies the data object Unpredictable Number (UN). LT returns only Track2 data elements * Data returned by LT is such as nun=0 Case 02: * AFL is NOT the standard PayPass Mag Stripe AFL * LT does not return the UDOL LT returns Track1 and Track2 data elements * Data returned by LT is such as nun=4 Case 03: * AFL is the standard PayPass M/Chip CDA AFL * LT does not return the UDOL LT returns Track1 and Track2 data elements * Data returned by LT is such as nun=7 * The PayPass reader issues a CCC command with data field comprising the value of the data element Unpredictable Number (UN). * The 8 - nun most significant digits of Unpredictable Number (UN) are zero. 107

132 G : CCC - Response contains only mandatory data objects To ensure that the PayPass reader verifies if the response message of the CCC command is correctly formatted when it only contains mandatory data objects. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] The response message of the CCC commands includes a Response Message Template with a value field that includes the CVC3TRACK2 and Application Transaction Counter data objects. The PayPass reader shall process the transaction until completion. G : CCC - Response contains mandatory and optional data objects To ensure that the PayPass reader verifies if the response message of the CCC command is correctly formatted when it contains mandatory and optional data objects. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] The response message of the CCC commands includes a Response Message Template with a value field that includes the CVC3TRACK2, Application Transaction Counter and CVC3TRACK1 data objects. The PayPass reader shall process the transaction until completion. 108

133 G : CCC - Response contains mandatory, optional and additional data objects To ensure that the PayPass reader ignores any additional data object in the response to the CCC command. [MS v3.3]: [2.2 CCC] [2.2.3 Data Field Returned in the Response Message] [MC v2.1]: [4.3.5 CCC Processing] [ ] Case 01: Track1 data objects are not returned by LT in ReadRecord and CCC. CCC response includes the Application Version Number (Card) data object. This data object is not returned in Read-Records Case 02: Track1 data objects are returned by LT in ReadRecord and CCC. CCC response includes the D5 data object. * The PayPass reader shall process the transaction until completion. * PayPass reader shall ignore the additional data object. 109

134 G : CCC - SW <> '9000' To ensure that, once the application selection process has been completed, if the PayPass reader receives any SW1SW2 from the card other than '9000' then the PayPass reader terminates the transaction. [MS v3.3]: [3.3 Exception Processing] [3.3.2 Status Bytes] [ ] [MC v2.1]: [4.2 Exception Processing] [4.2.3 Status Bytes] [ ] Test is performed for the cases where the LT returns the following status bytes for the CCC command: Case 01: '6A86'. Case 02: '6700'. Case 03: '6985'. Case 04: '6E00'. Case 05: '6D00'. Case 06: '6F00'. Case 07: '6283'. Case 08: FF FF. The following are for Refund transactions: Case 09: '6700'. Case 10: '6985'. Case 11: '6E00'. Case 12: '6D00'. * The reader shall terminate transaction. * If the device under test supports PayPass M/Chip then the transaction outcome shall be set to "End application". 110

135 G : CCC - Mandatory card data object missing To ensure that, if a data element, classified in section 6 of Part II of [PPMS] as mandatory, expected to be returned by the card is missing then the PayPass reader terminates the transaction. (Tag missing) [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] LT response to CCC does not contain Response Message Template tag. The PayPass reader terminates the transaction. G : CCC - CVC3TRACK2, ATC missing To ensure that the PayPass reader terminates the transaction if CVC3TRACK2 or ATC are missing. [MS v3.3]: [3.3 Exception Processing] [3.3.1 Data Objects] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] Case 01: LT response to CCC does not contain CVC3TRACK2 tag. LT does not return Track1 data objects in ReadRecord and CCC. Case 02: LT response to CCC does not contain CVC3TRACK2 tag. LT returns Track1 data objects in ReadRecord and CCC. Case 03: LT response to CCC does not contain Application Transaction Counter tag. The PayPass reader terminates the transaction. 111

136 G : CCC - CVC3TRACK1 missing To ensure that, if the Track 1 Data is available and the CVC3TRACK1 is not available, then the PayPass reader terminates the transaction. [MS v3.3]: [3.4.4 CCC] [ , ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all mandatory data objects as well as the Track1 data objects. * The response to the CCC commands includes a Response Message Template containing all mandatory data objects but does not include a CVC3TRACK1 data object. The PayPass reader terminates the transaction. 112

137 G : CCC - No response to the CCC command To ensure that, if the PayPass reader does not receive any response from the card for the CCC command then, on the jth (j=1,2,3, ) consecutive transaction for which no response from the card for the CCC command is received, the PayPass reader shall wait 2m* 300ms (m=min(j-1,5)) before processing is continued. [MS v3.3]: [3.4.4 CCC] [ , ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * An initialization transaction has to be performed first in order to initiate "j". * Then in the seven following transactions, LT does not respond to the CCC commands (j=1 to 7) * LT remains in front of the device after all CCC command. * LT configuration is such as the PAN and the selected AID are different from one transaction to another one. Selected AIDs shall be MasterCard or Maestro or Test or extended AID. * Then a final transaction is performed where LT correctly responds to the CCC command. * Initialization transaction: the reader correctly completes the transaction. * J=1: the PayPass reader issues the CCC command and then terminates the transaction at least 300 ms later. * J=2: the PayPass reader issues the CCC command and then terminates the transaction at least 600 ms later. * J=3: the PayPass reader issues the CCC command and then terminates the transaction at least 1.2 s later. * J=4: the PayPass reader issues the CCC command and then terminates the transaction at least 2.4 s later. * J=5: the PayPass reader issues the CCC command and then terminates the transaction at least 4.8 s later. * J=6: the PayPass reader issues the CCC command and then terminates the transaction at least 9.6 s later. * J=7: the PayPass reader issues the CCC command and then terminates the transaction at least 9.6 s later. * Final transaction: the reader correctly completes the eighth transaction. The reader deselects/resets the card not later than 80ms* after the reception of the card response to CCC command. *: 80ms is the maximum time allowed for the whole PayPass Mag Stripe transaction to be conducted, see [AN2] for further details. So the measured time between the CCC response and the deselect/reset will obviously be less than 80ms. The aim is to ensure that the transaction is performed in a reasonable time i.e.: j is initialized when the card sends a valid response to the CCC command. 113

138 G : CCC - Response not correctly formatted To ensure that, if the response message of the CCC command is not correctly formatted, then the PayPass reader terminates the transaction as indicated in the specifications. [MS v3.3]: [3.4.4 CCC] [ , ] [MC v2.1]: [4.3.5 CCC Processing] [ , ] * An initialization transaction has to be performed first in order to initiate "j". * Then in the seven following transactions, LT responds incorrectly to the CCC commands (j=1 to 7) as defined in cases below. * LT remains in front of the device after all CCC command. * LT configuration is such as the PAN and the selected AID are different from one transaction to another one. Selected AIDs shall be MasterCard or Test or extended AID. * Then a final transaction is performed where LT correctly responds to the CCC command. Case 01: LT returns 6283 Case 02: LT returns Case 03: CVC3TRACK2 is missing Case 04: CVC3TRACK1 is only 1 byte long * Initialization transaction: the reader correctly completes the transaction. * J=1: the reader terminates the transaction at least 300 ms after the CCC response. * J=2: the reader terminates the transaction at least 600 ms after the CCC response. * J=3: the reader terminates the transaction at least 1.2 s after the CCC response. * J=4: the reader terminates the transaction at least 2.4 s after the CCC response. * J=5: the reader terminates the transaction at least 4.8 s after the CCC response. * J=6: the reader terminates the transaction at least 9.6 s after the CCC response. * J=7: the reader terminates the transaction at least 9.6 s after the CCC response. * Final transaction: the reader correctly completes the eighth transaction. The reader deselects/resets the card not later than 80ms* after the reception of the card response to the CCC command. *: 80ms is the maximum time allowed for the PayPass Mag Stripe transaction to be conducted, see [AN2] for further details. So the measured time between the CCC response and the deselect/reset will obviously be less than 80ms. The aim is to ensure that the transaction is performed in a reasonable time i.e.: j is initialized when the card sends a valid response to the CCC command. 114

139 G : TrackComputation - Correctly builds discretionary data To ensure that the reader correctly builds discretionary data as per section of M/Chip 2.0 [MS v3.3]: [3.4.4 CCC Processing] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * The CVC3 data is overwritten by UN and ATC * UN and/or ATC are overwritten by nun PayPass reader correctly builds the discretionary data. G : TrackComputation - Copying CVC3TRACK2 To ensure that the PayPass reader copies the qtrack2 least significant digits of the BCD encoded CVC3TRACK2 into the eligible positions of the discretionary data field of Track 2 Data. The eligible positions are indicated by the q Track 2 non zero bits in PVC3 Track 2. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * AFL is the standard PayPass Mag Stripe AFL * LT returns all mandatory data objects. * Data returned by LT are such that the copied CVC3TRACK2 digits are different from the initial digits present in the discretionary data * Data returned by LT are such that the copied CVC3TRACK2 digits are not overwritten in the rest of the transaction * Please run at least 4 tests with different values of CVC3TRACK2, qtrack2, PCVC3TRACK2 and Track2 discretionary data length. The eligible positions of the discretionary data field of the Track 2 Data contain the qtrack2 non-zero bits in PVC3 Track

140 G : TrackComputation - Copying UN into Track 2 Data To ensure that the PayPass reader replaces the nun least significant eligible positions of the discretionary data field of Track 2 Data with the nun least significant digits of Unpredictable Number (UN). The eligible positions in the discretionary data field are indicated by the nun least significant non-zero bits in the PUNATC Track 2. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * AFL is the standard PayPass Mag Stripe AFL * LT returns all mandatory data objects. * Data returned by LT are such that the copied UN digits are different from the digits previously present in the discretionary data -Data returned by LT are such that the copied UN digits are not overwritten in the rest of the transaction -Please run at least 4 tests with different values of UN, nun (including values 0 and 8), PUNATCTRACK2 and Track2 discretionary data length. The nun least significant eligible positions of the discretionary data field of Track 2 Data contain the nun least significant digits of Unpredictable Number (UN). 116

141 G : TrackComputation - Copying ATC to Track 2 Data To ensure that the PayPass reader replaces the ttrack2 most significant eligible positions of the discretionary data field of Track 2 Data with the ttrack2 least significant digits of the BCD encoded Application Transaction Counter. The eligible positions in the discretionary data field are indicated by the t Track 2 most significant non-zero bits in the PUNATC Track 2. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * AFL is the standard PayPass Mag Stripe AFL * LT returns all mandatory data objects. * Data returned by LT are such that the copied ATC digits are different from the digits previously present in the discretionary data * Data returned by LT are such that the copied ATC digits are not overwritten in the rest of the transaction * Please run at least 4 tests with different values of ATC, ttrack2, PUNATCTRACK2 and Track2 discretionary data length.(including ttrack2=0 and ttrack2=5) The ttrack2 most significant eligible positions of the discretionary data field of Track 2 Data contain the ttrack2 least significant digits of Application Transaction Counter. If NATC >5 then the ATC value must be left padded with zero. 117

142 G : TrackComputation - Copying nun To ensure that the PayPass reader copies nun to the least significant digit of the discretionary data field of the Track 2 Data. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * AFL is the standard PayPass Mag Stripe AFL * The LT returns all mandatory data objects. Data returned by LT are such that the copied nun digit is different from the digit previously present at this position in the discretionary data. * Please run at least 4 tests with different values of nun and Track2 discretionary data length. Case 01: PCVC3TRACK2= '1C00' (giving qtrack2 = 3), PUNATCTRACK2= '003E' (ktrack2 = 5) and NATCTRACK2 = 5 (ttrack2 = 5). Case 02: PCVC3TRACK2= '1C00' (giving qtrack2 = 3), PUNATCTRACK2= '001E' (giving ktrack2 = 4) and NATCTRACK2 = 0 (giving ttrack2 = 0). Case 03: PCVC3TRACK2= '1C00' (giving qtrack2 = 3), PUNATCTRACK2 = '01FE' (giving ktrack2 = 8) and NATCTRACK2 = 0 (giving ttrack2 = 0). Case 04: PCVC3TRACK2= '1C01' (giving qtrack2 = 4), PUNATCTRACK2 = '0201' (giving ktrack2 = 2), NATCTRACK2 = 2 (giving ttrack2 = 2) Perform tests for Purchase and Refund transactions. The least significant digit of the discretionary data field of the Track 2 Data has the correct nun value. 118

143 G : TrackComputation - Copying CVC3TRACK1 To ensure that the PayPass reader converts the qtrack1 least significant digits of the BCD encoded CVC3TRACK1 into the ASCII format and copies the qtrack1 ASCII encoded CVC3TRACK1 characters into the eligible positions of the discretionary data field of the Track 1 Data. The eligible positions are indicated by the qtrack1 non-zero bits in PVC3TRACK1. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * AFL is the standard PayPass Mag Stripe AFL * LT returns all mandatory data objects. * Data returned by LT are such that the copied CVC3TRACK1 digits are different from the initial digits present in the discretionary data * Data returned by LT are such that the copied CVC3TRACK1 digits are not overwritten in the rest of the transaction * Please run at least 4 tests with different values of CVC3TRACK1, qtrack1, PCVC3TRACK1 and Track1 discretionary data length. The eligible positions of the discretionary data field of the Track 1 Data contain ASCII representation of the qtrack1 least significant digits of the BCD encoding of the base ten expression of CVC3TRACK1. 119

144 G : TrackComputation - Copying UN into Track 1 Data To ensure that, if the Track 1 Data is available, then the PayPass reader converts the BCD encoded Unpredictable Number (UN) into the ASCII format and replaces the nun least significant eligible positions of the discretionary data field of the Track 1 Data with the nun least significant characters of the ASCII encoded Unpredictable Number (UN). The eligible positions in the discretionary data field are indicated by the Nun least significant non-zero bits in PUNATC Track1. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * AFL is the standard PayPass Mag Stripe AFL * Data returned by LT are such that the copied UN digits are different from the digits previously present in the discretionary data * Data returned by LT are such that the copied UN digits are not overwritten in the rest of the transaction * Please run at least 4 tests with different values of UN, nun (including values 0 and 8), PUNATCTRACK1 and Track1 discretionary data length. The nun least significant eligible positions of the discretionary data field of Track 1 Data contain the nun least significant digits of Unpredictable Number (UN). 120

145 G : TrackComputation - Copying ATC to Track 1 Data To ensure that the PayPass reader replaces the ttrack1 most significant eligible positions of the discretionary data field of the Track 1 Data with the ttrack1 ASCII encoded Application Transaction Counter characters. [MS v3.3]: [3.4.4 CCC] [ ] [MC v2.1]: [4.3.5 CCC Processing] [ ] * AFL is the standard PayPass Mag Stripe AFL * Data returned by LT are such that the copied ATC digits are different from the digits previously present in the discretionary data * Data returned by LT are such that the copied ATC digits are not overwritten in the rest of the transaction -Please run at least 4 tests with different values of ATC, ttrack1, PUNATCTRACK1 and Track1 discretionary data length.(including ttrack1=0 and ttrack1=5) The ttrack1 most significant eligible positions of the discretionary data field of Track 1 Data contain the ttrack1 least significant digits of Application Transaction Counter. G : TrackComputation - Track 1 - nun at the end To ensure that during the Track 1 computation, the PayPass reader must write the nun at the end of the discretionary data field of the Track 1 Data. [MS v3.3]: [3.4 Functions Used in Transaction Processing] [3.4.4 CCC] [ , ] [MC v2.1]: [4.3.5 CCC Processing] [ , ] * AFL is the standard PayPass Mag Stripe AFL * The first record in the file with SFI 01 contains all the mandatory data objects as well as the data objects Track 1 Data, PCVC3TRACK1, PUNATCTRACK1 and NATCTRACK1. * Data returned by LT are such that the copied nun digit is different from the digit previously present at this position in the discretionary data. * Please run at least 4 tests with different values of nun (including 0 and 8) and Track1 discretionary data length. Perform tests for Purchase and Refund transactions. The least significant digit of the discretionary data field of the Track 1 Data has the correct nun value. 121

146 G : Completion - Data record with correct DDCARD,TRACK1, DDCARD,TRACK2 To ensure the PayPass reader prepares the Data Record with correct DDCARD, TRACK1, DDCARD, TRACK2. [MS v3.3]: [3.4.5 Completion] [ ] [MC v2.1]: [ Completion] [Table 4.7 & ] The PAN is 16 digits long. LT contains, Track 2 Data, Track 1 Data in such a way that Case 01: DDCARD, TRACK1 and DDCARD, TRACK2 shall be 3 digits long. (Track1 and Track2 bitmaps are such as CVC3, UN, ATC and nun fit in 3 digits. Especially pcvc3 value shall be '0 07'' for case 1) Case 02: DDCARD,TRACK1 shall be with the length greater than 3 and less than 48 digits and DDCARD,TRACK2 shall be with the length greater than 3 and less than 13 digits Case 03: DDCARD,TRACK1 shall be with the length 48 and DDCARD,TRACK2 shall be with the length 13 Case 04: DDCARD,TRACK1 shall be with the length 48 and DDCARD,TRACK2 shall be with the length greater than 3 and less than 13 Case 05: DDCARD,TRACK2 shall be with the length 13 and DDCARD,TRACK1 shall be with the length greater than 3 and less than 48 * The PayPass reader shall process the transaction until completion * Data Record sent to the terminal shall contain Track2, Track1 data and DDCARD, TRACK2, DDCARD, TRACK1. DDCARD,TRACK2, DDCARD,TRACK1 shall have the same value as returned by LT. 122

147 G : Completion - Optional data missing To ensure the PayPass reader prepares the Data Record, when LT does not contain optional data. [NO MCHIP] [MS v3.3]: [Functions Used in Transaction Processing] [3.4.5 Completion] [ ] [MC v2.1]: [N/A] * LT contains, Track 2 Data * LT does not contain Track 1 Data, PayPass Third Party Data, Application Label, Application Preferred Name, Issuer Code Table Index, Language Preference. * The PayPass reader shall process the transaction until completion * Data Record sent to the terminal shall contain Track2 data and DDCARD, TRACK2. DDCARD, TRACK2 shall have the same value as returned by LT. Data Record shall not contain any data stated in condition 2. G : Completion - Data record with correct Third Party Data To ensure the PayPass reader prepares the Data Record with same third party data return by LT. [NO MCHIP] [MS v3.3]: [Functions Used in Transaction Processing] [3.4.5 Completion] [ ] [MC v2.1]: [N/A] Case 01: LT contains, Third Party Data with the length of 5 (Proprietary Data with length of 1 byte) Case 02: LT contains, Third Party Data with the length of >5 and <32 Case 03: LT contains, Third Party Data with the length of 32 (Proprietary Data with length of 28 byte) * The PayPass reader shall process the transaction until completion * Data Record prepared to hand over to the terminal, shall contains correct (same) third party data 123

148 G : Completion - Mag Stripe Optional data missing To ensure the PayPass reader prepares the Mag Stripe Data Record, when LT does not contain optional data. [MCHIP] [MC v2.1]: [ Completion] [ ] * AIP of LT indicates M/Chip profile not supported (AIP byte 2 bit 8 = 0). * LT contains Track 2 Data and DF Name * LT does not contain Track 1 Data, PayPass Third Party Data, Application Label, Application Preferred Name, Issuer Code Table Index Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion * Data Record sent to the terminal shall contain Track2 data, DDCARD, TRACK2 and DFname. * DDCARD, TRACK2 shall have the same value as returned by LT. * Data Record shall not contain any data stated in condition

149 G : Completion - Mag Stripe Optional data present To ensure that the PayPass reader prepares the Mag Stripe Data Record, when LT contains all mandatory and optional data. [MS v3.3]: [Functions Used in Transaction Processing] [3.4.5 Completion ] [MC v2.1]: [N/A] * AIP of LT indicates M/Chip profile not supported (AIP byte 2 bit 8 = 0). * Case 01: Lt returns data such as i) all data objects defined as conditional in the data record are present ii) all card data objects defined in the data record have a minimum length as defined below (in bytes): Track2 Data (PAN (6 bytes), DD (3 digits)), Track1 Data (PAN (12 bytes), DD (3 bytes)), PayPass Third Party Data (5), Application Label (1), Application Preferred Name (1), Issuer Code Table Index (1), Language Preference (2) PayPass Third Party Data is returned in the ReadRecords. * Case 02: Lt returns data such as i) all data objects defined as conditional in the data record are present ii) all card data objects defined in the data record have a maximum length as defined below (in bytes): Track2 Data (PAN (19 digits), DD (10 digits)), Track1 Data (PAN (19), DD (10)), PayPass Third Party Data (32), Application Label (16), Application Preferred Name (16), Issuer Code Table Index (1), Language Preference (8) PayPass Third Party Data is returned in the FCI. * The PayPass reader shall process the transaction until completion * Data Record shall contain Track 2 Data and Track 1 Data * Data Record shall also contain DDCARD,TRACK2, DDCARD,TRACK1, PayPass Third Party Data, Application Label, Application Preferred Name, Issuer Code Table Index and Language Preference same as returned by LT. 125

150 G : Completion - Mag Stripe Optional data present To ensure that the PayPass reader prepares the Mag Stripe Data Record, when LT contains all mandatory and optional data. [MCHIP] [MC v2.1]: [ Completion] [ ] * AIP of LT indicates M/Chip profile not supported (AIP byte 2 bit 8 = 0). * Case 01: Lt returns data such as i) all data objects defined as conditional in the data record are present ii) all card data objects defined in the data record have a minimum length as defined below (in bytes): Track2 Data (PAN (6 bytes), DD (3 digits)), Track1 Data (PAN (12 bytes), DD (3 bytes)), PayPass Third Party Data (5), DF Name (7), Application Label (1), Application Preferred Name (1), Issuer Code Table Index (1) PayPass Third Party Data is returned in the ReadRecords. * Case 02: Lt returns data such as i) all data objects defined as conditional in the data record are present ii) all card data objects defined in the data record have a maximum length as defined below (in bytes): Track2 Data (PAN (19 digits), DD (10 digits)), Track1 Data (PAN (19), DD (10)), PayPass Third Party Data (32), DF Name (16), Application Label (16), Application Preferred Name (16), Issuer Code Table Index (1) PayPass Third Party Data is returned in the FCI. * The PayPass reader shall process the transaction until completion * Data Record shall contain Track 2 Data and Track 1 Data * Data Record shall also contain DDCARD,TRACK2, DDCARD,TRACK1, PayPass Third Party Data, DF Name, Application Label, Application Preferred Name and Issuer Code Table Index same as returned by LT. 126

151 G : DOL - UDOL - with maximum length To ensure the PayPass reader correctly behaves when the UDOL have maximum length [MS v3.3]: [Data Objects] [5.4 Data Object Dictionary] [MC v2.1]: [Annex A Data Objects Dictionary] * AIP of LT indicates M/Chip is not supported * LT contains UDOL with the length of 212 bytes * PayPass reader shall continue the transaction successfully * CCC data field shall contain value of the data object with correct length. G : Data Object Management - With minimum length To ensure the PayPass reader correctly behaves when the variable length data objects have minimum length. [MS v3.3]: [Data Objects] [5.4 Data Object Dictionary] [MC v2.1]: [Annex A Data Objects Dictionary] a) AIP of LT indicates M/Chip is not supported b) LT returns the following in response to PPSE: - Application Label (50) with length of 1 byte c) The selected application is such as the FINAL SELECT includes the following items: - Application Label (50) with length of 1 byte - Application Preferred name (9F12) with length of 1 byte - Language Preference (5F2D) with length 2 bytes d) LT returns the following in response to READ RECORD - Track 1 data (PAN is 16 digits long, Name in Track 1 with length of 2 bytes) Even if PayPass reader should not check this data item, please follow ISO7813 for this test: "Minimum encoded data shall be a single alpha character (as surname) and the surname separator". - Track 2 data (PAN is 16 digits long, DD with 4 digits) e) UDOL requests all data Elements stated in condition c) plus the Unpredictable Number * PayPass reader shall continue the transaction successfully * The LT shall receive correct data in the CCC data field 127

152 G : Data Object Management - With maximum length To ensure the PayPass reader correctly behaves when the variable length data objects have maximum length [MS v3.3]: [Data Objects] [5.4 Data Object Dictionary] [MC v2.1]: [Annex A Data Objects Dictionary] a) AIP of LT indicates M/Chip is not supported b) LT returns the following in response to PPSE: - An Application Label (50) with length of 16 bytes c) The selected application is such as the FINAL SELECT includes the following items: - An Application Label (50) with length of 16 byte - Application Preferred name (9F12) with length of 16 byte - Language Preference (5F2D) with length 8 bytes d) LT returns the following in response to READ RECORD - Track 1 data with the length of 76 bytes (Pan with length of 19 digits, Name with length of 26 bytes) - Track 2 data with the length of 19 bytes (PAN with length of 19 digits) e) UDOL requests all LT data stated in condition c) and d) plus the Unpredictable Number * PayPass reader shall continue the transaction successfully * The LT shall receive correct data in the CCC data field 128

153 G : Data Object Management - CVMlist not stored To ensure that the PayPass Mag Stripe reader does not perform CVM selection. [MS v3.3]: [Functions Used in Transaction Processing] [3.4.5 Completion] [ ] [MC v2.1]: [N/A] UDOL requests Unpredictable Number (9F6A) and CVM list PayPass Mag Stripe (9F 68). Case 01: AIP of LT indicates CVM is supported. Both CVM lists PayPass (9F68) and EMV (8E) are Signature if supported (1E 03). Case 02: AIP of LT indicates CVM is not supported. Both CVM lists PayPass (9F68) and EMV (8E) are Online pin Always (02 00) Case 3: AIP of LT indicates CVM is supported. Both CVM lists PayPass (9F68) and EMV (8E) are Fail Always (00 00) Application in LT is selected and transaction is processed with LT * Value of CVM list in UDOL shall be filled with hexadecimal zeroes * Transaction shall complete successfully G : Refund - Data record To ensure that the PayPass reader sets the Transaction Outcome to Approved for Refund MagStripe transaction. To ensure the reader correctly computes the data record. [REFUND] [MC v2.1]: [4.1.2 Refund Transaction Flow] * AIP of LT indicates M/Chip profile not supported (AIP byte 2 bit 8 = 0). * Data returned by LT is such that the data record includes all conditional data objects Application in LT is selected and transaction is processed with LT Transaction Outcome shall be set to Approved. The data record includes all the data objects with correct values. 129

154 G : Refund - Combined To ensure the PayPass reader correctly performs a refund transaction. [MCHIP] and [REFUND] [MC v2.1]: [4.1.2 Refund Transaction Flow] * AIP of LT indicates M/Chip profile not supported (AIP byte 2 bit 8 = 0). * AIP of LT indicates TRM supported (AIP byte 2 bit 4 = 1). * AIP of LT indicates CVM supported (AIP byte 2 bit 5 = 1). * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1) * UDOL requests Transaction Type. A Purchase transaction is performed prior the Refund. Perform the test for MasterCard and Maestro applications. * The reader must return Transaction Type= 20 at CCC. * The PayPass reader shall process the transaction until completion. * Transaction outcome shall be set to 'Approved' * The reader builds the data record with the correct values. 130

155 2.3 PayPass M/Chip Test Cases M : Pre-Process - CVM and Floor limits do not impact Mag Stripe transactions To ensure that the CVM and floor limits do not impact the PayPass Mag Stripe transaction. [MCHIP] [MS v3.3]: [NA] [MC v2.1]: [implicit test] * AID s are returned such that MC has the highest priority. * LT indicates that it does not support MChip. * The CVM and floor limits are non-zero. Case01: amount is greater than CVM and floor limits Case02: amount is lower than CVM and floor limit. * MC AID is selected for transaction. * The Transaction Outcome shall indicate Online Request. M : PPSE - Mandatory data missing: ADF Name, API To ensure that if any mandatory data object from table 2.22 is missing in an ADF Directory entry of the Payment System Directory, PayPass reader must continue with next entry. [MULTIAPPLI] and [MCHIP] [MC v2.1]: [3.4.1 Building the Candidate List] [ ] * PayPass reader and Payment System Directory of LT contains two ADF Directory entry in PPSE Case 01: First ADF Directory entry does not contain ADF Name data object (entire data missing: TLV) Case 02: Second ADF Directory entry does not contain API data object (entire data missing: TLV) Application selection process is performed by the LT PayPass reader shall remove the error application and continue with next entry 131

156 M : FINALSELECT - SW <> Combined test To ensure that if the card returns a status different from '90 00' to the FINAL SELECT command, the PayPass reader removes the application from the list of mutually supported applications and switches back to the final application selection process. [MCHIP] [MS v3.3]: [1.4 Final Selection] [ ] [MC v2.1]: [3.4.2 Final Selection] [ ] * Reader supports MasterCard and Maestro and Test AIDs. * Amount is smaller than the Contactless limit of MasterCard and Maestro AIDs. * Amount is greater than the Contactless limit of Test AID. * Amount is greater than MasterCard CVM limit. * Amount is smaller than Maestro CVM limit. * Amount is smaller than MasterCard floor limit. * Amount is greater than Maestro floor limit. * Application and related priorities returned by LT are: 1) MasterCard, 2) Test 3) Maestro with extended AID 4) MasterCard with extended AID * LT returns PDOL including the Terminal Capabilities tag Case 01: LT returns status value of '63 00' in response to the first SELECT final. Case 02: LT returns status value of '63 00' in response to the first and second SELECT final Application Selection using PPSE. * PayPass reader shall send a FINAL SELECT for the MasterCard AID. * PayPass reader shall remove the MasterCard application from the candidate list upon reception of the 6300 status words and shall then switch back to the final selection process. * PayPass reader shall then send a FINAL SELECT for the Maestro extended AID. Case 01: the transaction goes until completion. The terminal capabilities must be instantiated with the terminal capabilities - no CVM required. The TVR shall indicate "amount over floor limit". Case 02: PayPass reader shall remove the Maestro application from the candidate list upon reception of the 6300 status words and shall then switch back to the final selection process. * PayPass reader shall then send a FINAL SELECT for the MasterCard extended AID. The transaction goes until completion. The terminal capabilities must be instantiated with the terminal capabilities - CVM required. The TVR shall indicate "amount NOT over floor limit". 132

157 M : FINALSELECT - Mandatory data objects missing To ensure that, if a data element, classified as mandatory, expected to be returned by the card is missing then the PayPass reader shall terminate the transaction [MCHIP] [MC v2.1]: [ ] * LT and PayPass reader have several mutually supported applications (at least 2). Case 01: LT response to final SELECT does not contain the FCI Data object 6F (entire data missing: TLV; LT returns only 9000 ) Case 02: LT response to final SELECT does not contain the DF Name Data object 84 (entire data missing: TLV) Case 03: LT response to final SELECT does not contain FCI Proprietary Template Data object (entire data missing: TLV) Case 04: LT response to final SELECT with SW 'EF EF' * Transaction outcome shall be set to "End application". M : FINALSELECT - Incorrectly formatted FCI To ensure that, if the Select AID FCI is not correctly formatted then the PayPass M/Chip reader shall terminate the transaction. [MCHIP] [MC v2.1]: [4.3.1 FCI and SW1-SW2 Processing] [ ] * LT and PayPass reader have several mutually supported applications (at least 2). * Candidate list is built via PPSE: PPSE card response includes several applications and SW=9000. * FCI of ADF template returned in response to SELECT ADF does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...). Application selection process is performed by the LT. The PayPass reader shall terminate the transaction 133

158 M : GetPO - Valid PDOL To ensure that the PayPass reader issues a GetPO command if PDOL is present in the FCI of the Application Definition File of the card with a data field populated with a constructed data object with a tag of '83', a length field with appropriate length and, a value field of concatenated data elements coded according to the PDOL. To ensure that the PayPass reader supports valid PDOL. [MCHIP] [MC v2.1]: [5.2 DOL Handling] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: PDOL contains TVR Case 02: PDOL returned by LT contains TVR and Terminal capabilities Case 03: PDOL returned by LT contains IFD serial number and TVR The LT shall receive a GetPO data field (associated to the GetPO command field) with the correct syntax: data object containing value fields of Data Object requested introduced by Tag '83' M : GetPO - All bits in TVR and CVM results are set to 0b (1) To ensure that all TVR and CVM Results bits are set to 0b when the PayPass reader starts the transaction. (1) [MCHIP] [MC v2.1]: [4.3.2 GetPO] [ ] * A first transaction is performed raising the TVR bits: Byte 2 bit 8 to bit4 (ICC have different application version, Expired Application, Application not yet effective, Requested service not allowed for card product), Byte 3 bit 8 to 7 (Cardholder verification not successful, Unrecognized CVM). * A second transaction is performed where the PDOL requests TVR and CVM Results. Application in LT is selected and transaction is processed with LT TVR and CVM Results returned by PayPass reader with GetPO shall be set to 0b in the second transaction. 134

159 M : GetPO - All bits in TVR are set to 0b (2) To ensure that all TVR bits are set to 0b when the PayPass reader starts the transaction. (2) [MCHIP] and [SDA] [MC v2.1]: [4.3.2 GetPO] [ ] [EMV 4.2b]: [2CJ ] Case 01: * A first transaction is performed raising the TVR bits: Byte 2 bit 8 to 5 (ICC have different application version, Expired Application, Application not yet effective, Requested service not allowed for card product), Byte 3 bit 8 to 7 (Cardholder verification not successful, Unrecognized CVM) and SDA failed after 1st GenerateAC * A second transaction is performed where the PDOL requests TVR. Case 02: * A first transaction is performed raising the TVR bits: Byte 1 bit 8 (Offline Data Authentication not performed) * A second transaction is performed where the PDOL requests TVR. Application in LT is selected and transaction is processed with LT TVR returned by PayPass reader with GetPO shall be set to 0b in the second transaction. M : GetPO - All bits in TVR are set to 0b (3) To ensure that all TVR bits are set to 0b when the PayPass reader starts the transaction. (3) [MCHIP] and [EXCEPT] [MC v2.1]: [4.3.2 GetPO] [ ] * A first transaction is performed raising the TVR bits: Byte 1 bit 5 (Card appears in exception file), Byte 2 bit 8 to -4 (ICC have different application version, Expired Application, Application not yet effective, Requested service not allowed for card product), Byte 3 bit 8 to -7 (Cardholder verification not successful Unrecognized CVM). * A second transaction is performed where the PDOL requests TVR. Application in LT is selected and transaction is processed with LT TVR returned by PayPass reader with GetPO shall be set to 0b in the second transaction. 135

160 M : GetPO - All bits in TVR are set to 0b (4) To ensure that all TVR bits are set to 0b when the PayPass reader starts the transaction. (4) [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [4.3.2 GetPO] [ ] [EMV 4.2b]: [2CJ ] Case 01: * A first transaction is performed raising the TVR bits: Byte 2 bit 8 to 5 (ICC have different application version, Expired Application, Application not yet effective, Requested service not allowed for card product), Byte 3 bit 8- to 7 (Cardholder verification not successful, Unrecognized CVM) and CDA failed after 1st GenerateAC * A second transaction is performed where the PDOL requests TVR. Case 02: * A first transaction is performed raising the TVR bits: Byte 1 bit 8 (Offline Data Authentication not performed) *A second transaction is performed where the PDOL requests TVR Application in LT is selected and transaction is processed with LT TVR returned by PayPass reader with GetPO shall be set to 0b in the second transaction. M : GetPO - All bits in TVR are set to 0b (5) To ensure that all TVR bits are set to 0b when the PayPass reader starts the transaction. (5) [ENC PIN ONLINE] and [MCHIP] [MC v2.1]: [4.3.2 GetPO] [ ] [EMV 4.2b]: [2CJ ] * A first transaction is performed raising the TVR bits: Byte 2 bit 8 to 5 (ICC have different application version, Expired Application, Application not yet effective, Requested service not allowed for card product), Byte 3 bit 3 (Online PIN entered). * A second transaction is performed where the PDOL requests TVR. Application in LT is selected and transaction is processed with LT TVR returned by PayPass reader with GetPO shall be set to 0b in the second transaction. 136

161 M : GetPO - All bits in TVR are set to 0b (6) To ensure that all TVR bits are set to 0b when the PayPass reader starts the transaction. (6) [MCHIP] [MC v2.1]: [4.3.2 GetPO] [ ] [EMV 4.2b]: [2CJ ] * A first transaction is performed raising the TVR bits: Byte 2 bit 8 to 5 (ICC have different application version, Expired Application, Application not yet effective, Requested service not allowed for card product), Byte 3 bit 8 to 7 (Cardholder verification not successful, Unrecognized CVM) Byte 4 bit 8 (transaction exceeds floor limit). * A second transaction is performed where the PDOL requests TVR. Application in LT is selected and transaction is processed with LT TVR returned by PayPass reader with GetPO shall be set to 0b in the second transaction. M : GetPO - Retrieval of AIP and AFL To ensure that the PayPass reader retrieves the AIP and AFL data objects from the data field of the GetPO response message. [MCHIP] [MC v2.1]: [2.4.3 Data Field Returned in the Response Message] * Response to GetPO contains valid AIP and AFL. * CDOL1 requests AIP. Application in LT is selected and transaction is performed with LT. * The PayPass reader shall accept the card and process the transaction until the end. * Value of AIP in GenerateAC command shall be in accordance with the value sent back by the LT. * LT shall receive READ RECORD commands in accordance to AFL. 137

162 M : GetPO - AIP B2b8=1 and PayPass - Mag Stripe indicator not set To ensure that the PayPass reader correctly continues the transaction, when the PayPass - Mag Stripe indicator is not set in the reader for the selected AID and the AIP indicates "M/Chip profile supported". [MCHIP] [MC v2.1]: [4.3.2 GetPO] [ ] * Maestro Application is selected in Final selection. * PayPass - Mag Stripe indicator is not set in the reader for the Maestro AID. * Perform test for Purchase and Refund transactions. PayPass reader shall continue the transaction until completion M : GetPO - AIP B2b8=0 and PayPass - Mag Stripe indicator not set To ensure that the PayPass reader terminates the transaction when the PayPass - Mag Stripe indicator is not set in the reader for the selected AID and the AIP indicates "M/Chip profile not supported". [MCHIP] [MC v2.1]: [4.3.2 GetPO] [ ] * Maestro Application is selected in Final selection. * PayPass - Mag Stripe indicator is not set in the reader for the Maestro AID. * The AIP has bit b8 in byte 2 set to 0b ("M/Chip profile not supported") * Perform test for Purchase and Refund transactions. PayPass reader shall terminate the transaction after the GetPO response. 138

163 M : GetPO - RFU bit set in AIP - MChip To ensure that the PayPass reader is able to process the AIP when RFU bits are set. [MCHIP] [MC v2.1]: [Data Objects Dictionary] * Response to GetPO contains valid AIP and AFL * AIP is 40 FF * IAC denial is returned by LT with value PayPass M/Chip transaction shall complete the transaction. Transaction outcome shall be set to "Approved" or "Online request" M : GetPO - AFL with an incorrect number of records participating in ODA To ensure that the PayPass reader terminates the transaction if an entry in AFL has an incorrect number of records participating in Offline Data Authentication. [MCHIP] [MC v2.1]: [Data Objects Dictionary] [page # 50] * The test has to be performed for M/Chip card. * Ending record number - start record number + 1<number of records participating in Offline Data Authentication * The PayPass reader terminates the transaction. * Transaction outcome shall be set to "End Application" 139

164 M : GetPO - Padding in format 1 response To ensure that the PayPass reader is able to recognize the data field returned by GetPO command, encoded according to format 1 and that a PayPass reader terminates transaction, if there are padding with bytes 0x00 between 2 Data Elements in the Template. [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CA ] Case 01: Response to GetPO contains valid AIP and AFL encoded with format 1 (Template 80), followed by 5 bytes of 00 value padding (within 80 template). Case 02: Response to GetPO contains valid AIP and AFL encoded with format 1 (Template 80), with 5 bytes of 00 value padding between AIP and AFL. Application in LT is selected and transaction is performed with LT. * Transaction outcome shall be set to "End application" M : GetPO - Padding in format 2 response To ensure that the PayPass reader is able to recognize the data field returned by GetPO command, encoded according to format 2 and that a PayPass reader ignores the padding, if there are padding with bytes 0x00 between 2 Data Elements. [MS v3.3]: [Inherits from EMV] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CA ] Case 01: Response to GetPO contains valid AIP and AFL encoded with format 2 (Template 77), followed by 10 bytes of '00' value padding (within 77 template). Case 02: Response to GetPO contains valid AIP and AFL encoded with format 2 (Template 77), with 50 bytes of 00 value padding between AIP and AFL. Application in LT is selected and transaction is performed with LT. * PayPass reader shall process the transaction until completion * Value of AIP in GenerateAC command shall be in accordance with the value sent back by the LT. * LT shall receive READ RECORD commands in accordance to AFL 140

165 M : ReadRecord - Pre-defined AFL - no ODA To ensure that if the card returns a pre-defined AFL and no ODA is to be performed then the PayPass reader sends the correct READ RECORD commands. [MCHIP] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ , , , ] * AIP of LT indicates No ODA is supported. Case 01: AFL is a pre-defined SDA AFL. Purchase and Refund transactions. Case 02: AFL is a pre-defined CDA AFL. Purchase and Refund transactions. * AIP of LT indicates SDA and CDA are supported. Case 03: AFL is a pre-defined SDA AFL. Refund transactions. Case 04: AFL is a pre-defined CDA AFL. Refund transactions. * Immediately after receiving a GetPO command the LT receives a READ RECORD command with the syntax: 00 B * Then the reader sends a GenerateAC command. 141

166 M : ReadRecord - Pre-defined AFL - SDA To ensure that if the card returns a pre-defined AFL and SDA is to be performed, then the PayPass reader sends the correct READ RECORD commands. [SDA] and [OFFLINE CAPABLE] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ , , , ] Case 01: - LT indicates that SDA is supported - LT indicates that CDA is not supported - AFL is a pre-defined SDA AFL. Case 02: - LT indicates that SDA is supported - LT indicates that CDA is not supported - AFL is a pre-defined CDA AFL. Immediately after GetPO the reader shall send: - a READ RECORD command with the syntax: 00 B a second READ RECORD command with the syntax: 00 B2 01 1C 00 - a third READ RECORD command with the syntax: 00 B2 02 1C 00 - then the reader sends a GenerateAC command. 142

167 M : ReadRecord - Pre-defined AFL - CDA To ensure that if the card returns a pre-defined CDA AFL and CDA is to be performed, then the PayPass reader sends the correct READ RECORD commands. [CDA] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ , , ] * AIP of LT indicates CDA supported (AIP byte 1 bit 1 = 1). * AFL is a pre-defined CDA AFL. Case 01: AIP of LT indicates SDA not supported (AIP byte 1 bit 7 =0). Case 02: AIP of LT indicates SDA supported (AIP byte 1 bit 7 =1). Immediately after GetPO the reader shall send: - a READ RECORD command with the syntax: 00 B a second READ RECORD command with the syntax: 00 B2 01 1C 00 - a third READ RECORD command with the syntax: 00 B a third READ RECORD command with the syntax: 00 B then the reader sends a GenerateAC command. M : ReadRecord - Pre-defined AFL Online only To ensure the PayPass reader reads only one record if reader does not support CDA nor SDA. [MCHIP] and [NO CDA] and [NO SDA] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ , , , ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: The AIP has bit b7 in byte 1 set to 1b ("Offline static data authentication is supported"). AFL is a pre-defined SDA AFL Case 02: The AIP has bit b1 in byte 1 set to 1b ("Combined DDA - GenerateAC is supported"). AFL is a pre-defined CDA AFL PayPass reader shall send only one read record 00 B

168 M : ReadRecord - Files containing multiple records (Non-M/Chip profile AFL) To ensure that if the AFL is not a pre-defined AFL, then the PayPass reader reads application data as specified in section 10.2 of [EMV BOOK 3]. To ensure that the PayPass reader is able to read data in file with several records using READ RECORD commands. [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CI ] * AFL is not a pre-defined AFL. * One Mandatory Data Element (PAN for instance) is located in first record of a file. * Another Mandatory Data Element (Expiration Date for Instance) is located in second record of same file. The PayPass reader shall process the transaction until completion by requesting a TC or an AAC. 144

169 M : ReadRecord - Length of Mandatory Data Objects: PAN To ensure that PayPass reader accepts the Application PAN with a variety of lengths up to 19 digits. [MCHIP] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * CDOL1 requests Application PAN. * 10 tests are performed with varying lengths of the Application PAN: * Case 01: LT contains PAN with length 5 bytes (CN 10). * Case 02: LT contains PAN with length 6 bytes (CN 11). * Case 03: LT contains PAN with length 6 bytes (CN 12). * Case 04: LT contains PAN with length 7 bytes (CN 13). * Case 05: LT contains PAN with length 7 bytes (CN 14). * Case 06: LT contains PAN with length 8 bytes (CN 15). * Case 07: LT contains PAN with length 8 bytes (CN 16). * Case 08: LT contains PAN with length 9 bytes (CN 17). * Case 09: LT contains PAN with length 9 bytes (CN 18). * Case 10: LT contains PAN with length 10 bytes (CN 19). * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * First GenerateAC will contain the PAN as read from the LT. 145

170 M : ReadRecord - Padding of Data Objects: Track 2 equivalent Data To ensure that PayPass reader accepts the Track 2 equivalent Data with a variety of lengths up to 19 bytes padded with 'F' when needed. [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CI ] * CDOL1 requests Track 2 Equivalent Data. * 4 tests are performed with varying lengths of the Track 2 equivalent Data: Case 01: LT contains Track 2 equivalent Data with 15 bytes length, 14.5 bytes used, with an 'F' padding at the end. Case 02: LT contains Track 2 equivalent Data with 16 bytes length, all bytes used, thus no padding. Case 03: LT contains Track 2 equivalent Data with 19 bytes length, 18.5 bytes used, with an 'F' padding at the end. Case 04: LT contains Track 2 equivalent Data with 19 bytes length, all bytes used, thus no padding. Application in LT is selected and transaction is processed with LT (in particular Read Application Data with padding). * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * First GenerateAC will contain the Track 2 Equivalent Data as read from the LT. 146

171 M : ReadRecord - Mandatory data - SDA tag list not in SFI2 - record 1 To ensure that the PayPass reader continue the transaction when SDA tag list present in any read record with any SFI [MCHIP] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: SDA tag list is present in Read record 1 with SFI2 Case 02: SDA tag list is present in Read record 1 with SFI2. AFL is the standard SDA PayPass AFL. SDA supported by LT. Case 03: SDA tag list is present in Read record 1 with SFI2. AFL is the standard CDA PayPass AFL. CDA supported by LT. Case 04: SDA tag list is present in Read record 1 with SFI2. AFL is the not standard SDA PayPass AFL. SDA supported by LT. Case 05: SDA tag list is present in Read record 1 with SFI2. AFL is not standard CDA PayPass AFL. CDA supported by LT. The PayPass reader shall continues the transaction until completion M : ReadRecord - Length coded on 2 bytes and data less than 128 To ensure that the PayPass reader completes the transaction when the read record length is coded on 2 bytes and data is less than 128 byte. [MCHIP] [MC v2.1]: [Field Issue] * Read record length is coded on 2 bytes where data is less than 128 byte Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * Transaction outcome shall be set to Approved 147

172 M : ReadRecord - Data objects processing (Unrecognized Data Objects) To ensure that the PayPass reader ignores unrecognized Data Objects read during the Read Application Data phase. [MCHIP] [MC v2.1]: [Inherits from EMV Inherits from EMV] [EMV 4.2b]: [2CJ ] * Records to be read contain non-emv Data Objects. The PayPass reader shall accept the card and process the transaction until completion by requesting a TC or an AAC. M : ReadRecord - Mandatory data missing - PAN To ensure that the PayPass reader shall terminate the transaction if the mandatory data object Application Primary Account Number (PAN) is not present. [MCHIP] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] Case 01: LT does not contain PAN (entire data missing: TLV). AFL is a pre-defined AFL. Case 02: LT contains PAN with a zero length. AFL is a non-pre-defined AFL. Case 03: PAN is returned in the Select ADF BF0C and not in read record. AFL is a predefined AFL. Case 04: PAN is returned in the Select PPSE BF0C and not in read record. AFL is a nonpre-defined AFL. Transaction outcome shall be set to End application 148

173 M : ReadRecord - Mandatory data missing - CDOL1 To ensure that the PayPass reader shall terminate the transaction if the mandatory data object CDOL1 is not present. [MCHIP] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: LT does not contain CDOL1 data object (entire data missing: TLV). AFL is a predefined AFL. Case 02: LT contains CDOL1 with a length equal to zero. AFL is a non pre-defined AFL. Transaction outcome shall be set to "End application". M : ReadRecord - Mandatory data missing - Application Expiration Date To ensure that the PayPass reader shall terminate the transaction if the mandatory data object Application Expiration Date is not present. [MCHIP] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: LT does not contain Application Expiration Date data object (entire data missing: TLV). AFL is a pre-defined AFL. Case 02: LT contains Application Expiration Date with a length equal to zero. AFL is a non pre-defined AFL. Transaction outcome shall be set to End Application 149

174 M : ReadRecord - Mandatory data missing - SDA tag list To ensure that the PayPass reader terminates the transaction if the SDA tag list is missing. [MCHIP] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * SDA tag list is missing in LT. Case 01: Tag not present. AFL is the standard SDA PayPass AFL. SDA supported by LT. Case 02: Tag not present. AFL is the standard CDA PayPass AFL. CDA supported by LT. Case 03: Tag not present. AFL is the standard SDA PayPass AFL. SDA and DDA and CDA NOT supported by LT. Case 04: Tag not present. AFL is NOT the standard SDA PayPass AFL. SDA supported by LT. Case 05: Tag not present. AFL is NOT the standard CDA PayPass AFL. CDA supported by LT. Case 06: Tag not present. AFL is NOT the standard PayPass AFL. SDA and CDA and CDA NOT supported by LT. Case 07: Tag present but length zero * The PayPass reader shall terminate the transaction after all Read Record. * Outcome of the transaction shall be "End Application" 150

175 M : ReadRecord - Duplication of data objects (MChip) To ensure that the PayPass reader terminates the transaction if a Data Object is duplicated. [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CJ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: PAN is duplicated in LT Case 02: Expiration Date is duplicated in LT Case 03: AUC is duplicated in LT Case 04: Issuer Public Key Exponent is duplicated in LT Case 05: CDOL1 is duplicated in LT The PayPass reader shall terminate the transaction. M : Processing restrictions - AVN, AUC and Expired Application To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that the PayPass reader performs processing restrictions functions at some time after Read Application Data and before completion of the Terminal action analysis process. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Application Version Number is different in LT and PayPass reader. * Issuer Country Code matches Terminal Country Code. * Transaction is not valid for domestic in AUC. * Application Expiration Date in the LT has passed. * The PayPass reader shall process the transaction until completion. * TVR byte 2, bit 8 = '1' (i.e. ICC and PayPass reader have different application versions) received at 1st GenerateAC. * TVR byte 2, bit 5 = '1' (i.e. Requested service not allowed for card product) received at 1st GenerateAC. * TVR byte 2, bit 7 = '1' (i.e. Expired application) received at 1st GenerateAC. 151

176 M : Processing restrictions - Processing the Year To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 4]. To ensure that the PayPass reader is able process 2 digits year correctly [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: Application Expiration Date with year 00 Case 02: Application Expiration Date with year 10 Case 03: Application Expiration Date with year 49 Case 04: Application Expiration Date with year 50 Case 05: Application Expiration Date with year 67 Case 06: Application Expiration Date with year 99 * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 7 shall be set according to the Application Expiration Dates ('1' if before the current date, '0' if after the current date), received at 1st GenerateAC. 152

177 M : Processing restrictions - Calculation, Storage, and Display Date-Dependant Fields For Year To ensure that the PayPass reader is able to accurately calculate and store date dependent fields representing the year 2000 [MCHIP] and [IDM] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * CDOL1 requests Transaction Date and Transaction Time Case 01: Terminal Date is set to 31/12/ h 59min Case 02: Terminal Date is set to 28/02/ h 59min Case 03: Terminal Date is set to 28/02/ h 59min The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. Transaction Date shall have been updated to correct value: * 01/01/2021 * 01/03/2013 * 29/02/

178 M : Processing restrictions - Calculation of Dates To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 4]. To ensure that the PayPass reader is capable of properly calculating date associated with processing restrictions for dates before, including, and after the year 2000 [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: Application Expiration Date is Case 02: Application Expiration Date is Case 03: Application Expiration Date is Case 04: Application Effective Date is Case 05: Application Effective Date is Case 06: Application Expiration Date is Case 07: Application Expiration Date is Case 08: Application Expiration Date is Case 09: Application Effective Date is Case 10: Application Effective Date is Case 11: Application Effective Date is Case 12: Application Effective Date is * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 7 shall be set according to the Application Expiration Dates ('1' if the current date is after the expiration date, '0' if the current date is before the expiration date), received at 1st GenerateAC. * TVR byte 2, bit 6 shall be set according to the Application Effective Dates ('0' if the current date is after the effective date, '1' if the current date is before the effective date), received at 1st GenerateAC. 154

179 M : Processing restrictions - Current Date is later than Application Expiration Date To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that the PayPass reader sets the 'expired Application' bit in TVR to 1b, if the current date is later than the Application Expiration Date. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Current date is later than the Application Expiration Date. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 7 = '1' (i.e. expired Application) received at 1st GenerateAC. M : Processing restrictions - Current date is later than expiration date(leap year date) To ensure that the PayPass reader sets the 'expired Application' bit in TVR to 1b, if the current date is later than expiration date(leap year date) [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] Card expiration date is set to 29 Feb 2004 Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 7 = '1' (expired Application) received at 1st GenerateAC. 155

180 M : Processing restrictions - Current Date is equal to the Application Expiration Date To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that the PayPass reader does not set the 'expired Application' bit in TVR to 1b, if the current date is earlier or equal to the Application Expiration Date. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Current date is equal to the Application Expiration Date. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 7 = '0' (i.e. non expired Application) received at 1st GenerateAC. M : Processing restrictions - Current Date equal to expiration date(leap year) To ensure that the PayPass reader does not set the 'expired Application' bit in TVR to 1b, if the expiration date is equal to the current date(leap year) [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] Terminal date is set to 29 Feb 2012 Card expiration date is set to 29 Feb 2012 Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 7 = '0' (non expired Application) received at 1st GenerateAC 156

181 M : Processing restrictions - Current Date is earlier than Application Expiration Date To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that the PayPass reader does not set the 'expired Application' bit in TVR to 1b, if the current date is earlier or equal to the Application Expiration Date. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Current date is earlier than the Application Expiration Date. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 7 = '0' (i.e. non expired Application) received at 1st GenerateAC. M : Processing restrictions - Current date is earlier than expiration date To ensure that the PayPass reader does not set the 'expired Application' bit in TVR to 1b, if the expiration date is later than the current date(leap year) [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] Card expiration date is set to 29 Feb 2012 Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 7 = '0' (non expired Application) received at 1st GenerateAC. 157

182 M : Processing restrictions - Current Date is earlier than Application Effective Date To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that the PayPass reader sets 'Application not yet effective' bit in TVR to 1b the, if the current date is earlier than the Application Effective Date. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Application Effective Date is present in the LT. * Current date is earlier than the Application Effective Date. * The PayPass reader shall process the transaction until completion by requesting a TC or an AAC. * TVR byte 2, bit 6 = '1' (i.e. Application not yet effective) received at 1st GenerateAC. M : Processing restrictions - Current Date is equal to Application Effective Date To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that the PayPass reader does not set 'Application not yet effective' bit in TVR to 1b, if the current date is later or equal to the Application Effective Date. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Application Effective Date is present in the LT. * Current data is equal to the Application Effective Date. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 6 = '0' (i.e. Application effective) received at 1st GenerateAC. 158

183 M : Processing restrictions - Current Date is later than Application Effective Date(implied) To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that the PayPass reader does not set 'Application not yet effective' bit in TVR to 1b, if the current date is later or equal to the Application Effective Date. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Application Effective Date is present in the LT. * Current date is later than the Application Effective Date. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 6 = '0' (i.e. Application effective) received at 1st GenerateAC. M : Processing restrictions - Effective date out of range To ensure that the PayPass reader terminates the transaction if dates provided by the card are out of range - effective date [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: Month of the date is 13 Case 02: Month of the date is 00 Case 03: Month of the date is 99 Case 04: Day of the date is 00 Case 05: Day of the date is 32 Case 06: Day of the date is 99 Case 07: Date is (31 February 2012) Application in LT is selected and transaction is processed with LT Transaction outcome shall be set to "End Application" 159

184 M : Processing restrictions - Expiration Date out of range To ensure that the PayPass reader terminates the transaction if dates provided by the card are out of range - expiration date [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) Case 01: Month of the date is 13 Case 02: Month of the date is 00 Case 03: Month of the date is 99 Case 04: Day of the date is 00 Case 05: Day of the date is 32 Case 06: Day of the date is 99 Case 07: Date is (31 February 2006) Transaction outcome shall be set to End Application M : Processing restrictions - PayPass reader Checks Presence of card in Exception file To ensure that the PayPass reader performs the Terminal Risk Management function specified in [EMV BOOK 4]. To ensure that if the PayPass reader has an exception file, the PayPass reader checks the presence of the application selected in the exception file and does not set the 'Card appears in Exception file' bit in the TVR to 1b, if no match is found with the current PAN [EXCEPT] and [MCHIP] [MC v2.1]: [4.3.9 Terminal Risk Management] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: Exception File does not contain the PAN of LT Case 02: Exception File does not contain the PAN sequence number of LT * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 1, bit 5 = '0' (i.e. Card does not appear in Exception file, received at 1st GenerateAC. 160

185 M : Processing restrictions - TVR Set if Match is Found in Exception File To ensure that if the PayPass reader has an exception file, the PayPass reader sets the 'Card appears in Exception file' bit in the TVR to 1b, if a match is found with the current PAN [EXCEPT] and [MCHIP] [MC v2.1]: [4.3.9 Terminal Risk Management] [ ] * The PayPass reader exception file contains data also represented in the LT (I.e. PAN and PAN Sequence Number) * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 1, bit 5 = '1' (i.e. Card appears in Exception file) received at 1st GenerateAC M : Processing restrictions - AVN assigned by the payment system To ensure that the PayPass reader maintains an Application Version Number assigned by the payment system. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * CDOL1 requests Application Version Number (9F 09). * Test is made for all applications supported by the PayPass reader. * The PayPass reader shall process the transaction until completion. * LT shall receive the value of application version number for the selected application. 161

186 M : Processing restrictions - AVN same To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that the PayPass reader does not set the ' ICC and PayPass reader have different application versions' bit in the TVR to 1b if the Application Version Number present in the ICC and in the PayPass reader are the same. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * LT and PayPass reader have the same Application Version Number. * The PayPass reader shall process the transaction until completion. * TVR byte 2, bit 8 = '0' (i.e. ICC and PayPass reader have the same application versions) received at 1st GenerateAC. M : Processing restrictions - Card and PayPass reader AVN are different To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 4]. To ensure that if the card and PayPass reader Application Version Numbers are different, the PayPass reader attempts to continue processing the transaction. If it is unable to continue, the PayPass reader aborts the transaction. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * LT and PayPass reader have different Application Version Number * The PayPass reader shall attempt to process the transaction until completion, by requesting a TC or an AAC, if unable the PayPass reader shall abort the transaction. * TVR byte 2, bit 8 = '1' (i.e. ICC and PayPass reader have different application versions) received at 1st GenerateAC. 162

187 M : Processing restrictions - AVN missing To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that the PayPass reader continues processing the transaction until the end if Application Version Number is not present in the ICC. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Application Version Number is not present in the LT. * The PayPass reader shall process the transaction until completion. * The PayPass reader shall presume applications are compatible between ICC and PayPass reader. * TVR byte 2, bit 8 = '0' (i.e. ICC and PayPass reader does not have different application versions) received at 1st GenerateAC. M : Processing restrictions - AUC missing To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that if the Application Usage control is not present in the ICC, the PayPass reader does not set the 'Requested service not allowed for card product' bit in the TVR to 1b. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * AUC is not present in LT. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '0' (i.e. Requested service allowed for card product) received at 1st GenerateAC. 163

188 M : Processing restrictions - AUC valid at ATM and other than ATM To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that if the Application Usage control is present in the ICC but not Issuer Country Code, the PayPass reader skips the second set of tests described in EMV Book 3 Section [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * AUC is present in LT. * 'valid at ATMs' and 'valid at PayPass readers other than ATMs' are set in AUC. * Issuer Country Code is not present in the LT. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '0' (i.e. Requested service allowed for card product) received at 1st GenerateAC. 164

189 M : Processing restrictions - ICC match with TCC,'Valid for domestic goods set to 1 in AUC' To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that if the Terminal Country Code matches Issuer Country Code, Transaction Type indicates a purchase of goods and services, the AUC is present in the card, and the 'Valid for domestic goods' bit is set to 1b in the AUC, the PayPass reader does not set the 'Requested service not allowed for card product' bit in the TVR to 1b. [GOODS] or [SERVICES] and [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Transaction is a purchase of goods or services (Transaction type is '00') * AUC is present in LT. * Issuer Country Code matches Terminal Country Code. * 'Valid for domestic goods' bit is set to 1b in the AUC. * Valid for international services bit is not set to 1b in the AUC. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '0' (i.e. Requested service allowed for card product) received at 1st GenerateAC. * Transaction Type shall indicate a purchase of goods and services. 165

190 M : Processing restrictions - ICC match with TCC,'Valid for domestic services set to 1 in AUC' To ensure that if the Terminal Country Code matches Issuer Country Code, Transaction Type indicates a purchase of goods and services, the AUC is present in the card, and the 'Valid for domestic services' bit is set to 1b in the AUC, the PayPass reader does not set the 'Requested service not allowed for card product' bit in the TVR to 1b. [GOODS] or [SERVICES] and [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Transaction is a purchase of goods or services. * AUC is present in LT. * Issuer Country Code matches Terminal Country Code. * 'Valid for domestic services' bit is set to 1b in the AUC. * Valid for domestic goods bit is not set to 1b in the AUC. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '0' (i.e. Requested service allowed for card product) received at 1st GenerateAC. * Transaction Type shall indicate a purchase of goods and services. 166

191 M : Processing restrictions - No match with ICC and TCC 'Valid for international goods set to 1 in AUC' To ensure that if the Terminal Country Code does not match Issuer Country Code, Transaction Type indicates a purchase of goods and services, the AUC is present in the card, and the 'Valid for international goods' bit is set to 1b in the AUC, the PayPass reader does not set the 'Requested service not allowed for card product' bit in the TVR to 1b. [GOODS] or [SERVICES] and [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] [EMV 4.2b]: [2CJ ] * Transaction is a purchase of goods or services. * AUC is present in LT. * Issuer Country Code does not match Terminal Country Code. * 'Valid for international goods' bit is set to 1b in the AUC. * Valid for international services bit is not set to 1b in the AUC. Case 01: Transaction is a purchase of goods. Case 02: Transaction is a purchase of services * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '0' (i.e. Requested service allowed for card product) received at 1st GenerateAC. * Transaction Type shall indicate a purchase of goods and services. 167

192 M : Processing restrictions - No match with ICC and TCC 'Valid for international services set to 1 in AUC' To ensure that if the Terminal Country Code does not match Issuer Country Code, Transaction Type indicates a purchase of goods and services, the AUC is present in the card, and the 'Valid for international services' bit is set to 1b in the AUC, the PayPass reader does not set the 'Requested service not allowed for card product' bit in the TVR to 1b. [GOODS] or [SERVICES] and [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Transaction is a purchase of goods or services. * AUC is present in LT. * Issuer Country Code does not match Terminal Country Code. * 'Valid for international services' bit is set to 1b in the AUC. * Valid for international goods bit is not set to 1b in the AUC. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '0' (i.e. Requested service allowed for card product) received at 1st GenerateAC. * Transaction Type shall indicate a purchase of goods and services. 168

193 M : Processing restrictions - No match with ICC and TCC 'Valid for international goods not set to 1 in AUC' To ensure that if the Terminal Country Code does not match Issuer Country Code, Transaction Type indicates a purchase of goods and services, the AUC is present in the card, and the 'Valid for international goods' bit is not set to 1b in the AUC, the PayPass reader sets the 'Requested service not allowed for card product' bit in the TVR to 1b. [GOODS] or [SERVICES] and [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Transaction is a purchase of goods or services. * AUC is present in LT. * Issuer Country Code does not match Terminal Country Code. * 'Valid for international goods' bit is not set to 1b in the AUC. * Valid for international services bit is not set to 1b in the AUC. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '1' (i.e. Requested service not allowed for card product) received at 1st GenerateAC. * Transaction Type shall indicate a purchase of goods and services. 169

194 M : Processing restrictions - No match with ICC and TCC 'Valid for international services not set to 1 in AUC' To ensure that if the Terminal Country Code does not match Issuer Country Code, Transaction Type indicates a purchase of goods and services, the AUC is present in the card, and the 'Valid for international services' bit is not set to 1b in the AUC, the PayPass reader sets the 'Requested service not allowed for card product' bit in the TVR to 1b. [GOODS] or [SERVICES] and [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Transaction is a purchase of goods or services. * AUC is present in LT. * Issuer Country Code does not match Terminal Country Code. * 'Valid for international services' bit is not set to 1b in the AUC. * 'Valid for international goods bit is set to 1b in the AUC. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '1' (i.e. Requested service not allowed for card product) received at 1st GenerateAC. * Transaction Type shall indicate a purchase of goods and services. 170

195 M : Processing restrictions - ICC match with TCC,'Valid for domestic goods not set to 1 in AUC' To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that if the Terminal Country Code matches Issuer Country Code, Transaction Type indicates a purchase of goods and services, the AUC is present in the card, and the 'Valid for domestic goods' bit is not set to 1b in the AUC, the PayPass reader sets the 'Requested service not allowed for card product' bit in the TVR to 1b. [GOODS] or [SERVICES] and [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Transaction is a purchase of goods and services. * AUC is present in LT. * Issuer Country Code matches Terminal Country Code. * 'Valid for domestic goods' bit is not set to 1b in the AUC. * Valid for domestic services bit is not set to 1b in the AUC. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '1' (i.e. Requested service not allowed for card product) received at 1st GenerateAC. * Transaction Type shall indicate a purchase of goods and services. 171

196 M : Processing restrictions - ICC match with TCC,'Valid for domestic services not set to 1 in AUC' To ensure that if the Terminal Country Code matches Issuer Country Code, Transaction Type indicates a purchase of goods and services, the AUC is present in the card, and the 'Valid for domestic services' bit is not set to 1b in the AUC, the PayPass reader sets the 'Requested service not allowed for card product' bit in the TVR to 1b. [GOODS] or [SERVICES] and [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * Transaction is a purchase of goods or services. * AUC is present in LT. * Issuer Country Code matches Terminal Country Code. * 'Valid for domestic services' bit is not set to 1b in the AUC. * Valid for domestic goods bit is set to 1b in the AUC. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '1' (i.e. Requested service not allowed for card product) received at 1st GenerateAC. * Transaction Type shall indicate a purchase of goods and services. 172

197 M : Processing restrictions - AUC set to 'Not valid for other than ATM' To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that if the PayPass reader is not an ATM, the AUC is present in the card, and the 'Valid at PayPass reader other than ATMs ' bit is not set to 1b in the AUC, the PayPass reader sets the 'Requested service not allowed for card product' bit in the TVR to 1b. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * AUC is present in LT. * 'Valid at PayPass readers other than ATMs' bit is not set to 1b in the AUC. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '1' (i.e. Requested service not allowed for card product) received at 1st GenerateAC. M : Processing restrictions - AUC set to 'Valid for other than ATM' To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 3]. To ensure that if the PayPass reader is other than ATM, the AUC is present in the card, and the 'Valid at PayPass reader other than ATMs ' bit is set to 1b in the AUC, the PayPass reader does not set the 'Requested service not allowed for card product' bit in the TVR to 1b. [MCHIP] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * AUC is present in LT. * 'Valid at PayPass readers other than ATMs' bit is set to 1b in the AUC. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 2, bit 5 = '0' (i.e. Requested service allowed for card product) received at 1st GenerateAC. 173

198 M : Terminal Risk Management - Terminal Risk Management bit in AIP To ensure that the PayPass reader performs Risk Management at sometime after Read Application Data and prior to the issuing of the first GenerateAC command. [MCHIP] [MC v2.1]: [4.3.9 Terminal Risk Management] [ ] * Transaction Amount is above Terminal floor Limit * CDOL1 requests Amount Authorized Numeric Case 01: * AIP of LT indicates TRM to be performed (AIP byte 1 bit 4 = 1). Case 02: * AIP of LT indicates TRM NOT to be performed (AIP byte 1 bit 4 = 0). Application in LT is selected and transaction is performed with LT. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 4, bit 8 = '1' (i.e. Transaction exceeds floor limit) received at 1st GenerateAC. M : CVM selection - Cardholder Verification is supported in the AIP To ensure that if the card supports Cardholder verification (AIP indicates Cardholder Verification supported), the PayPass reader performs Cardholder verification after the Read Application Data and before completion of the Terminal analysis process. To ensure that the PayPass reader sets the 'Cardholder verification was not successful' bit in TVR to 1b, if the list of CVMs is exhausted and Cardholder Verification has not been successful. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM, always' (00 00). * The PayPass reader shall process the transaction until completion, by requesting a TC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * Transaction CVM set to "NO CVM" * CVM Results shall be set to " ''. 174

199 M : CVM selection - Supported CVM To ensure that CVM supported by the PayPass reader are indicated in Terminal Capabilities [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ a] * PDOL requests Terminal capabilities * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * Terminal Capabilities returned by PayPass reader shall reflect the CVM supported by the PayPass reader. M : CVM selection - CVM condition-always To ensure that PayPass reader supports CVM condition 'Always' [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1) * CVM in LT is 'Fail CVM, always' (00 00). * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * CVM Results shall be set to " '' * Transaction CVM set to 'No CVM'. 175

200 M : CVM selection - Condition not satisfied To ensure that if the conditions expressed in the second byte of a Cardholder Verification Rule are not satisfied, the PayPass reader bypasses the rules and proceeded to the next rule. To ensure that the PayPass reader sets the CVM Results byte 3 to 'failed' when the last CVM performed was not considered as successful. To ensure that if the CVM List is present in the ICC, the PayPass reader processes each rule in the order in which it appears in the CVM List, until the cardholder verification process is completed. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ a] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * All cases below must be run for amount below and above the CVM limit * CVM List is 'Fail CVM, (associated condition described in below sub-cases) followed by 'Fail CVM, always' (00 00). Case 01: condition is if unattended cash (00 01) and transaction is not cash. Case 02: condition is if unattended cash (5F 01) and transaction is not cash. Case 03: [Attended Terminal] supported - condition is if unattended cash (00 01). Case 04: condition is if supported and the code is not supported (01 03)*. Case 05: condition is if supported and the code is not supported (03 03)*. Case 06: condition is if supported and the code is not supported (05 03)*. Case 07: condition is if supported and the code is not supported (44 03)*. Case 08: condition is if supported and the code is not supported (30 03)*. Case 09: condition is if supported and the code is not supported (FF 03)*. Case 10: condition is manual cash (1F 04) and transaction is not cash. Case 11: condition is manual cash (40 04) and transaction is not cash. Case 12: [Unattended Terminal] supported - condition is manual cash (00 04). Case 13: condition is purchase with cashback (1E 05) and transaction is not cashback. Case 14: condition is if transaction is under X' (00 06) and amount is over X. Case 15: condition is if transaction is over X' (02 07) and amount is under X. Case 16: condition is if transaction is under Y' (1F 08) and amount is over Y. Case 17: condition is if transaction is over Y' (00 09) and amount is under Y. * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 7 = '0' (i.e. Unrecognized CVM) received at 1st GenerateAC. * CVM result =' '. * Transaction CVM is set to "No CVM". As per EMV4.2 Book3 Figure 8, the condition 03 is considered as not satisfied in case the CVM code is not supported. 176

201 M : CVM selection - Condition If supported and code not supported (Online PIN) To ensure that PayPass reader processes the next CVM in the list when the CVM condition is 'If terminal supports the CVM', when CVM is Online PIN and the PayPass reader does not support online Enciphered PIN. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ a] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CDOL1 requests CVM Results. * Tests are performed below and above (if applicable) the CVM limit Case 01: CVM in LT is 'Online Enciphered PIN verification performed by ICC if reader supports the CVM' (02 03) followed by 'Fail CVM, always' (00 00). Case 02: CVM in LT is 'Online Enciphered PIN verification performed by ICC if reader supports the CVM' (42 03) followed by 'Fail CVM, always' (00 00). * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 3 = '0' (i.e. Online PIN not entered) received at 1st GenerateAC. * CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed (' '). * Transaction CVM set to "No CVM" This test is applicable to all readers because only no CVM must be supported below the CVM limit. 177

202 M : CVM selection - Condition If supported and code not supported (Signature) To ensure that PayPass reader processes the next CVM in the list when the CVM condition is 'If reader supports the CVM', when CVM is Signature and the PayPass reader does not support Signature. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ a] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CDOL1 requests CVM Results. * Tests are performed below and above (if applicable) the CVM limit Case 01: CVM in LT is 'Signature if reader supports the CVM' (1E 03) followed by 'Fail CVM, always' (00 00). Case 02: CVM in LT is 'Signature if reader supports the CVM' (5E 03) followed by 'Fail CVM, always' (00 00). * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed (' '). * Transaction CVM set to "No CVM" This test is applicable to all readers because only no CVM must be supported below the CVM limit. 178

203 M : CVM selection - no condition satisfied and no more CVRs To ensure that if there is no condition satisfied and no more CVRs, then the PayPass reader sets the Transaction CVM to "nocvm" and sets the "cardholder verification not successful" bit in the TVR. It sets CVM Results byte 1 to 'No CVM performed' and byte 3 to "failed". [MCHIP] [MC v2.1]: [ d] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM list in LT is FF FF FF FF FF FF FF FF F 7F Case 01: amount is below the CVM limit Case 02: amount is above the CVM limit * The PayPass reader shall process the transaction until completion. * Transaction CVM is set to 'No CVM' * B3b8(Card holder verification not successful) set to 1 received at First GenerateAC * CVM Results ('3F 00 01') 179

204 M : CVM selection - If Transaction is under X value when the transaction amount = X To ensure that PayPass reader supports CVM condition "If Transaction is in the application currency and is under X value" when the transaction amount is Equal to X. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM, if Transaction is in the application currency under X' value (00 06) followed by 'Fail CVM, always' (00 00). * Transaction amount is equal to X value. * Transaction Currency Code equals Application Currency Code. * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed (' '). * Transaction CVM set to "No CVM". 180

205 M : CVM selection - If Transaction is over X value when transaction amount = X. To ensure that PayPass reader supports CVM condition "If Transaction is in the application currency and is over X value" when transaction amount is Equal to X. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM, if Transaction is in the application currency and is over X' value (00 07) followed by 'Fail CVM, always' (00 00). * Transaction amount is equal to X value. * Transaction Currency Code equals Application Currency Code. * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed (' '). * Transaction CVM is set to "No CVM". 181

206 M : CVM selection - If Transaction is under Y value when the transaction amount = Y To ensure that PayPass reader supports CVM condition is 'If Transaction is in the application currency and is under Y value' when the transaction amount is equal to Y. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM, if Transaction is in the application currency and is under Y' value (00 08) followed by 'Fail CVM, always' (00 00). * Transaction amount is equal to Y value. * Transaction Currency Code equals Application Currency Code. * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed (' '). * Transaction CVM set to "No CVM". 182

207 M : CVM selection - If Transaction is over Y value when the transaction amount = Y To ensure that PayPass reader supports CVM condition is 'If Transaction is in the application currency and is over Y value' when the transaction amount is equal to Y. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM, if Transaction is in the application currency and is over Y' value (00 09) followed by 'Fail CVM always' (00 00). * Transaction amount is equal to Y value. * Transaction Currency Code equals Application Currency Code. * The PayPass reader shall process the transaction until completion * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed (' '). * Transaction CVM set to "No CVM". 183

208 M : CVM selection - If unattended Cash and transaction is not cash To ensure that PayPass reader processes the next CVM in the list when the CVM condition is 'If unattended cash' when transaction type is not cash. [ATTENDED] and [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM If unattended cash' (00 01) followed by 'Fail CVM, always' (00 00). * Transaction type is not cash. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification unsuccessful) received at 1st GenerateAC. * CVM Result = ( ) * Transaction CVM shall be set to "No CVM" 184

209 M : CVM selection - If manual cash, and transaction is not manual cash To ensure that PayPass reader processes the next CVM in the list when the CVM condition is 'If manual cash' when transaction type is not manual cash. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM If manual cash' (00 04) followed by 'Fail CVM, always' (00 00). * Transaction type is not cash. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification unsuccessful) received at 1st GenerateAC. * CVM Result = ( ) * Transaction CVM shall be set to "No CVM" 185

210 M : CVM selection - CVM processing fails and CVR indicates to proceed with next rule To ensure that the PayPass reader processes next CVR in the CVM List, if the current one is not successful and the 'Apply succeeding Cardholder Verification Rule if this CVM is unsuccessful' bit is set to 1b [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). Case 01: CVM in LT is 'Plaintext PIN verification performed by ICC, Always' (41 00) followed by 'Fail CVM, always' (00 00). Case 02: [Signature] not supported - CVM in LT is 'Signature, Always' (5E 00) followed by 'Fail CVM, always' (00 00). Case 03: [Enciphered Pin Online] not supported - CVM in LT is 'Online PIN, Always' (42 00) followed by 'Fail CVM, always' (00 00) * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification unsuccessful) received at 1st GenerateAC. * CVM Result = ( ) * Transaction CVM is set to "No CVM" 186

211 M : CVM selection - If unattended Cash and transaction is not cash To ensure that PayPass reader processes the next CVM in the list when the CVM condition is 'If unattended cash' when transaction is not cash [MCHIP] and ([GOODS] or [SERVICES]) [MC v2.1]: [ M/Chip CVM Selection] [ a] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM If unattended cash' (00 01) followed by 'Fail CVM, always' (00 00). Case 01: [Goods] supported - Transaction is goods Case 02: [Services] supported - Transaction is services * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification unsuccessful) received at 1st GenerateAC. * CVM Result = ( ) * Transaction CVM is set to "No CVM" 187

212 M : CVM selection - If manual cash, and transaction is not manual cash To ensure that PayPass reader processes the next CVM in the list when the CVM condition is 'If manual cash' when transaction is not manual cash. [ATTENDED] and [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ a] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM If manual cash' (00 04) followed by 'Fail CVM, always' (00 00). Case 01: [Goods] supported - Transaction is goods Case 02: [Services] supported - Transaction is services * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification unsuccessful) received at 1st GenerateAC. * CVM Result = ( ) * Transaction CVM is set to "No CVM" 188

213 M : CVM selection - If purchase with cashback, and transaction is not purchase with cashback To ensure that PayPass reader processes the next CVM in the list when the CVM condition is 'If purchase with cashback' when transaction is not purchase with cashback. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ a] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM If purchase with cashback' (00 05) followed by 'Fail CVM, always' (00 00). Case 01: [Goods] supported - Transaction is goods Case 02: [Services] supported - Transaction is services * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification unsuccessful) received at 1st GenerateAC. * CVM Result = ( ) * Transaction CVM is set to "No CVM" 189

214 M : CVM selection - RFU bit setting in CVM List To ensure that, if the conditions or the code expressed in the CVM list are outside the range, then the PayPass reader bypasses the rule and proceeds to the next CVR in the CVM List. If there are no more CVRs in the list, cardholder verification fails. [MCHIP] [MC v2.1]: [ c] * Cardholder Verification Method (CVM) List is present in the LT. * Tests performed for cases where Cardholder Verification Method (CVM) List contains the entry: Condition is satisfied: Case 01: 'RFU, always' ('06 00'). Case 02: 'RFU, always' ('07 00'). Case 03: 'RFU, always' ('1D 00'). Code is satisfied: Case 04: 'No CVM required, RFU' ('1F 0A') Case 05: 'No CVM required, RFU' ('1F 2F'). Case 06: 'No CVM required, RFU' ('1F 4F'). Case 07: 'No CVM required, RFU' ('1F 7F'). * The PayPass reader shall process the transaction until completion. * Cardholder verification fails. * Transaction CVM shall be set to "No CVM" Case 01-03: * TVR B3b7 shall be set to 1 190

215 M : CVM selection - CVM processing fails and no more CVRs in the CVM List To ensure that the PayPass reader fails the Cardholder verification and sets the 'Cardholder verification was not successful' bit in the TVR to 1b, if a CVM processing fails, the 'Apply succeeding Cardholder Verification Rule if this CVM is unsuccessful' bit is set to 1b, and there are no more Cardholder Verification Rules in the CVM List. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM, always' (40 00) * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification was not successful) received at 1st GenerateAC. * CVM Result = * Transaction CVM is set to "No CVM" 191

216 M : CVM selection - CVM processing fails and CVR indicates to not proceed with next rule To ensure that the PayPass reader fails the Cardholder verification and sets the 'Cardholder verification was not successful' bit in the TVR to 1b, if a CVM processing fails, and the 'Apply succeeding Cardholder Verification Rule if this CVM is unsuccessful' bit is not set to 1b. To ensure that if the CVM List is present in the ICC, the PayPass reader processes each rule in the order in which it appears in the CVM List, until the cardholder verification process is completed. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). Case 01: [Signature] not supported - CVM in LT is 'Signature Always' ('Apply succeeding Cardholder Verification Rule if this CVM is unsuccessful' bit is not set to 1b) (1E 00) followed by 'No CVM required, if transaction is under X' (1F 06) Case 02: CVM in LT is 'Fail CVM, Always' (00 00) followed by 'Signature, always' (1E 00) * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification was not successful) received at 1st GenerateAC. * Transaction CVM shall be set to "No CVM". * CVM Result =3F for case 1 * CVM Result = for case 2 192

217 M : CVM selection - Condition satisfied and Code is supported (No CVM) To ensure that the CVM is successful when the CVM code is 'No CVM required' and the reader supports it and CVM condition is satisfied. The PayPass reader must set the Transaction CVM as indicated by the CVM Code. In the CVM Results, the PayPass reader must copy the CVR to bytes 1 and 2, and must set byte 3 to "unknown". [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ &2] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * Tests are performed for amount below AND above (if applicable) the CVM limit * CVM List is 'No CVM required' with the following conditions satisfied: Case 01: condition is 'always' (1F 00) Case 02: condition is 'always' (5F 00), followed by Case 03: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (1F 02) Case 04: condition is 'if supported' (1F 03), followed by Case 05: condition is 'transaction is under X (and Amount is under X)' (1F 06) Case 06: condition is 'transaction is over X (and Amount is over X)' (1F 07) Case 07: condition is 'transaction is under Y (and Amount is under Y)' (1F 08) Case 08: condition is 'transaction is over Y (and Amount is over Y)' (1F 09) * The PayPass reader shall process the transaction until completion. * Cardholder verification was not successful bit is not set in TVR * CVM Result = (1F xx 00) where xx = number of the CVM condition of the sub case in question. * Transaction CVM is set to "No CVM" This test is applicable to all readers because no CVM must be supported below the CVM limit. 193

218 M : CVM selection - Condition satisfied and Code not supported (No CVM) To ensure that if the PayPass reader does not support 'No CVM required', the PayPass reader fails the CVM if the condition code is satisfied and CVM code is 'No CVM Required' and CVM b7=0 (or b7=1 and no more CVR). The PayPass reader shall set the Transaction CVM to "No CVM" and set the "Cardholder verification was not successful" bit in the TVR. The PayPass reader must set byte 1 of the CVM Results to "No CVM" and byte 3 to "failed". [NO NO CVM] and [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * Amount is above the CVM limit * CVM List is 'No CVM required' with the following conditions satisfied followed by : Case 01: condition is 'always' (1F 00) Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (5F 02), not followed by any CVR. Case 03: condition is 'transaction is under X (and Amount is under X)' (1F 06) Case 04: condition is 'transaction is over X (and Amount is over X)' (1F 07) Case 05: condition is 'transaction is under Y (and Amount is under Y)' (1F 08) Case 06: condition is 'transaction is over Y (and Amount is over Y)' (1F 09) * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 7 = '0' (i.e. Not an Unrecognized CVM) received at 1st GENERATE AC. * CVM Result = (3F 00 01) * Transaction CVM is set to "No CVM" 194

219 M : CVM selection - Condition satisfied and Code not supported (No CVM) To ensure that if the PayPass reader does not support 'No CVM required', the PayPass reader fails the CVM and perform the next CVM, if the condition code is satisfied and CVM code is 'No CVM Required' and CVM b7=1, another CVR(00 00) follows. The PayPass reader shall set the Transaction CVM to "No CVM" and set the "Cardholder verification was not successful" bit in the TVR. The PayPass reader must set byte 1 and byte 2 of the CVM Results to "Fail CVM" and byte 3 to "failed". [MCHIP] and [NO NO CVM] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * Amount is above the CVM limit * CVM List is 'No CVM required' with the following conditions satisfied followed by : Case 01: condition is 'always' (5F 00) Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (5F 02). Case 03: condition is 'transaction is under X (and Amount is under X)' (5F 06) Case 04: condition is 'transaction is over X (and Amount is over X)' (5F 07) Case 05: condition is 'transaction is under Y (and Amount is under Y)' (5F 08) Case 06: condition is 'transaction is over Y (and Amount is over Y)' (5F 09) * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 7 = '0' (i.e. Not an Unrecognized CVM) received at 1st GenerateAC. * CVM Result = ( ) * Transaction CVM is set to "No CVM" 195

220 M : CVM selection - Condition satisfied and Code is supported (signature) To ensure that if PayPass reader supports signature, the PayPass reader performs the CVM if the condition code is satisfied and CVM code is Signature. The PayPass reader must set the Transaction CVM as indicated by the CVM Code. In the CVM Results, the PayPass reader must copy the CVR to bytes 1 and 2, and must set byte 3 to "unknown". [SIGNATURE] and [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ &2] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction is processed so the outcome is an Approval * Amount is above the CVM limit * Transaction Amount is in the Application Currency * CVM List is 'signature' with the following conditions satisfied: Case 01: condition is 'always' (1E 00), followed by Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (1E 02) Case 03: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (5E 02) Case 04: condition is if reader supports the CVM' (1E 03). Case 05: condition is 'transaction is under X (and Amount is under X)' (1E 06) Case 06: condition is 'transaction is over X (and Amount is over X)' (1E 07) Case 07: condition is 'transaction is under Y (and Amount is under Y)' (1E 08) Case 08: condition is 'transaction is over Y (and Amount is over Y)' (1E 09) * The PayPass reader shall process the transaction until completion. * Cardholder verification was not successful bit is NOT set in TVR * CVM Result = (1E xx 00) where xx = number of the CVM condition of the sub case in question. * Transaction CVM is set to "Signature" * If PayPass reader under test has a printer, it shall print a ticket with sign line 196

221 M : CVM selection - Condition satisfied and Code is supported (PIN Online) To ensure that if PayPass reader supports Enciphered PIN Online, the PayPass reader performs the CVM if the condition code is satisfied and CVM code is Enciphered PIN Online. The PayPass reader must set the Transaction CVM as indicated by the CVM Code. In the CVM Results, the PayPass reader must copy the CVR to bytes 1 and 2, and must set byte 3 to "unknown". The PayPass reader must set the "Online PIN entered" bit in the TVR. [ENC PIN ONLINE] and [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ &2] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Amount is above the CVM limit * Transaction Amount is in the Application Currency * CVM List is 'Enciphered PIN online' with the following conditions satisfied: Case 01: condition is 'always' (02 00). Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback)' (02 02). Case 03: condition is 'if Terminal supports the CVM' (02 03). Case 04: condition is 'if Terminal supports the CVM' (42 03). Case 05: condition is 'transaction is under X (and Amount is under X)' (02 06). Case 06: condition is 'transaction is over X (and Amount is over X)' (02 07). Case 07: condition is 'transaction is under Y (and Amount is under Y)' (02 08). Case 08: condition is 'transaction is over Y (and Amount is over Y)' (02 09). Case 09: condition is 'transaction is over Y (and Amount is over Y)' (42 09). * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '0' (i.e. Cardholder verification succeeded) received at 1st GenerateAC. * TVR byte 3, bit 3 = '1' (i.e. Online PIN entered) received at 1st GenerateAC. * CVM Result = (02 xx 00) where xx = number of the CVM condition of the sub case in question. * Transaction CVM is set to "Enciphered pin online" 197

222 M : CVM selection - Condition satisfied and Code not supported (Online PIN) To ensure that if the PayPass reader does not support Enciphered PIN Online, the PayPass reader fails the CVM if the condition code is satisfied and CVM code is Enciphered PIN Online and CVM b7=0. The PayPass reader shall set the Transaction CVM to "No CVM" and set the "Cardholder verification was not successful" bit in the TVR. The PayPass reader must set byte 1 of the CVM Results to "No CVM" and byte 3 to "failed". [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * Tests are performed below and above (if applicable) the CVM limit * CVM List is 'Enciphered PIN online' with the following conditions satisfied: Case 01: condition is 'always' (02 00). Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback)' (02 02). Case 03: condition is 'transaction is under X (and Amount is under X)' (02 06). Case 04: condition is 'transaction is over X (and Amount is over X)' (02 07). Case 05: condition is 'transaction is under Y (and Amount is under Y)' (02 08). Case 06: condition is 'transaction is over Y (and Amount is over Y)' (02 09). * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 7 = '0' (i.e. Not an Unrecognized CVM) received at 1st GENERATE AC * CVM Result = (3F 00 01) * Transaction CVM shall be set to 'No CVM'. This test is applicable to all readers because only no CVM must be supported below the CVM limit. 198

223 M : CVM selection - Condition satisfied and Code not supported (Online PIN) To ensure that if the PayPass reader does not support Enciphered PIN Online, the PayPass reader fails the CVM and perform the next CVM, if the condition code is satisfied, CVM code is Enciphered PIN Online and CVM b7=1, another CVR (00 00) follows. The PayPass reader shall set the Transaction CVM to "No CVM" and set the "Cardholder verification was not successful" bit in the TVR. The PayPass reader must set byte 1 and byte 2 of the CVM Results to "Fail CVM" and byte 3 to "failed". [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * Tests are performed below and above (if applicable) the CVM limit * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * CVM List is 'Enciphered PIN online' with the following conditions satisfied followed by : Case 01: condition is 'always' (42 00). Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback)' (42 02). Case 03: condition is 'transaction is under X (and Amount is under X)' (42 06). Case 04: condition is 'transaction is over X (and Amount is over X)' (42 07). Case 05: condition is 'transaction is under Y (and Amount is under Y)' (42 08). Case 06: condition is 'transaction is over Y (and Amount is over Y)' (42 09). * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 7 = '0' (i.e. Not an Unrecognized CVM) received at 1st GENERATE AC * CVM Result = ( ) * Transaction CVM shall be set to 'No CVM'. 199

224 M : CVM selection - Condition satisfied and non-paypass Code To ensure that the PayPass reader correctly behaves when the condition code is satisfied and the CVM code is not supported in PayPass and CVM b7=0 (or b7=1 and no more CVR). The PayPass reader shall set the Transaction CVM to "No CVM" and set the "Cardholder verification was not successful" bit in the TVR. The PayPass reader must set byte 1 of the CVM Results to "No CVM" and byte 3 to "failed". [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * Tests are performed below AND above the CVM limit * CVM List is 'Plaintext PIN verified by ICC with the following conditions followed by : Case A1: condition is 'always' (01 00). Case A2: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (01 02) Case A3: condition is 'transaction is under X (and Amount is under X)' (41 06), not followed by any other CVR. Case A4: condition is 'transaction is over X (and Amount is over X)' (01 07). Case A5: condition is 'transaction is under Y (and Amount is under Y)' (01 08). Case A6: condition is 'transaction is over Y (and Amount is over Y)' (01 09). * CVM List is 'Plaintext PIN and signature' with the following conditions: Case B1: condition is 'always' (03 00). Case B2: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback)' (43 02), not followed by any other CVR. Case B3: condition is 'transaction is under X (and Amount is under X)' (03 06). Case B4: condition is 'transaction is over X (and Amount is over X)' (03 07). Case B5: condition is 'transaction is under Y (and Amount is under Y)' (03 08). Case B6: condition is 'transaction is over Y (and Amount is over Y)' (03 09). * CVM List is 'Enciphered PIN verified by ICC with the following conditions: Case C1: condition is 'always' (44 00), not followed by any other CVR Case C2: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback )' (04 02) Case C3: condition is 'transaction is under X (and Amount is under X)' (04 06) Case C4: condition is 'transaction is over X (and Amount is over X)' (04 07) Case C5: condition is 'transaction is under Y (and Amount is under Y)' (04 08) Case C6: condition is 'transaction is over Y (and Amount is over Y)' (04 09) * CVM List is 'Enciphered PIN and signature' with the following conditions: 200

225 Case D1: condition is 'always' (05 00) Case D2: condition is ''not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback ) (05 02) Case D3: condition is 'transaction is under X (and Amount is under X)' (05 06). Case D4: condition is 'transaction is over X (and Amount is over X)' (05 07). Case D5: condition is 'transaction is under Y (and Amount is under Y)' (05 08). Case D6: condition is 'transaction is over Y (and Amount is over Y)' (45 09), not followed by any other CVR. * PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 7 = '0' (i.e. Not an Unrecognized CVM) received at 1st GENERATE AC * CVM Result = (3F 00 01) * Transaction CVM shall be set to "No CVM" 201

226 M : CVM selection - Condition satisfied and non-paypass Code To ensure that the PayPass reader correctly behaves when the condition code is satisfied and the CVM code is not supported in PayPass and CVM b7=1, another CVR (00 00) follows. The PayPass reader shall set the Transaction CVM to "No CVM" and set the "Cardholder verification was not successful" bit in the TVR. The PayPass reader must set byte 1 and byte 2 of the CVM Results to "Fail CVM" and byte 3 to "failed". [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] [EMV 4.2b]: [2CJ , 2CJ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * Tests are performed below AND above the CVM limit * CVM List is 'Plaintext PIN verified by ICC with the following conditions followed by : Case A1: condition is 'always' (41 00). Case A2: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (41 02) Case A3: condition is 'transaction is under X (and Amount is under X)' (41 06) Case A4: condition is 'transaction is over X (and Amount is over X)' (41 07). Case A5: condition is 'transaction is under Y (and Amount is under Y)' (41 08). Case A6: condition is 'transaction is over Y (and Amount is over Y)' (41 09). * CVM List is 'Plaintext PIN and signature' with the following conditions: Case B1: condition is 'always' (43 00). Case B2: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback)' (43 02). Case B3: condition is 'transaction is under X (and Amount is under X)' (43 06). Case B4: condition is 'transaction is over X (and Amount is over X)' (43 07). Case B5: condition is 'transaction is under Y (and Amount is under Y)' (43 08). Case B6: condition is 'transaction is over Y (and Amount is over Y)' (43 09). * CVM List is 'Enciphered PIN verified by ICC with the following conditions: Case C1: condition is 'always' (44 00). Case C2: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback )' (44 02) Case C3: condition is 'transaction is under X (and Amount is under X)' (44 06) Case C4: condition is 'transaction is over X (and Amount is over X)' (44 07) Case C5: condition is 'transaction is under Y (and Amount is under Y)' (44 08) Case C6: condition is 'transaction is over Y (and Amount is over Y)' (44 09) * CVM List is 'Enciphered PIN and signature' with the following conditions: Case D1: condition is 'always' (45 00) Case D2: condition is ''not unattended cash and not manual cash, and not purchase with 202

227 cashback' (Transaction is not cash and not purchase with cashback ) (45 02) Case D3: condition is 'transaction is under X (and Amount is under X)' (45 06). Case D4: condition is 'transaction is over X (and Amount is over X)' (45 07). Case D5: condition is 'transaction is under Y (and Amount is under Y)' (45 08). Case D6: condition is 'transaction is over Y (and Amount is over Y)' (45 09), not followed by any other CVR. * PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 7 = '0' (i.e. Not an Unrecognized CVM) received at 1st GENERATE AC * CVM Result = ( ) * Transaction CVM shall be set to "No CVM" 203

228 M : CVM selection - Condition satisfied and Code not supported (signature) To ensure that if the PayPass reader does not support signature, the PayPass reader fails the CVM if the condition code is satisfied and CVM code is Signature and CVM b7=0. The PayPass reader shall set the Transaction CVM to "No CVM" and set the "Cardholder verification was not successful" bit in the TVR. The PayPass reader must set byte 1 of the CVM Results to "No CVM" and byte 3 to "failed". [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * Tests are performed below and above (if applicable) the CVM limit * CVM List is 'signature' with the following conditions satisfied: Case 01: condition is 'always' (1E 00) Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (1E 02) Case 03: condition is 'transaction is under X (and Amount is under X)' (1E 06). Case 04: condition is 'transaction is over X (and Amount is over X)' (1E 07). Case 05: condition is 'transaction is under Y (and Amount is under Y)' (1E 08). Case 06: condition is 'transaction is over Y (and Amount is over Y)' (1E 09). * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 7 = '0' (i.e. Not an Unrecognized CVM) received at 1st GENERATE AC. * Transaction CVM shall be set to "No CVM" * CVM Result = (3F 00 01) This test is applicable to all readers because only no CVM must be supported below the CVM limit. 204

229 M : CVM selection - Condition satisfied and Code not supported (signature) To ensure that if the PayPass reader does not support signature, the PayPass reader fails the CVM and performs next CVM, if the condition code is satisfied and CVM code is Signature and CVM b7=1, another CVR (00 00) follows.. The PayPass reader shall set the Transaction CVM to "No CVM" and set the "Cardholder verification was not successful" bit in the TVR. The PayPass reader must set byte 1 and byte 2 of the CVM Results to "Fail CVM" and byte 3 to "failed". [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * Tests are performed below and above (if applicable) the CVM limit * CVM List is 'signature' with the following conditions satisfied followed by : Case 01: condition is 'always' (5E 00) Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (5E 02) Case 03: condition is 'transaction is under X (and Amount is under X)' (5E 06). Case 04: condition is 'transaction is over X (and Amount is over X)' (5E 07). Case 05: condition is 'transaction is under Y (and Amount is under Y)' (5E 08). Case 06: condition is 'transaction is over Y (and Amount is over Y)' (5E 09). * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * TVR byte 3, bit 7 = '0' (i.e. Not an Unrecognized CVM) received at 1st GENERATE AC. * Transaction CVM shall be set to "No CVM" * CVM Result = ( ) 205

230 M : CVM selection - Functions not specified in the AIP: Cardholder verification To ensure that if Cardholder Verification is not supported in AIP, the PayPass reader sets the Transaction CVM to No CVM, sets CVM result Byte 1 to NoCVM and byte 3 to successful. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is not supported (AIP byte 1 bit 5 = 0). Case 01: CVM is present in LT and indicates 'Fail CVM, always' (00 00). Amount is below the CVM limit Case 02: CVM is not present in LT. Amount is above the CVM limit. * The PayPass reader shall process the transaction until completion. * CVM result = (3F 00 02) * TVR byte 3, bit 8 = '0' (i.e. Cardholder verification not failed) * Transaction CVM is set to No CVM. M : CVM selection - CVM Results Set With Method Code and Condition Code of Last CVM Performed To ensure that the PayPass reader sets the CVM Results bytes 1 and 2 according to the last CVM performed [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM list in LT is 'Fail CVM, always' (00 00) followed by 'NO CVM always' (1F 00) * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * CVM Result shall be set to '. * Transaction CVM set to No CVM * TVR B3b8 (Card holder verification was not successful) bit is set received at 1st GenerateAC 206

231 M : CVM selection - CVM Results Set With Method Code and Condition Code of Last CVM Performed (5) To ensure that the PayPass reader sets the CVM Results bytes 1 and 2 according to the last CVM performed [MCHIP] and [NO CVM] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM list in LT is 'NO CVM always' (1F 00) followed by 'Fail CVM, always' (00 00). * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * CVM Result shall be set to 1F 00 00' * Transaction CVM set to No CVM M : CVM selection - CVM Results Set With Method Code and Condition Code of Last CVM Performed (3) To ensure that the PayPass reader sets the CVM Results bytes 1 and 2 according to the last CVM performed [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). Case 01: CVM list in LT is 'Online Enciphered PIN always' (42 00) followed by 'Fail CVM always' (00 00) Case 02: CVM list in LT is 'Fail CVM, always' (00 00) followed by 'NO CVM always' (1F 00) * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC * Case 01: CVM Result = ' * Case 02: CVM Result = ' 207

232 M : CVM selection - CVM processing succeeds (2) To ensure that the PayPass reader does not set the 'Cardholder verification was not successful' bit in the TVR to 1b, if the CVM processing succeeds. [ENC PIN ONLINE] or [SIGNATURE] and [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM List is 'Enciphered Online PIN if reader supports the CVM' (02 03) followed by 'Signature, always' (1E 00) * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * When processing Online Enciphered PIN, CVM Result = and TVR Byte 3, bit 3=1 (Online pin entered) * When processing Signature, CVM Result = 1E * Transaction CVM is set to "Enciphered PIN Online or Signature" M : CVM selection - CVM processing succeeds (3) To ensure that the PayPass reader does not set the 'Cardholder verification was not successful' bit in the TVR to 1b, if the CVM processing succeeds. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM List is 'No CVM, always' (1F 00) * Amount is below the CVM limit. * A PayPass reader shall set the TVR B3b8=0 (i.e. Cardholder verification successful) * CVM Result = 1F

233 M : CVM selection - CVM processing succeeds -No CVM To ensure that the PayPass reader does not set the 'Cardholder verification was not successful' bit in the TVR to 1b, if the CVM processing succeeds. [MCHIP] and [NO CVM] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM List is 'No CVM, always' (1F 00) * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * CVM Result = (1F 00 00) * Transaction CVM is set to "No CVM" 209

234 M : CVM selection - ICC Data required by the CVM Condition Code is missing To ensure that if the ICC data required by the condition expressed in the second byte of a Cardholder Verification Rule is not present, the PayPass reader bypasses the rules and proceeded to the next rule. [MCHIP] [MC v2.1]: [ b] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM List is Fail CVM if transaction is in the application currency and is under X' value (00 06) followed by 'Fail CVM, always' (00 00). * Application Currency Code is not present in the LT. * X is such as Transaction amount is under X. * CDOL1 requests CVM Results. Case 01: amount is below the CVM limit Case 02: amount is above the CVM limit * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed (' '). * Transaction CVM set to "No CVM". 210

235 M : CVM selection - CVM List is not present in the ICC To ensure that if Cardholder verification is supported in AIP and CVM List is missing in the card, the PayPass reader sets the 'ICC data missing' bit in the TVR to 1b and the Transaction CVM to nocvm. It shall set the CVM Results byte 1 to 'No CVM performed' and byte 3 to unknown. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM is not present in the LT. Case 01: amount is below the CVM limit Case 02: amount is above the CVM limit * The PayPass reader shall process the transaction until completion. * TVR byte 1, bit 6 = '1' (i.e. ICC Data missing) received at 1st GenerateAC. * TVR byte 3, bit 8 = '0' (i.e. Cardholder verification not failed) * CVM Results ('3F 00 00) * Transaction CVM shall be set to "No CVM". 211

236 M : CVM selection - CVM List with no Cardholder Verification Rules To ensure that if Cardholder verification is supported in AIP and the CVM List has no CVRs, then the PayPass reader sets the 'ICC data missing' bit in the TVR to 1b and the Transaction CVM to nocvm. It shall set the CVM Results byte 1 to 'No CVM performed' and byte 3 to unknown. [MCHIP] [MC v2.1]: [ M/Chip CVM Selection] [ ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). Case 01: CVM List in LT does not contain any Cardholder Verification Rule (Length = 0) Case 02: CVM List in LT does not contain any Cardholder Verification Rule, but contains 8 bytes as value X and Y (Length= 08, Value = ) * The reader shall process the transaction to completion * TVR byte 1, bit 6 = '1' (i.e. ICC data missing) * TVR byte 3, bit 8 = '0' (i.e. Cardholder verification not failed) * CVM Results ('3F 00 00') * Transaction CVM shall be set to "No CVM". 212

237 M : CVM selection - Condition Code outside the range of understood codes To ensure that if the condition code expressed in the second byte of a Cardholder Verification Rule is outside the range of codes understood by the PayPass reader, the PayPass reader bypasses the rules and proceeded to the next rule. [MCHIP] [MC v2.1]: [ c] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). Case 01: CVM List is 'Fail CVM, if RFU (00 0A) following by 'Fail CVM, always' (00 00). Case 02: CVM List is 'Online Enciphered PIN, if RFU' (02 10) following by 'Fail CVM, always' (00 00). Case 03: CVM List is 'Offline Plaintext PIN and signature, if RFU' (03 7A) following by 'Fail CVM, always' (00 00). Case 04: CVM List is 'offline enciphered PIN, if RFU' (04 80) following by 'Fail CVM, always' (00 00). Case 05: CVM List is 'Offline enciphered PIN and signature, if RFU' (05 AA) following by 'Fail CVM, always' (00 00). Case 06: CVM List is 'RFU, if RFU' (3F B0) following by 'Fail CVM, always' (00 00). Case 07: CVM List is 'RFU, if RFU' (07 FF) following by 'Fail CVM, always' (00 00). * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification failed) received at 1st GenerateAC. * CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed (' '). * Transaction CVM set to "No CVM" 213

238 M : CVM selection - condition satisfied and Code not understood b7=0 To ensure that the PayPass reader sets the 'Unrecognized CVM ' bit in the TVR to 1b, if the condition code is satisfied and CVM code is not understood by the PayPass reader (RFU). If b7=0 or there are no more CVRs in the list then the PayPass reader shall set the Transaction CVM to no CVM and the Cardholder verification was not successful bit in the TVR to 1. It shall set the CVM result bytes 1 & 2 to nocvm and byte 3 to failed. [MCHIP] [MC v2.1]: [ b] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * tests must be made for amounts below and above the CVM limit * CVM List is 'RFU' with the following conditions satisfied followed by No CVM always. Case 01: condition is 'always' (3F 00) Case 02: CVM List is 'RFU, always' (07 00) Case 03: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback')' (07 02) Case 04: condition is 'not unattended cash and not manual cash, and not purchase with cashback' (Transaction is not cash and not purchase with cashback) (3F 02) Case 05: condition is 'transaction is under X (and Amount is under X)' (2F 06) Case 06: condition is 'transaction is over X (and Amount is over X)' (3F 07) Case 07: condition is 'transaction is under Y (and Amount is under Y)' (3F 08) Case 08: condition is 'transaction is over Y (and Amount is over Y)' (2F 09) * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification was not successful * TVR byte 3, bit 7 = '1' (i.e. Unrecognized CVM) received at 1st GenerateAC. * CVM Result = 3F * Transaction CVM is set to "No CVM" 214

239 M : CVM selection - condition satisfied and Code not understood b7=1 To ensure that the PayPass reader sets the 'Unrecognized CVM ' bit in the TVR to 1b, if the condition code is satisfied and CVM code is not understood by the PayPass reader (RFU). If b7=1 then the PayPass reader shall continue with the next CVR if present. [MCHIP] [MC v2.1]: [ b] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * CVM List is 'RFU' with the following conditions satisfied and followed by : Case 01: condition is 'always' (7F 00) Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback')' (47 02) Case 03: condition is 'transaction is under X (and Amount is under X)' (6F 06) Case 04: condition is 'transaction is over X (and Amount is over X)' (7F 07) Case 05: condition is 'transaction is under Y (and Amount is under Y)' (7F 08) Case 06: condition is 'transaction is over Y (and Amount is over Y)' (47 09) * The PayPass reader shall process the transaction until completion. * PayPass reader shall continue with the next CVR * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification was not successful * TVR byte 3, bit 7 = '1' (i.e. Unrecognized CVM) received at 1st GenerateAC. * CVM Result = * Transaction CVM shall be set to "No CVM". 215

240 M : CVM selection - Condition satisfied and Code is "Fail CVM" - b7=0 To ensure that if the CVM condition code is satisfied and CVM code is fail CVM with b7=0 (or b7=1 and no more CVRs) then the PayPass reader sets the Transaction CVM to "No CVM" and sets the "Cardholder verification was not successful" bit in the TVR. The PayPass reader must set byte 3 of the CVM Results to "failed" and must copy the CVR to bytes 1 and 2. [MCHIP] [MC v2.1]: [ b] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * CVM List is 'Fail CVM' with the following conditions satisfied: Case 01: condition is 'always' (00 00). Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback)' (00 02). Case 03: condition is 'if CVM supported' (00 03) followed by fail CVM always (00 00). Case 04: condition is 'if CVM supported' (40 03) not followed by any other CVR. Case 05: condition is ' transaction is under X (and Amount is under X)' (00 06) followed by fail CVM always (00 00). Case 06: condition is ' transaction is over X (and Amount is over X)' (00 07) followed by fail CVM always (00 00). Case 07: condition is ' transaction is under Y (and Amount is under Y)' (40 08) not followed by any other CVR. Case 08: condition is ' transaction is over Y (and Amount is over Y)' (40 09) not followed by any other CVR. * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification was not successful * CVM Result = xx xx 01 where xx xx = CVR of the sub case in question. * Transaction CVM is set to 'No CVM'. 216

241 M : CVM selection - Condition satisfied and CVM Code is Fail CVM b7=1 To ensure that if the CVM condition code is satisfied and CVM code is fail CVM with b7=1 then the PayPass reader continues with the next CVR. [MCHIP] [MC v2.1]: [ b] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Transaction Amount is in the Application Currency * CVM code is 'Fail CVM' with the following conditions satisfied and followed by fail CVM always (00 00): Case 01: condition is 'always' (40 00). Case 02: condition is 'not unattended cash and not manual cash, and not purchase with cashback (Transaction is not cash and not purchase with cashback)' (40 02). Case 03: condition is 'if CVM supported' (40 03). Case 04: condition is ' transaction is under X (and Amount is under X)' (40 06). Case 05: condition is ' transaction is over X (and Amount is over X)' (40 07). Case 06: condition is ' transaction is under Y (and Amount is under Y)' (40 08). Case 07: condition is ' transaction is over Y (and Amount is over Y)' (40 09). * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '1' (i.e. Cardholder verification was not successful * CVM Result = * Transaction CVM shall be set to 'No CVM'. 217

242 M : TAA - TVR and IAC-Denial check requests a TC (implied) To ensure that the PayPass reader performs Action Analysis prior to the issuing of the first GenerateAC command. To ensure that the PayPass reader issues a GenerateAC requesting a TC if for a bit that is set to 1b in the TVR, the corresponding bit in the IAC Denial is set to 0b. [OFFLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] * Issuer Action Code Denial has one bit set to 0b and the corresponding TVR bit is set to 1b. * Issuer Action Codes Online & Default have all bits set to 0b. * AIP of LT must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail * The PayPass reader shall process the transaction until completion * The LT shall receive a first GenerateAC command requesting a TC in all cases M : TAA - TAC Denial processing bit set to 0b To ensure that the PayPass reader issues a GenerateAC requesting a TC, if for a bit set to 1b in the TVR, the corresponding bit in the TAC Denial is set to 0b. [OFFLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] * Issuer Action Codes have all bits set to 0b. * AIP of LT must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail * The LT shall receive a first GenerateAC command requesting a TC in all cases. * The PayPass reader shall process the transaction until completion 218

243 M : TAA - TAC Online Processing bit set to 0b To ensure that the PayPass reader issues a GenerateAC requesting a TC, if the PayPass reader has online capabilities and if for a bit set to 1b in the TVR, the corresponding bit in the TAC Online is set to 0b. [ONLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] * Terminal Action Code Online has one bit set to 0b and the corresponding TVR bit is set to 1b. * Terminal Action Code Denial has all bits set to 0b. * Issuer Action Codes have all bits set to 0b. * AIP of LT must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail * The PayPass reader shall process the transaction until completion * The LT shall receive a first GenerateAC command requesting a TC in all cases M : TAA - Reader has online capability, TVR and IAC-Online Codes check requests a TC (implied) To ensure that the PayPass reader Issues a GenerateAC requesting a TC, if PayPass reader has online capabilities and if for a bit set to 1b in the TVR, the corresponding bit in the IAC Online is set to 0b. [MCHIP] and [ONLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] Terminal Action Codes have all bits set to 0b. * Issuer Action Codes Denial & Default have all bits set to 0b. * Issuer Action Code Online has one bit set to 0b and the corresponding TVR bit is set to 1b. * AIP of LT must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail * The PayPass reader shall process the transaction until completion * The LT shall receive a first GenerateAC command requesting a TC in all cases 219

244 M : TAA - Reader has not online capability, TVR and IAC default check requests a TC To ensure that the PayPass reader skips the check of Online Action Codes and issues a first GenerateAC requesting a TC, if PayPass reader has not rejected the transaction, PayPass reader has no online capabilities, and for a bit set to 1b in the TVR, the corresponding bit in the IAC-Default is set to 0b. [OFFLINE ONLY] [MC v2.1]: [ Generate AC Processing] [ ] * Issuer Action Code Denial has all bits set to 0b. * Issuer Action Code Default has one bit set to 0b and the corresponding TVR bit is set to 1b. * AIP of LT must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail * The PayPass reader shall process the transaction until completion * The LT shall receive a first GenerateAC command requesting an TC in all cases M : TAA - TAC Default processing bit set to 0b & PayPass reader has no online capability To ensure that the PayPass reader skips the check of Online Action Codes and issues a first GenerateAC requesting a TC, if PayPass reader has no online capability, and for each bit set to 1b in the TVR, the corresponding bit in both the IAC Default and TAC-Default is set to 0b. [OFFLINE ONLY] [MC v2.1]: [ Generate AC Processing] [ ] * Issuer Action Code Denial has all bit set to 0b. * Issuer Action Code Default has all bits set to 0b. * AIP of LT must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail The LT shall receive a first GenerateAC command requesting a TC in all cases 220

245 M : TAA - Requests a TC on first GenAC To ensure that if the PayPass reader requests a TC in first GenerateAC, it supports AAC, or ARQC or TC in the response from the card [MCHIP] [MC v2.1]: [4.1 Transaction Flow] [Symbol 13 GenerateAC] * IAC and TAC set so that PayPass reader requests TC on first GenerateAC. Case 01: LT returns AAC in the response to first GenerateAC Case 02: LT returns ARQC in the response to first GenerateAC Case 03: LT returns TC in the response to first GenerateAC * Case 01: Transaction outcome shall be set to Try Another Interface * Case 02: Transaction outcome shall be set to Online request for online capable terminals and declined for offline only terminals. * Case 03:Transaction outcome shall be set to Approved M : TAA - TVR and IAC-Denial/Online check requests a ARQC (implied) To ensure that the PayPass reader performs Action Analysis prior to the issuing of the GenerateAC command. To ensure that the PayPass reader issues a GenerateAC requesting an ARQC if for a bit that is set to 1b in the TVR, the corresponding bit in the IAC Denial is set to 0b and the corresponding bit in the IAC Online is set to 1b. [ONLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] * Terminal Action Codes have all bits set to 0b. * Issuer Action Code Online has one bit set to 1b and the corresponding TVR bit is set to 1b. * Issuer Action Codes Denial & Default have all bits set to 0b. * AIP of LT must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail * The LT shall receive a GenerateAC command requesting an ARQC 221

246 M : TAA - TAC Denial processing bit set to 0b and IAC online to 1b To ensure that the PayPass reader issues a GenerateAC requesting an ARQC, if for a bit set to 1b in the TVR, the corresponding bit in the TAC Denial is set to 0b. [ONLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] * Issuer Action Codes Default and Denial have all bits set to 0b. * Issuer Action Code Online has one bits set to 1b in order that the PayPass reader should request an ARQC * AIP of LT must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail * The LT shall receive a first GenerateAC command requesting an ARQC in all cases M : TAA - Reader has online capability, TVR and IAC-Online check requests an ARQC To ensure that the PayPass reader issues a GenerateAC requesting an ARQC, if the PayPass reader has online capabilities and if for a bit set to 1b in the TVR, the corresponding bit in the IAC Online is set to 1b. [ONLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] * Issuer Action Codes Denial & Default have all bits set to 0b. * Issuer Action Code Online has one bit set to 1b and the corresponding TVR bit is set to 1b. * AIP of LT must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail * The LT shall receive a first GenerateAC command requesting an ARQC in all cases 222

247 M : TAA - Online only terminal requests an ARQC when not matching TAC- Online or IAC-Online To ensure that the PayPass reader issues a GenerateAC requesting an ARQC, if the reader has online capabilities and if for a bit set to 1b in the TVR, the corresponding bit in the IAC Online is set to 0b. [ONLINE ONLY] and [MCHIP] [MC v2.1]: [ Generate AC Processing] [ ] * Issuer Action Codes have all bits set to 0b. * Terminal Action Codes have all bits set to 0b. * The LT shall receive a first GenerateAC command requesting an ARQC. M : TAA - TAC Online Processing bit set to 1b To ensure that the PayPass reader issues a GenerateAC requesting an ARQC, if the PayPass reader has online capabilities and if for a bit set to 1b in the TVR, the corresponding bit in the TAC Online is set to 1b. [ONLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] * Terminal Action Code Online has one bit set to 1b and the corresponding TVR bit is set to 1b. * Terminal Action Code Denial has all bits set to 0b. * Issuer Action Codes have all bits set to 0b. * AIP of LT must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail * The LT shall receive a first GenerateAC command requesting an ARQC in all cases 223

248 M : TAA - Requests an ARQC on first GenAC To ensure that if the PayPass reader requests an ARQC in first GenerateAC, it supports AAC, or ARQC in the response from the card. [MCHIP] and [ONLINE CAPABLE] [MC v2.1]: [4.1 Transaction Flow] [Symbol 13 GenerateAC] * IAC and TAC set so that PayPass reader requests ARQC on first GenerateAC. Case 01: LT returns AAC in the response to first GenerateAC Case 02: LT returns ARQC in the response to first GenerateAC Application in LT is selected and transaction is processed with LT * Case 01: Transaction outcome shall be set to Try another Interface * Case 02: Transaction outcome shall be set to Online request M : TAA - IAC-Denial is not present in the ICC To ensure that if the Issuer Action Code Denial does not exist in the card, the PayPass reader uses a default value with all bits set to 0b. [MCHIP] and [OFFLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] * Terminal Action Code Denial has all bits set to 0b. * Terminal Action Code Online has all bits set to 0b. * Terminal Action Code Default has all bits set to 0b. * Issuer Action Code Denial does not exist in the card * Issuer Action Code Online has all bits set to 0b. * Issuer Action Code Default has all bits set to 0b. * AIP of LT must be set to execute the function associated with the IAC bit selected by the tester and the LT will be set so the executed function will fail * The LT shall receive a first GenerateAC command requesting a TC. 224

249 M : TAA - IAC-Online is not present in the ICC To ensure that If the Issuer Action Code Online does not exist in the card, the PayPass reader uses a default value with all bits set to 1b. [MCHIP] and [ONLINE CAPABLE] [MC v2.1]: [ Generate AC Processing] [ ] * Terminal Action Code Online has all bits set to 0b. * Terminal Action Code Denial has all bits set to 0b. * Terminal Action Code Default has all bits set to 0b. * Issuer Action Code Online does not exist in the card * Issuer Action Code Denial has all bits set to 0b. * Issuer Action Code Default has all bits set to 0b. * AIP of LT must be set to execute the function associated with the IAC bit selected by the tester and the LT will be set so the executed function will fail * The LT shall receive a first GenerateAC command requesting an ARQC 225

250 M : TAA - IAC-Default is not present in the ICC and the PayPass reader is offline only To ensure that if the Issuer Action Code Default does not exist in the card, the PayPass reader uses a default value with all bits set to 1b when the PayPass reader is offline only. [OFFLINE ONLY] [MC v2.1]: [ Generate AC Processing] [ ] * Terminal Action Code Default has all bits set to 0b. * Terminal Action Code Denial has all bits set to 0b. * Terminal Action Code Online has all bits set to 0b. * Issuer Action Code Default does not exist in the card * Issuer Action Code Denial has all bits set to 0b. * Issuer Action Code Online has all bits set to 0b. * AIP must be set to execute a function associated with the IAC and this function will be failed by the LT (e.g. SDA is failed then the TVR byte 1 bit 7 is set to 1b) The LT shall receive a first GenerateAC command requesting an AAC in all cases M : TAA - TVR and IAC-Denial check requests an AAC To ensure that the PayPass reader performs Action Analysis prior to the issuing of the first GenerateAC command. To ensure that the PayPass reader issues a GenerateAC requesting an AAC if for a bit that is set to 1b in the TVR, the corresponding bit in the IAC Denial is set to 1b. [MCHIP] [MC v2.1]: [ Generate AC Processing] [ ] * Issuer Action Code Denial has one bit set to 1b and the corresponding TVR bit is set to 1b. * Issuer Action Code Default has all bits set to 0b. * AIP of LT must be set to execute the function associated with the IAC bit selected by tester and the LT will be set so the executed function will fail * The PayPass reader shall process the transaction until completion * The LT shall receive a first GenerateAC command requesting an AAC in all cases 226

251 M : TAA - TAC Denial processing bit set to 1b To ensure that the PayPass reader issues a GenerateAC requesting an AAC, if for a bit set to 1b in the TVR, the corresponding bit in the TAC Denial is set to 1b. [MCHIP] [MC v2.1]: [ Generate AC Processing] [ ] * Issuer Action Codes have all bits set to 0b. * AIP of LT must be set to execute the function associated with the TAC bit selected by tester and the LT will be set so the executed function will fail * The LT shall receive a first GenerateAC command requesting an AAC in all cases M : TAA - Reader has not online capability, TVR and IAC-Default check requests an AAC To ensure that the PayPass reader skips the check of Online Action Codes and issues a first GenerateAC requesting an AAC, if PayPass reader has not rejected the transaction, PayPass reader has no online capabilities, and for a bit set to 1b in the TVR, the corresponding bit in the IAC-Default is set to 1b. [OFFLINE ONLY] [MC v2.1]: [ Generate AC Processing] [ ] Terminal Action Codes have all bits set to 0b. * Issuer Action Code Denial has all bits set to 0b. * Issuer Action Code Default has one bit set to 1b and the corresponding TVR bit is set to 1b. * AIP of LT must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail * The LT shall receive a first GenerateAC command requesting an AAC in all cases 227

252 M : TAA - TAC Default processing bit set to 1b & PayPass reader has no online capability To ensure that the PayPass reader skips the check of Online Action Codes and issues a first GenerateAC requesting an AAC, if PayPass reader has no online capabilities, and for a bit set to 1b in the TVR, the corresponding bit in the TAC Default is set to 1b. [OFFLINE ONLY] [MC v2.1]: [ Generate AC Processing] [ ] *IAC default have all bits set to 0b. *IAC online have all bits set to 1b. * AIP of LT must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail * The LT shall receive a first GenerateAC command requesting an AAC in all cases M : TAA - Requests a AAC at first GenAC To ensure that if the PayPass reader requests an AAC in first GenerateAC, it supports only AAC in the response from the card [MCHIP] [MC v2.1]: [4.1 Transaction Flow] [Symbol 13 GenerateAC] * IAC and TAC set so that PayPass reader requests AAC on first GenerateAC. * LT returns AAC in the response to first GenerateAC. Transaction outcome shall be set to declined 228

253 M : GenerateAC - CDOL1 for the first GenAC To ensure that the PayPass reader supports valid CDOL1. To ensure that the PayPass reader checks that mandatory Data Object CDOL1 is present in the card and use it. To ensure that the PayPass reader is able to build GenerateAC Data field according to CDOL1 rules. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: CDOL1 contains date of the day, terminal type, PAN Case 02: CDOL1 contains transaction amount, terminal type, transaction amount Case 03: CDOL1 contains Issuer Authentication Data, Transaction Amount The PayPass reader shall return a GenerateAC command to the LT with Data field correctly filled according to CDOL1 M : GenerateAC - No CDA request when DA selected is not CDA To ensure that PayPass reader does not request for CDA signature in GenerateAC command when ODA method selected is not CDA [OFFLINE CAPABLE] [MC v2.1]: [ ] * AIP of LT indicates M/Chip profile is supported (AIP byte 2 bit 8 = 1). * AIP of LT indicates CDA is not supported (AIP byte 1 bit 1 = 0). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * LT returns data needed for successful CDA operation. * The PayPass reader shall process the transaction until completion, by requesting a TC without CDA at 1st GenerateAC. * PayPass reader shall approve the transaction after 1st GenerateAC. 229

254 M : GenerateAC - No CDA request when CDA failed To ensure that PayPass reader does not request for CDA signature in GenerateAC command when CDA failed [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ ] * AIP of LT indicates M/Chip profile is supported (AIP byte 2 bit 8 = 1). * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * ICC certificate is missing in LT * LT returns data so that CDA fail detected before GenerateAC * The PayPass reader shall process the transaction until completion, by requesting a TC without CDA at 1st GenerateAC. * PayPass reader shall approve the transaction after 1st GenerateAC. M : GenerateAC - No ODA to be performed To ensure that if neither SDA, nor CDA is performed, the PayPass reader sets the 'Offline data authentication was not performed' bit in the TVR to 1b [MC v2.1]: [4.3.6 Offline Data Authentication Method Selection] [ ] * IACs and TACs are such that the transaction is approved offline. Case 01: LT does not support SDA or CDA. Test must be performed for both MasterCard and Maestro applications. Case 02: LT does support SDA but not CDA. Test must be performed for Maestro application only. The Terminal Capabilities data item for the Maestro application shall indicate "SDA NOT supported"; it may require this data item to be modified. Application in LT is selected and transaction is processed with LT * PayPass reader shall generate TC at 1st GenerateAC * TVR Byte1 bit8 = 1: ODA was not performed * TVR Byte1 bit7 = 0: SDA did not fail * TVR Byte1 bit3 = 0: CDA did not fail * Transaction outcome shall be set to 'Approved' *: a similar test will be performed during TIP testing as it is a product rule to not support SDA for the Maestro PayPass application. Doing this test at the Level 2 step ensures that the reader will not fail this major test during TIP. 230

255 M : GenerateAC - PayPass reader completes transaction when card indicated approval To ensure that the PayPass reader completes the transaction if the card returned an Approval to GenerateAC. [OFFLINE CAPABLE] and [MCHIP] [MC v2.1]: [4.1 Transaction Flow] [Symbol 18] * IAC-Online, IAC-Default & IAC-Denial are zero filled * LT returns TC to first GenerateAC * The PayPass reader shall process the transaction until completion * Transaction outcome shall be set to 'Approved' after 1st GenerateAC 231

256 M : GenerateAC - Syntax of response message: Format 1 To ensure that the PayPass reader is able to recognize the data field returned by GenerateAC command, encoded according to format 1 syntax and in particular the order of the value field of Data Object included in the returned Data field. [MCHIP] [MC v2.1]: [2.3 GenerateAC] [2.3.3 Data Field Returned in the Response Message] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) Case 01: Response to GenerateAC includes only the mandatory Data Objects and shall be encoded with format 1 (Template 80) Case 02: Response to GenerateAC includes the mandatory Data Objects and the Issuer Application Data and shall be encoded with format 1 (Template 80) Case 03: Response to GenerateAC includes the mandatory Data Objects and the Issuer Application Data and shall be encoded with format 1 (Template 80). Tag 80 length is coded on 2 bytes (81 xx). Application in LT is selected and transaction is performed with LT. * The reader shall accept the card and interpret correctly the format 1 syntax. * The reader shall process the transaction until completion, by requesting a TC or an AAC. * Values for Cryptogram Information Data, ATC, Application Cryptogram, Issuer Application Data managed by the PayPass reader and data record sent to terminal shall be in accordance with values sent back by the LT 232

257 M : GenerateAC - Syntax of response message: Format 2 To ensure that the PayPass reader is able to recognize the data field returned by GenerateAC command, encoded according to format 2 syntax. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) * LT does not support SDA and CDA Case 01: Response to GenerateAC includes only the mandatory Data Objects and shall be encoded with format 2 (Template 77) Case 02: Response to GenerateAC includes the mandatory Data Objects and the Issuer Application Data and shall be encoded with format 2 (Template 77) Case 03: Response to GenerateAC includes the mandatory Data Objects and the Issuer Application Data and shall be encoded with format 2 (Template 77). Tag 77 length is coded on 2 bytes (81 xx) where xx is less than 128. Case 04: Response to GenerateAC includes the mandatory Data Objects and the Issuer Application Data and shall be encoded with format 2 (Template 77). Tag 77 length is coded on 2 bytes (81 xx) where xx is greater than 128. Application in LT is selected and transaction is performed with LT. * The PayPass reader shall accept the card and interpret correctly the format 2 syntax. * The PayPass reader shall run the transaction to completion according to the LT's response to the GenerateAC command. 233

258 M : GenerateAC - Retrieval of CID To ensure that the PayPass reader retrieves the Cryptogram Information Data data object from the data field of the GenerateAC response message. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: LT parameter set so that reader requests TC and Lt returns AAC at first GenerateAC Case 02: LT parameter set so that reader requests TC and Lt returns TC at first GenerateAC Case 03: LT parameter set so that reader requests TC and Lt returns ARQC at first GenerateAC Case 04: LT parameter set so that reader requests ARQC and Lt returns AAC at first GenerateAC Case 05: LT parameter set so that reader requests ARQC and Lt returns ARQC at first GenerateAC Case 06: LT parameter set so that reader requests AAC and Lt returns AAC at first GenerateAC Application in LT is selected and transaction is performed with LT. * The PayPass reader shall process the transaction until the end. * Case 02 & Case 03 & Case 05: Value for Cryptogram Information Data included in data record shall be the same as that returned by the LT in the GenerateAC response message. * Case 01 & Case 04 : Is the transaction outcome set to Try Another Interface * Case 06: Is the transaction outcome set to Declined. 234

259 M : GenerateAC - CID - TC To verify that the PayPass reader interprets correctly answer to a GenerateAC command requesting the ICC to return a TC. To ensure that the PayPass reader accepts the presence of a valid Cryptogram Information Data in response to the GenerateAC command. [MCHIP] and [OFFLINE CAPABLE] [MS v3.3]: [MC v2.1]: [EMV 4.2b]: * LT response to the GenerateAC: Case 01: LT responses a TC without advice (40) Case 02: LT responses a TC with advice and no reason (48) Case 03: LT responses a TC with advice and reason is PIN Try Limit exceeded (4A) Case 04: LT responses a TC with advice and reason is Issuer authentication failed (4B) Application in LT is selected and transaction is performed with LT until completion. Transaction outcome shall be set to "Approved" M : GenerateAC - CID- ARQC To verify that the PayPass reader interprets correctly answer to a GenerateAC command requesting the ICC to return an ARQC [MCHIP] and [ONLINE CAPABLE] [MC v2.1]: [4.1 Transaction Flow] [Symbol 18 Card Generated ARQC (No CDA)] * LT response to the GenerateAC: Case 01: LT responses an ARQC without advice (80) Case 02: LT responses an ARQC with advice and no reason (88) Case 03: LT responses an ARQC with advice and reason is PIN Try Limit exceeded (8A) Case 04: LT responses an ARQC with advice and reason is Issuer authentication failed (8B) Application in LT is selected and transaction is performed with LT until completion. * The PayPass reader shall complete the transaction on line * Transaction outcome shall be set to "Online request" 235

260 M : GenerateAC - CID- AAC To verify that the PayPass reader interprets correctly a GenerateAC response indicating an AAC. To ensure that the PayPass reader accepts the presence of a valid Cryptogram Information Data in response to the GenerateAC command. [MCHIP] [MC v2.1]: [4.1 Transaction Flow] [Symbol 14 Card Generated AAC?] Case 01: Data returned by LT is such that the reader requests a TC or an ARQC. LT responses an AAC without advice (00) * Data returned by LT is such that the reader requests an AAC. Case 02: LT responses an AAC with advice and no reason (08) Case 03: LT responses an AAC with advice and reason is PIN Try Limit exceeded (0A) Case 04: LT responses an AAC with advice and reason is Issuer authentication failed (0B) Application in LT is selected and transaction is performed with LT until completion. Case 01: Transaction outcome shall be set to "Try Another Interface" Cases 02-04: Transaction outcome shall be set to "Declined" M : GenerateAC - RAPDU with an TC in first GenAC To ensure that if the card responds with a TC to first GenerateAC and is permitted to do so, the PayPass reader completes the transaction offline, accepted. [MCHIP] and [OFFLINE CAPABLE] [MC v2.1]: [PayPass M/Chip Transaction Processing] [4.1 Transaction Flow] [Symbol 18] * All Issuer Action Codes have all bits set to 0b. * LT returns TC in the response to first GenerateAC. * The PayPass reader shall complete the transaction offline (accepted). * Transaction outcome shall be set to "Approved" 236

261 M : GenerateAC - Response template when CDA - mandatory items - CID To ensure that if the PayPass reader requested the card to perform CDA then the PayPass reader recognizes the mandatory Cryptogram Information Data returned in the data field of the GenerateAC response message. [CDA] and [OFFLINE CAPABLE] [MC v2.1]: [ GenerateAC Processing] [ ] * Response to GenerateAC includes all mandatory data items in the Response Message Template data object. * AIP of LT indicates CDA supported (AIP byte 1 bit 1 = 1). * Cryptogram Information Data in GenerateAC response message is coded according to Table I-14 of [EMV BOOK 3]. * LT data set, so that TC requested at 1st GenerateAC Application in LT is selected and transaction is performed with LT. * The PayPass reader shall request TC with CDA at 1st GenerateAC * The PayPass reader shall act in the appropriate manner for the returned Cryptogram Information Data (e.g. PayPass reader requests TC and ICC returns TC, the transaction is approved). 237

262 M : GenerateAC - Response template when CDA not requested - mandatory items - CID To ensure that if the PayPass reader did not request the card to perform combined DDA/AC generation then the PayPass reader recognizes the mandatory Cryptogram Information Data in a Response Message Template, encoded as specified by Table 15 of [PPMC], returned in the data field of the GenerateAC response message. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * Response to GenerateAC includes all mandatory data items in the Response Message Template data object. * AIP of LT indicates CDA not supported (AIP byte 1 bit 1 =0). * Cryptogram Information Data in GenerateAC response message is coded according to Table I-14 of [EMV BOOK 3]. Application in LT is selected and transaction is performed with LT. The PayPass reader shall act in the appropriate manner for the returned Cryptogram Information Data (e.g. PayPass reader requests TC and ICC returns TC, the transaction is approved). M : GenerateAC - Response template when CDA - mandatory items - ATC To ensure that if the PayPass reader requested the card to perform CDA then the PayPass reader recognizes the mandatory Application Transaction Counter returned in the data field of the GenerateAC response message. [CDA] and [OFFLINE CAPABLE] [MC v2.1]: [ GenerateAC Processing] [ ] * Response to GenerateAC includes all mandatory data items in the Response Message Template data object. * The Cryptogram Information Data indicates that the card generated a TC. * AIP of LT indicates CDA supported (AIP byte 1 bit 1 = 1). * LT data set, so that TC requested at 1st GenerateAC Application in LT is selected and transaction is performed with LT until completion. * The PayPass reader shall request TC with CDA at 1st GenerateAC * Value for Application Transaction Counter in Data Record given to terminal shall be in accordance with value sent back by the LT. 238

263 M : GenerateAC - Response template when CDA not requested - mandatory items - ATC To ensure that if the PayPass reader did not request the card to perform CDA then the PayPass reader recognizes the mandatory Application Transaction Counter returned in the data field of the GenerateAC response message. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * Response to GenerateAC includes all mandatory data items in the Response Message Template data object. * AIP of LT indicates CDA not supported (AIP byte 1 bit 1 = 0). Application in LT is selected and transaction is performed with LT until completion. Value for Application Transaction Counter in data record returned to the terminal shall be in accordance with value sent back by the LT. M : GenerateAC - Response template when CDA not requested - mandatory items - AC To ensure that if the PayPass reader did not request the card to perform CDA then the PayPass reader recognizes the mandatory Application Cryptogram returned in the data field of the GenerateAC response message. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * Response to GenerateAC includes all mandatory data items in the Response Message Template data object. * AIP of LT indicates CDA not supported (AIP byte 1 bit 1 = 0). Application in LT is selected and transaction is performed with LT until completion. Value for Application Cryptogram in data record returned to the terminal shall be in accordance with value sent back by the LT. 239

264 M : GenerateAC - Response template when CDA not requested - optional items - IAD To ensure that if the PayPass reader did not request the card to perform CDA then the PayPass reader recognizes the optional Issuer Application Data returned in the data field of the GenerateAC response message. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * Response to GenerateAC includes all mandatory data items and the optional data item Issuer Application Data in the Response Message Template data object. * AIP of LT indicates CDA not supported (AIP byte 1 bit 1 = 0). Application in LT is selected and transaction is performed with LT until completion. Value for Issuer Application Data in data record returned to terminal shall be in accordance with value sent back by the LT. M : GenerateAC - Response template when CDA requested - optional items - IAD To ensure that if the PayPass reader requested the card to perform CDA then the PayPass reader recognizes the optional Issuer Application Data returned in the data field of the GenerateAC response message. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ GenerateAC Processing] [ ] * Response to GenerateAC includes all mandatory data items and the optional data item Issuer Application Data in the Response Message Template data object. * The Cryptogram Information Data indicates that the card generated a TC. * The AIP has bit b1 in byte 1 set to 1b ("CDA supported"). * LT data set so that TC is requested at 1st GenerateAC Application in LT is selected and transaction is performed with LT until completion. * The PayPass reader shall request TC with CDA at 1st GenerateAC * Value for Issuer Application Data in Data Record returned to terminal shall be in accordance with value sent back by the LT. 240

265 M : GenerateAC - Proprietary data objects To ensure that the PayPass reader ignores any proprietary data objects returned in the data field of the GenerateAC response message. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates SDA supported (AIP byte 1 bit 7 = 1). * LT does not support CDA * AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) * Response to GenerateAC is in format 2 and includes Proprietary Data Object in the Response Message Template data object. Application in LT is selected and transaction is performed with LT. * The PayPass reader shall accept the card and ignore the proprietary data object in the response to the GenerateAC command. * The PayPass reader shall process the transaction until the end. M : GenerateAC - If CDA performed - data record contain valid Application Cryptogram To ensure that if the PayPass reader performs CDA, Application cryptogram in data record contain ARQC or TC contained in the ICC Dynamic Data [CDA] and [OFFLINE CAPABLE] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA supported (AIP byte 1 bit 1 = 1). * LT data set, so that TC with CDA requested at 1st GenerateAC * LT contains valid signed dynamic data Application in LT is selected and transaction is performed with LT until completion. * PayPass reader shall request TC with CDA at 1st GenerateAC * Application cryptogram in data record shall be set with ARQC or TC contained in the ICC Dynamic Data used to calculate signed dynamic application data 241

266 M : GenerateAC - SW <> 9000 To ensure that the PayPass reader rejects transaction if status in response to GenerateAC command is different from '90 00' [MCHIP] [MC v2.1]: [2.3 GenerateAC] [2.3.4 Status Bytes Table 2.2 Generic Status Bytes] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: LT returns status value '62 83' in response to GenerateAC Case 02: LT returns status value '63 00' in response to GenerateAC Case 03: LT returns status value '63 Cx' in response to GenerateAC Case 04: LT returns status value '69 83' in response to GenerateAC Case 05: LT returns status value '69 84' in response to GenerateAC Case 06: LT returns status value '69 85' in response to GenerateAC Case 07: LT returns status value '6A 81' in response to GenerateAC Case 08: LT returns status value '6A 82' in response to GenerateAC Case 09: LT returns status value '6A 83' in response to GenerateAC Case 10: LT returns status value '6A 88' in response to GenerateAC Case 11: LT returns status value '90 01' in response to GenerateAC Case 12: LT returns status value '64 00' in response to GenerateAC Case 13: LT returns status value '65 00' in response to GenerateAC Case 14: LT returns status value '67 00' in response to GenerateAC Case 15: LT returns status value '6A 86' in response to GenerateAC Case 16: LT returns status value '6D 00' in response to GenerateAC Case 17: LT returns status value '6E 00' in response to GenerateAC Case 18: LT returns status value '6F 00' in response to GenerateAC Case 19: LT returns status value 'AB 21' in response to GenerateAC The following are Refund transactions: Case 20: LT returns status value '6A 83' in response to GenerateAC Case 21: LT returns status value '6A 88' in response to GenerateAC Case 22: LT returns status value '90 01' in response to GenerateAC Case 23: LT returns status value '64 00' in response to GenerateAC The PayPass reader shall terminate processing of transaction. 242

267 M : GenerateAC - Mandatory data object - CID missing To ensure that, if a data element, classified in either [EMV BOOK 1], [EMV BOOK 3] or section 6 of Part II of [M/CHIP PROFILE] as mandatory, expected to be returned by the card is missing then the PayPass reader terminates the transaction. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates CDA not supported (AIP byte 1 bit 1 = 0). * LT response to GenerateAC does not contain Cryptogram Information Data tag. * The PayPass reader terminates the transaction after 1st GenerateAC. * Outcome of the transaction shall be End Application M : GenerateAC - Mandatory data object - AC missing To ensure that, if a data element, classified in either [EMV BOOK 1], [EMV BOOK 3] or section 6 of Part II of [M/CHIP PROFILE] as mandatory, expected to be returned by the card is missing then the PayPass reader terminates the transaction. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates CDA not supported (AIP byte 1 bit 1 = 0). * LT response to GenerateAC does not contain Application Cryptogram tag. * The PayPass reader terminates the transaction after 1st GenerateAC. * Outcome of the transaction shall be "End Application" 243

268 M : GenerateAC - Mandatory data object - ATC missing To ensure that, if a data element, classified in either [EMV BOOK 1], [EMV BOOK 3] or section 6 of Part II of [M/CHIP PROFILE] as mandatory, expected to be returned by the card is missing then the PayPass reader terminates the transaction. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates CDA not supported (AIP byte 1 bit 1 = 0). * LT response to GenerateAC does not contain Application Transaction Counter tag. * The PayPass reader terminates the transaction after 1st GenerateAC. * Outcome of the transaction shall be "End Application" M : GenerateAC - Mandatory data objects missing, format 1, TC response To ensure that the PayPass reader checks that the mandatory data is present when performing GenerateAC without CDA. [OFFLINE CAPABLE] and [MCHIP] [MC v2.1]: [2.3 GenerateAC] [2.3.3 Data Field Returned in the Response Message] * AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) * TAC/IAC set to request a TC in first GenerateAC * LT responds to GenerateAC command with a TC in format1, no optional data is present. Case 01: Application Cryptogram value is not present in first GenerateAC response Case 02: Cryptogram Information Data value is not present in first GenerateAC response Case 03: Application Transaction Counter value is not present in first GenerateAC response Application in LT is selected and transaction is performed with LT. * The PayPass reader shall terminate the transaction. 244

269 M : GenerateAC - Mandatory data objects missing, format 2, TC response To ensure that the PayPass reader checks that the mandatory data is present when performing GenerateAC [OFFLINE CAPABLE] and [MCHIP] [MC v2.1]: [2.3 GenerateAC] [2.3.3 Data Field Returned in the Response Message] * AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) * TAC/IAC set to request a TC in first GenerateAC * LT responds to GenerateAC command with a TC in format2 Case 01: Application Cryptogram value is missing from the TLV data object in the GenerateAC response (9F 26 00) Case 02: Application Cryptogram data object is missing in its entirety in the GenerateAC response Case 03: Cryptogram Information Data value is missing from the TLV data object in the GenerateAC response. (9F 27 00) Case 04: Cryptogram Information Data TLV data object is missing in its entirety in the GenerateAC response. Case 05: Application Transaction Counter value is missing from the TLV data object in the GenerateAC response (9F 36 00) Case 06: Application Transaction Counter TLV data object is missing in its entirety in the GenerateAC response Application in LT is selected and transaction is performed with LT. * The PayPass reader shall terminate the transaction. 245

270 M : GenerateAC - Response template tag missing - CDA not supported To ensure that, if a data element, classified in either [EMV BOOK 1], [EMV BOOK 3] or section 6 of Part II of [M/CHIP PROFILE] as mandatory, expected to be returned by the card is missing then the PayPass reader terminates the transaction. [MCHIP] [MC v2.1]: [ GenerateAC Processing SDA] [ , , , ] * AIP of LT indicates CDA not supported (AIP byte 1 bit 1 = 0). Test cases where: Case 01: LT response to GenerateAC has a zero-length data field (and consequently cannot contain a Response Message Template tag). Case 02: LT response to GenerateAC has a length greater than zero but does not contain Response Message Template tag. * The PayPass reader terminates the transaction after 1st GenerateAC. * Outcome of the transaction shall be End Application 246

271 M : GenerateAC - Mandatory data is missing when CDA generation requested To ensure that if CDA is requested and any mandatory data is missing in GenerateAC response, PayPass reader terminates the transaction [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates CDA supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates SDA supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37) * LT responds to GenerateAC command with a TC Case 01: Signed Dynamic Application Data (Tag 9F4B) is not present in TC response to the first GenerateAC. Case 02: Cryptogram Information Data (Tag 9F27) is not present in response to the GenerateAC Case 03: Application Transaction Counter (Tag 9F36) is not present in response to the GenerateAC Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader shall generate TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * The PayPass reader terminates the transaction after 1st GenerateAC. * Transaction outcome shall be set to 'End application' 247

272 M : GenerateAC - Additional data objects in SDAD calculation - CDA To ensure that reader uses additional data objects in GenerateAC response during verification of the SDAD data. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * Additional data object present in GenerateAC response from LT other than listed in Table 2.9 * SDAD calculation shall include the additional data object. Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader shall generate TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * The PayPass reader shall complete the transaction. * Transaction outcome shall be set to 'Approved' 248

273 M : GenerateAC - Incorrect response To ensure that the PayPass reader terminates the transaction if GenerateAC response template does not parse correctly [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: GenerateAC response template '77' of LT contains CID with bad Tag '9D 27' Case 02: GenerateAC response template '77' of LT contains ATC with bad length '03' and value field has the correct length Case 03: GenerateAC response template '77' of LT contains Application Cryptogram with bad length of the value field: Tag '9F 26', Length field '08', value on 9 bytes. Case 04: GenerateAC response template '77' of LT has the length field incorrect: total length +1 Case 05: GenerateAC response template of LT has a bad tag '70' Case 06: GenerateAC response template '80' of LT has the length field incorrect: total length +1 Transaction outcome shall be set to End Application 249

274 M : GenerateAC - Incorrect format - CDA generation requested To ensure that if the data field of the GenerateAC response message is not correctly formatted then the PayPass reader terminates the transaction when CDA is requested. [CDA] and [OFFLINE CAPABLE] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates CDA supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates SDA not supported (AIP byte 1 bit 7 = 0). * GenerateAC response template returned in response to GenerateAC does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...). * The PayPass reader shall request TC with CDA at 1st GenerateAC * The PayPass reader terminates the transaction after 1st GenerateAC. * Transaction outcome shall be set to End Application M : GenerateAC - ARQC in format 1 without CDA To ensure that the PayPass reader can use the ICC response format 1 without Enhanced Combined DDA/AC even when CDA is supported in AIP [ONLINE CAPABLE] and [CDA] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * TAC and IAC are set so that a ARQC is requested at 1st GenerateAC * LT response to GenerateAC is in format 1 without CDA. * LT answers with an ARQC to first GenerateAC. Application in LT is selected and transaction is processed with LT (in particular CDA). * Transaction outcome shall be set to 'Online Request' 250

275 M : GenerateAC - Reversal Used To ensure that the PayPass reader transmits reversal messages real-time [MCHIP] and [ODC] and [INTEGRATED_TERMINAL] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CO ] * GenerateAC response from LT is ARQC * Acquirer returns an incorrect Issuer authorization response to the terminal Application in LT is selected and transaction is processed with LT The PayPass terminal shall prepare and transmit a Reversal in real time. M : GenerateAC - Card responds with a AAC on first GenAC To ensure that if the card responds with an AAC to first GenerateAC, the PayPass reader completes the transaction offline (declined). To ensure that the PayPass reader declines the transaction if the card returned a Decline to GenerateAC. [MCHIP] [MC v2.1]: [4.1 Transaction Flow] [Symbol 14 Card Generated AAC?] Case 01 IAC and TAC set so that the PayPass reader requests an AAC in first GenerateAC, ICC responds with AAC. Case 02 IAC and TAC set so that the PayPass reader requests an ARQC in first GenerateAC, ICC responds with AAC and PayPass reader is [Online Only or Offline/Online Capable]. Case 03 IAC and TAC set so that the PayPass reader requests a TC in first GenerateAC, ICC responds with AAC and PayPass reader is [Offline Only or Offline/online Capable]. Case 01: Transaction outcome shall be set to declined Case 02 and 03: Transaction outcome shall be set to Try another interface 251

276 M : GenerateAC - AAC in format 1 or 2 To ensure that the PayPass reader can use the ICC response format 1 or 2 (as specified in book 3 part I) in CDA, when LT responds AAC to GenerateAC command. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [2.3 GenerateAC] [2.3.3 Data Field Returned in the Response Message] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: LT responds with AAC to first GenerateAC in format 1. Case 02: LT responds with AAC to first GenerateAC in format 2. Application in LT is selected and transaction is processed with LT (in particular CDA). * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * Transaction outcome shall be set to 'Try Another Interface' M : GenerateAC - Offline only and ARQC To ensure that if the card generated an ARQC, then an offline-only PayPass reader will decline the transaction. [OFFLINE ONLY] and [MCHIP] [MC v2.1]: [4.1 Transaction Flow] [Symbol 18 Card Generated ARQC (No CDA)] * LT returns ARQC in response to GenerateAC. * TACs and IACs are such as transaction is not declined. * The PayPass reader shall decline the transaction. * Transaction outcome shall be set to "Declined" 252

277 M : GenerateAC - AAC not digitally signed To ensure that the PayPass reader does not support an AAC response to GenerateAC, if the response is formatted as a TC (AAC digitally signed), in CDA. [OFFLINE CAPABLE] and [CDA] [MS v3.3]: [MC v2.1]: [EMV 4.2b]: [2CC ] * TAC and IAC are set so that an TC is requested at first GENERATE AC. * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). * LT responds with AAC to first GenerateAC digitally signed (same process as a TC) in format 2. Application in LT is selected and transaction is processed with LT (in particular CDA). * Transaction Outcome shall be set to Try Another Interface' M : GenerateAC - TC not in format 2 To ensure that the PayPass reader does not use the ICC response format 1 in CDA (as specified in book 3 part I) when responding TC. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). Case 01: TAC and IAC are set so that a TC is requested at first GenerateAC. LT answers with TC to first GenerateAC in format 1. Case 02: TAC and IAC are set so that a TC is requested at first GenerateAC. LT answers to the first GenerateAC with an ARQC in format 1. Application in LT is selected and transaction is processed with LT (in particular CDA). * TVR Byte 1, bit 8 =0 (Offline data authentication was performed) in 1st GenerateAC. * Transaction Outcome shall set to 'End Application' 253

278 M : GenerateAC - Cryptogram at a higher level than requested (1) To ensure that the PayPass reader terminates the transaction if the card responds with a cryptogram with higher level than the one requested in first GenerateAC. [MCHIP] [MC v2.1]: [ Generate AC Processing] [ ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). Case 01: IAC and TAC set so that the PayPass reader requests an AAC in first GenerateAC, ICC responds with TC Case 02: IAC and TAC set so that the PayPass reader requests an AAC in first GenerateAC, ICC responds with ARQC. Case 03: IAC and TAC set so that the PayPass reader an ARQC in first GenerateAC, ICC responds with TC and PayPass reader is [Online Only or Offline/online capable] * The PayPass reader shall terminate the transaction * Transaction outcome shall be set to "End application" M : GenerateAC - CID - AAR To verify that the PayPass reader treats an answer to a GenerateAC command requesting the ICC to return an AAR as a logical error and terminates the transaction [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] * LT response to the first GenerateAC: Case 01: LT responses an AAR without advice (C0) Case 02: LT responses an AAR with advice and no reason (C8) Case 03: LT responses an AAR with advice and reason is PIN Try Limit exceeded (CA) Case 04: LT responses an AAR with advice and reason is Issuer authentication failed (CB) Application in LT is selected and transaction is performed with LT until completion. The PayPass reader shall terminate the transaction. Specification v2.0 does not state explicitly that the reader must terminate when it receives an AAR but the specification will be clarified. 254

279 M : GenerateAC - Padding in format 1 response To ensure that the PayPass reader terminates the transaction if padding is present in format 1 GenerateAC response. [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CA ] Response to GenerateAC includes the mandatory Data Objects and the Issuer Application Data (32 bytes long) and shall be encoded with format 1 (Template 80) with 5 bytes of padding before the data objects. Application in LT is selected and transaction is performed with LT. * Transaction outcome shall be set to "End application" 255

280 M : GenerateAC - Padding in format 2 response To ensure that the PayPass reader is able to recognize the data field returned by GenerateAC command, encoded according to format 2 syntax with padding bytes 0x00 between 2 Data Elements in the Template. [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CA ] Case 01: Response to GenerateAC includes only the mandatory Data Objects and shall be encoded with format 2 (Template 77) with a "00 padding of 50 bytes between two data. Case 02: Response to GenerateAC includes the mandatory Data Objects and the Issuer Application Data and shall be encoded with format 2 (Template 77) with a "00 padding of 50 bytes after the last data. Case 03: Response to GenerateAC includes the mandatory Data Objects and the Issuer Application Data and shall be encoded with format 2 (Template 77). Tag "77 length is coded on 2 bytes (81 xx) with a "00 padding of 50 bytes between two data. Case 04: Response to GenerateAC includes the mandatory Data Objects, the Issuer Application Data and a proprietary data object with a length such that the response length is greater than 150 bytes and shall be encoded with format 2 (Template 77). Tag "77 length is coded on 2 bytes (81 xx) with a "00 padding of 50 bytes after the last data. Application in LT is selected and transaction is performed with LT. * The PayPass reader shall accept the card and interpret correctly the format 2 syntax. * The PayPass reader shall run the transaction to completion according to the LT's response to the GenerateAC command. 256

281 M : SDA - PayPass reader shall be able to store 6 CA Index per RID To ensure that if the PayPass reader supports SDA, it is able to store 6 Certification Authority Public Keys and the key-related information to be used with the key and it is able, given RID and Certification Authority Public Key Index, to locate such key. To ensure the reader is able to manage different key lengths. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ & ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: LT contains proper static signature and associated data based on the Certification Authority Public Index F3 and RID 1 (144 bytes). Case 02: LT contains proper static signature and associated data based on the Certification Authority Public Index F5 and RID 1 (248 bytes). Case 03: LT contains proper static signature and associated data based on the Certification Authority Public Index F6 and RID 1 (224 bytes). Case 04: LT contains proper static signature and associated data based on the Certification Authority Public Index 00 and RID 1 (160 bytes). Case 05: LT contains proper static signature and associated data based on the Certification Authority Public Index F1 and RID 1 (176 bytes). Case 06: LT contains proper static signature and associated data based on the Certification Authority Public Index F9 and RID 1 (192 bytes). Case 07: LT contains proper static signature and associated data based on the Certification Authority Public Index F3 and RID 2 (128 bytes). Case 08: LT contains proper static signature and associated data based on the Certification Authority Public Index F5 and RID 2 (224 bytes). Case 09: LT contains proper static signature and associated data based on the Certification Authority Public Index F6 and RID 2 (128 bytes). Case 10: LT contains proper static signature and associated data based on the Certification Authority Public Index F7 and RID 2 (144 bytes). Case 11: LT contains proper static signature and associated data based on the Certification Authority Public Index F8 and RID 2 (192 bytes). Case 12: LT contains proper static signature and associated data based on the Certification Authority Public Index F9 and RID 2 (248 bytes). Application in LT is selected and transaction is processed with LT (in particular SDA). The tests are run in a raw, without loading additional keys between the tests. * The PayPass reader shall process the transaction until completion, by requesting a TC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 257

282 M : SDA - Bit Length of all Moduli To ensure that the PayPass reader supports Moduli with a bit length being a multiple of 8 for SDA. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * Static signature in LT is valid. * Length of moduli used is multiple of 8. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Test is made for the CA key. Case 02: Test is made for the Issuer key. Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). * The PayPass reader shall process the transaction until completion, by requesting a TC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 258

283 M : SDA - Value of Certification Authority Public Key Exponent To ensure that the PayPass reader supports values 3 and 2^ as exponent for Certification Authority Public Key for SDA. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * Static signature in LT is valid. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * CDOL1 requests Terminal Capabilities * Tests are performed for amount above the CVM limit Case 01: Exponent of Certification Authority Public Key is 3. Case 02: Exponent of Certification Authority Public Key is 2^ Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. * Terminal Capabilities in CDOL1 indicates that SDA is supported 259

284 M : SDA - Value of Issuer Public Key Exponent To ensure that the PayPass reader supports values 3 and 2^ as exponent for Issuer Public Key used in SDA. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * Static signature in LT is valid. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * CDOL1 requests Terminal Capabilities * Tests are performed for amount below the CVM limit Case 01: Exponent of Issuer Public Key is 3. Case 02: Exponent of Issuer Public Key is 2^ Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. * Terminal capabilities in CDOL1 indicates that SDA is supported 260

285 M : SDA - Algorithm For SDA To ensure that the PayPass reader supports reversible algorithm for SDA as specified in Book 2, A2.1. To ensure that the PayPass reader supports Issuer Public Key Algorithm value equal to '01' with SDA. To ensure that the PayPass reader supports Hash Algorithm Indicator value equal to '01' with SDA. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Static signature in LT is good (it is calculated using the reversible algorithm). * Issuer Public Key Certificate in LT is calculated with Issuer Public Key Algorithm value equal to '01'. * Issuer Public Key Certificate in LT is calculated with Hash Algorithm Indicator value equal to '01'. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 261

286 M : SDA - Issuer Identifier with length between 3 to 8 digits To ensure that the PayPass reader correctly processes SDA, if the Recovered Issuer Identifier has a length between 3 to 8 digits. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] [EMV 4.2b]: * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Issuer Public Key Certificate in LT is calculated using Issuer Identifier with length of 3 digits and right padded with 'F' up to a length of 8 digits. Case 02: Issuer Public Key Certificate in LT is calculated using Issuer Identifier with length of 6 digits and right padded with 'F' up to a length of 8 digits. Case 03: Issuer Public Key Certificate in LT is calculated using Issuer Identifier with length of 8 digits. * The PayPass reader shall process the transaction until completion, by requesting a TC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 262

287 M : SDA - Relationship Between the Lengths of the CA, Issuer, and ICC Public Keys To ensure that if PayPass reader supports the SDA, it supports Public key Moduli with length verifying NI <= NCA. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: NI<NCA, Static signature computed by LT is valid. Case 02: NI = NCA, Static signature computed by LT is valid. Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 263

288 M : SDA - Upper bound for size of moduli To ensure that if PayPass reader supports SDA, it supports Public key Moduli with maximum length as defined below: max NI length is 248 bytes. max NCA length is 248 bytes. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Length NI = 248 bytes, length NCA = 248 bytes. * Static signature in LT is valid. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 264

289 M : SDA - Rules for Processing the records identified by the AFL To ensure that when PayPass reader performs SDA and builds the string to be signed, the PayPass reader includes all data of records referenced in AFL as participating in SDA and located in files with SFI in range 11 to 30. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * Records participating in Static Data Authentication are located in: - File with SFI 11, record 1. - File with SFI 15, records 2 and 3. - File with SFI 30, record 5. * Records from SFI are BER-TLV encoded. * Static signature in the LT is valid Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). * PayPass reader shall generate TC at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * Transaction outcome shall be set to 'Approved' 265

290 M : SDA - Rules for Processing the Input Data To ensure that if SDA is performed, the PayPass reader concatenates the data retrieved from the records identified by the AFL with the data from the SDA Tag List, and uses the concatenation as input to the string to be signed. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] [EMV 4.2b]: [2CJ ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * AFL indicates data to be included in Static Signature. * LT contains a SDA Tag List. Case 01: One record of LT indicated in AFL for Static Signature is right padded with '00' (after the last data object but in the record template). Case 02: One record of LT indicated in AFL for Static Signature is not padded. Case 03: One record of LT indicated in AFL for Static Signature is right padded with 50 bytes of value '00' (after the last data object but in the record template). Case 04: 25 records of LT indicated in AFL are used as input for Static Signature * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 266

291 M : SDA - Rules for Processing the Input Data(2) This test is for backward compatibilities, to ensure that if SDA is performed, the PayPass reader concatenates the data retrieved from the records identified by the AFL with the data from the SDA Tag List, and uses the concatenation as input to the string to be signed. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ ] [EMV 4.2b]: [2CJ ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * AFL indicates data to be included in Static Signature. * LT contains a SDA Tag List. Case 01: One record of LT indicated in AFL for Static Signature is left padded with 'FF' (before the first data object but in the record template). Case 02: One record of LT indicated in AFL for Static Signature is left padded with 50 bytes of value 'FF' (before the first data object but in the record template). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 267

292 M : SDA - Proprietary data participating in SDA To ensure that the PayPass reader is able to read and include in SDA, data objects located in proprietary files, provided that proprietary files are TLV-coded. [SDA] and [OFFLINE CAPABLE] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AFL is not a pre-defined AFL. * An EMV Data Object is included in a record, located in a proprietary file, listed in AFL, and included in the data to be signed. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * EMV Data Object located in proprietary files is TLV coded with record tag 70. * Signed Static Application Data is valid, including in the computation the tag '70' and associated length of the record contained in the proprietary files. Application in LT is selected and transaction is processed with LT (in particular SDA). * PayPass reader shall process the transaction until completion by requesting TC at 1st GenerateAC. * TVR Byte 1, bit8=0(offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 268

293 M : SDA - Hash Result of SDA calculated with a long string of data To ensure that the PayPass reader performs correctly the SDA process if the Hash Result of the Signed Static Application Data is calculated with a long string of data. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] [EMV 4.2b]: * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * Length NI = 247 bytes, length NCA = 248 bytes. * Exponent of Issuer Public Key is 3. * Signed Static Application Data in LT is calculated with the following: * An EMV file containing all the usual EMV signed data and containing in separate record where the signed data is one proprietary tag filled with 00s followed by 00 padding up to the maximum record size (252 bytes in template 70 ). * Another EMV file (in the SFI range 1 to 10) with 3 signed records, one of 127 bytes in length (with a proprietary tag and with the length coded in a single byte length), one with 127 bytes (with a proprietary tag and with the length coded in two bytes length) and one with the maximum record size length (252 bytes in template 70 ). * Sign all allowable EMV records of all EMV files of the LT (some data such as AFL, Issuer Certificate and SSAD cannot be included) * AFL is built correctly including the reference of the data authentication of the above records. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 =0 (Offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 269

294 M : SDA - Certification Revocation List update, removal To ensure that the PayPass reader is be able to update the Certification Revocation List by deleting an entry. [SDA] and [REVOC] and [OFFLINE CAPABLE] [MC v2.1]: [ SDA] [ , , ] * PayPass is loaded with 30 CRL entries (formatted according to ICS defined format) per RID. 29 of these entries per RID are based on Certificate Serial Numbers which are not signed (i.e. dummy test data) * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates that other data authentication methods are not supported * The CRL update process is completed before undertaking a PayPass transaction. * A valid CRL entry is removed from the device, where the LT Issuer Public Key Certificate is calculated with RID, CA Public Key Index and Certificate Serial Number corresponding to this valid entry. A default acquirer process as documented by the device vendor is performed to update the CRL. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * Transaction outcome shall be set to "Approved" 270

295 M : SDA - Certification Revocation List update, addition To ensure that the PayPass is able to update the Certification Revocation List by adding an entry. [SDA] and [REVOC] [MC v2.1]: [ SDA] [ , ] * Reader is loaded with 29 CRL entries and C has been performed before this test * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates that other data authentication methods are not supported * The CRL update process is completed before undertaking a PayPass transaction. * A valid CRL entry is loaded to the device, where the LT Issuer Public Key Certificate is calculated with RID, CA Public Key and Certificate Serial Number corresponding to this valid entry. * A default acquirer process as documented by the device vendor is performed to update the CRL. * Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * Transaction outcome shall be set to "End application" 271

296 M : SDA - Issuer Public Key Remainder not needed To ensure that PayPass reader performs the SDA, if Offline Static Data Authentication is supported in AIP and Issuer Public Key Remainder is missing in the card and the length of the recovered Issuer Public Key indicates that Issuer Public Key Remainder should not be present. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates Offline SDA supported (AIP byte 1 bit 7 = 1) * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Size of Issuer Public Key and CA Public Key is such as NI < NCA - 36 Case 01 - Issuer Public Key Remainder data object is not present in LT (entire data object missing: TLV) Case 02 - Issuer Public Key Remainder data object is coded with a length of '00' in LT * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 272

297 M : SDA - Processing AIP during Offline SDA To ensure that when PayPass reader performs SDA the PayPass reader checks the AIP and processes the Data Authentication accordingly. To ensure that the PayPass reader verifies signature as described in Book 2 Annex A 2.1 when SDA is performed. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate and Static signature in LT are valid. * CDOL1 requests the terminal Capabilities Application in LT is selected and transaction is processed with LT (in particular SDA). * PayPass reader shall generate TC at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * In CDOL1, Terminal Capabilities B3 b8 = 1 (SDA supported) * Transaction outcome shall be set to 'Approved' M : SDA - Card supports SDA and Not CDA To ensure that if both the card and the PayPass reader support SDA and the PayPass reader does not support CDA, then the PayPass reader performs SDA. [SDA] and [NO CDA] [MC v2.1]: [4.3.6 Offline Data Authentication Method Selection] [ ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * Issuer Public Key Certificate is missing in LT Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). * TVR Byte1 bit8 = 0: ODA was performed * TVR Byte1 bit7 = 1: SDA failed * TVR Byte1 bit3 = 0: CDA did not fail (CDA was not performed) 273

298 M : SDA - Card supports SDA, DDA and does not support CDA generation To ensure that if both the card and the PayPass reader support SDA, and the card does not support CDA, the PayPass reader performs SDA. [OFFLINE CAPABLE] and [SDA] and [CDA] [MC v2.1]: [4.3.6 Offline Data Authentication Method Selection] [ ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates DDA is supported (AIP byte 1 bit 6 = 1)* * AIP of LT indicates CDA is not supported (AIP byte 1 bit 1 = 0). * Issuer Public Key Exponent is missing in LT Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). * TVR Byte1 bit8 = 0: ODA was performed * TVR Byte1 bit7 = 1: SDA failed * TVR Byte1 bit3 = 0: CDA did not fail (CDA was not performed) *: as per DDA is not allowed M : SDA - Mandatory Data Objects for SDA To ensure that the PayPass reader verifies presence in the card of mandatory Data Objects used for SDA (if supported), and that it uses these objects. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] [EMV 4.2b]: * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Certification Authority Public Key Index is present in LT. * Issuer Public Key Certificate is present in LT. * Signed Static Application Data is present in LT. * Issuer Public Key Remainder is present in LT (The Issuer Public Key used in this test case allows the issuer public Key remainder to not be present). * Issuer Public Key Exponent is present in LT Application in LT is selected and transaction is processed with LT (in particular SDA). * PayPass reader approve the transaction by generating TC at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * Transaction outcome shall be set to 'Approved' 274

299 M : SDA - Non recognized data object participating in ODA To ensure that the PayPass reader is able to include non recognized data objects used in SDA, provided that they are read with the READ RECORD command and are located in records participating in SDA, according to AFL. [SDA] and [OFFLINE CAPABLE] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AFL is a pre-defined AFL. * A non-emv Data Object is included in a record listed in the AFL as participating in data authentication. * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate and Signed Static Application Data are valid. Application in LT is selected and transaction is processed with LT (in particular SDA). * PayPass reader shall process the transaction until completion by requesting TC at 1st GenerateAC. * TVR Byte 1, bit 8=0(Offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 275

300 M : SDA - Calculation of Dates Associated With SDA To ensure that the PayPass reader performs the processing restrictions function specified in [EMV BOOK 4]. To ensure that the PayPass reader is capable of properly calculating date associated with Static data authentication for dates before, including, and after the year 2000 [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [4.3.8 Processing Restrictions] [ ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with different Certificate Expiration Dates: Case 01: Certificate Expiration Date is Case 02: Certificate Expiration Date is Case 03: Certificate Expiration Date is Case 04: Certificate Expiration Date is Case 05: Certificate Expiration Date is Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0, (Offline data authentication was performed) bit received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC if date is before the current date. * Reader shall approve the transaction if date is later then current date. * Reader shall terminate the transaction if date is earlier then current date. 276

301 M : SDA - SSAD data set to FF To ensure that the PayPass reader is able to complete the transaction when AIP indicates SDA not supported and SSAD value set to FF [MCHIP] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates SDA is not supported (AIP byte 1 bit 7 = 0). * Value of Signed static application data is FF Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 1 (offline data authentication was not performed) received at 1st GenerateAC. * Transaction outcome shall be set to 'Approved' or online request. M : SDA - SSAD value set to 1 byte value other than FF To ensure that the PayPass reader is able to complete the transaction when AIP indicates SDA not supported and SSAD value set to 1 byte data other than FF [MCHIP] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates SDA is not supported (AIP byte 1 bit 7 = 0). * Value of Signed static application data is EE Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 1 (offline data authentication was not performed) received at 1st GenerateAC. * Transaction outcome shall be set to 'Approved' or online request. 277

302 M : SDA - SSAD has length 00 To ensure that the PayPass reader is able to complete the transaction when AIP indicates SDA not supported and SSAD value has length 00. [MCHIP] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates SDA is not supported (AIP byte 1 bit 7 = 0). * Value of Signed static application data has data with length 00 Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 1 (offline data authentication was not performed) received at 1st GenerateAC. * Transaction outcome shall be set to 'Approved' or online request. M : SDA - no ODA supported by the reader To ensure that the PayPass reader does not perform Offline Data Authentication if not supported by the reader. [NO CDA] and [NO SDA] [MC v2.1]: [4.3.6 Offline Data Authentication Method Selection] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * Issuer Public Key Certificate is missing in LT Application in LT is selected and transaction is processed with LT * TVR Byte1 bit8 = 1: ODA was not performed * TVR Byte1 bit7 = 0: SDA did not fail (SDA was not performed) * TVR Byte1 bit3 = 0: CDA did not fail (CDA was not performed) 278

303 M : SDA - SDA Tag List -Contains only AIP To ensure that the PayPass reader checks that SDA Tag List contains only AIP in SDA. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * SDA Tag List contains tag '82' (AIP). Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. M : SDA - ODA - Functions not specified in the AIP To ensure that the PayPass reader does not perform Offline Data Authentication if not supported in AIP [SDA] or [CDA] [MC v2.1]: [4.3.6 Offline Data Authentication Method Selection] [ ] * AIP of LT indicates CDA not supported (AIP byte 1 bit 1 = 0). * AIP of LT indicates SDA not supported (AIP byte 1 bit 7 = 0). * Issuer Public Key Certificate is missing in LT * LT returns data such as the transaction is accepted offline Application in LT is selected and transaction is processed with LT * TVR Byte1 bit8 = 1: ODA was not performed * TVR Byte1 bit7 = 0: SDA did not fail (SDA was not performed) * TVR Byte1 bit3 = 0: CDA did not fail (CDA was not performed) * Transaction outcome shall be set to 'Approved' 279

304 M : SDA - Unknown CA Public Key To ensure that if SDA is to be performed and if the Certification Authority Public Keys is not supported by the reader, then the PayPass reader must set the SDA failed bit in the TVR to 1b. [SDA] and [OFFLINE CAPABLE] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates CDA is not supported (AIP byte 1 bit 1 =0). * PayPass reader does not contain the Certification Authority Public Key referenced in LT. Case 01: AFL is a pre-defined AFL Case 02: AFL is not a pre-defined AFL Application in LT is selected and transaction is processed with LT (in particular SDA). * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * TVR Byte 1, bit 7 = 1 (SDA failed) received at 1st GenerateAC. 280

305 M : SDA - Set TVR when mandatory SDA objects missing To ensure that if SDA is to be performed and any mandatory SDA object is missing, the PayPass reader sets the 'ICC data missing' and SDA failed bits in the TVR to 1b. [SDA] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AIP has bit b8 in byte 2 set to 1b ("M/Chip profile supported") * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). Case 01: Index of CA Public Key is missing in LT. LT returns the SDA pre-defined AFL. Case 02: Issuer Public Key Certificate data object (entire data missing: TLV) is not present in LT. LT returns the SDA pre-defined AFL. Case 03: Issuer Public key Exponent is missing in LT. LT returns the CDA pre-defined AFL. Case 04: Signed Static Application Data missing. LT returns a non-pre-defined AFL. * TVR byte 1, bit 8=0 (offline data authentication was performed) received at 1st GenerateAC * TVR Byte 1, bit 7 = 1 (SDA failed) received at 1st GenerateAC. * TVR Byte 1, bit 6 = 1 (ICC data missing) received at 1st GenerateAC. 281

306 M : SDA - Combined test To ensure that the PayPass reader correctly behaves with the following LT profile: SDA, Issuer Public Key remainder is missing, Proprietary Data and EMV data [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ GenerateAC Processing SDA] [ , , , ] * AIP of LT = '5C 80' * Language Preference of LT = ' 6A E' * Application Version Number of LT = '02 00' * AFL of LT has a length of 20 bytes * CDOL1 of LT have a length of 128 bytes * CVM List of LT = ' E F 03' * A record of LT contain the proprietary tag '9F 54' * A record of LT contain the proprietary tag 'DF 4F' * A record of LT contain the proprietary tag '9F 55'' * CA Public Key has a length of 1984 bits * Issuer Public Key has a length of 1744 bits * Issuer Public Key Remainder is missing in LT * TAC/IAC are set, so that TC is requested at 1st GenerateAC * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC * Transaction outcome shall be "End Application" after 1st GenerateAC 282

307 M : SDA - Issuer Public Key Remainder missing To ensure that PayPass reader terminates the transaction, if Offline Static Data Authentication is supported in AIP and Issuer Public Key Remainder is missing in the card and the length of the recovered Issuer Public Key indicates that Issuer Public Key Remainder should be present [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ ] * AIP of LT indicates SDA supported (AIP byte 1 bit 7 = 1) * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Remainder data object (entire data missing: TLV) is not present in LT * Size of Issuer Public Key and CA Public Key is such as NI > NCA - 36 * PayPass reader shall process the transaction until completion by requesting a TC at 1st GenerateAC * TVR byte 1, bit 8=0 (offline data authentication was performed) received at 1st GenerateAC * PayPass reader shall terminate the transaction after 1st GenerateAC. 283

308 M : SDA - Rules for Processing the records identified in AFL To ensure that when PayPass reader performs SDA and builds the string to be signed, the PayPass reader does not include tag 70 and length for records referenced in AFL as participating in SDA but located in files with SFI in range 1 to 10. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Records participating in SDA are located in: - File with SFI 1, record 1 - File with SFI 3, records 2 and 3. - File with SFI 10, record 5. * Static signature in the LT is valid. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (Offline data authentication was performed) received at 1st GenerateAC * PayPass reader shall approve the transaction. 284

309 M : SDA - Length of Issuer Public Key Certificate To ensure that if the PayPass reader supports SDA, and if Issuer Public Key Certificate has a length different from Certification Authority Public Key Modulus, the PayPass reader fails the SDA process. [OFFLINE CAPABLE] and [SDA] [MS v3.3]: [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Issuer Public Key Certificate in LT is greater than Certification Authority Public Key Modulus. Case 02: Issuer Public Key Certificate in LT is less than Certification Authority Public Key Modulus. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 285

310 M : SDA - Recovered Data Trailer not equal to 'BC' To ensure that the PayPass reader fails the SDA process if the Data Trailer recovered from the Issuer Public Key Certificate does not equal 'BC'. [OFFLINE CAPABLE] and [SDA] [MS v3.3]: [MC v2.1]: [ SDA] [ , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * Issuer Public Key Certificate in LT is calculated with a Data Trailer different from 'BC'. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. M : SDA - Recovered Data Header not equal to '6A' To ensure that the PayPass reader fails the SDA process if the Data Header recovered from the Issuer Public Key Certificate does not equal '6A'. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with a Data Header different from '6A'. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 286

311 M : SDA - Certificate Format not equal to '02' To ensure that the PayPass reader fails the SDA process if the Certificate Format recovered from Issuer Public Key Certificate does not equal '02'. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with a Certificate Format different from '02'. Application in LT is selected and transaction is processed with LT (in particular SDA). * The reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * Reader shall terminate the transaction after 1st GenerateAC. M : SDA - Difference between calculated Hash Result and recovered Hash Result To ensure that the PayPass reader fails the SDA process if the calculated Hash Result is different from the Hash Result recovered from the Issuer Public Key Certificate. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with a bad Hash value. Case 01: Error is on the first byte of the Hash. Case 02: Error is on the last byte of the Hash. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC 287

312 M : SDA - Issuer Identifier does not match leftmost 3-8 PAN digits To ensure that the PayPass reader fails the Static Data Authentication process if the Recovered Issuer Identifier does not match the leftmost 3-8 PAN digits. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Issuer Public Key Certificate in LT is calculated with Issuer Identifier different from leftmost 3-8 PAN digits: difference is on digit 3. Case 02: Issuer Public Key Certificate in LT is calculated with Issuer Identifier different from leftmost 3-8 PAN digits: difference is on digit 8. Case 03: Issuer Public Key Certificate in LT is calculated with Issuer Identifier different from leftmost 3-8 PAN digits: difference is on all 3-8 digits. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC 288

313 M : SDA - Certificate Expiration Date earlier than today's date To ensure that the PayPass reader fails the SDA process if the Certificate Expiration Date has expired. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with Certificate Expiration Date earlier than the current date. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC M : SDA - Non-TLV coded proprietary data participating in ODA To ensure that the PayPass reader fails SDA when data objects located in proprietary files are not TLV coded with record tag 70. [OFFLINE CAPABLE] and [SDA] [MS v3.3]: [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AIP of LT indicates SDA supported (AIP byte 1 bit 7 = 1). * An EMV Data Object is included in a record, located in a proprietary file, listed in AFL, and included in the data to be signed. * EMV Data Object located in proprietary file is not TLV coded with record tag 70. * IAC Byte1 bit 7 (SDA failed) bit is set Application in LT is selected and transaction is processed with LT (in particular SDA). * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * Transaction outcome shall be set to Declined * TVR Byte 1, bit 7= 1 (SDA failed) received at 1st GenerateAC. 289

314 M : SDA - RID, CA Public Key Index and Certificate Serial Number not valid To ensure that the PayPass reader fails the SDA process if the concatenation of RID, CA Public Key Index and Certificate Serial Number indicates a revocated Certificate. [REVOC] and [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with RID, CA Public Key Index and Certificate Serial Number such that the certificate corresponds to the signed CRL entry in the revocation list of the PayPass reader. Case 01: The PayPass reader is loaded with the 30 CRL entries, specified above, for RID 1. Case 02: The PayPass reader is loaded with the 30 CRL entries, specified above, for RID 2. Application in LT is selected, for each RID as specified in each case, and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC 290

315 M : SDA - Issuer Public Key Algorithm not recognized To ensure that the PayPass reader fails the SDA process if the Issuer Public Key Algorithm is not supported (different from '01'). [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with Issuer Public Key Algorithm value different from '01'. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC M : SDA - Signed Static Application Data Length not OK To ensure that if the PayPass reader supports SDA, and if Signed Static Application Data has a length different from Issuer Public Key Modulus, the PayPass reader fails the SDA process. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Signed Static Application Data is greater than Issuer Public Key Modulus in LT. Case 02: Signed Static Application Data is less than Issuer Public Key Modulus in LT. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC 291

316 M : SDA - Recover Data Trailer not equal to 'BC'-SSAD To ensure that the PayPass reader fails the SDA process if the Data Trailer recovered from Signed Static Application Data does not equal 'BC'. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Signed Static Application Data in LT is calculated with a Data Trailer different from 'BC'. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC M : SDA - Recover Data Header not equal to '6A'-SSAD To ensure that the PayPass reader fails the SDA process if the Data Header recovered from the Signed Static Application Data does not equal '6A'. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * Signed Static Application Data in LT is calculated with a Data Header different from '6A'. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 292

317 M : SDA - Certificate Format not equal to '03'-SSAD To ensure that the PayPass reader fails the SDA process if the Certificate Format recovered from Signed Static Application Data does not equal '03'. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * Signed Static Application Data in LT is calculated with a Certificate Format different from '03'. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. M : SDA - SDA Tag List in SDA To ensure that the PayPass reader checks that SDA Tag List contains only AIP in SDA. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: SDA Tag List contains AFL Case 02: SDA Tag List contains AFL and AIP Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC 293

318 M : SDA - Difference between calculated Hash Result and recovered Hash Result- SSAD To ensure that the PayPass reader fails the SDA process if the calculated Hash Result is different from the Hash Result recovered from Signed Static Application Data. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [ SDA] [ , , ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Signed Static Application Data in LT is calculated with a bad Hash value. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC M : SDA - PayPass reader terminates when SDA failed To ensure that the PayPass reader terminates the transaction regardless of TAC/IAC settings when SDA fails. [SDA] and [OFFLINE CAPABLE] [MC v2.1]: [ Static Data Authentication] [ ] * AFL is a pre-defined AFL. * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate or Signed Static Application Data is invalid. Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall terminate the transaction after 1st GenerateAC. * Transaction outcome shall be set to "End Application" 294

319 M : CDA - GenAC Reference Control Parameter To ensure that if the result of the Terminal Action Analysis is "approved offline" (TC), and the result of Offline Data Authentication Method Selection is CDA, then the PayPass reader indicates "CDA requested" in the Reference Control Parameter of the GenerateAC command. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). * IAC and TAC set so that the PayPass reader requests TC at first GenerateAC. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion. * P1 = Reference Control Parameter (50 - TC). M : CDA - CDA is the ODA to be performed To ensure that if the AIP data object indicates that the card supports CDA generation then the PayPass reader performs CDA generation. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [4.3.6 Offline Data Authentication Method Selection] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate and ICC Public Key Certificate are valid. * Dynamic signature generated by LT is valid. * CDOL1 requests the terminal Capabilities Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader shall generate TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * In CDOL1, Terminal Capabilities B3 b4 = 1 (CDA supported) * Transaction outcome shall be set to 'Approved' 295

320 M : CDA - CDA is the ODA to be performed - SDA must not be performed To ensure that if the AIP data object indicates that the card supports CDA and the reader supports CDA as well then the PayPass reader does not perform SDA. [CDA] [MC v2.1]: [4.3.6 Offline Data Authentication Method Selection] [ ] * The AIP has bit b1 in byte 1 set to 1b ("CDA is supported"). * CDOL1 includes Unpredictable Number generated by the PayPass reader. * Issuer public Key certificate is missing in LT Case 01: The AIP has bit b7 in byte 1 set to 0b ("SDA is NOT supported"). Case 02: The AIP has bit b7 in byte 1 set to 1b ("SDA is supported"). Application in LT is selected and transaction is processed with LT (in particular CDA). * TVR Byte1 bit8 = 0: ODA was performed * TVR Byte1 bit7 = 0: SDA did NOT fail (SDA was not performed) * TVR Byte1 bit3 = 1: CDA failed M : CDA - Unpredictable Number generated by the PayPass reader To ensure that the PayPass reader generates a different random number from one transaction to another, for CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). At least three transactions are processed. The unpredictable number values generated by the PayPass reader will be compared. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * Tag 9F37 is checked and compared with the one from the previous transaction in 1st GenerateAC. They shall be different. 296

321 M : CDA - CDA not performed when card returns ARQC To ensure that reader correctly goes online when the card returns ARQC with CDA. [ONLINE CAPABLE] and [CDA] [MC v2.1]: [4.3.6 Offline Data Authentication Method Selection] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate and ICC Public Key Certificate are valid. * Dynamic signature generated by LT is valid. Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader shall generate TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * Transaction outcome shall be set to 'Online Request' 297

322 M : CDA - Rules for Processing the Input Data To ensure that if CDA is performed, the PayPass reader concatenates the data retrieved from the records identified by the AFL with the data from the SDA Tag List, and uses the concatenation as input to the string to be signed. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] [EMV 4.2b]: [2CJ ] * * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate, ICC Public Key Certificate and Dynamic signature are valid. Case 01: One record of LT indicated in AFL for Static Signature is right padded with '00' (after the last data object but in the record template). Case 02: One record of LT indicated in AFL for Static Signature is not padded. Case 03: One record of LT indicated in AFL for Static Signature is right padded with 50 bytes of value '00' (after the last data object but in the record template). Case 04: 25 records of LT indicated in AFL are used as input for Static Signature * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 298

323 M : CDA - Rules for Processing the Input Data(2) This test is for backward compatibilities, to ensure that if CDA is performed, the PayPass reader concatenates the data retrieved from the records identified by the AFL with the data from the SDA Tag List, and uses the concatenation as input to the string to be signed. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [EMV 4.2b]: [2CJ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate, ICC Public Key Certificate and Dynamic signature are valid. Case 01: One record of LT indicated in AFL for Static Signature is left padded with 'FF' (before the first data object but in the record template). Case 02: One record of LT indicated in AFL for Static Signature is left padded with 50 bytes of value 'FF' (before the first data object but in the record template). * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 299

324 M : CDA - Proprietary data participating in offline CDA generation To ensure that the PayPass reader is able to read and include in Offline CDA, data objects located in proprietary files, provided that proprietary files are TLV-coded. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * An EMV Data Object is included in a record, located in a proprietary file, listed in AFL, and included in the data to be signed. * AIP of LT indicates CDA is supported (AIP byte 1 bit b1 = 1). * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * EMV Data Object located in proprietary files are TLV coded with record tag 70. * ICC Public Key Certificate is valid including in the computation the tag '70' and associated length of the record contained in the proprietary files. Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader approve the transaction by generating TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * Transaction outcome shall be set to 'Approved' after 1st GenerateAC 300

325 M : CDA - Non recognized data object participating in ODA To ensure that the PayPass reader is able to include non recognized data objects used in CDA, provided that they are read with the READ RECORD command and are located in records participating in CDA, according to AFL. [CDA] and [OFFLINE CAPABLE] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AFL is a pre-defined AFL. * A non-emv Data Object is included in a record listed in the AFL as participating in data authentication. * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate, ICC Public Key Certificate and Dynamic signature are valid. Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader shall process the transaction until completion by requesting TC with CDA at 1st GenerateAC. * TVR Byte 1, bit8=0(offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 301

326 M : CDA - Rules for Processing the records identified by the AFL - SFI in range To ensure that when PayPass reader performs CDA and builds the string to be signed, the PayPass reader includes all data of records referenced in AFL as participating in CDA and located in files with SFI in range 11 to 30. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Records participating in CDA are located in: - File with SFI 11, record 1. - File with SFI 15, records 2 and 3. - File with SFI 30, record 5. * Records from SFI are BER-TLV encoded. * Dynamic signature generated by the LT is valid. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 302

327 M : CDA - Hash Result of ICC Public Key calculated with a long string of data To ensure that the PayPass reader performs correctly the Combined Data Authentication process if the Hash Result of the ICC Public Key Certificate is calculated with a long string of data [OFFLINE CAPABLE] and [CDA] [MS v3.3]: [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] [EMV 4.2b]: [2CC , 2CC ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * LT returns a TC to the first GEN AC. * Length NIC = 238 bytes, length NI = 247 bytes, length NCA = 248 bytes. * Exponent of ICC Public Key is 3. * Static Application Data to be authenticated in LT is calculated with the following: - An EMV file containing all the usual EMV signed data and containing in separate record where the signed data is one proprietary tag filled with 00s followed by 00 padding up to the maximum record size (252 bytes in template 70 ). - Another EMV file (in the SFI range 1 to 10) with 3 signed records, one of 127 bytes in length (with a proprietary tag and with the length coded in a single byte length), one with 127 bytes (with a proprietary tag and with the length coded in two bytes length) and one with the maximum record size length (252 bytes in template 70 ). - Sign all allowable EMV records of all EMV files of the LT (some data such as AFL, Issuer Certificate and SSAD cannot be included) - AFL is built correctly including the reference of the data authentication of the above records. Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader shall request TC with CDA at 1st GenerateAC * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * Transaction outcome shall be set to 'Approved' 303

328 M : CDA - Issuer Identifier with length between 3 to 8 digits (2) To ensure that the PayPass reader correctly processes the CDA, if the Recovered Issuer Identifier has a length between 3 and 8 digits [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * TAC/IAC set to request a TC in the 1st GenerateAC, and LT responds TC. Case 01: Issuer Public Key Certificate in LT is calculated using Issuer Identifier with length of 3 digits and right padded with 'F' up to a length of 8 digits. Case 02: Issuer Public Key Certificate in LT is calculated using Issuer Identifier with length of 6 digits and right padded with 'F' up to a length of 8 digits. Case 03: Issuer Public Key Certificate in LT is calculated using Issuer Identifier with length of 8 digits. Application in LT is selected and transaction is processed with LT * PayPass reader approve the transaction by generating TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * Transaction outcome shall be set to 'Approved' 304

329 M : CDA - Bit Length of All Moduli To ensure that the PayPass reader supports Moduli with a bit length which is a multiple of 8 for CDA [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * Dynamic signature computed by LT is valid. * Length of moduli used is multiples of 8 for the CA key, Issuer key and ICC key. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Application in LT is selected and transaction is processed with LT (in particular Combined Data Authentication). * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 305

330 M : CDA - PDOL in CDA To ensure that the PayPass reader can use PDOL in CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: PDOL is present in LT. Case 02: PDOL is empty in LT. Case 03: no PDOL in LT. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 306

331 M : CDA - Values of CDOL1 for Transaction Data hash To ensure that the PayPass reader stores the values of the data elements specified by CDOL1 for CDA at the first GenerateAC. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * LT sends a TC at 1st GenerateAC, CDA is correct at the 1st GenerateAC. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion by requesting a TC with CDA at 1st GenerateAC * TVR Byte 1, bit 8 = 0 (Offline data authentication was performed) at 1st GenerateAC. * The PayPass reader shall approve the transaction. M : CDA - Non-TLV coded proprietary data participating in ODA To ensure that the PayPass reader fails CDA when data objects located in proprietary files are not TLV coded with record tag 70. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * An EMV Data Object is included in a record, located in a proprietary file (SFI 11 to 30), listed in AFL, and included in the data to be signed. * EMV Data Object located in proprietary files is not TLV coded with record tag 70. * IAC Byte 1 bit 3 (CDA failed) bit is set * ICC Public Key Certificate is valid. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * Transaction outcome shall be set to Declined * TVR Byte 1, bit 3= 1 (CDA failed) received at 1st GenerateAC. 307

332 M : CDA - Value of CA Public Key Exponent To ensure that the PayPass reader supports value 3 and 2^ as exponent for Certification Authority Public Key used in CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * Dynamic signature computed by LT is valid. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * CDOL1 requests Terminal Capabilities * Tests are performed for amount above the CVM limit Case 01: Exponent of Certification Authority Public Key is 3. Case 02: Exponent of Certification Authority Public Key is 2^ * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. * Terminal Capabilities in CDOL1 indicates that CDA is supported 308

333 M : CDA - Value of Issuer Public Key Exponent To ensure that the PayPass reader supports value 3 and 2^ as exponent for Issuer Public Key used in CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * Dynamic signature computed by LT is valid. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * CDOL1 requests Terminal Capabilities * Tests are performed for amount below the CVM limit Case 01: Exponent of Issuer Public Key is 3. Case 02: Exponent of Issuer Public Key is 2^ Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. * Terminal Capabilities in CDOL1 indicates that CDA is supported. 309

334 M : CDA - Value of ICC Public Key Exponent To ensure that the PayPass reader supports value 3 and 2^ as exponent for ICC Public Key used in CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * Dynamic signature computed by LT is valid. * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Exponent of ICC Public Key is 3. Case 02: Exponent of ICC Public Key is 2^ * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. M : CDA - Success when 9F 4B data length < 128bytes and length coded on 2 bytes. To ensure that PayPass reader is able to complete combined DDA/AC successfully if Signed Dynamic Application Data length has length smaller than 128 bytes and length coded on 2 bytes. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [Field Issue] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * Signed dynamic application data is valid and length smaller than 128 bytes and coded on 2 bytes. * TAC and IAC are set so that TC is requested at 1st GenerateAC * LT returns TC at 1st GenerateAC. Application in LT is selected and transaction is performed with LT until completion. * The PayPass reader shall request TC with CDA at 1st GenerateAC * Transaction outcome shall be set to Approved 310

335 M : CDA - Success when 9F 4B data length > 128bytes and length coded on 2 bytes. To ensure that PayPass reader is able to complete CDA successfully if Signed Dynamic Application Data length has length greater than 128 bytes and length coded on 2 bytes. [CDA] and [OFFLINE CAPABLE] [MC v2.1]: [Field Issue] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * Signed dynamic application data is valid and length greater than 128 bytes and coded on 2 bytes. * TAC and IAC are set so that TC is requested at 1st GenerateAC * LT returns TC at 1st GenerateAC. Application in LT is selected and transaction is performed with LT until completion. * The PayPass reader shall request TC with CDA at 1st GenerateAC * Transaction outcome shall be set to Approved 311

336 M : CDA - Upper bound for size of moduli To ensure that if PayPass reader supports CDA, it supports Public key Moduli with maximum length as defined below: - max NIC length is 240 bytes - max NI length is 247 bytes - max NCA length is 248 bytes. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Dynamic signature computed by LT is valid * LT response of GenerateAC is in format 2 and IAD is not present. Case 01: length NCA = 248 bytes, length NI < 100 bytes, Length NIC <= NI Case 02: length NCA = 248 bytes, length NI = 247 bytes, Length NIC < 100 bytes Case 03: length NCA = 248 bytes, length NI = 247 bytes, Length NIC = 240 bytes Case 04: length NCA=248 bytes, length NI=247 bytes, Length NIC=240 bytes. The AFL is not a PayPass standard one. Only one record is signed. The LT returns Third Party Data (in Read Record) with max length as well as SDAD as well as PayPass MagStripe data plus other data so that the total RAPDU length (PPSE, ADF, GPO, RR, GenAC) is around 1406 bytes. Case 05: length NCA=248 bytes, length NI=247 bytes, Length NIC=240 bytes. The AFL is not a PayPass standard one. Three records are signed. The LT returns Third Party Data (in Read Record) with max length as well as SDAD as well as PayPass MagStripe data plus other data so that the total RAPDU length (PPSE, ADF, GPO, RR, GenAC) is around 1406 bytes * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 =0 (Offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. EMV 4.2 book 2 Annex D details the maximum lengths allowed when CDA is performed. 312

337 M : CDA - PayPass reader shall be able to store 6 CA Index per RID To ensure that if the PayPass reader supports CDA, it is able to store 6 Certification Authority Public Keys as well as the key-related information to be used with the key and it is able, given RID and Certification Authority Public Key Index, to locate such key. To ensure the reader is able to manage different key lengths. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * Reader supports two RIDs (RIDs 1 and RIDs 2). * PayPass reader is loaded with the 6 Certification Authority Public Keys (from Key index 00 to 05) per RID * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1) * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: LT generates proper good dynamic signature and associated data based on the Certification Authority Public Index 00 and RID 1 (160 bytes). Case 02: LT generates proper good dynamic signature and associated data based on the Certification Authority Public Index F3 and RID 1 (144 bytes). Case 03: LT generates proper good dynamic signature and associated data based on the Certification Authority Public Index F1 and RID 1 (176 bytes). Case 04: LT generates proper good dynamic signature and associated data based on the Certification Authority Public Index F6 and RID 1 (224 bytes). Case 05: LT generates proper good dynamic signature and associated data based on the Certification Authority Public Index F5 and RID 1 (248 bytes). Case 06: LT generates proper good dynamic signature and associated data based on the Certification Authority Public Index F9 and RID 1 (192 bytes). Case 07: LT generates proper good dynamic signature and associated data based on the Certification Authority Public Index 00 and RID 2. Case 08: LT generates proper good dynamic signature and associated data based on the Certification Authority Public Index 02 and RID 2. Case 09: LT generates proper good dynamic signature and associated data based on the Certification Authority Public Index 05 and RID 2. The tests are run in a raw, without loading additional keys between the tests. * PayPass reader approves the transaction by generating TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * Transaction outcome shall set to 'Approved' 313

338 M : CDA - Relationship Between the Lengths of the CA, Issuer, and ICC Public Keys To ensure that if PayPass reader supports the CDA, it supports Public key Moduli with length verifying NIC <= NI <= NCA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: NIC<NI<NCA, Dynamic signature computed by LT is valid. Case 02: NIC = NI = NCA, Dynamic signature computed by LT is valid. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 =0 (Offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 314

339 M : CDA - Algorithm for CDA To ensure that the PayPass reader supports reversible algorithm for CDA as specified in Book 2, A2.1. To ensure that the PayPass reader supports Issuer Public Key Algorithm value equal to '01' in CDA. To ensure that the PayPass reader supports ICC Public Key Algorithm value equal to '01' in CDA. * To ensure that the PayPass reader supports Hash Algorithm Indicator value equal to '01' with CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1) * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Dynamic signature computed by LT is valid (it is calculated using the reversible algorithm). * Issuer Public Key Certificate in LT is calculated with Issuer Public Key Algorithm value equal to '01'. * ICC Public Key Certificate in LT is calculated with ICC Public Key Algorithm value equal to '01'. * Issuer Public Key Certificate in LT is calculated with Hash Algorithm Indicator value equal to '01'. * ICC Public Key Certificate in LT is calculated with Hash Algorithm Indicator value equal to '01'. Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader approve the transaction by generating TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * Transaction outcome shall be set to 'Approved' 315

340 M : CDA - Issuer Public Key Remainder not needed To ensure that PayPass reader performs the CDA, if CDA is supported in AIP and Issuer Public Key Remainder is missing in the card and the length of the recovered Issuer Public Key indicates that Issuer Public Key Remainder should not be present. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = '1') * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Size of Issuer Public Key and CA Public Key is such as NI < NCA - 36 Case 01 - Issuer Public Key Remainder data object is not present in LT (entire data object missing: TLV) Case 02 - Issuer Public Key Remainder data object is coded with a length of '00' in LT * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * Transaction outcome shall be set "Approved". 316

341 M : CDA - ICC Public Key Remainder not needed To ensure that PayPass reader performs the CDA, if CDA is supported in AIP and ICC Public Key Remainder is missing in the card and the length of the recovered ICC Public Key indicates that ICC Public Key Remainder should not be present. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = '1') * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Size of ICC Public Key and Issuer Public Key is such as NICC < NI - 42 Case 01 - ICC Public Key Remainder data object is not present in LT (entire data object missing: TLV) Case 02 - ICC Public Key Remainder data object is coded with a length of '00' in LT * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * Transaction outcome shall be set to "Approved" M : CDA - no CDA request if ARQC To ensure the PayPass reader does not request CDA when ARQC is requested at 1st GenerateAC [ONLINE CAPABLE] [MC v2.1]: [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * data returned by LT is such as no bit is set in TVR byte 1. * LT data set, so that PayPass reader requests ARQC at 1st GenerateAC * PayPass Reader shall request ARQC at 1st GenerateAC * PayPass reader must not indicate "CDA requested" in the Reference Control Parameter of the GenerateAC command. * Transaction outcome shall be set to Online Request 317

342 M : CDA - Length of Issuer Public Key Certificate To ensure that if the PayPass reader supports CDA, and if Issuer Public Key Certificate has a length different from Certification Authority Public Key Modulus, the PayPass reader fails the CDA process. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Issuer Public Key Certificate in LT is greater than Certification Authority Public Key Modulus. Case 02: Issuer Public Key Certificate in LT is less than Certification Authority Public Key Modulus. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 318

343 M : CDA - Recovered Issuer Data Trailer not equal to 'BC' To ensure that the PayPass reader fails the CDA process, if the Data Trailer recovered from the Issuer Public Key Certificate does not equal 'BC'. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with a Data Trailer different from 'BC'. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. M : CDA - Recovered ICC Data Trailer not equal to 'BC' To ensure that the PayPass reader fails the CDA process, if the Data Trailer recovered from the ICC Public Key Certificate does not equal 'BC'. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * ICC Public Key Certificate in LT is calculated with a Data Trailer different from 'BC'. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 319

344 M : CDA - Recovered Issuer Data Header not equal to '6A' To ensure that the PayPass reader fails the CDA, if the Data Header recovered from the Issuer Public Key Certificate does not equal '6A'. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with a Data Header different from '6A'. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. M : CDA - Certificate Format not equal to '02' To ensure that the PayPass reader fails the CDA, if the Certificate Format recovered from Issuer Public Key Certificate does not equal '02'. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with a Certificate Format different from '02'. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 320

345 M : CDA - Calculated Hash Result <> recovered Issuer Hash Result (2) To ensure that the PayPass reader fails the CDA process, if the calculated Hash Result is different from the Hash Result recovered from the Issuer Public Key Certificate. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with a bad Hash value. Case 01: Error is on the first byte of the Hash. Case 02: Error is on the last byte of the Hash. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. M : CDA - Calculated Hash Result <> recovered ICC Hash Result To ensure that the PayPass reader fails the CDA process, if the calculated Hash Result is different from the Hash Result recovered from the ICC Public Key Certificate. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * ICC Public Key Certificate in LT is calculated with a bad Hash value. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 321

346 M : CDA - Issuer Application Data To ensure that the PayPass reader can use Issuer Application Data in CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * LT responds with TC to first GenerateAC. * Issuer Application Data is present in response to first GenerateAC command. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction by requesting a TC at 1st GenerateAC. * TVR Byte1 bit 8 = 0 (Offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 322

347 M : CDA - Issuer Identifier does not match leftmost 3-8 PAN digits To ensure that the PayPass reader fails the CDA process, if the Recovered Issuer Identifier does not match the leftmost 3-8 PAN digits. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Issuer Public Key Certificate in LT is calculated with Issuer Identifier different from leftmost 3-8 PAN digits: difference is on digit 3. Case 02: Issuer Public Key Certificate in LT is calculated with Issuer Identifier different from leftmost 3-8 PAN digits: difference is on digit 8. Case 03: Issuer Public Key Certificate in LT is calculated with Issuer Identifier different from leftmost 3-8 PAN digits: difference is on all 3-8 digits. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 323

348 M : CDA - Issuer Certificate Expiration Date earlier than today's date To ensure that the PayPass reader fails the CDA process, if the Issuer Certificate Expiration Date is earlier than the current date. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with Certificate Expiration Date earlier than the current date. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. M : CDA - ICC Certificate Expiration Date earlier than today's date To ensure that the PayPass reader fails the CDA process, if the ICC Certificate Expiration Date is earlier than the current date. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * ICC Public Key Certificate in LT is calculated with Certificate Expiration Date earlier than the current date. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 324

349 M : CDA - RID, CA Public Key Index and Certificate Serial Number not valid To ensure that the PayPass reader fails the CDA, if the concatenation of RID, CA Public Key Index and Certificate Serial Number indicates a revocated Certificate. [OFFLINE CAPABLE] and [CDA] and [REVOC] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with RID, CA Public Key Index and Certificate Serial Number such that the certificate corresponds to the signed CRL entry in the revocation list of the PayPass reader. Case 01:The PayPass reader is loaded with the 30 CRL entries, specified above, for RID 1. Case 02:The PayPass reader is loaded with the 30 CRL entries, specified above, for RID 2. Application in LT is selected, for each RID as specified in each case, and transaction is processed with LT.(in particular CDA) * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 325

350 M : CDA - RID, CA Public Key Index and Certificate Serial Number not valid (2) To ensure that when supporting Certification Revocation List (CRL), thirty entries per RID are supported, and when the PayPass fails the CDA process if the concatenation of RID, CA Public Key Index and Certificate Serial Number and any additional data indicates a revoked certificate. [CDA] and [REVOC] and [OFFLINE CAPABLE] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] PayPass reader supports three RIDs PayPass reader is loaded with 30 CRL entries (formatted according to ICS defined format) per RID 29 of these entries are based on Certificate Serial Numbers which are not signed (i.e. dummy test data) * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at first Gen AC. * Issuer Public Key Certificate in LT is calculated with RID, CA Public Key Index and Certificate Serial Number such that the certificate correspond to the signed CRL valid entry in the revocation list of the PayPass reader. Case 01: The PayPass reader is loaded with the 30 CRL entries, specified above, for RID 1. Case 02: The PayPass reader is loaded with the 30 CRL entries, specified above, for RID 2. Application in LT is selected, for each RID as specified in each case, and transaction is processed with LT * PayPass reader shall process the transaction until completion by request a TC at 1st GENERAT AC * Transaction outcome shall be set to "End application" 326

351 M : CDA - Issuer Public Key Algorithm not recognized To ensure that the PayPass reader fails the CDA process, if the Issuer Public Key Algorithm is not supported (different from '01'). [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Certificate in LT is calculated with Issuer Public Key Algorithm value different from '01'. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. M : CDA - Length of ICC Public Key Certificate To ensure that if the PayPass reader supports CDA, and if ICC Public Key Certificate has a length different from that of Issuer Public Key Modulus, the PayPass reader fails the CDA process. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: ICC Public Key Certificate in LT is greater than Issuer Public Key Modulus. Case 02: ICC Public Key Certificate in LT is less than Issuer Public Key Modulus. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 327

352 M : CDA - Recovered ICC Data Header not equal to '6A' To ensure that the PayPass reader fails the CDA process, if the Data Header recovered from the ICC Public Key Certificate does not equal '6A'. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * ICC Public Key Certificate in LT is calculated with a Data Header different from '6A'. * IAC s and TAC s are set so that TC is requested at first Gen AC. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 328

353 M : CDA - ODA - Functions not specified in the AIP To ensure that the PayPass reader does not perform CDA if not supported by the ICC, as specified in the Application Interchange Profile. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ ] * AIP of LT indicates CDA is not supported (AIP byte 1 bit 1 = 0). * AIP of LT indicates SDA is not supported (AIP byte 1 bit 7 = 0). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37) * LT responds to GenerateAC command with a TC Application in LT is selected and transaction is processed with LT * The PayPass reader shall not ask the ICC to process a CDA in 1st GenerateAC. * The PayPass reader shall process the transaction until completion, by requesting a TC. * TVR Byte1 bit8 = 1: ODA was not performed * Transaction outcome shall be set to 'Approved' M : CDA - Certificate Format not equal to '04'-ICC Certificate To ensure that the PayPass reader fails the CDA process, if the Certificate Format recovered from ICC Public Key Certificate does not equal '04'. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * ICC Public Key Certificate in LT is calculated with a Certificate Format different from '04'. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 329

354 M : CDA - SDA Tag List Contains AFL To ensure that the PayPass reader checks that SDA Tag List contains only AIP while performing CDA process. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: SDA Tag List contains AFL, certificate and hash are calculated with the AFL value. Case 02: SDA Tag List contains AFL and AIP, certificate and hash are calculated with the AFL and AIP values. Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader shall generate TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * Transaction outcome shall be set to 'End application' M : CDA - Recovered PAN is not equal to read PAN-ICC Certificate To ensure that the PayPass reader fails the CDA process, if the Recovered PAN does not match the PAN digits recovered from the LT. [OFFLINE CAPABLE] and [CDA] [MS v3.3]: [MC v2.1]: [EMV 4.2b]: [2CC ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * ICC Public Key Certificate in LT is calculated with Issuer ID different from PAN in LT. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 330

355 M : CDA - ICC Public Key Algorithm not recognized To ensure that the PayPass reader fails the CDA process, if the ICC Public Key Algorithm used is not supported (different from '01'). [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * ICC Public Key Certificate in LT is calculated with ICC Public Key Algorithm value different from '01'. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. * Transaction outcome shall be set to "End application" 331

356 M : CDA - SDAD Length To ensure that the PayPass reader compares the Signed Dynamic Application Data length with the ICC Public Key length for CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * CDOL1 in LT include Unpredictable Number generated by the PayPass reader (tag 9F 37). * Length of Signed Dynamic Application Data is different from the ICC Public Key length. LT responds to the 1st GenerateAC with a TC. Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader shall generate a TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed * The PayPass reader shall terminate the transaction * Transaction outcome shall be set to 'End application' 332

357 M : CDA - Recovered Data trailer not equal to BC-SDAD To ensure that the PayPass reader checks the recovered data trailer for CDA. [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Data trailer is different from BC. Case 01: LT responds with TC. Case 02: LT responds with ARQC. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion with requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC 333

358 M : CDA - Recovered Data header not equal to 6A-SDAD To ensure that the PayPass reader checks the recovered data header for CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Data header is different from 6A. * LT responds with TC. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion with requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC 334

359 M : CDA - Recovered Signed Data Format not equal to 05-SDAD To ensure that the PayPass reader checks the recovered signed data format for CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Signed Data Format is different from 05. * LT responds with TC. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion with requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC 335

360 M : CDA - Recovered CID different from CID obtained after GenAC (1) To ensure that the PayPass reader checks that the CID recovered for CDA is the same as that transmitted in the response to the GenerateAC command. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT include Unpredictable Number generated by the PayPass reader (tag 9F 37). * TAC and IAC are set so that a TC is requested at first GenerateAC. * LT responds to the first GenerateAC with a TC. * CID in signature is ARQC. Application in LT is selected and transaction is processed with LT (in particular CDA). * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC. 336

361 M : CDA - Compare hash result-sdad To ensure that the PayPass reader compares the hash result for CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT include Unpredictable Number generated by the PayPass reader (tag 9F 37). * Hash result is corrupted. * LT responds to the 1st GenerateAC with a TC. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion with requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC * Transaction Outcome shall be set to 'End Application' 337

362 M : CDA - Compare Transaction Data Hash Code-SDAD To ensure that the PayPass reader compares the Transaction Data Hash Code for CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Transaction Data Hash result is corrupted. * LT responds to the first GenerateAC with a TC. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion with requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC * Transaction Outcome shall be set to 'End Application' M : CDA - Unknown CA Public Key To ensure that if CDA is to be performed and if the Certification Authority Public Key returned by the card is not supported by the reader, then the PayPass reader must set the CDA failed bit in the TVR to 1b. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * PayPass reader does not contain the Certification Authority Public Key referenced in LT. * IAC's and TAC's are set so that TC is requested at first Gen AC. Application in LT is selected and transaction is processed with LT (in particular CDA). * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * TVR Byte 1, bit 3 = 1 (CDA failed) received at 1st GenerateAC. 338

363 M : CDA - Set TVR when mandatory CDA objects missing To ensure that if CDA is to be performed and any mandatory CDA object is missing in ICC, the PayPass reader sets the 'ICC data missing' and CDA failed bits in the TVR to 1b and does not indicate CDA requested in the Reference Control Parameter of the GenerateAC command. [CDA] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IACs and TACs are set to zero Case 01: CA Public Key Index is missing in LT. LT returns the CDA pre-defined AFL. Case 02: Issuer Public Key Certificate data object (entire data missing: TLV) is missing in LT. LT returns the CDA pre-defined AFL. Case 03: Issuer Public key Exponent is missing in LT. LT returns a non-pre-defined AFL. Case 04: ICC Public Key Certificate data object is missing in LT. LT returns a non-predefined AFL. Case 05: ICC Public Key Exponent data object is missing in LT. LT returns the CDA predefined AFL. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * TVR Byte 1, bit 3 = 1 (CDA failed) received at 1st GenerateAC. * TVR Byte 1, bit 6 = 1 (ICC data missing) received at 1st GenerateAC. * The reader shall not indicate CDA requested in the Reference Control Parameter of the GenerateAC command*. An online-only reader may send an ARQC. 339

364 M : CDA - Response template tag missing - CDA supported To ensure that, if a data element, classified in either [EMV BOOK 1], [EMV BOOK 3] or section 6 of Part II of [M/CHIP PROFILE] as mandatory, expected to be returned by the card is missing then the PayPass reader terminates the transaction. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ GenerateAC Processing SDA] [ , , , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * LT data set, so that TC is requested at 1st GenerateAC * LT response to GenerateAC does not contain Response Message Template tag. * The PayPass reader shall request TC with CDA at 1st GenerateAC * The PayPass reader terminates the transaction after 1st GenerateAC. * Outcome of the transaction shall be End Application M : CDA - Issuer Public Key Remainder missing To ensure that PayPass reader terminates the transaction, if Offline CDA is supported in AIP and Issuer Public Key Remainder is missing in the card and the length of the recovered Issuer Public Key indicates that Issuer Public Key Remainder should be present [CDA] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] [EMV 4.2b]: [2CL ] * AIP of LT indicates CDA supported (AIP byte 1 bit 1 = 1) * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Issuer Public Key Remainder data object (entire data missing: TLV) is not present in LT * Size of Issuer Public Key and CA Public Key is such as NI > NCA - 36 * PayPass reader shall process the transaction until completion by requesting a TC at 1st GenerateAC * TVR byte 1, bit 8=0 (offline data authentication was performed) received at 1st GenerateAC * PayPass reader shall terminate the transaction after 1st GenerateAC. 340

365 M : CDA - ICC Public Key Remainder missing To ensure that PayPass reader terminates the transaction, if Offline CDA is supported in AIP and ICC Public Key Remainder is missing in the card and the length of the recovered ICC Public Key indicates that ICC Public Key Remainder should be present [CDA] [MS v3.3]: [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] [EMV 4.2b]: [2CL ] * AIP of LT indicates CDA supported (AIP byte 1 bit 1 = 1) * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * ICC Public Key Remainder data object (entire data missing: TLV) is not present in LT * Size of ICC Public Key and CA Public Key is such as NICC> NI - 42 * PayPass reader shall process the transaction until completion by requesting a TC at 1st GenerateAC * TVR byte 1, bit 8=0 (offline data authentication was performed) received at 1st GenerateAC * PayPass reader shall terminate the transaction after 1st GenerateAC. 341

366 M : CDA - Rules for Processing the records identified by the AFL - SFI in range 1-10 To ensure that when PayPass reader performs CDA and builds the string to be signed, the PayPass reader does not include tag 70 and length for records referenced in AFL as participating in CDA but located in files with SFI in range 1 to 10. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Records participating in CDA are located in: - File with SFI 1, record 1. - File with SFI 3, records 2 and 3. - File with SFI 10, record 5. * Dynamic signature generated by the LT is valid. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. 342

367 M : CDA - Certification Revocation List update, removal To ensure that the PayPass reader is be able to update the Certification Revocation List by deleting an entry. [CDA] and [REVOC] and [OFFLINE CAPABLE] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * PayPass reader is loaded with 30 CRL entries (formatted according to ICS defined format) per RID. 29 of these entries are based on Certificate Serial Numbers which are not signed (i.e. dummy test data) * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates that other data authentication methods are not supported * The CRL update process is completed before undertaking an PayPass transaction * A valid CRL entry is removed from the device, where the LT Issuer Public Key Certificate in LT is calculated with RID, CA Public Key Index and Certificate Serial Number to correspond to this valid entry. * A default acquirer process as documented by the device vendor is performed to update the CRL. * Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GENERAT AC * Transaction outcome shall be set to "Approved" 343

368 M : CDA - Certification Revocation List update, addition To ensure that the PayPass reader is be able to update the Certification Revocation List by adding an entry. [CDA] and [REVOC] and [OFFLINE CAPABLE] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] [EMV 4.2b]: [2CC ] * PayPass reader is loaded with 29 CRL entries and m has been performed before this test * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates that other data authentication methods are not supported * The CRL update process is completed before undertaking a PayPass transaction. * A valid CRL entry is loaded to the device, where the LT Issuer Public Key Certificate in LT is calculated with RID, CA Public Key Index and Certificate Serial Number to correspond to this valid entry. * A default acquirer process as documented by the device vendor is performed to update the CRL. * Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion, by requesting a TC * Transaction outcome shall be set to "End application" M : CDA - No CDA generation when AAC To ensure that CDA is not requested when the device generates an AAC in the 1st GenerateAC. [CDA] and [OFFLINE CAPABLE] [MC v2.1]: [ ] * AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT includes Unpredictable Number generated by the PayPass reader (tag 9F 37). * data returned by LT is such as no bit is set in TVR byte 1. * TAC and IAC are such that the PayPass reader requests AAC at first GenerateAC. Application in LT is selected and transaction is processed with LT (in particular CDA). * The PayPass reader shall process the transaction until completion, as a decline. * TVR byte 1 is 00 * P1 = '00' at first GenerateAC 344

369 M : CDA - CDA failed when ICC responded with TC (1) * To ensure that the PayPass reader terminates the transaction if ICC has responded with TC and CDA failed [CDA] and [OFFLINE CAPABLE] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * LT responds TC to the GenerateAC. * Digital signature is not valid. Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader shall process the transaction by requesting a TC with CDA at 1st GENERAE AC * TVR byte 1, bit 8 =0(Offline data authentication was performed) in 1st GenerateAC * Transaction outcome shall be set to "End application" M : CDA - ICC responds with AAR with SDAD To ensure that the PayPass reader treats an AAR as a logical error even in CDA context and terminates the transaction (case where dynamic signature is present). [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * TAC and IAC are set so that a TC is requested at first GenerateAC. * LT responds AAR at the first GenerateAC with dynamic signature. Application in LT is selected and transaction is processed with LT (in particular CDA). The PayPass reader shall terminate the transaction. 345

370 M : CDA - ICC responds with AAR without SDAD To ensure that the PayPass reader treats the AAR as a logical error even in CDA context and terminates the transaction (case where dynamic signature is not present). [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * TAC and IAC are set so that a TC is requested at first GenerateAC. * LT responds AAR at the first GenerateAC without dynamic signature. Application in LT is selected and transaction is processed with LT (in particular CDA). The PayPass reader shall terminate the transaction 346

371 M : CDA - ICC Dynamic Data To ensure that the PayPass reader supports ICC Dynamic Data containing the ICC Dynamic Number with variable length (2-8 bytes) and optionally Additional Dynamic Data with a total length LDD Nic-25, during the Combined Data Authentication process. [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] [EMV 4.2b]: [2CC ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * TAC and IAC are set so that a TC is requested at first GenerateAC. * LT returns a TC to the first GEN AC. Length NIC = 238 bytes, length NI = 247 bytes, length NCA = 248 bytes. Case 01: ICC Dynamic Data used in dynamic signature computation = table 19 of Book 2 with ICC Dynamic Number (length = 2) without Additional Dynamic Data (LDD = 32) Case 02: ICC Dynamic Data used in dynamic signature computation = table 19 of Book 2 with ICC Dynamic Number (length = 8) without Additional Dynamic Data (LDD = 38) Case 03: ICC Dynamic Data used in dynamic signature computation = table 19 of Book 2 with ICC Dynamic Number (length = 8) + Additional Dynamic Data (length = 175 bytes, value = AA..AA), no padding (LDD = 213) Case 04: ICC Dynamic Data used in dynamic signature computation = table 19 of Book 2 with ICC Dynamic Number (length = 2) + Additional Dynamic Data (length = 181 bytes, value = AA..AA), no padding (LDD = 213) Case 05: ICC Dynamic Data used in dynamic signature computation = table 19 of Book 2 with ICC Dynamic Number (length = 4) + Additional Dynamic Data (length = 4 bytes, value = ) (LDD = 38) Case 06: ICC Dynamic Data used in dynamic signature computation = table 19 of Book 2 with ICC Dynamic Number (length = 4) + Additional Dynamic Data (length = 9 bytes, value = F FF) (LDD = 43) Case 07: ICC Dynamic Data used in dynamic signature computation = table 19 of Book 2 with ICC Dynamic Number (length = 8) + Additional Dynamic Data (length = 8 bytes, value = TLV data with proprietary tag: 5F AA BB CC DD) (LDD = 46) Case 08: ICC Dynamic Data used in dynamic signature computation = table 19 of Book 2 with ICC Dynamic Number (length = 4) + Additional Dynamic Data (length = 4 bytes, value = BB BB) (LDD = 38) Case 09: ICC Dynamic Data used in dynamic signature computation = table 19 of Book 2 with ICC Dynamic Number (length = 8) + Additional Dynamic Data (length = 6 bytes, value = TLV Expiration Data data:..5f (LDD = 44) Application in LT is selected and transaction is processed with LT (in particular CDA). * PayPass reader approve the transaction by generating TC with CDA at 1st GenerateAC * TVR Byte1 bit8 = 0: ODA was performed 347

372 * Transaction outcome shall be set to 'Approved' M : Completion - MChip Optional data present in Offline Transaction To ensure the PayPass reader prepares the MChip Data Record, when LT contains all mandatory and optional data. Case of offline transaction. [MCHIP] and [OFFLINE CAPABLE] [MC v2.1]: [ Completion] [ ] * LT data set, so that Reader requests TC at 1st GenerateAC * CDA is performed * LT respond with TC at 1st GenerateAC * Case 01: Lt returns data such as i) all data objects defined as conditional in the data record are present ii) all card data objects defined in the data record have a minimum length as defined below (in bytes): Track2 Equivalent Data (PAN (6 bytes), DD (3 digits)), PayPass Third Party Data (5), DF Name (7), Application Label (1), Application Preferred Name (1), Issuer Code Table Index (1), Issuer Application Data (1), PAN (6), PSN (1), ExpirationDate (3) PayPass Third Party Data is returned in the FCI. * Case 02: Lt returns data such as i) all data objects defined as conditional in the data record are present ii) all card data objects defined in the data record have a maximum length as defined below (in bytes): Track2 Equivalent Data (PAN (19 digits), DD (10 digits)), PayPass Third Party Data (32), DF Name (16), Application Label (16), Application Preferred Name (16), Issuer Code Table Index (1), Issuer Application Data (32), PAN (19 digits), PSN (1), ExpirationDate (3) PayPass Third Party Data is returned in the ReadRecords. * The PayPass reader shall process the transaction until completion * Transaction outcome shall be Approved * Data Record shall contain all data objects same as returned by LT: Track2 Equivalent Data, PayPass Third Party Data, DF Name, Application Label, Application Preferred Name, Issuer Code Table Index, AC, CID, IAD, ATC, TVR, UN, Transaction Currency Code, Transaction Type, Terminal Capabilities, Transaction Date, Transaction Amount, Terminal Country Code, CVM Result, AIP, PSN and ExpirationDate. 348

373 M : Completion - MChip - Optional data present in Online Transaction To ensure the PayPass reader prepares the MChip Data Record, when LT contains all mandatory and optional data. Case of online transaction. [MCHIP] and [ONLINE CAPABLE] [MC v2.1]: [ Completion] [ ] * LT data set, so that Reader requests ARQC at 1st GenerateAC * LT respond with ARQC at 1st GenerateAC * Case 01: Lt returns data such as i) all data objects defined as conditional in the data record are present ii) all card data objects defined in the data record have a minimum length as defined below (in bytes): Track2 Equivalent Data (PAN (6 bytes), DD (3 digits)), PayPass Third Party Data (5), DF Name (7), Application Label (1), Application Preferred Name (1), Issuer Code Table Index (1), Issuer Application Data (1), PAN (6), PSN (1), ExpirationDate (3) PayPass Third Party Data is returned in the ReadRecords. * Case 02: Lt returns data such as i) all data objects defined as conditional in the data record are present ii) all card data objects defined in the data record have a maximum length as defined below (in bytes): Track2 Equivalent Data (PAN (19 digits), DD (10 digits)), PayPass Third Party Data (32), DF Name (16), Application Label (16), Application Preferred Name (16), Issuer Code Table Index (1), Issuer Application Data (32), PAN (19 digits), PSN (1), ExpirationDate (3) PayPass Third Party Data is returned in the FCI. * The PayPass reader shall process the transaction until completion * Transaction outcome shall be Online Request * Data Record shall contain all data objects same as returned by LT: Track2 Equivalent Data, PayPass Third Party Data, DF Name, Application Label, Application Preferred Name, Issuer Code Table Index, AC, CID, IAD, ATC, TVR, UN, Transaction Currency Code, Transaction Type, Terminal Capabilities, Transaction Date, Transaction Amount, Terminal Country Code, CVM Result, AIP, PSN and ExpirationDate. 349

374 M : Completion - PayPass reader transmits data record To ensure that the PayPass reader transmits a data record if the card indicates to process Online in response to first GenerateAC. [ONLINE CAPABLE] and [MCHIP] [MS v3.3]: [MC v2.1]: [EMV 4.2b]: * AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) * LT returns ARQC to GenerateAC. * Transaction outcome shall be 'Online Request' after 1st GenerateAC * The PayPass reader shall format and transmit a data record as specified. M : Completion - MChip - Optional data not present (Offline Transaction) To ensure the PayPass reader prepares the MChip Data Record, when LT does not contain optional data. Case of offline transaction. [MCHIP] and [OFFLINE CAPABLE] [MC v2.1]: [ Completion] [ ] * LT contains DF Name, AC, CID, ATC and AIP,API * LT does not contain Track2 Equivalent Data, PayPass Third Party Data, Application Label, Application Preferred Name, Issuer Code Table Index and Issuer Application Data * LT data set, so that Reader requests TC at 1st GenerateAC * LT respond with TC at 1st GenerateAC * The PayPass reader shall process the transaction until completion * Transaction outcome shall be Approved * Data Record sent to the terminal shall contain DF Name, AC, CID, ATC, TVR, UN, Transaction Currency Code, Transaction Type, Terminal Capabilities, Transaction Date, Transaction Amount, Terminal Country Code, CVM Result, AIP, PAN and ExpirationDate * Data Record shall not contain any data stated in condition

375 M : Completion - MChip - Optional data not present (Online Transaction) To ensure the PayPass reader prepares the MChip Data Record, when LT does not contain optional data. Case of online transaction. [MCHIP] and [ONLINE CAPABLE] [MC v2.1]: [ Completion] [ ] * LT contains DF Name, AC, CID, ATC and AIP * LT does not contain Track2 Equivalent Data, PayPass Third Party Data, Application Label, Application Preferred Name, Issuer Code Table Index and Issuer Application Data * LT data set, so that Reader requests ARQC at 1st GenerateAC * LT respond with ARQC at 1st GenerateAC ** The PayPass reader shall process the transaction until completion * Transaction outcome shall be Online Request * Data Record sent to the terminal shall contain DF Name, AC, CID, ATC, TVR, UN, Transaction Currency Code, Transaction Type, Terminal Capabilities, Transaction Date, Transaction Amount, Terminal Country Code, CVM Result, AIP, PAN and ExpirationDate * Data Record shall not contain any data stated in condition

376 M : DOL - Data Elements are Initialized in PayPass reader To ensure that the data elements listed in "Data Elements Table" EMV-Book 3 Annex A are initialized in the PayPass reader or obtainable at the time of a transaction [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CN ] * CDOL1 requests (several tests can be made since length is too long to return all data): - Additional Terminal Capabilities. - Amount, Authorized (Binary) - Amount, Authorized (Numeric) - Amount, Other (Binary) - Amount, Other (Numeric) - Application Identifier. - Application Version Number. - CVM Results. - Certification Authority Public Key Index. - Interface Device Serial Number. - Merchant Category Code. - Merchant Custom Data - Terminal Capabilities. - Terminal Country Code. - Terminal Type. - Terminal Verification Results. - Transaction Category Code - Transaction Currency Code. - Transaction Currency Exponent. - Transaction Date. - Transaction Time. - Transaction Type. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * Data Element returned by the PayPass reader shall have correct format and coherent value: - Additional Terminal Capabilities - b - Amount Authorized - b - Amount Authorized - n 12 - Amount Other - b - Amount Other - n 12 - Application Identifier - b - Application Version Number - b - CVM Results - b - Certification Authority Public Key Index - b - Interface Device Serial Number - an 8 352

377 - Merchant Category Code - n 4 - Merchant Custom Data - ans 20 - Terminal Capabilities - b - Terminal Country Code - n 3 - Terminal Type - n 2 - Terminal Verification Results - b - Transaction Category Code - an 1 -Transaction Currency Code - n 3 - Transaction Currency Exponent - n 1 - Transaction Date - n 6 (YYMMDD) - Transaction Time - n 6 (HHMMSS) - Transaction Type - n 2 M : DOL - Unpredictable Number (Tag 9F 37) in CDOL1 To ensure that the PayPass reader checks the presence of PayPass reader Unpredictable Number (tag 9F 37) in CDOL1 for CDA. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ , ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * CDOL1 in LT does not include Unpredictable Number generated by the PayPass reader (tag 9F 37). Application in LT is selected and transaction is processed with LT (in particular CDA). * Transaction outcome shall be set to "End Application" 353

378 M : DOL - CDOL1 - Authorized Amount To ensure that the PayPass reader stores Amount Authorized with Implicit Decimal Point [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CM ] * Purchase Amount has decimal values * CDOL1 requests Amount Authorized Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * Amount Authorized shall be expressed with implicit decimal point for the currency used M : DOL - Clock local date and Time To ensure that Offline-only PayPass readers and offline PayPass readers with online capability have a clock with the local date and time [MCHIP] and [OFFLINE CAPABLE] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CM ] * CDOL1 requests Transaction Date and Transaction Time Several Transactions are performed with the PayPass reader Transaction Date and Time shall be coherent 354

379 M : DOL - longer data object length, compressed numeric format To ensure that, if the length specified is greater than the actual data, the PayPass reader pads the actual data with trailing hexadecimal FF s if the data has compressed numeric (cn) format, or with leading hexadecimal zeroes if the data has numeric (n) format and with trailing hexadecimal zeroes for any other format. [MCHIP] [MC v2.1]: [5.2 DOL Handling] [ ] The CDOL1 of LT contains a data object which has compressed numeric format and a length longer than actual Data Object Length Application in LT is selected and transaction is performed with LT (in particular the DOL processing). The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly padded with trailing hexadecimal FF's (portion has the same length as the Data Object in DOL). No test can be done with PDOL because there is no PayPass reader resident data object having cn format. No test can be done with UDOL because there is no PayPass Mag Stripe data object having cn format. M : Data Object Management - Optional Data Objects To ensure that the PayPass reader accepts presence or absence of optional Data Objects. [MCHIP] [MC v2.1]: [4.3.7 Read M/Chip Application Data] [ ] * Test is made for the presence and the absence of all Optional Data Objects coming from card (source = ICC in Table A-1 Data Elements Dictionary) and read with READ RECORD. * Presence of Mandatory data Object listed in Book 3 table II-2, table II-3, table II-4 is not tested. Case 01: no optional data objects are present. Case 02: all optional data objects are present. The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC 355

380 M : Data Object Management - with minimum length To ensure the PayPass reader correctly behaves when the variable length data objects have minimum length' [MCHIP] [MC v2.1]: [5.1 Data Object Format] [ ] [EMV 4.2b]: [2CA ] a) AIP of LT indicates M/Chip is supported b) LT returns the following in response to PPSE: - Application Label (50) with length of 1 byte c) The selected application is such as the FINAL SELECT includes the following items: - Application Label (50) with length of 1 byte - Application Preferred name (9F12) with length of 1 byte - Language Preference (5F2D) with length 2 bytes d) LT returns the following in response to READ RECORD - ICC dynamic Number (9F4C) with length of 2 bytes e) CDOL1 requests all data Elements stated in condition c) and d) * PayPass reader shall continue the transaction successfully * The LT shall receive the same data returned by LT in the GenerateAC data field 356

381 M : Data Object Management - with maximum length (2) To ensure the PayPass reader correctly behaves when the variable length data objects have maximum length [MCHIP] [MC v2.1]: [5.1 Data Object Format] [ ] [EMV 4.2b]: [2CA ] a) LT contains - ICC dynamic Number (9F4C) with length of 8 bytes - Issuer Application Data (9F10) with length of 32 bytes - Track 2 Data (57) with length of 19 bytes (PAN with 19 digits) b) CDOL1 requests all LT data stated in condition a) except Issuer Application Data (9F10) * PayPass reader shall continue the transaction successfully * The LT shall receive correct data in the GenerateAC data field * The Batch data capture or Financial confirmation message or any form of receipt shall contain the correct Issuer Application Data returned in response to GenerateAC 357

382 M : Data Object Management - with maximum length (1) To ensure the PayPass reader correctly behaves when the variable length data objects have maximum length' [MCHIP] [MC v2.1]: [5.1 Data Object Format] [ ] [EMV 4.2b]: [2CA ] a) AIP of LT indicates M/Chip is supported c) LT returns the following in response to PPSE: - File Control Information (FCI) Template (6F) with length of 252 bytes - File Control Information (FCI) Issuer Discretionary Data (BF0C) with length of 222 bytes (in response to PPSE) - An Application Label (50) with length of 16 byte d) The selected application is such as the FINAL SELECT includes the following items: - An Application Label (50) with length of 16 byte - Application Preferred name (9F12) with length of 16 byte - Language Preference (5F2D) with length 8 bytes e) CDOL1 requests all LT data stated in condition d) * PayPass reader shall continue the transaction successfully * The LT shall receive correct data in the GenerateAC data field M : Data Object Management - with maximum length (3) To ensure the PayPass reader correctly behaves when the variable length data objects have maximum length [MCHIP] [MC v2.1]: [5.1 Data Object Format] [ ] [EMV 4.2b]: [2CA ] * LT contains Cardholder Verification Method List (8E) with length of 248 bytes * CDOL1 requests CVM list * PayPass reader shall continue the transaction successfully * The LT shall receive correct data in the GenerateAC data field 358

383 M : Data Object Management - PayPass reader Displays Error Message if Verification Process fails To ensure that if the Checksum verification process fails during the loading of the Certification Authority Public Key, the PayPass reader shall not accept the Certification Authority Public Key. To ensure that if operator action is needed during the loading of the Certification Authority Public Key, the PayPass reader displays an error message if the process fails. [CAPK_VERIFICATION] and [MCHIP] and [INTEGRATED_TERMINAL] [MC v2.1]: [ SDA] [ , , ] * Certification Authority Public Key is verified with Certification Authority Public Key checksum * The Certification Authority Public Key checksum is not good Certification Authority Public Key loading is processed * The Certification Authority Public Key attempting to be loaded is rejected * The PayPass reader shall display an error message If an operator action is needed M : Integrated terminal features - Amount Entry Separate From PIN Entry To ensure that if the PayPass reader is attended and supports PIN entry, the amount entry process is separate from the PIN entry process [ENC PIN ONLINE] and [MCHIP] and [ATTENDED] and [INTEGRATED_TERMINAL] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CM ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is Enciphered Online PIN verification performed, always (02 00) Application in LT is selected and transaction is processed with LT Card is removed from the proximity of the PCD. * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * The amount entry process shall be separated from the PIN entry process to avoid any accidental display of a PIN on the PayPass reader display 359

384 M : Integrated terminal features - online request message when ARQC To ensure that if the card responds with an ARQC to first GenerateAC and is permitted to do so and if PayPass reader has online capability, the PayPass reader prepares and sends an authorization or financial request message [MCHIP] and [ONLINE CAPABLE] and [INTEGRATED_TERMINAL] [MC v2.1]: [4.1 Transaction Flow] [Symbol 18] * Issuer Action Code Denial has all bits set to 0b to prevent the PayPass reader from requesting an AAC on the first GenerateAC. * LT returns ARQC in the response to first GenerateAC. The PayPass terminal shall prepare and send an authorization or financial request message. M : Integrated terminal features Digit PIN (Online PIN) To ensure that PIN Pad PayPass reader supports 4 to 12 digits PIN when CVM to be performed is Online PIN. [ENC PIN ONLINE] and [MCHIP] and [INTEGRATED_TERMINAL] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CM ] * AIP of LT indicates Cardholder verification is supported (AIP byte 1 bit 7 = 1). * CVM in LT is enciphered PIN verified online, always (02 00) Case 01: PIN in LT has a length of 4 digits Case 02: PIN in LT has a length of 5 digits Case 03: PIN in LT has a length of 6 digits Case 04: PIN in LT has a length of 9 digits Case 05: PIN in LT has a length of 12 digits * PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * TVR byte 3, bit 8 = 0 (i.e. Cardholder verification successful) received at 1st GenerateAC. * TVR byte 3, bit 3 = '1' (i.e. Online PIN entered) received at 1st GenerateAC. * PIN transmitted in the online message shall match the value entered at the PIN pad 360

385 M : Integrated terminal features - Protection of Values of Entered PIN * To ensure that when a display is present on a PIN Pad, an indication of the entry of each digit shall be displayed * To ensure that when a display is present on a PIN Pad, the values of the entered PIN are not displayed or disclosed by visible or audible feedback means, in accordance with ISO [ENC PIN ONLINE] and [MCHIP] and [INTEGRATED_TERMINAL] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CM ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is Enciphered Online PIN verification performed by ICC, always (02 00) Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * An indication of the entry of each digit shall be displayed * The value of the entered PIN shall not be displayed * The value of the entered PIN shall not be disclosed by audible feedback means M : Integrated terminal features - Data Printed on Receipt To ensure that the PayPass reader prints the DF name in hexadecimal characters on the receipt [PRINT] and [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CO ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * The PayPass reader shall print a receipt with the DF name in hexadecimal characters 361

386 M : Integrated terminal features - Protection of PIN During Online PIN Verification To ensure that the PayPass reader enciphers the Online PIN according to ISO and transmits it according to the payment system's rules, if the PayPass reader supports Online PIN verification [ENC PIN ONLINE] and [MCHIP] and [INTEGRATED_TERMINAL] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CM ] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is enciphered PIN verified online, always (02 00) Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * The enciphered PIN Data in financial or authorization request message shall contain the PIN entered enciphered according to ISO M : Integrated terminal features - Application Used Identified on Receipt To ensure that the PayPass reader prints partial Application PAN (or the full PAN, if allowed by payment system rules) and the AID on the receipt [PRINT] and [INTEGRATED_TERMINAL] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CO ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * The PayPass reader shall print a receipt with partial Application PAN (or the full PAN, if allowed by payment system rules) and the AID 362

387 M : Integrated terminal features - Protection of Captured Transactions To ensure that when the PayPass reader supports batch data capture, the captured transactions are not erased or altered until the next reconciliation with the acquiring system [MCHIP] and [BDC] and [INTEGRATED_TERMINAL] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CM ] AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1). * Several Transactions are performed with the PayPass reader. * Transaction stored are read before reconciliation with the acquiring system The Captured transactions shall not be erased or altered. M : Integrated terminal features - PayPass reader Prints Receipt With Line for Cardholder Signature To ensure that the PayPass reader prints a receipt with line for Cardholder signature when signature is the applicable CVM [MCHIP] and [SIGNATURE] and [PRINT] and [INTEGRATED_TERMINAL] [MC v2.1]: [ M/Chip CVM Selection] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM is Signature, always (1E 00) * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC. * PayPass reader shall print a receipt with a line for Cardholder signature * Transaction CVM set to Signature 363

388 M : Integrated terminal features - PIN entry when Online PIN selected as CVM To ensure that if Online PIN processing is the selected CVM and the PIN pad is functioning then the PayPass product performs the Online PIN entry after the Completion function. [ENC PIN ONLINE] and [MCHIP] and [INTEGRATED_TERMINAL] [MC v2.1]: [4.3.10] * The AIP has bit b5 in byte 1 set to 1b ("Cardholder verification is supported"). * CVM List is 'Enciphered PIN verified online' with a satisfied condition, i.e.: always Card is removed from the reader upon request. * The PayPass reader shall process the transaction until completion. * The PayPass product shall display the Enter PIN message. * Authorization or financial request message shall contain encrypted PIN. M : Combined test - GetPO and GenAC with different response format To ensure that the PayPass reader supports in the same transaction the response format 1 and 2 for GetPO and GenerateAC. [MCHIP] [MC v2.1]: [ GenerateAC Processing] [ ] Case 01: Response to GetPO is in format 1 and Response to GenerateAC is in format 2 Case 02: Response to GetPO is in format 2 and Response to GenerateAC is in format 1 Application in LT is selected and transaction is performed with LT. The reader shall accept the card and process the transaction until completion, by requesting a TC or an AAC. 364

389 M : Combined test - SDA and Record length coded on 1 or 2 bytes To ensure that the PayPass reader supports SDA and the records involved in the SDA calculation are coded on 1 or 2 bytes [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CS ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * Signed Static Application Data is good in LT Case 01: Record length listed in the AFL as participating in data authentication is coded on 1 byte (b8 = 0) Case 02: Record length listed in the AFL as participating in data authentication is coded on 2 bytes (81 xx) Case 03: The length of a Data Object participating in data authentication is coded on 1 byte (b8 = 0) Case 04: The length of a Data Object participating in data authentication is coded on 2 bytes (81 xx) * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction and Transaction outcome as Approved 365

390 M : Combined test - SDA and Record length of proprietary file coded on 1 or 2 bytes To ensure that the PayPass reader supports SDA and the records of proprietary file involved in the SDA calculation are coded on 1 or 2 bytes. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CS ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * An EMV Data Object is included in a record, located in a proprietary file, and listed in AFL and included in the data to be signed * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * EMV Data Object located in proprietary files will be TLV coded with record tag 70 * Signed Static Application Data is good including in the computation the tag 70 and associated length of the record contained in the proprietary files Case 01: Record length of the proprietary file participating in data authentication is coded on 1 byte (b8 = 0) Case 02: Record length of the proprietary file participating in data authentication is coded on 2 bytes (81 xx) Application in LT is selected and transaction is processed with LT (in particular SDA). * The PayPass reader shall process the transaction until completion, by requesting a TC at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction and Transaction outcome as Approved 366

391 M : Combined test - GetPO and GenAC with different response format, CDA To ensure that the PayPass reader supports in the same transaction the response format 1 and 2 for GetPO and GenerateAC when performing CDA [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [ GenerateAC Processing] [ ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Response to GetPO is in format 1 and Response to GenerateAC is in format 2 Case 02: Response to GetPO is in format 2 and Response to GenerateAC is in format 2 Application in LT is selected and transaction is performed with LT. * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA * TVR Byte1, bit8 = 0(Offline data authentication was performed) received at 1st GenerateAC * PayPass reader shall approve the transaction * Transaction outcome shall be set to "Approved" 367

392 M : Combined test - CDA and Record length coded on 1 or 2 bytes To ensure that the PayPass reader supports CDA and the records involved in the CDA calculation are coded on 1 or 2 bytes [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CS ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * IAC s and TAC s are set so that TC is requested at 1st GenerateAC Case 01: Record length listed in the AFL as participating in data authentication is coded on 1 byte (b8 = 0) Case 02: Record length listed in the AFL as participating in data authentication is coded on 2 bytes (81 xx) Case 03: The length of a Data Object participating in data authentication is coded on 1 byte (b8 = 0) Case 04: The length of a Data Object participating in data authentication is coded on 2 bytes (81 xx) * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction * Transaction outcome shall be set to "Approved" 368

393 M : Combined test - CDA and Record length of proprietary file coded on 1 or 2 bytes To ensure that the PayPass reader supports CDA and the records of proprietary file involved in the CDA calculation are coded on 1 or 2 bytes. [OFFLINE CAPABLE] and [CDA] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CS ] * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1). * An EMV Data Object is included in a record, located in a proprietary file, and listed in AFL and included in the data to be signed * IAC s and TAC s are set so that TC is requested at 1st GenerateAC * EMV Data Object located in proprietary files will be TLV coded with record tag 70 * Signed Dynamic Application Data is good including in the computation the tag 70 and associated length of the record contained in the proprietary files Case 01: Record length of the proprietary file participating in data authentication is coded on 1 byte (b8 = 0) Case 02: Record length of the proprietary file participating in data authentication is coded on 2 bytes (81 xx) * The PayPass reader shall process the transaction until completion, by requesting a TC with CDA at 1st GenerateAC. * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall approve the transaction. * Transaction outcome shall be set to Approved 369

394 M : Combined test - Combined functions To ensure that the PayPass reader is able to perform correctly the transaction on the following LT profile containing Proprietary Data and EMV data [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT = '7D 80' * AID partially matches the ADF. * Language Preference of LT = ' 6A E' * Application Version Number of LT = '02 00' * AFL of LT has a length of 20 bytes * Read record contains TSI and CDOL2 data object. * CDOL1 requests TSI and CDOL2 data object. * CDOL1 of LT have a length of 128 bytes * CVM List of LT = ' E F 03' * A record of LT contain the proprietary tag '9F 54' * A record of LT contain the proprietary tag 'DF 4F' * A record of LT contain the proprietary tag '9F 55'' Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion, by requesting a TC or an ARQC * Data record shall contain the DF name as returned by card 370

395 M : Combined test - Valid PDOL, SDA, SIGNATURE, GetPO, GenAC in format1 To ensure that the PayPass reader supports in the same transaction the following LT functions: GetPO Format 1, TRM, SDA, Paper Signature, No Issuer Authentication (IAD present), GenerateAC Format 1 [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * AIP of LT indicates Terminal Risk Management is to be performed (AIP byte 1 bit 4 = 1). * Select ADF response of LT contains a valid PDOL * GetPO response of LT is in format 1 * CVM requires 'Paper Signature, if terminal supports CVM (1E 03), followed by 'No CVM, always' (1F 00) * GenerateAC LT response is in format 1, IAD present IACs and TACs are all zeroes. Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion. 371

396 M : Combined test - PDOL empty, SDA, Paper Signature, No Issuer Authentication, GenAC Format 1 To ensure that the PayPass reader supports in the same transaction the following LT functions: GetPO with an empty PDOL, SDA, Paper Signature, No Issuer Authentication, GenerateAC Format 1 [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Select ADF response of LT contains an empty PDOL * CVM requires 'Paper Signature, if PayPass reader supports CVM (1E 03), followed by 'No CVM, always' (1F 00) * GenerateAC LT response is in format 1, IAD is not present * IACs and TACs are all zeroes. Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion. 372

397 M : Combined test - PDOL empty, SDA, Plaintext PIN, No Issuer Authentication, GenAC Format 2 To ensure that the PayPass reader supports in the same transaction the following LT functions: GetPO with an empty PDOL, SDA, Plaintext PIN, No Issuer Authentication (IAD present), GenerateAC Format 2 [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * LT responds with SW 9000 to PPSE * Select ADF response of LT contains an empty PDOL * CVM requires 'Plaintext PIN verification Offline, if reader supports CVM (01 03), followed by 'Paper Signature, if reader supports CVM (1E 03), followed by 'No CVM, always' (1F 00) * GenerateAC LT response is in format 2, IAD present * IACs and TACs are all zeroes. Application in LT is selected and transaction is processed with LT *The PayPass reader shall process the transaction until completion. 373

398 M : Combined test - TVR byte checking: Online Only, TRM, AUC To ensure that the PayPass Online-Only reader correctly sets the TVR. AIP indicates TRM to be performed. Application Usage Control is returned. [ONLINE ONLY] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] LT does not support SDA nor CDA * AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1), * AIP of LT indicates Terminal risk management supported(aip byte 1 bit 4=1) * AIP of LT indicates Card holder verification supported(aip byte 1 bit 5=1) * Lower consecutive limit, Upper consecutive limit are returned by LT. * Application usage control indicates Valid at terminals other than ATM (AUC byte 1 bit 1 =1), Valid for domestic goods (AUC byte 1 bit 6 =1) * Issuer country code matches the terminal country code. * Card is not listed in exception file Case 01: reader supports nocvm or Signature - CVM indicates SIGNATURE to be performed and then nocvm Case 02: reader supports Online PIN only - CVM indicates Online PIN to be performed Application in LT is selected and transaction is processed with LT Case 01: TVR value shall be x0 00 where x could be 0 or 8*. Case 02 (Online PIN): TVR value shall be x0 00 where x could be 0 or 8*. *.According to EMV book3 page 119, an online-only reader may bypass the IAConline and TAConline analysis and send an ARQC even if the floor limit exceeded bit is not set in the TVR. 374

399 M : Combined test - TVR byte checking: Offline Capable, no TRM, no AUC To ensure that the PayPass Offline Capable reader correctly sets the TVR. AIP indicates TRM is not to be performed. Application Usage Control is not returned. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT indicates Terminal risk management not supported (AIP byte 1 bit 4=0). * AIP of LT indicates SDA supported (AIP byte 1 bit 7=1). * Lower consecutive limit, Upper consecutive limit and LATC are returned by LT. * Issuer country code matches the terminal country code. * Amount used for transaction is below floor limit * Card is not listed in exception file * Static data returned by LT is good * CVM list in LT is 'Fail CVM, always' (00 00) followed by 'NO CVM always' (1F 00) Application in LT is selected and transaction is processed with LT * TVR byte 1, byte 2, byte 3, byte 4, byte 5 are set to 00 * No bits in the TVR are set. 375

400 M : Combined test - TVR byte checking: Offline Capable, TRM, AUC To ensure that the PayPass Offline Capable reader correctly sets the TVR. AIP indicates TRM to be performed. Application Usage Control is returned. [OFFLINE CAPABLE] and [SDA] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT indicates M/Chip profile supported (AIP byte 2 bit 8 = 1) * AIP of LT indicates Terminal risk management supported(aip byte 1 bit 4=1) * AIP of LT indicates SDA supported (AIP byte 1 bit 7=1). * AIP of LT indicates Card holder verification supported(aip byte 1 bit 5=1) * Lower consecutive limit, Upper consecutive limit and LATC are returned by LT. * Application usage control indicates Valid at terminals other than ATM (AUC byte 1 bit 1 =1), Valid for domestic goods (AUC byte 1 bit 6) * Issuer country code matches the terminal country code. * Amount used for transaction is below floor limit * Card is not listed in exception file * Static data returned by LT is good * CVM list in LT is 'Fail CVM, always' (00 00) followed by 'NO CVM always' (1F 00) Application in LT is selected and transaction is processed with LT TVR byte 1, byte 2, byte 3(except b8), byte 4, byte 5 are set to 00: no bits are set in the TVR except B3 b8. 376

401 M : Combined test - GetPO Format 2, SDA, Plaintext PIN, No Issuer Authentication, GenAC Format 2 To ensure that the PayPass reader supports in the same transaction the following LT functions: GetPO Format 2, SDA, Plaintext PIN, No Issuer Authentication (IAD present), GenerateAC Format 2 [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Select ADF response of LT contains a valid PDOL * GetPO response of LT is in format 2 * CVM requires 'Plaintext PIN verification Offline, if reader supports CVM (01 03), followed by 'Paper Signature, if reader supports CVM (1E 03), followed by 'No CVM, always' (1F 00) * GenerateAC LT response is in format 2, IAD present * IACs and TACs are all zeroes. Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion. 377

402 M : Combined test - GetPO Format 1, SDA, Paper Signature, No Issuer Authentication, GenAC Format 1 To ensure that the PayPass reader supports in the same transaction the following LT functions: GetPO Format 1, SDA, Paper Signature, No Issuer Authentication (IAD present), GenerateAC Format 1 [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * Select ADF response of LT contains a valid PDOL * GetPO response of LT is in format 1 * CVM requires 'Paper Signature, if reader supports CVM (1E 03), followed by 'No CVM, always' (1F 00) * GenerateAC LT response is in format 1, IAD present * IACs and TACs are all zeroes. Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion. 378

403 M : Combined test - GetPO Format 2, TRM, SDA, CDA, EncPIN, GenAC Format 2 To ensure that the PayPass reader supports in the same transaction the following LT functions: GetPO is in format 2, TRM, SDA, CDA, Enciphered PIN, GenerateAC Format 2 [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT indicates SDA supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates CDA supported (AIP byte 1 bit 1 = 1). * AIP of LT indicates CVM supported (AIP byte 1 bit 5 = 1). * AIP of LT indicates TRM to be performed (AIP byte 1 bit 4 = 1). * GetPO response of LT is in Format 2 * CVM requires 'Enciphered PIN verification Offline, if Terminal supports CVM (04 03), followed by 'Paper Signature, if reader supports CVM (1E 03), followed by 'No CVM, always' (1F 00) * GenerateAC LT response is in format 2 * IACs and TACs are all zeroes. Application in LT is selected and transaction is processed with LT * The PayPass reader shall process the transaction until completion. 379

404 M : Combined test - CDA, Keys remainder missing, Proprietary Data and EMV data To ensure that the PayPass reader is able to perform correctly the transaction on the following LT profile: CDA, Keys remainder not present, Proprietary Data and EMV data [CDA] and [OFFLINE CAPABLE] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CT ] * AIP of LT = '7D 80' * Language Preference of LT = ' 6A E' * Application Version Number of LT = '02 00' * AFL of LT has a length of 20 bytes * CDOL1 of LT have a length of 128 bytes * CVM List of LT = ' E F 03' * A record of LT contain the proprietary tag '9F 54' * A record of LT contain the proprietary tag 'DF 4F' * A record of LT contain the proprietary tag '9F 55'' * CA Public Key has a length of 1984 bits * Issuer Public Key has a length of 1744 bits * CC Public Key has a length of 1504 bits * TAC and IAC are set so that a TC is requested at 1st GenerateAC. Case 01: Issuer Public Key Remainder is missing Case 02: ICC Public Key Remainder is missing Application in LT is selected and transaction is processed with LT * TVR Byte 1, bit 8 = 0 (offline data authentication was performed) received at 1st GenerateAC. * PayPass reader shall terminate the transaction after 1st GenerateAC * Transaction Outcome shall be set to "End Application" after 1st GenerateAC 380

405 M : Miscellaneous - CDOL1 - Additional Terminal Capabilities To ensure that the PayPass reader has Additional Terminal capabilities coded according to its effective Capabilities [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CP ] * CDOL1 requests Additional Terminal Capabilities Transaction Type Capabilities shall be coded according to the PayPass reader supported features. M : Miscellaneous - CDOL1 - Terminal Capabilities To ensure that the PayPass reader has Terminal capabilities coded according to its effective Capabilities [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CP ] CDOL1 requests Terminal Capabilities Terminal capabilities shall be coded according to the PayPass reader supported features 381

406 M : Miscellaneous - CDOL1 - Terminal Type To ensure that the PayPass reader has terminal Type coded according to its effective type. [MCHIP] [MC v2.1]: [Inherits from EMV] [EMV 4.2b]: [2CP ] CDOL1 requests Terminal Type and Terminal Capabilities Terminal capabilities shall be coded according to the PayPass reader supported features indicated below: * Online only - x1 or x4 * Offline with online capabilities - x2 or x5 * Offline only - x3 or x6 M : Miscellaneous - Coding of Bits and Bytes RFU - Capabilities To ensure that the PayPass reader sets to zeroes data (bits and bytes) indicated as RFU, unless otherwise stated. This applies particularly to TVR, Terminal capabilities, additional capabilities, GenerateAC reference control parameter [MCHIP] [MC v2.1]: [5.1 Data Object Format] [ ] [EMV 4.2b]: [2CA ] * TVR: byte 1 - bits 2 to 1, byte 2 - bits 3 to 1, byte 3 - bits 2 to 1, byte 4 - bits 3 to 1, byte 5 - bits 4 to 1 are set to 0, received at 1st GenerateAC. * Terminal Capabilities: byte 1 - bits 5 to 1, byte 2 - bits 3 to 1, byte 3 - bits 3 to 1 and bit 5 are set to 0, received at 1st GenerateAC. * Terminal Additional Capabilities: byte 2 - bits 7 to 1, byte 3 - bits 4 to 1, byte 4 - bits 4 to 3 are set to 0, received at 1st GenerateAC. * Reference control parameter of GenerateAC received by LT shall have bits 1, 2, 3, 4 and 6 set to 0 382

407 M : Miscellaneous - Coding of Bits and Bytes RFU - IAC and TAC set to 0 To ensure that the PayPass reader sets to zeroes data (bits and bytes) indicated as RFU, and also understands LT data with RFU bits set to zeroes. This applies to IAC and TAC. [MCHIP] [MC v2.1]: [5.1 Data Object Format] [ ] [EMV 4.2b]: [2CA ] * IACs and TACs RFU bits are set to '0' * Terminal shall not terminate the transaction and shall follow the IAC and TAC setting and process the transaction until completion. M : Miscellaneous - Generation of Unpredictable Number To ensure that the PayPass reader is able to generate an unpredictable number [MCHIP] [MC v2.1]: [ Retrieve ICC Key and Verify SDAD (CDA)] [ ] * A minimum of 4 Transaction are performed * CDOL1 requests Unpredictable Number * The PayPass reader shall process the transaction until completion, by requesting a TC or an AAC for each transaction * Unpredictable Number shall be different at each transaction 383

408 M : Miscellaneous - Coding of Bits and Bytes RFU - IAC set to 1 To ensure that the PayPass reader does not use the RFU bits, even when set to '1'. This applies to IAC. [MCHIP] [MC v2.1]: [5.1 Data Object Format] [ ] [EMV 4.2b]: [2CA ] * IACs RFU bits are set to '1'. PayPass reader shall ignore RFU bits set to 1 and continue to process the transaction as normal M : Refund - No Processing restrictions To ensure that the PayPass reader does not perform the processing restrictions function during a Refund transaction. [MCHIP] and [REFUND] [MC v2.1]: [4.1.2 Refund transaction flow] * Application Version Number is different in LT and PayPass reader. * Issuer Country Code matches Terminal Country Code. * Transaction is not valid for domestic in AUC. * Application Expiration Date in the LT has passed. * The PayPass reader shall process the transaction until completion. * TVR byte 2, bit 8 = '0' (i.e. ICC and PayPass reader do not have different application versions) received at 1st GenerateAC. * TVR byte 2, bit 5 = '0' (i.e. Requested service allowed for card product) received at 1st GenerateAC. * TVR byte 2, bit 7 = '0' (i.e. Not Expired application) received at 1st GenerateAC. 384

409 M : Refund - No Terminal Risk Management To ensure that the PayPass reader does not perform Risk Management during Refund transaction. [MCHIP] and [REFUND] [MC v2.1]: [4.1.2 Refund transaction flow] * Transaction Amount is above Terminal floor Limit * CDOL1 requests Amount Authorized Numeric AIP of LT indicates TRM to be performed (AIP byte 1 bit 4 = 1). Application in LT is selected and transaction is performed with LT. * The PayPass reader shall process the transaction until completion. * TVR byte 4, bit 8 = '0' (i.e. Transaction does not exceed floor limit) received at 1st GenerateAC. M : Refund - No CVM selection To ensure that the PayPass reader does not perform CVM selection during Refund transaction. To ensure the PayPass reader sets the Transaction CVM to No CVM, sets CVM result Byte 1 to NoCVM and byte 3 to unknown. [MCHIP] and [REFUND] [MC v2.1]: [4.1.2 Refund transaction flow] * AIP of LT indicates Cardholder Verification is supported (AIP byte 1 bit 5 = 1). * CVM in LT is 'Fail CVM, always' (00 00). Case 01: CVM is present in LT and indicates 'Fail CVM, always' (00 00). Amount is below the CVM limit Case 02: CVM is not present in LT. Amount is above the CVM limit. * The PayPass reader shall process the transaction until completion. * TVR byte 3, bit 8 = '0' (i.e. Cardholder verification did not fail) received at 1st GenerateAC. * CVM Result = 3F * Transaction CVM shall be set to 'No CVM'. 385

410 M : Refund - No TAA To ensure that the PayPass reader does not perform Action Analysis during Refund transaction. To ensure the PayPass reader issues a GENERATE AC command requesting an AAC while performing refund transaction. [MCHIP] and [REFUND] [MC v2.1]: [4.1.2 Refund transaction flow] Case 01: TACs, IAC denial, IAC default are all zeroes. IAConline are all FF. Case 02: TACs are all zeroes. IACs are not returned. Case 03: TACs, IAC denial, IAC default are all zeroes. IAConline are not returned. * The PayPass reader shall process the transaction until completion by requesting an AAC. * The Transaction Outcome is set to Approved. 386

411 M : Refund - No ODA To ensure the PayPass reader does not perform any ODA for refund transaction. To ensure the PayPass reader sets the ODA to be performed to none. [MCHIP] and [REFUND] [MS v3.3]: [MC v2.1]: [4.1.2 Refund Transaction Flow] * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * All TACs and IACs are zeroes. * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1) Case01: CDA is correct Case02: CDA is not correct (SDAD is invalid) Case03: Issuer certificate is missing. * AIP of LT indicates CDA is not supported (AIP byte 1 bit 1 = 0); Case04: SDA is correct Case05: SDA is not correct (SSAD is invalid) Case06: Issuer certificate is missing. * The PayPass reader shall process the transaction until completion, by sending an AAC. * TVR Byte1 bit8 = 1: ODA was not performed * TVR Byte1 bit7 = 0: SDA did not fail (SDA was not performed) * TVR Byte1 bit3 = 0: CDA did not fail (CDA was not performed) * Transaction outcome shall be set to 'Approved' 387

412 M : Refund - Combined To ensure the PayPass reader correctly performs a refund transaction. [MCHIP] and [REFUND] [MC v2.1]: [4.1.2 Refund transaction flow] * AIP of LT indicates TRM supported (AIP byte 2 bit 4 = 1). * AIP of LT indicates CVM supported (AIP byte 2 bit 5 = 1). * AIP of LT indicates SDA is supported (AIP byte 1 bit 7 = 1). * AIP of LT indicates CDA is supported (AIP byte 1 bit 1 = 1) * All TACs and IACs are zeroes. * CDOL requests Transaction Type. A Purchase transaction is performed prior the Refund. Perform the test for MasterCard and Maestro applications. * The reader must return Transaction Type= 20 at GenAC. * The PayPass reader shall process the transaction until completion, by sending an AAC. * TVR Byte1 bit8 = 1: ODA was not performed * TVR Byte1 bit7 = 0: SDA did not fail (SDA was not performed) * TVR Byte1 bit3 = 0: CDA did not fail (CDA was not performed) * Transaction outcome shall be set to 'Approved' * The reader builds the data record with the correct values. *** END OF DOCUMENT *** 388