ppcr manual

PayPassM/ChipRequirements

10 April 2014

NoticesFollowing are policies pertaining to proprietary rights, trademarks, translations, and details aboutthe availability of additional information online.

Proprietary Rights

The information contained in this document is proprietary and confidential to MasterCard InternationalIncorporated, one or more of its affiliated entities (collectively MasterCard), or both.This material may not be duplicated, published, or disclosed, in whole or in part, without the priorwritten permission of MasterCard.

Trademarks

Trademark notices and symbols used in this document reflect the registration status of MasterCardtrademarks in the United States. Please consult with the Customer Operations Services team or theMasterCard Law Department for the registration status of particular product, program, or service namesoutside the United States.All third-party product and service names are trademarks or registered trademarks of their respectiveowners.

Disclaimer

MasterCard makes no representations or warranties of any kind, express or implied, with respect tothe contents of this document. Without limitation, MasterCard specifically disclaims all representationsand warranties with respect to this document and any intellectual property rights subsisting therein orany part thereof, including but not limited to any and all implied warranties of title, non-infringement,or suitability for any purpose (whether or not MasterCard has been advised, has reason to know, or isotherwise in fact aware of any information) or achievement of any particular result. Without limitation,MasterCard specifically disclaims all representations and warranties that any practice or implementation ofthis document will not infringe any third party patents, copyrights, trade secrets or other rights.

Translation

A translation of any MasterCard manual, bulletin, release, or other MasterCard document into a languageother than English is intended solely as a convenience to MasterCard customers. MasterCard provides anytranslated document to its customers AS IS and makes no representations or warranties of any kindwith respect to the translated document, including, but not limited to, its accuracy or reliability. In noevent shall MasterCard be liable for any damages resulting from reliance on any translated document.The English version of any MasterCard document will take precedence over any translated version inany legal proceeding.

Information Available Online

MasterCard provides details about the standards used for this documentincluding times expressed,language use, and contact informationon the Publications Support page available on MasterCardConnect. Go to Publications Support for centralized information.

20132014 MasterCard. Proprietary. All rights reserved.

PPMR 10 April 2014 PayPassM/Chip Requirements

Summary of Changes, 10 April 2014This document reflects changes associated with the 10 April 2014 publication. To locate thesechanges online, click the hyperlinks in the following table.

Description of Change Where to Look

Removed Purchase with Cash Back is not supported on Maestro PayPass Chapter 2, section PayPassTransaction Types

Added information that the contactless interface must not be used fortransactions identified with specific MCCs

Chapter 2, section PayPassTransaction Types

Removed General Requirements, topic PayPass Enrollment Chapter 3, IssuerRequirements

Removed Maestro cards must not support Purchase with Cash Back on thecontactless interface. from the topic Purchase with Cash Back

Chapter 3, section CardRequirements

Added information in Application Selection:

R ALL Issuers must configure the Kernel Identifier in each directoryentry of the PPSE on the card.

Chapter 3, section CardRequirements, topicApplication Selection

Added information in Personalization Requirements:

BP ALL Issuers should be aware of the ricks and limitations associatedwith using proprietary tags in their card personalization.

BP ALL If present in the card personalization, it is recommended thatThird Party Data be included in the FCI Issuer Discretionary Data thatis returned when the application is selected.Added Issuers should be aware that the contents of the Proprietary Datasubfield of Third Party Data can be freely read, and therefore should notcontain sensitive cardholder information

BP ALL Issuers should respect relevant local data privacy laws whenpersonalizing the Proprietary Data subfield of Third Party Data onthe card.

Chapter 3, sectionCard Requirements,topic PersonalizationRequirements

Added the following information regarding PayPassM/ChipPersonalization Requirements:If the card application supports the configuration of a maximum transactionamount then this must only be used to influence the decision to authorizethe transaction online or offline. A transaction must not be declined basedsolely on this parameter.

R ALL If a maximum transaction amount in the contactless cardconfiguration is used, it must not lead to transactions being declinedoffline.To facilitate ATC monitoring, issuers should able to distinguish cardidentifiers read from separate cardholder devices, even if they are linked.This can be done by using different PAN values and/or PAN SequenceNumbers.

Chapter 3, sectionCard Requirements,topic PayPassM/ChipPersonalizationRequirements


PayPassM/Chip Requirements 10 April 2014 1


BP ALL The issuer should not use the same combination of PAN andPAN Sequence Number on separate cardholder devices, even if linked.Issuers may choose to use an Application PAN on the contactless interfacewhich is different to the PAN present on the magnetic stripe or that appearson the face of the card.

Added the following information regarding Card Delivery:In order to fully benefit from new payment opportunities that contactlessoffers, issuers must inform cardholders that contactless functionality isavailable and provide directions on using it with the card.

R ALL Issuers must alert cardholders that contactless functionalityexists when issuing/providing new cards.

Chapter 3, section CardDelivery

Updated DE 22, subfield 1 values in topic Authorization Messages Chapter 3, section IssuerHost Requirements, topicAuthorization Messages

Updated the following information regarding Authorization Decisions:Although the information in DE 55 is normally consistent with other fields,there may be some difference for certain data elements. Issuers should notroutinely decline transactions when differences occur in the data.

BP ALL If the ARQC is correct, the issuer should not decline atransaction simply because the data in DE 55 is different from thevalues in the following data elements:

DE 3Processing Code

DE 4Amount, Transaction

DE 13Date, Local Transaction

DE 43Card Acceptor, Name/Location

DE 49Currency Code, Transaction

DE 54Additional Amounts

Chapter 3, section IssuerHost Requirements, topicAuthorization Decisions

Added the following information regarding Authorization Responses:As a result of contactless-specific risk management the issuer may wish todecline and prompt the cardholder to perform a contact transaction withCVM where possible. In this case the issuer should use an authorizationresponse code 65 exceeds withdrawal count limit.

BP ALL If the issuer declines a contactless transaction on a dualinterface card, but wants to offer the cardholder the option to performa contact transaction, an authorization response code 65 exceedswithdrawal count limit should be used.

Chapter 3, section IssuerHost Requirements, topicAuthorization Responses

Clarified wording regarding PayPassM/Chip PersonalizationRequirements

Chapter 3, section CardRequirements


2 10 April 2014 PayPassM/Chip Requirements


Added the following information regarding PayPass Acceptance:

R ALL A contactless-enabled terminal that supports EMV contact chiptransactions must also support EMV mode contactless transactions.

Chapter 4, section GeneralRequirements, topicPayPass Acceptance

Added the following information regarding terminal approvals and testing:All existing contactless readers that comply with PayPassM/Chip version3.0 or EMVCo Book C-2 must support the Terminal Risk Management Datadata object (as defined in Data Requirements) before 1 January 2015.

R ALL Contactless readers that comply with PayPassM/Chip version3.0 or EMVCo Book C-2 must support the Terminal Risk ManagementData data object by 1 January 2015.

Chapter 4, sectionTerminals, topicApprovals and Testing

Added the following information regarding terminal design and ergonomics:Additional actions must not be required on the terminal in order to enable acontactless transaction. This includes:

Inserting a card

Pressing extra buttons on the POS terminal (with respect to contacttransactions)

Entering the amount a second time on the POS terminal

R ALL Additional actions must not be required on the paymentterminal in order to activate the contactless reader.

Chapter 4, Terminals,topic Terminal Design andErgonomics

Updated information regarding Purchase with Cash Back Chapter 4, sectionTerminals,topic TransactionTypesPurchase withCash Back

Updated information regarding Manual Cash Advance Chapter 4, sectionTerminals, topic ManualCash Advance

Updated information regarding Reader Specifications Chapter 4, sectionTerminals, topic ReaderSpecifications

Clarified information regarding Visual Card Checks Chapter 4, sectionTerminals, topic VisualCard Checks

Updated information regarding the presence of CVM Results (tag 9F34)being mandatory for all authorization messages containing DE 55 that aretransmitted from acquirer chip systems certified by MasterCard on or after13 April 2012

Chapter 4, sectionAuthorization Requirements

Updated information regarding POI Currency Conversion Chapter 4, sectionTerminals


PayPassM/Chip Requirements 10 April 2014 3


Updated information regarding Terminal Action Codes Chapter 5, section TerminalAction Codes

Updated references:From: chargeback protection amountTo: CVM limit

Throughout document


4 10 April 2014 PayPassM/Chip Requirements

Table of Contents

Chapter 1 Using This Manual............................................................... 1-iPurpose.................................................................................................................................... 1-1

Scope ....................................................................................................................................... 1-1

Audience.................................................................................................................................. 1-2

Requirements and Best Practices ............................................................................................. 1-2

Terminology............................................................................................................................. 1-3

Reference Information ............................................................................................................. 1-4

Conventions............................................................................................................................. 1-5

Chapter 2 PayPass Introduction........................................................... 2-iIntroduction ............................................................................................................................. 2-1

Participation............................................................................................................................. 2-1

PayPass Operating Modes ....................................................................................................... 2-2

PayPass Cards.......................................................................................................................... 2-2

PayPass Transaction Types ...................................................................................................... 2-2

PayPass Acceptance................................................................................................................. 2-3

PayPass Transaction Flow........................................................................................................ 2-4

Other Transaction Environments ............................................................................................. 2-7

Chapter 3 Issuer Requirements............................................................ 3-iCard Requirements .................................................................................................................. 3-1

Card Delivery................................................................................................................... 3-15

Issuer Host Requirements ...................................................................................................... 3-15

Clearing Requirements........................................................................................................... 3-19

Chargeback and Exception Processing .................................................................................. 3-20

Chapter 4 Acquirer Requirements ....................................................... 4-iGeneral Requirements ............................................................................................................. 4-1

Terminals ................................................................................................................................. 4-2

Offline Card Authentication ................................................................................................... 4-13

Cardholder Verification .......................................................................................................... 4-14

Terminal Risk Management.................................................................................................... 4-17

Terminal Action Codes .......................................................................................................... 4-17


PayPassM/Chip Requirements 10 April 2014 i

Table of Contents

Authorization Responses........................................................................................................ 4-18

Cardholder Receipts............................................................................................................... 4-18

Subsequent Contact Transactions........................................................................................... 4-19

Terminated Transactions ........................................................................................................ 4-20

Cardholder Activated Terminals............................................................................................. 4-20

Automated Teller Machines ................................................................................................... 4-21

Vending Machines.................................................................................................................. 4-21

Acquirer Network Requirements............................................................................................ 4-21

Authorization Requirements................................................................................................... 4-23

Clearing Requirements........................................................................................................... 4-24

Exception Processing............................................................................................................. 4-25

On-behalf Services................................................................................................................. 4-25

Chapter 5 Data Requirements.............................................................. 5-iTerminal Action Codes ............................................................................................................ 5-1

Payment Scheme Specific Data Objects ................................................................................... 5-5Application Capabilities Information ................................................................................. 5-5Terminal Risk Management Data ....................................................................................... 5-6Third Party Data ................................................................................................................ 5-8Track 1 Data ...................................................................................................................... 5-9Track 2 Data .................................................................................................................... 5-10

Appendix A Abbreviations ..................................................................... A-iAbbreviations...........................................................................................................................A-1


ii 10 April 2014 PayPassM/Chip Requirements

Chapter 1 Using This ManualThis section provides information on the purpose, overview, and conventions used withinthis manual as well as other related information.

Purpose.......................................................................................................................................... 1-1

Scope ............................................................................................................................................. 1-1

Audience........................................................................................................................................ 1-2

Requirements and Best Practices ................................................................................................... 1-2

Terminology................................................................................................................................... 1-3

Reference Information ................................................................................................................... 1-4

Conventions................................................................................................................................... 1-5


PayPassM/Chip Requirements 10 April 2014 1-i

Using This Manual

Purpose

PurposeThis document provides the MasterCard requirements and best practicesfor issuers and acquirers when using contactless chip technology with theirMasterCard M/Chip products.

It contains the requirements relating to MasterCard, Debit MasterCard andMaestro PayPass card programs, and the requirements for performingcontactless transactions at attended and unattended terminals.

This document does not provide an introduction to PayPass or explanation asto how PayPass works, nor does it duplicate or reproduce existing standardssuch as EMV or the existing MasterCard requirements for other technologies.The purpose of the manual is to:

Define the PayPass requirements that MasterCard has established for usewith MasterCard brands

Propose recommendations that constitute best practices for PayPassimplementations

Define when and how the functions must be used as a requirement orshould be used as a best practice

ScopeThis document does not discuss general brand rules or requirements, except toexplain how certain rules are implemented in PayPass.

In general, the brand rules continue to apply to PayPass transactions exceptwhen modified for PayPass and as explained in this document. For example,chargeback rights are the same for PayPass except in connection with CVMlimits described here. For full details of the rules and requirements for specificcard brands, refer to the relevant documentation on MasterCard Connect (seethe Reference Information below).

These requirements have been written for PayPassM/Chip deployments. Inthat context they also cover PayPassMag Stripe functionality. They do notapply to PayPass-Mag Stripe only deployments.


PayPassM/Chip Requirements 10 April 2014 1-1

Using This Manual

Audience

The following products, services, or environments are not in the scope of thisdocument because they are already addressed in other dedicated documents:

Card Application Specifications (for example, M/Chip Advance,PayPassM/Chip 4)

Terminal and reader specifications

EMV contact chip card interface and transactions (for example, M/ChipRequirements)

Personalization Data

Data Storage applications used with PayPass

MasterCard Cash

AudienceThis document is intended for use by MasterCard customers and productvendors involved in PayPass implementation projects who already have ageneral understanding of how the contactless chip product works.

The target audience includes:

Staff working on PayPassM/Chip implementation projects

Operations staff who need to understand the impact of PayPass on theiractivities

Requirements and Best PracticesRequirements are functional elements which must be implemented as stated inthe text to achieve the required level of acceptance for MasterCard or Maestrobranded PayPass cards on PayPass-enabled terminals.

Requirements are always expressed using the word must. Requirements arecontained in tables and are indicated by a capital R in the left column.

Best practices are MasterCard recommendations for the best ways to implementdifferent options. If customers choose not to follow them, their PayPassimplementation will still work but may not be as effective or efficient as itcould be.

Best practices are written using the word should. Best practices are formattedin the same way as requirements but are preceded by the letters BP.

Requirements and best practices include an indication of whether they apply toall products or just to the MasterCard or Maestro brand.


1-2 10 April 2014 PayPassM/Chip Requirements

Using This Manual

Terminology

R All Requirement applies to all PayPass cards or terminals.

R MC Requirement applies to MasterCard branded PayPass cardsor terminals.

R MS Requirement applies to Maestro branded PayPass cards orterminals.

TerminologyThe following terms and their meanings are used throughout this manual.

PayPass Cards and Devices

PayPass devices can be issued in form factors other than that of a traditionalpayment card, for example: mobile phones, key fobs, watches. Throughoutthis document a reference to PayPass cards includes other devices unlessspecifically excluded.

A dual interface card refers to a chip card that can perform both EMV contactand contactless chip transactions.

A hybrid card refers to a card that has a magnetic stripe and a chip with acontact interface. The chip carries an EMV payment application that supportsthe same payment product that is encoded on the magnetic stripe.

PayPass Terminals and Readers

Functionality for the acceptance of PayPass cards may be provided by thePayPass reader or by the accompanying terminal. Throughout this documenta reference to a PayPass terminal includes both the reader and terminalfunctionality and unless specifically stated does not imply the function shouldbe in a specific part of the terminal system.

A hybrid terminal refers to a payment device that can accept transactions usingboth contact chip and magnetic stripe technologies.

Magnetic Stripe Grade Issuers

Magnetic stripe grade issuers receive additional information produced duringa chip transaction, but do not process it. If the magnetic stripe grade issueruses the Chip Conversion service, the issuer does not receive the additionalinformation.

On Device Cardholder Verification

Devices such as a mobile phone may allow the cardholder to verify themselvesto the device, for example by entering a PIN, either before or during a PayPasstransaction. When required, the device confirms to the terminal that cardholderverification has been performed during the transaction processing. This isknown as On Device Cardholder Verification but is also referred to as mPIN.



Using This Manual

Reference Information

Reference InformationThe following references are used in, or are relevant to, this document. Thelatest version applies unless a publication date is explicitly stated.

Chargeback Guide

M/Chip Card Personalization Standard Profiles

M/Chip Requirements

MasterCard Contactless ATM Implementation Requirements

Maestro PayPass Branding Standards

MasterCard PayPass Branding Standards

Transaction Processing Rules

Quick Reference Booklet

PayPassMag Stripe Acquirer Implementation Requirements

PayPass On-behalf Services Guide

PayPass Personalization Data Specification

M/Chip Advance Personalization Data Specifications

PayPass Vendor Product Approval Process Guide (Cards and Devices)

PayPass Vendor Product Approval Process Guide (Terminals)

Mobile PayPass Issuer Implementation Guide

PayPassM/Chip Issuer Guide

PayPass Mag Stripe Issuer Implementation Requirements

Security Rules and Procedures



Using This Manual

Conventions

ConventionsA generic reference to PayPass includes all applicable products. The termsMasterCard PayPass or Maestro PayPass are used to identify specific productrequirements.

A reference to the MasterCard product or MasterCard brand includes MasterCardand Debit MasterCard unless specifically addressed.

MasterCard brands refers to MasterCard and Maestro products.

Values expressed in hexadecimal form (0 to 9 and A to F) are enclosedin single quotes. For example, a hexadecimal value of ABCD is indicated asABCD.

Values expressed in binary form are followed by a lower case b. For example,1001b.

EMV Card commands are indicated in bold capitals, for example, GENERATEAC.

Specific byte/bit references within a data object are included in square brackets.For example, [1][3] means the third bit of the first byte of the given data object.



Chapter 2 PayPass IntroductionThis section provides information on PayPass participation, transaction types, andtransaction flows.

Introduction ................................................................................................................................... 2-1

Participation................................................................................................................................... 2-1

PayPass Operating Modes ............................................................................................................. 2-2

PayPass Cards................................................................................................................................ 2-2

PayPass Transaction Types ............................................................................................................ 2-2

PayPass Acceptance....................................................................................................................... 2-3

PayPass Transaction Flow.............................................................................................................. 2-4

Other Transaction Environments ................................................................................................... 2-7



PayPass Introduction

Introduction

IntroductionPayPass is the proximity payments program from MasterCard Worldwide.

It allows cardholders to make payments without having to hand over, dip orswipe a payment card. To make a payment, the cardholder simply taps theirPayPass card onto a PayPass terminal. The details are read from the card overa contactless interface using radio frequency communications and a transactionis performed over the existing MasterCard payment networks and infrastructure.

Primary characteristics of PayPass transactions are speed and convenience formerchants and cardholders.

PayPass is supported on the MasterCard and Maestro brands. The PayPasscontactless functionality can be used at any merchant location that has PayPassterminals and accepts the underlying payment brand. The merchant segmentswhere PayPass is expected to be most attractive include those environmentswith high transaction volumes and where fast transaction times are important.PayPass contactless functionality can also be used at ATMs.

ParticipationTo issue PayPass cards or acquire PayPass transactions customers must enrollin the PayPass program.

Vendors are required to obtain a license agreement before developing andselling PayPass cards and devices.

All cards, devices and readers used for performing PayPass transactions musthave been approved and licensed by MasterCard. Customers must onlypurchase and deploy cards and terminals from properly licensed vendors.Detailed information about the type approval process can be found in thePayPass Vendor Product Approval Process Guide (Cards and Devices) and thePayPass Vendor Product Approval Process Guide (Terminals) documents.

Issuers and acquirers must start a project with the relevant MasterCard projectteam in order to define and complete various certification steps that are required.Unless otherwise stated within the Project Implementation Plan issuers willcomplete Issuer NIV, CPV and Issuer End-to-end Demonstration and acquirerswill complete Acquirer NIV, TIP and Acquirer End-to-end Demonstration.

Questions about the PayPass license process should be directed [email protected].




PayPass Operating Modes

PayPass Operating ModesPayPass supports two modes of operation as detailed below.

PayPassMag Stripe mode

PayPassM/Chip mode

PayPassMag Stripe transactions are authorized online by the issuer, eitherin real-time or deferred. PayPassMag Stripe is designed for contactlesstransactions using authorization networks that currently support only magneticstripe authorization for MasterCard cards.

PayPassM/Chip transactions use transaction logic similar to EMV contactchip. They may require online authorization but may be approved offline bythe card and terminal. The PayPassM/Chip mode is designed for contactlesstransactions in markets that have migrated to chip technology for EMV contacttransactions.

EMV mode (PayPassM/Chip) is the preferred transaction mode for contactlessMasterCard transactions, however to ensure interoperability all contactlessMasterCard cards and terminals support Mag-Stripe mode (PayPassMagstripe).

Maestro contactless cards and terminals are configured to support onlyPayPassM/Chip transactions for the Maestro product.

PayPass CardsPayPass functionality may be:

Included in a standard ISO 7816 ID-1 card

Issued in another form factor, such as a mobile phone or key fob

All PayPass cardholder devices are valid for acceptance at PayPass terminals;not just cards.

PayPass Transaction TypesDifferent transaction types are available for PayPass.

PayPass issuers and acquirers must support purchase transactions. Refundsmust be supported by issuers for contactless MasterCard transactions. Refundsmust be supported by acquirers for contactless MasterCard and Maestrotransactions, although they may not be available at every PayPass terminal.

PayPass data should only be used for card present transactions. Electroniccommerce or Mail Order/Telephone Order transactions should not beperformed with PayPass data read through the contactless interface.




PayPass Acceptance

The contactless interface may be used for Purchase with Cash Back transactionsbased on the existing product rules. Cardholder verification is always requiredfor Purchase with Cash Back transactions.

The contactless interface may be used for payment transactions based on theexisting product rules.

The contactless interface must not be used for transactions identified with thefollowing MCCs:

Gambling Transactions (MCC 7995)

Gambling-Horse Racing, Drag Racing, Non-Sports Intrastate InternetGambling (MCC 9754)

Money Transfer (MCC 4829)

Quasi Cash-Customer Financial Institution (MCC 6050)

Quasi Cash-Merchant (MCC 6051)

For MCC descriptions, refer to Chapter 3 of the Quick Reference Booklet.

PayPass AcceptancePayPass cards may be accepted at attended and unattended terminals. PayPasscards may be used at ATMs.

Card Checking

PayPass transactions are carried out by the cardholder; therefore, the card doesnot need to be given to the merchant. Since the PayPass card may remain inthe hands of the cardholder, the merchant is exempt from the visual inspectionrequirement to determine if the PayPass card is valid. The card only needsto be given to the merchant after the contactless interaction is complete ifsignature verification is to be performed.

Transaction Amount

The transaction amount is usually known before the PayPass transaction isinitiated to ensure fast processing of PayPass transactions. The amount shouldbe displayed to the cardholder.

If the transaction amount exceeds the maximum amount for PayPasstransactions, for the product or terminal, the terminal or merchant shouldprompt the cardholder to use a different technology to complete the transaction(for example an EMV contact chip transaction). This ensures cardholders are notdenied service when they have a valid MasterCard product for the transaction.




PayPass Transaction Flow

Limits

Appendix C of the Chargeback Guide lists, per market, a limit to be used forcontactless transactions. Transactions equal to or less than this limit do notneed cardholder verification. In addition, receipts need only be provided onrequest of the cardholder.

For Maestro PayPass, apart from some markets listed in Appendix C of theChargeback Guide, transactions are not allowed above this limit. In thatcontext, it is referred to as a ceiling limit.

In this document the term CVM limit is used generically to refer to this limit.

A maximum transaction amount, above which contactless transactions arenot permitted, may be published separately for MasterCard PayPass in somespecific markets.

Floor limits for contactless transactions are for EVM contact chip(PayPassM/Chip) or magnetic stripe (PayPassMag Stripe) transactions.The floor limit may vary per market.

Fallback

If the contactless technology fails the transaction may be completed by anyother technology available. A subsequent transaction is not considered atechnical fallback transaction.

PayPass Transaction FlowSeveral steps are involved in the PayPass transaction.

Technology Selection

The cardholder decides whether to use PayPass or an alternative interface onthe card. PayPass technology is used for the transaction when the PayPass cardis presented by the cardholder to the PayPass reader.

If the card application selected and the terminal supports PayPassM/Chipmode, then it is automatically used by the terminal to complete the transaction.Otherwise, PayPassMag Stripe mode is used.

Application Selection

If the cardholder has chosen to pay by PayPass, the terminal attempts to findan application via the contactless interface to complete the transaction.

When the terminal detects more than one application that it supports on thePayPass card, the terminal automatically selects the application with the highestpriority set by the issuer. To improve transaction speed, interactive cardholderselection or confirmation is not supported for PayPass.





If there are no available applications, given any relevant transaction limits, thenthe PayPass transaction cannot proceed.

For MasterCard products, the same Application Identifiers (AID) are usedfor PayPass transactions as for EMV contact chip transactions. There are noPayPass specific AIDs.

Card Authentication

For all PayPass transactions the card being used is authenticated. ForPayPassM/Chip transactions the card can be authenticated:

Offline by the terminal

OR

Online by the issuer

All offline approved Maestro PayPass transactions must be authenticated bythe terminal using CDA.

All offline MasterCard PayPassM/Chip transactions must be authenticatedby the terminal using either:

CDA

OR

SDA1

While older cards may support SDA, the only offline card authenticationmethod allowed for new cards is CDA. All PayPassM/Chip terminals supportCDA. PayPass does not support DDA.

For online PayPassM/Chip transactions the issuer should perform onlineauthentication by verifying the application cryptogram received in the onlineauthorization.

For PayPassMag Stripe transactions, transactions are authorized online bythe issuer, either in real time or deferred. The PayPass card produces a uniquepassword, referred to as dynamic CVC3, for each transaction. The value isplaced by the terminal in issuer defined positions within the existing trackdata fields. The issuer should perform online authentication by verifying thedynamic CVC3 received in the online authorization.

If PayPassMag Stripe profile transactions are not authorized by the issuer,then the acquirer may be liable for any disputed transactions.

1. SDA authenticates the card, but not the transaction data. New PayPass cards cannot be issued supportingSDA. Newly deployed PayPass terminals do not support SDA, and are not configured to support SDA.





Offline-only terminals may be configured to:

decline transactions performed with PayPassMag Stripe cards.

allow transactions where an ARQC is provided by the PayPassM/Chipcard.

Cardholder Verification

PayPass purchase transactions for amounts less than or equal to the CVM limitdo not require cardholder verification.

For transaction amounts above the CVM limit, cardholder verification is requiredor the acquirer may be liable for disputed transactions.

For MasterCard PayPass, acceptable cardholder verification methods are:

Online PIN

Signature


For Maestro PayPass, acceptable cardholder verification methods are:

Online PIN


PayPass does not support offline PIN.

For PayPassMag Stripe transactions, the CVM to be used for transactionsabove the CVM limit is determined by the terminal. This can be done in asimilar way to swiped magnetic stripe transactions, based on the methodssupported by the terminal and data read from the card. The cardholder devicenotifies the terminal if On Device Cardholder Verification is supported, inwhich case this method is used if supported by the terminal and cardholderverification is required.

For PayPassM/Chip transactions, the CVM is determined by the PayPassreader application in the terminal, based on the CVM List or other informationcontained in the card. The actual CVM is completed after the interaction withthe card is complete, except for On Device Cardholder Verification which iscompleted before the interaction begins.

Card Risk Management

The card risk management performed is at the discretion of the issuer.

Online/Offline Authorization

PayPassM/Chip transactions may be authorized offline by the PayPass cardor the card may request online authorization by the issuer.

PayPassMag Stripe transactions are usually authorized online by the issuer.




Other Transaction Environments

If PayPassMag Stripe transactions are not authorized online, then the acquirermay be liable for any disputed transactions.

If online PIN has been identified as the cardholder verification method for thetransaction, the PIN is verified as part of the online authorization request.

End of Transaction

A PayPassM/Chip terminal ends the interaction with the card once theresponse to the first GENERATE AC command is received by the terminal.A PayPassMag Stripe terminal ends the interaction with the card once theresponse to the COMPUTE CRYPTOGRAPHIC CHECKSUM command isreceived by the terminal. This is not the end of the PayPass transaction.

The PayPass terminal completes the transaction based on:

An offline approval or decline response from the card for PayPassM/Chiptransactions.

OR

An online authorization response (approve or decline) when requested forPayPassM/Chip or PayPassMag Stripe transactions

When the printing of a receipt is supported by the point of sale, for PayPasstransactions less than or equal to the CVM limit, a receipt must be available ifrequested by the cardholder. A receipt must be provided for transactions abovethe CVM limit amount if the terminal is capable of producing a receipt. SeeTransaction Processing Rules for exemptions.

Neither Issuer Authentication Data nor issuer scripts are returned to the cardduring a PayPassM/Chip transaction.

Other Transaction EnvironmentsThere are additional transaction types and environments in which PayPasscards may or may not be used.

Cardholder Activated Terminals

MasterCard defines several types of cardholder activated terminals (CATs).PayPass may be used at CAT Level 1, 2, 3 and 4 terminals (see the ChargebackGuide for full definitions).

As CAT Level 1 terminals require PIN based cardholder verification, onlyPayPass cards that support online PIN or On Device Cardholder Verificationmay be used at these terminals.

Automated Teller Machines

PayPass contactless functionality can also be used at ATMs.



Chapter 3 Issuer RequirementsThis section includes information on requirements for the issuer.

Card Requirements ........................................................................................................................ 3-1Card Delivery......................................................................................................................... 3-15

Issuer Host Requirements ............................................................................................................ 3-15

Clearing Requirements................................................................................................................. 3-19

Chargeback and Exception Processing ........................................................................................ 3-20



Issuer Requirements

Card Requirements

Card RequirementsVarious requirements and best practices exist for the PayPass card.

Approvals and Testing

All PayPass cards issued are required by MasterCard to have MasterCard vendorproduct approval. It is the issuers responsibility to confirm all products havereceived this approval. A full PayPass card Letter of Approval is only granted toa card when it has successfully completed all of the following:

Interface and Application Testing

Compliance Assessment and Security Testing

Card Quality Management

When ordering cards from a card manufacturer, the issuer must ensure that thecard manufacturer has a current PayPass Letter of Approval for the productbeing purchased. The Letter of Approval is valid for the duration of the timethe cards are held in stock prior to being issued.

All PayPass products must have a valid PayPass Letter of Approval at the timethe product is issued.

R ALL Issuers must ensure that all PayPass cards are covered by a valid Letterof Approval at the time they are issued.

Branding, Appearance and Physical Requirements

For the brand standards and design elements required for PayPass cards, pleaserefer to the MasterCard PayPass Branding Standards and the Maestro PayPassBranding Standards. Issuers must obtain approval from MasterCard CardDesign Management for their PayPass card design, even if a similar design hasalready been approved for use on a non-PayPass card.

R ALL Cards must comply with the PayPass branding requirements.

PayPass Cards

If PayPassM/Chip is implemented on an ISO 7816 compliant ID-1 plastic cardthen the card must support an EMV contact chip and optionally a magneticstripe.

R ALL PayPassM/Chip cards that are of ID-1 format and ISO 7816 compliantmust be dual interface cards supporting EMV contact chip transactions.



Issuer Requirements

Card Requirements

A MasterCard PayPass card that supports EMV contact chip transactions on thecontact interface normally also supports PayPassM/Chip.

BP MC An EMV contact chip capable MasterCard branded PayPass card shouldsupport PayPassM/Chip.

Non-card Devices

PayPass functionality can be present in form factors other than traditionalpayment cards. Examples of different forms are:

Mobile phones

Key fobs

Watches

All PayPass non-card devices conduct PayPass transactions in the same wayas PayPass cards. They may support special functionality, such as On DeviceCardholder Verification.

When PayPassM/Chip cards use offline risk management features, aninteraction with the card is required to manage the offline risk managementcounters. This cannot be performed in a normal PayPass transaction sinceresponse data from the issuer is not returned to the card. This interaction maybe achieved:

By performing a transaction through the EMV contact chip interface of ahybrid card

By over-the-air messages, for example to a mobile phone

Through the contactless interface in a special terminal designed for thispurpose, if supported by the cardholder device.

PayPass cards which support offline transactions must be able to supportthe management of the offline risk management counters. PayPassM/Chipnon-card devices that cannot support the management of the offline riskmanagement counters must be configured as online only.

All PayPass non-card device programs must be approved by MasterCard.

The MasterCard PayPass device given to the cardholder can be linked to aMasterCard card account assigned to that same cardholder accessed by astandard MasterCard card. This card does not have to be a PayPass card. Theexpiration date of the PayPass device must not be later than the card that it islinked to. If the MasterCard card is cancelled, the issuer must simultaneouslycancel the companion PayPass device.

It is not necessary for the PayPass device to display an account number. Asa result, a non-card form factor that is issued without a companion card maybe limited in use. Issuers must highlight this to the account holder at the timeof issuance.



Issuer Requirements

Card Requirements

Devices other than mobile phones should accommodate a signature panelwhere possible. Those devices that cannot accommodate a signature panelshould contain a customization area or unique identification number. Aminimal space on small form factors is sufficient to provide cardholders withan opportunity to customize the device with their initials or another mark toidentify it as belonging to them.

R ALL All PayPass non-card device programs must be approved in advanceby MasterCard.

R ALL If linked to a card, the expiration date of the PayPass device must notexceed the expiration date of the card to which it is linked.

R ALL If linked to a card, the PayPass device must be cancelled if the cardis cancelled.

BP ALL The PayPass device, other than a mobile phone, should accommodatea signature panel.

R ALL PayPassM/Chip non-card devices that do not provide a mechanismto reset offline risk management counters must be configured as onlineonly.

R ALL PayPassM/Chip non-card devices must be issued with clearinstructions for the account holder regarding the limitations of their use.

Card Application

PayPassM/Chip must be implemented using approved applications. Examplesare:

M/Chip Advance

PayPassM/Chip 4

Mobile PayPass

PayPassM/Chip Flex

R ALL All PayPassM/Chip cards must use approved applications.

Support of PayPassM/Chip and PayPassMag Stripe

A PayPass card using the MasterCard brand:

Must support PayPassMag Stripe transactions (unless for domestic useonly)

May support PayPassM/Chip transactions

R MC A MasterCard PayPass card that is not exclusively for domestic usemust support PayPassMag Stripe transactions.



Issuer Requirements

Card Requirements

A PayPass card using the Maestro brand:

Must support PayPassM/Chip transactions

Must not support PayPassMag Stripe transactions for Maestro

R MS A Maestro PayPass card must support PayPassM/Chip transactions.

R MS Unless explicitly allowed in the Transaction Processing Rules, a MaestroPayPass card must not support PayPassMag Stripe transactions.

PayPass technology may not currently be used on MasterCard Fleet or MultiCardproducts as data positions required by PayPass are already used in the productpersonalization requirements of these products.

R MC MasterCard Fleet or MultiCard products must not support contactlesstransactions.

ATM

The CVM used for ATM transactions is online PIN.

Issuers should support ATM transactions on the contactless interface.

Because not all ATMs validate the settings of the card, issuers should be awarethat they may receive transactions from ATMs even if:

support for ATM is not indicated in the Application Usage Control

support for online PIN is not included in the CVM list

BP ALL The Application Usage Control should indicate support for ATMtransactions.

Online and Offline Capability

PayPassMag Stripe transactions are always authorized online, either inreal-time or deferred. The card has no input into the decision to seekauthorization.

In PayPassM/Chip cards the transaction counters and decision makingcapability of the chip are used to control risk. To support fast transactions, it isrecommended that PayPassM/Chip cards be configured to support offlinetransaction approval.

As some terminals operate online only, PayPassM/Chip cards should beconfigured to support online transaction approval.

PayPassM/Chip cards issued in the U.S. region must be configured to supportboth online and offline transaction approval.



Issuer Requirements

Card Requirements

To meet special market requirements MasterCard may approve cards that areonline only or offline only; however, issuers should be aware that these cardsdo not work in some terminals.

R ALL PayPassM/Chip cards issued in the U.S. region must be configuredto support both online and offline transaction approval.

BP ALL PayPassM/Chip cards should be configured to support offlinetransaction approval. They should not be configured to be online only.

BP ALL PayPassM/Chip cards should be configured to support onlinetransaction approval. They should not be configured to be offline only.

Service Codes

A value for the service code may be found several times on a PayPassM/Chipcard. For example:

on the magnetic stripe of the card in both Track 1 and Track 2

Track 1 Data (tag 56) and Track 2 Data (tag 9F6B) accessed via thecontactless interface

Track 2 Equivalent Data (tag 57) accessed via the contactless interface

Track 2 Equivalent Data (tag 57) accessed via the EMV contact chipinterface

It is recommended that cards be personalized to use the service codeappropriate for the product. The service code values that are used in thePayPass application should be consistent in each data object when the servicecode appears. Although not recommended, PayPass issuers may choose to useservice code values in the PayPass application that differ from those used onthe magnetic stripe of the same card.

If the issuer does use a different service code value on the contactless interface,the value may be acted on by some terminals. In particular, terminals thatprocess the service code may reject international cards that have a service codevalue starting with 5 (National use only).

BP ALL Issuers should use a value of the service code appropriate for theproduct.

BP ALL Issuers should use the same value of the service code each time theservice code is used.

Expiry Dates

The expiry date of the card should be consistent across all technologiessupported.

BP ALL The expiry date in the PayPass application should be consistent withthe expiry date of the card.



Issuer Requirements

Card Requirements

Purchase with Cash Back

Debit MasterCard cards and Maestro cards may support Purchase with CashBack on the contactless interface.

Purchase with Cash Back on the contactless interface may only be supportedby MasterCard credit cards in European markets.

Purchase with Cash Back transactions always require cardholder verification,regardless of the amount.

R MC MasterCard credit cards issued outside the Europe region must not beconfigured to support Purchase with Cash Back through the contactlessinterface.

Application Selection

PayPass terminals normally perform application selection using the PPSE onthe card. All PayPass cards must contain a PPSE.

Issuers must configure the Application Priority Indicator in each directory entryof the FCI of the PPSE to show the preferred sequence of choice of all PayPassapplications on the card. Issuers must set a different priority for each directoryentry in the FCI of the PPSE. Cardholder confirmation must not be requested.

The AID value used for PayPass is the same AID used for the EMV contact chipinterface. There are no specific AIDs for PayPass.

Supported AIDs are:

MasterCard A0000000041010

Maestro A0000000043060

Identification of PayPass cards use the product AID without any extension, asshown above. PIX extensions may be used by issuers and are considered asa successful match by the terminal when partial AID matching is supported.However, it is recommended not to use PIX extensions, as some legacy PayPassterminals do not support partial AID matching.

If the same account is accessed through the contact and contactless interfaces,the AID used on each interface may be different if supported by the cardimplementation.

The Application Label (tag 50) must be present in a PayPass card. This mayappear on any receipts.

A MasterCard card must be configured with an appropriate ApplicationLabel such as MasterCard, MASTERCARD, Debit MasterCard, or DEBITMASTERCARD.

A Maestro card must be configured with an appropriate Application Label suchas Maestro or MAESTRO.



Issuer Requirements

Card Requirements

Issuers may personalize the Application Preferred Name (tag 9F12) and IssuerCode Table Index (tag 9F11). The Application Preferred Name may be usedon receipts instead of the Application Label if the terminal supports the codetable indicated.

R ALL All PayPass cards must contain a PPSE.

R ALL Issuers must set a unique value for the Application Priority Indicator ineach directory entry in the FCI of the PPSE.

R ALL Issuers must not set the Cardholder Confirmation bit in the ApplicationPriority Indicator in the FCI of the PPSE.

R ALL Issuers must use the appropriate Application Label.

BP ALL PIX extensions should not be used in the AID for PayPass.

Card Authentication

MasterCard requires the use of dynamic CVC3 by all PayPassMagStripe capable cards. This includes PayPassM/Chip cards that performPayPassMag Stripe transactions.

For PayPassM/Chip online transactions the application cryptogram should bevalidated to prevent counterfeit fraud.

For MasterCard PayPassM/Chip:

New cards issued in the Europe or U.S. regions must support CDA andmust not support SDA

New cards issued outside of the Europe or U.S. regions that do not supportCDA must operate as online only. Cards must not support SDA. Cards thatdo not support CDA may experience interoperability issues and may notwork with some merchants such as mass transit agencies.

MasterCard recommends that the issuer support CDA.

Issuers of old cards that support only SDA should note that SDA will not beperformed on PayPass readers that comply with EMVCo Book C-2 and thereforeall transactions at these readers will require online authorization.

All Maestro PayPass cards must support CDA and must not support SDA forMaestro PayPassM/Chip.

PayPass does not support DDA.

R MS Maestro PayPassM/Chip cards must support CDA and must notsupport SDA.

R MC MasterCard PayPassM/Chip cards must not support SDA.

R MC MasterCard PayPassM/Chip cards issued in the Europe or U.S.regions must support CDA.



Issuer Requirements

Card Requirements

R MC MasterCard PayPassM/Chip cards issued outside of the Europe or U.S.regions that do not support CDA must be configured as online only.

BP MC Issuers outside the Europe and U.S. regions are strongly recommendedto use CDA on MasterCard PayPassM/Chip cards.

R ALL PayPassM/Chip cards must not support DDA on the PayPassinterface.

R MC MasterCard PayPassM/Chip cards must use a dynamic CVC3 forPayPassMag Stripe transactions.

BP ALL Issuers are strongly recommended to validate the applicationcryptogram for online PayPassM/Chip transactions.

The payment system public keys for PayPassM/Chip have the same valuesand expiry dates as those used for MasterCard EMV contact chip transactions. Itis recommended to use the same Issuer Key pair for transactions on the contactand contactless interface of a PayPassM/Chip card; therefore, the same IssuerPublic Key certificate may be used.

It is recommended to use the same ICC Key pair for transactions on the contactand contactless interface of a PayPassM/Chip card. The ICC Public KeyCertificate cannot be shared between the contact and contactless interfaceeven if the same keys are used since some of the data elements signed in thecertificate are different.

BP ALL Issuers should use the same Issuer and ICC Public Keys across boththe contact and contactless interface.

Cardholder Verification

A signature or PIN is not required for a PayPass transaction less than or equalto the CVM limit regardless of the setting of the Service Code for PayPassMagStripe, or CVM List for PayPassM/Chip.

For transactions greater than the CVM limit, cardholder verification is normallyrequested. If transactions are completed offline with no cardholder verificationabove the CVM limit then the acquirer may be liable for disputed transactions.

For PayPassMag Stripe transactions, the cardholder verification methodis determined by the terminal in a similar manner to swiped magnetic stripetransactions. The terminal is not required to refer to the Service Code, whichappears in multiple data elements. If the device supports On Device CardholderVerification, this is communicated to the terminal as part of the transaction.

For PayPassM/Chip transactions, the CVM is determined by the PayPassreader application in the terminal based on the terminal capabilities and CVMList or other data in the cardholder device.



Issuer Requirements

Card Requirements

NOTE

For the remainder of this section a distinction is made between cardholderdevices that support On Device Cardholder Verification (mobile phones) andall other cardholder devices (cards).

MasterCard PayPassM/Chip cards:

Must support Signature

Must support Online PIN

Must support No CVM

MasterCard PayPassM/Chip mobile phones:

Must support No CVM

Must support Signature

Must support Online PIN or On Device Cardholder Verification, or both.

Support for both Online PIN and On Device Cardholder Verification isrecommended for MasterCard mobile phones.

The issuer may elect for either Signature or Online PIN to be preferred andpersonalize the CVM List accordingly. On Device Cardholder Verification isperformed above the CVM limit if supported by the mobile phone and theterminal.

If issuers require support for MasterCard PayPassM/Chip mobile phones atATMs, then Online PIN must be supported.

Maestro PayPass cards and mobile phones must support No CVM.

If the issuer supports Maestro PayPass transactions above the CVM limit, then:

Maestro PayPass cards must support Online PIN.

Maestro PayPass mobile phones must support Online PIN or On DeviceCardholder Verification or both.

If issuers require support for Maestro PayPassM/Chip cards or mobile phonesat ATMs then Online PIN must be supported.

Support for On Device Cardholder Verification is recommended for allMasterCard and Maestro PayPass mobile phones.

CVM List entries should not make use of the X and Y values to influence theavailability of a particular CVM. This means that condition codes: 06, 07, 08or 09 should not be used.

Offline PIN is not supported for PayPassM/Chip transactions. Offline PINmay be supported on the same card but only for EMV contact chip transactions.Issuers must not include offline PIN options in the CVM List read through thecontactless interface.



Issuer Requirements

Card Requirements

R ALL All PayPassM/Chip cards and mobile phones must support No CVMin the CVM List read through the contactless interface.

R ALL PayPassM/Chip cards and mobile phones must not support eitheroffline plain text PIN or offline enciphered PIN in the CVM List readthrough the contactless interface.

R MC MasterCard PayPassM/Chip cards must support Online PIN andSignature in the CVM List read through the contactless interface.

R MC MasterCard PayPassM/Chip mobile phones must support Signaturein the CVM List read through the contactless interface.

R MC MasterCard PayPassM/Chip mobile phones must support Online PIN,in the CVM List read through the contactless interface, or On DeviceCardholder Verification, or both.

R MS If the issuer allows Maestro PayPass transactions above the CVM limit,then cards must support Online PIN in the CVM List read through thecontactless interface.

R MS If the issuer allows Maestro PayPass transactions above the CVM limit,then mobile phones must support Online PIN in the CVM List readthrough the contactless interface, or On Device Cardholder Verification,or both.

BP MS Support for Online PIN is recommended for all Maestro PayPass cardsand mobile phones.

BP ALL Support for On Device Cardholder Verification is recommended for allPayPassM/Chip mobile phones.

BP ALL CVM List entries should not make use of the X and Y values toinfluence the availability of a particular CVM.

Magnetic Stripe Based PVV

It may not be possible or easy to change some of the data on a PayPasscard. Any existing magnetic stripe processes that rely on rewriting data tothe magnetic stripe after the card has been issued need to be evaluated. Inparticular this may affect magnetic stripe based PVV solutions for online PINverification if PIN change is supported.

BP ALL Magnetic stripe based PVV methods should not be used for online PINverification if PIN change is supported.

Managing the Contactless Controls

The issuer should manage the offline counters and parameters for the contactlessinterface during the authorization response to a contact chip transaction. Theycannot be managed during a PayPass transaction as the Issuer AuthenticationData from the authorization response is never delivered to the card.



Issuer Requirements

Card Requirements

The PayPassM/Chip application may trigger an online authorization requestat the next contact transaction to enable management of the offline counters.

Personalization Requirements

The PayPass personalization requirements are detailed in the PayPassPersonalization Data Specifications and the M/Chip Advance PersonalizationData Specifications.

MasterCard requires that the personalization of each card configuration beapproved using the CPV service before cards are issued.

R ALL CPV must be successfully completed for all PayPass cards issued.

Proprietary data objects included in the card personalization that arenot documented in the MasterCard specifications may require dedicatedfunctionality on the terminal. Issuers should be aware of potential conflictswhen using such tags.

BP ALL Issuers should be aware of the risks and limitations associated withusing proprietary tags in their card personalization.

MasterCard prohibits encoding the cardholder name in the data read through thecontactless interface to prevent unauthorized disclosure. It is recommended touse a space character followed by the surname separator / in the Track 1 Data.

R ALL The name of the cardholder must not be readable over the contactlessinterface.

BP ALL Issuers should use / for the cardholder name in the data readthrough the contactless interface.

Third Party Data may be used by a terminal for proprietary processing. Issuersthat intend to participate in a scheme utilizing this data object must request aUnique Identifier from MasterCard. A sub-field of this data object is also used tocarry the Device Type. Refer to Data Requirements for more information. IfThird Party Data is personalized on the card, it is recommended that it be addedto the FCI Issuer Discretionary Data that is returned during application selection.

BP ALL If present in the card personalization, it is recommended that ThirdParty Data be included in the FCI Issuer Discretionary Data that isreturned when the application is selected.

R ALL If the Third Party Data included in the PayPass card is intended to beused to carry proprietary data, then the issuer must contact MasterCardto obtain the Unique Identifier.



Issuer Requirements

Card Requirements

R ALL Non-card form factors must be personalized with the Device Typepresent in the Third Party Data data object.

R ALL U.S. and Canada region issuers must ensure that each newly issued orreissued PayPass-enabled card, access device, and mobile paymentdevice is personalized with the appropriate Device Type value.

Issuers should be aware that the contents of the Proprietary Data subfield ofThird Party Data can be freely read and therefore should not contain sensitivecardholder information.

BP ALL Issuers should respect relevant local data privacy laws whenpersonalizing the Proprietary Data subfield of Third Party Data onthe card.

Data objects may be personalized in the card organized in the pre-defined filestructure detailed in the PayPass Personalization Data Specifications to allowefficient data capture by the PayPass terminal resulting in a faster transaction.

R ALL If data objects are not organized according to the rules specified forthe pre-defined file structure, then the pre-defined values for the AFLmust not be used.

PayPassM/Chip Personalization Requirements

Some data elements are unique for the contactless interface and some areshared with the contact interface.

For PayPass the issuer may operate in full chip grade, semi-grade or magneticstripe grade on the contact profile.

Issuers must use a different value for Chip CVC on the contactless interface tothe CVC1 encoded on the magnetic stripe. This prevents compromised PayPassdata being used to fraudulently create valid counterfeit magnetic stripe cards.

R ALL Issuers must support a Chip CVC in Track 2 Equivalent Data on thecontactless interface that is different to the CVC1 if present.

Maestro cards that do not have a CVC1 encoded on the magnetic stripe do notneed to include a Chip CVC.

However to protect against the risk of counterfeiting, it must not be possible toreproduce the Track 2 on the magnetic stripe from the PayPass data in the chip.This means that some aspect of the magnetic stripe data must be unique to thestripe, unpredictable and validated during the authorization.



Issuer Requirements

Card Requirements

R ALL Issuers that have the capability to distinguish between chip-read andmagnetic stripe-read transactions must support a Chip CVC in Track2 Equivalent Data on the contactless interface that is different to theCVC1 if present.

R ALL The genuine CVC1, as found on the physical magnetic stripe, must notappear in any data element that can be read through the contactlessinterface.

R MS Issuers of Maestro PayPass cards that do not have a Chip CVC in Track2 Equivalent Data must ensure that the Track 2 data found on themagnetic stripe cannot be reproduced from the PayPass data on thechip. Some aspect of the magnetic stripe data must be unique to themagnetic stripe, unpredictable and validated during the authorization.

To facilitate ATC monitoring, issuers should able to distinguish card identifiersread from separate cardholder devices, even if they are linked. This can bedone by using different PAN values and/or PAN Sequence Numbers.

BP ALL The issuer should not use the same combination of PAN and PANSequence Number on separate cardholder devices, even if linked.

Issuers may choose to use an Application PAN on the contactless interfacewhich is different to the PAN present on the magnetic stripe or that appearson the face of the card.

If this option is chosen, the issuer must be aware of the requirements to returnthe value of the embossed PAN in the response message for PayPass transittransactions.

To protect critical data used in the transaction, if the card supports offline cardauthentication then the data elements shown in the table below must be storedin records that are signed.

Data Element Tag

Application Currency Code 9F42

Application Expiration Date 5F24

Application Effective Date1 5F25

Application PAN Sequence Number 5F34

Application Primary Account Number 5A

Application Usage Control 9F07

CDOL1 8C

CDOL2 8D

1. If present



Issuer Requirements

Card Requirements

Data Element Tag

CVM List 8E

Issuer Action CodeDefault 9F0D

Issuer Action CodeDenial 9F0E

Issuer Action CodeOnline 9F0F

Issuer Country Code 5F28

SDA Tag List 9F4A

R ALL The data elements shown in the table above, if present, must all bestored in records that are signed.

If the card application supports the configuration of a maximum transactionamount, then it must only be used to influence the decision to authorize thetransaction online when possible. A transaction must not be declined basedsolely on this parameter on online capable terminals.

R ALL If a maximum transaction amount in the contactless card configurationis used, it must not lead to transactions being declined offline ononline capable terminals.

PayPassMag Stripe Personalization Requirements

The first and only record of the file SFI 1 must include the data objectsnecessary to perform the PayPass -Mag Stripe transactions.

The last digit of both Track 1 and Track 2 must not be used by the issuer as thisis used by the terminal to indicate the number of digits of the unpredictablenumber (nUN). The length of the unpredictable number must not be fewerthan 2 digits.

The positions where the PayPass reader stores the ATC, UN, and CVC3 in thediscretionary data in Track 1 Data and Track 2 Data, should be filled with zeroes.This is a requirement if PayPass On Behalf CVC validation services are used.

If the issuer intends to make use of MasterCards On-behalf Service for dynamicCVC3 verification, then the value of NATCTRACK1 and the value of NATCTRACK2must be greater than or equal to 3 for the CVC3 Validation in Stand-in Service,or greater than or equal to 2 for the dynamic CVC3 Pre-validation Service or thePayPass Mapping Service (processing only option). In both cases, a value of atleast 4 for NATCTRACK1 and NATCTRACK2 is recommended.

R MC Record 1 of SFI 1 must contain the data to perform a PayPassMagStripe transaction. Record 1 must be the only record included in SFI 1.

R MC The last digit of both Track 1 and Track 2 must not be used by theissuer.



Issuer Requirements

Issuer Host Requirements

R MC Placeholders for dynamic CVC3 data which is inserted by the terminalin either Track 1 or Track 2 must be zero filled if PayPass-on behalfCVC validation services are used.

R ALL The Unpredictable Number must be at least 2 digits in length.

R ALL Users of on-behalf services must use the appropriate minimum valuesfor NATCTRACK1 and NATCTRACK2.

Card Delivery

PayPass data can be read by any reader that can power the contactless chipand send the correct commands.

In order to fully benefit from new payment opportunities that contactless offers,issuers must inform cardholders that contactless functionality is available andprovide directions on using it with the card.

R ALL Issuers must alert cardholders that contactless functionality exists whenissuing/providing new cards.

Issuer Host RequirementsIssuer host must meet requirements to accommodate authorization messagesand decisions.

Authorization Messages

PayPass issuers must ensure host systems are capable of correctly receivingand processing authorization messages containing specific values for the dataelement (DE) 22 (POS Entry Mode) and DE 61 (POS Data) that identify PayPasstransactions.

DE 22 (POS Entry Mode), subfield 1, values of 06, 07 and 08 are usedfor PayPassM/Chip transactions. The values of 91 and 92 are used forPayPassMag Stripe transactions even if performed at a PayPassM/Chipterminal.

DE 61 (POS Card Data Terminal Input Capability Indicator), subfield 11,value of 3 indicates that the terminal supports PayPassM/Chip andPayPassMag Stripe transactions. A value of 4 indicates support forPayPassMag Stripe transactions. Note that these values may be used evenin the context of a contact transaction.

R ALL Issuers must support on their network interface and host systemPayPass transactions as described above.



Issuer Requirements


Authorization Decisions

Authorization requests are approved against the account balance or open tobuy position in the usual way. In addition, issuers should check the authenticityof the PayPass card by validating the dynamic CVC3 or application cryptogramreceived.

The issuer should take into account that bits that are not set in the TVR includedin the authorization request of a PayPassM/Chip transaction may not alwaysreflect the final outcome of the terminal tests performed. An example of this iswhen card authentication may have been completed after the GENERATE ACcommand was issued to the card or after the TVR was signed.

As part of the authorization decision process, issuers should also consider thenumber of transactions without cardholder verification that have been doneconsecutively.

Issuers should also consider the presence of transit indicators in DE 48(Additional Data), subelement 64 (Transit Program) of the authorizationmessage during the decision process.

Issuers should be prepared to receive correctly identified contactless ATMtransactions, even if not enabled on the card. Characteristics of contactlesstransactions performed on ATM are described in MasterCard Contactless ATMImplementation Requirements.

Although the information in DE 55 is normally consistent with other fields, theremay be some difference for certain data elements. Issuers should not routinelydecline transactions when differences occur in the data.

BP ALL Issuers should adapt their host systems to receive contactlesstransactions from ATMs, even if the card configuration indicates thecard is not valid for use on ATMs.

BP ALL Issuers should always perform online CAM by checking that the ARQCcontained in a PayPassM/Chip online authorization request is correct.

R ALL An authorization or clearing request may legitimately contain a TC inDE 55 (Integrated Circuit Card [ICC] System-Related Data). Issuers mustnot routinely decline transactions in this situation.

BP ALL If the ARQC is correct, the issuer should not decline a transactionsimply because the data in DE 55 is different from the values in thefollowing data elements:

DE 3Processing Code

DE 4Amount, Transaction

DE 13Date, Local Transaction

DE 43Card Acceptor, Name/Location

DE 49Currency Code, Transaction

DE 54Additional Amounts



Issuer Requirements


R MC Issuers must always perform online CAM by checking that the CVC3contained in a PayPass Mag Stripe online authorization request iscorrect.

R MC Issuers must be able to process PayPassMag Stripe transactions ifeither Track 1 Data or Track 2 Data is present in the authorizationmessage.

BP ALL Issuers should manage the risk of PayPass transactions done without aCVM that are approved consecutively.

BP ALL Issuers should adopt the authorization decision process whenappropriate for transit-based transactions.

Application Transaction Counter Monitoring

The role of the ATC is to ensure that every cryptogram produced by a genuinecard is unique.

The ATC is incremented by the card during each transaction. However,although ATC values are generated sequentially, they may not be presentedto the issuer in this way. Transactions may sometimes be completed offline,completed with deferred authorization, or not completed at all. In thesesituations ATCs could be missing in the sequence received by the issuer, or theycould be received out of sequence.

For approved transactions where the application cryptogram or dynamic CVC3has been successfully validated, issuers should keep a record of the most recentATC received (the last seen ATC). Issuers should set a feasible range, outsideof which the receipt of an ATC value is considered suspicious. This mayindicate fraud, or that a cardholder is having problems using their card. Forthese transactions issuers should raise a post-event alert and conduct furtherinvestigation, but should not decline the transaction for this reason only. Asuitable value for this range will depend on the market environment where thecard is used. For example, if offline transactions are frequently performed fortollways or transit, then a wider range will be required. The range might not bethe same above as below the last seen ATC.

Issuers should not routinely decline transactions where the ATC is out of therange that they have set or if the ATCs arrive out of sequence.

To detect duplicate ATCs, issuers may also consider keeping a record ofprevious ATCs received where the application cryptogram or dynamic CVC3has been successfully validated (limited to a practical window size) or all ATCsmissing from the sequence up to the last seen ATC. If the same ATC is receivedtwice with valid, but different application cryptogram or dynamic CVC3 valuesthen this indicates that the secret keys of the card have been compromised. Ifthe same ATC is received twice with valid, but identical application cryptogramor dynamic CVC3 values then this may indicate attempted replay fraud. In bothcases the issuer should decline the transaction and investigate further.



Issuer Requirements


The issuer may wish to accept and process Authorization Advice/0120 messagesin order to maintain up to date ATC values as part of ATC management.

BP ALL For approved transactions where the application cryptogram hasbeen successfully validated, issuers should keep a record of the lastseen ATC and set a feasible range. Subsequent transactions receivedwhich contain an ATC outside of this range should be treated assuspicious, but should not be routinely declined.

BP ALL Issuers should implement a mechanism to detect duplicate ATCs anddecline and investigate further when duplicates are detected.

Authorization Responses

A referral response must not be given to a PayPass authorization request.

Since the consumer remains in control of the PayPass card throughout thetransaction, the opportunity for merchants to pick up these cards is limited.Issuers should not use a capture card authorization response to PayPasstransactions.

As a result of contactless-specific risk management the issuer may wish todecline and prompt the cardholder to perform a contact transaction with CVMwhere possible. In this case the issuer should use an authorization responsecode 65 exceeds withdrawal count limit.

The issuer should therefore be aware that if a response code other than 65exceeds withdrawal count limit is used the terminal might not prompt for asubsequent contact transaction to be performed.

For PayPassM/Chip authorization responses, the issuer should not generateIssuer Authentication Data, because the PayPass terminal is not able to passit to the PayPass card.

For PayPassM/Chip authorization responses, the issuer should not includeissuer scripts because the PayPass terminal is not able to pass them to thePayPass card.

R ALL Issuers must not use a referral 01 authorization response code.

BP ALL Issuers should not use a capture card 04 authorization response code.

BP ALL PayPassM/Chip issuers should not generate Issuer AuthenticationData for authorization responses.

BP ALL PayPassM/Chip issuers should not send scripts with authorizationresponses.



Issuer Requirements

Clearing Requirements

R ALL Issuers that use a PAN mapping service must return the genuine PANin the authorization response message, even if an alternative PAN wasused in the authorization request.

BP ALL If the issuer declines a contactless transaction on a dual interface card,but wants to offer the cardholder the option to perform a contacttransaction, an authorization response code 65 exceeds withdrawalcount limit should be used.

Refunds

MasterCard PayPass issuers must be able to support the processing of a refundtransaction initiated via the contactless interface.

R MC Issuers must be able to process refunds initiated via the contactlessinterface.

Clearing RequirementsPayPass transactions are identified in clearing messages.

Clearing Messages

PayPass issuers must ensure host systems are capable of correctly receiving andprocessing existing subfields within the clearing message containing specificvalues of the data input capability and the data input profile, DE 22 (POSEntry Code).

DE 22, subfield 1 identifies the terminal capabilities and must contain:

the value of M for a transaction at a PayPassM/Chip terminal.

the value of A for a transaction at a PayPassMag Stripe terminal.

DE 22, subfield 7 identifies the card data input profile for this transaction andmust contain:

the value M for a PayPassM/Chip transaction.

the value A for a PayPassMag Stripe transaction.

R ALL Issuers must support PayPass transactions as described above on theirclearing interface and host system.

As there is only one GENERATE AC command in a PayPass transaction, thecryptogram and related data included in the clearing message will always relateto the first GENERATE AC. The cryptogram may be a TC or an ARQC.



Issuer Requirements

Chargeback and Exception Processing

Chargeback and Exception ProcessingIssuers may not make a retrieval request for a transaction identified as a PayPasstransaction that is less than the CVM limit, except in certain transit situationsas defined in the Chargeback Guide.

No new chargeback reason codes have been introduced to support PayPass.Updates to the existing reason codes are documented in the Chargeback Guide.



Chapter 4 Acquirer RequirementsThis section includes

ppcr manual

Documents