Technical Solution for Transit Contactless Open Payments Use Case 1: Pay As You Go/ Card

Transcription

1 Technical Solution for Transit Contactless Open Payments Use Case 1: Pay As You Go/ Card Transit Contactless Open Payments Working Committee Version 1.0 Date: September 2017 U.S. Payments Forum 2017 Page 1

2 About the U.S. Payments Forum The U.S. Payments Forum, formerly the EMV Migration Forum, is a cross-industry body focused on supporting the introduction and implementation of EMV chip and other new and emerging technologies that protect the security of, and enhance opportunities for payment transactions within the United States. The Forum is the only non-profit organization whose membership includes the entire payments ecosystem, ensuring that all stakeholders have the opportunity to coordinate, cooperate on, and have a voice in the future of the U.S. payments industry. Additional information can be found at About the Transit Contactless Open Payments Working Committee The goal of the Transit Contactless Open Payments Working Committee is for all interested stakeholders to work collaboratively to identify possible solutions that address the challenges associated with the implementation of contactless open loop acceptance terminals at gated customer points of entry within the unique retail environment of the U.S. and Canadian public transit market. EMV is a trademark owned by EMVCo LLC. Copyright 2017 U.S. Payments Forum and Secure Technology Alliance. All rights reserved. The U.S. Payments Forum has used best efforts to ensure, but cannot guarantee, that the information described in this document is accurate as of the publication date. The U.S. Payments Forum disclaims all warranties as to the accuracy, completeness or adequacy of information in this document. Comments or recommendations for edits or additions to this document should be submitted to: Transit-Open- Payments@uspaymentsforum.org. U.S. Payments Forum 2017 Page 2

3 Table of Contents 1. Introduction U.S. Payments Forum Antitrust Compliance Statement Key Terms General Background Purpose Background on the Transit Environment Overview Unique Aspects of the Transit Environment Description of Use Case 1: Pay As You Go / Card Definition Transit Merchant Use Case 1 Requirements Acquirer/Processor Transit Use Case 1 Requirements Issuer Transit Use Case 1 Requirements Technical Functional Proposal Approach to Developing the Solution Three Pillars to a Secure Transaction: Card Authentication, Cardholder Verification, Financial Authorization Step 1: Card Authentication Online and Offline Authentication Types of Offline Authentication Differences between Credit and Debit Card Authentication Solution Stakeholder Impact Step 2: Cardholder Verification Differences between Credit and Debit Cardholder Verification Solution Stakeholder Impact Step 3: Financial Authorization Differences between Credit and Debit Authorization Solution Stakeholder Impact Transaction Flow Diagram Conclusion Legal Notice U.S. Payments Forum 2017 Page 3

4 1. Introduction 1.1 U.S. Payments Forum Antitrust Compliance Statement This paper was prepared in compliance with the U.S. Payments Forum Antitrust Compliance Statement, which is stated below: U.S. Payments Forum activities and meetings of U.S. Payments Forum members and participants necessarily involve cooperation of industry competitors. Accordingly, it is the express policy of the Forum to require that all of its activities be conducted strictly in accordance with applicable antitrust laws. It is therefore extremely important that members and meeting attendees adhere to meeting agendas, comply with the Forum bylaws and Secure Technology Alliance Antitrust Guidelines, and at all times, be aware of and not participate in any activities that are prohibited under applicable U.S. state, federal or foreign antitrust laws. Examples of types of actions that are prohibited at Forum meetings and in connection with its activities are: price fixing, agreements to allocate customers or markets, boycotts and other concerted refusals to deal, as well as discussion of or agreements regarding discriminatory pricing, discounts, incentives, awards, penalties, compliance and enforcement programs and other related matters. Any discussion of such activity is strictly prohibited. Forum bylaws are available at: Secure Technology Alliance Antitrust Guidelines are available at: Policy-Jan-2017.pdf 1.2 Key Terms These key terms are defined for purposes of their use in this paper. Access form factor (or a credential): A card associated in the merchant system with a stored fare product (dollar value or a pass) that has been purchased in advance, and which can be used to gain entry through a Paid In Advance transaction. Such card could be credit, debit, or prepaid, including gift cards and electronic benefit transfer (EBT) cards. Card: Generally, used within this document to refer to a chip-enabled contactless payment device, regardless of form factor. For the purpose of this document with respect to any discussion of Transit Use Case 1 (defined below), however, card shall be used to refer specifically to a plastic card issued by a financial institution which has an EMV contactless interface and with which a Pay As You Go transaction can be made. Such card could be a credit, debit, prepaid, gift or benefit transfer card (e.g., transit, EBT). Deferred Authorization: An authorization request or financial request that occurs when a merchant captures transaction information while connectivity is interrupted; the merchant holds the transaction until connectivity is restored. After connectivity is restored, the merchant sends the transaction to make an online authorization request, and receives an authorization response from the issuer. A subset of Delayed Authorization. Delayed Authorization: An authorization request sent any time after the transit customer has been allowed entry to travel. U.S. Payments Forum 2017 Page 4

5 Fixed fare: The cost of a ride is constant or flat. Merchant host: The backend (or back office) of the merchant s payment system. Open Payments (or Contactless Open Payments): For the purpose of this document, Open Payment will mean a purchase transaction made with a card at a transit point of entry terminal. Paid In Advance transaction: A fare purchased in a completed financial transaction at a terminal other than the transit point of entry terminal before entry (e.g., purchased at a kiosk or attended booth, via mobile app, or online). Pay As You Go transaction (PAYG): A single ride fare purchased with a contactless card or other form factor issued by a financial institution by tapping at the transit point of entry. The single ride fare may be fixed or variable. Transit Point of Entry: Generally, used within this document to refer to a fare gate with a barrier (for entry and/or exit), a bus entry either next to an operator or at a rear door, a train platform device or other space within the transit area wherein a customer needs to pass in order to access and/or pay for the travel service. For the purpose of this document with respect to any discussion of Transit Use Case 1, however, transit point of entry shall be used to refer specifically to only an unattended contactless-only fare gate or bus entry used to control access in/out of the transit network (which network may include trams and ferries). Transit Point of Entry Terminal (Transit POE Terminal, Transit POE or POE): For the purpose of this document, a contactless-only (i.e., no contact or magnetic stripe acceptance) point of sale terminal placed at a transit point of entry and, in some cases, integrated with the entry point barrier (e.g., a terminal at a turnstile or at a bus entry). Transit Use Case 1: A specific retail scenario defined in this paper in Section 3 below. Variable fare: The cost of a ride is contingent on time of day, distance travelled and/or other factor. 1.3 General Background This paper is a deliverable of the Technical Work Group designated as part of the larger Transit Contactless Open Payments Working Committee (TWC). The goal of the Transit Contactless Open Payments Working Committee is for interested stakeholders to work collaboratively to identify possible solutions that address the challenges associated with the implementation of contactless acceptance terminals at gated customer points of entry within the unique retail environment of the U.S. and Canadian public transit market. The TWC is using a use case approach to identify specific scenarios and the challenges associated with those scenarios for transit merchants of contactless open payments acceptance in order to meet the following objectives of the TWC (as stated in the TWC Statement of Work): Create and/or identify potential payment network-agnostic solutions that meet stakeholder needs and preferences for POE contactless payment card acceptance, for both attended and unattended terminals, specific to the distinct features of the transit retail environment. o o Viable solutions will need to address acceptance challenges for mobile and other form factors that are valid contactless payment credentials that can be resolved through technical implementations. Viable solutions will need to encompass acceptance of prepaid and gift cards, electronic benefit cards and transit-issued cards, along with credit and debit cards. U.S. Payments Forum 2017 Page 5

6 o Areas that require a business solution(s) and best practices for resolving those business issues may be identified but will be out of scope for resolution as Working Committee activities. Understand each stakeholder group s business needs and preferences for contactless payments acceptance at transit POEs. Understand the potential impact of identified solutions on each stakeholder group, including customers. The TWC first identified several possible transit scenarios, considering variations in fare types and payment technologies, shown in Table 1 below. Table 1. Potential Transit Scenarios to Address TRANSIT FARE SCENARIOS PAYMENT TECHNOLOGIES SCENARIOS Pay-As-You-Go/Single Ride Fare Paid-In-Advance Aggregated Pay-As-You-Go Post-ride Customer Service Prepaid, including Transit Benefit Cards, EBT Mobile Tokenization, PAR, F-PAN to D-PAN Additional Challenges of Debit The TWC also captured items in a parking lot that were challenges that cut across multiple scenarios. These items, such as tokenized primary account number (PAN) with deferred authorization and card positioning (when multiple contactless cards are in physical wallet, and the card closest to reader is read), may turn into individual use cases later or be addressed with one or more of the above scenarios. The TWC discussed the various identified scenarios, and decided to proceed forward with Pay As You Go/Card as Use Case 1. This scenario, further discussed below, was selected primarily because it was a relatively simple scenario that would also result in solutions that would be the foundation for other scenarios. The TWC Co-Chairs designated a Technical Work Group to address the above stated objectives for Use Case 1. The Technical Work Group is comprised of technical experts, including representatives from American Express, Discover, Mastercard, Visa, FIS Global on behalf of the U.S. debit networks, Interac, transit merchants, and payments consultants. The solutions presented in this paper cover the global networks and the domestic U.S. and Canadian debit networks. The following should be noted: JCB expects to follow Discover requirements for JCB transactions acquired in the U.S. via Discover, and expects to follow American Express requirements in Canada. UnionPay expects to follow Discover requirements where its transactions use Discover rails. Debit Network Alliance (DNA) expects to have a contactless solution that each of the debit networks can use, in addition to cards enabled with the U.S. Common Debit AID. U.S. Payments Forum 2017 Page 6

7 1.4 Purpose The scope for this paper is to identify and provide guidance for technological solutions that could be used to implement contactless open payments, as defined below, in Transit under Use Case 1. Business risks and challenges, such as the following, are out of scope: network or other payment industry business rules, terms or similar matters; pricing, fares, penalties, discounts, and related policies and matters, including but not limited to incentives for cardholders to more rapidly adapt to usage of contactless open payments; and any allocation or sharing of risk, liability, payments or similar matters. Additional use cases based on the scenarios shown in Table 1 above are expected to be addressed by this or other work groups to be designated for this purpose. 2 Background on the Transit Environment 2.1 Overview At points of entry, legacy fare payment systems present minor risk to transit merchants. Fare transactions at transit points of entry are typically based on fares purchased in advance and the required presentment of a transit-issued closed loop stored value magnetic-stripe or chip card, paper ticket with bar code or magnetic stripe, or token or exact change at a point of entry. The customer has to complete a financial transaction to obtain the required fare media at a terminal located other than the point of entry (e.g., kiosk, attended booth, via mobile app or online). Thus, today s point of entry transactions are relatively low risk to the transit merchant since authentication and payment are already confirmed with the purchase of fare media before the customer uses fare media to gain entry. It should be noted, however, that such purchase transactions are subject to being charged back after the fare media is used to gain entry. Many transit agencies that issue electronic fare media can also quickly shut down a transit card should, for example, there be value remaining on a card after a fraudulent purchase. Transit is looking to deploy retail-like open payment systems. This provides the potential for financial transactions to move: FROM being made in advance and away from the entry point (e.g., at vending machines) TO being made at the entry point when the customer is ready to travel A customer no longer has to use his/her own payment form factor to first obtain transit-issued fare media for entry; s/he can use his/her own form factor at the entry point. However, authentication and payment may not be as certain for the transit merchant as it is with, for example, a purchased ticket. Through discussion of the applicable transit use cases, the objective is to understand and identify the technological changes needed in the payments ecosystem for open payments and contactless EMV chip cards to be a viable option to supplant or supplement the transit closed loop system. 2.2 Unique Aspects of the Transit Environment The transit retail environment has several distinct features: Contactless-only terminals are at transit points-of-entry. Given current processing speed capabilities and rider safety concerns, it will not be feasible to accept magnetic-stripe or contact U.S. Payments Forum 2017 Page 7

8 EMV payments at the transit point-of-entry. The transit rider must have an EMV-based 1 contactless payment card to tap in order to be able to enter a ride. Point-of-entry terminals are not always online. Given their use in a subway environment (which may be wired and/or wireless) and/or on board a bus (which is only wireless), payment terminals may lose connectivity to the merchant host periodically (i.e., be offline). Point-of-entry terminal must have capability to be able to process 100% of the time. Regardless of the online/offline availability of the terminal, the terminal needs to be able to transact in order to ensure a consistent customer experience. No cardholder verification is possible at the point-of-entry terminal. There is no terminal ability to capture a PIN or signature at the transit point-of-entry (unattended, low value payment). The only EMV cardholder verification method (CVM) available on the transit POE for a card is No CVM. No real-time authorization response is possible at the point-of-entry terminal prior to go/no customer prompt. There is no ability to perform consistent real-time online authorization as currently defined in networks operating rules within a sub-second timeframe needed to provide safe, consistent, passenger flow through the transit point-of-entry. Transaction amount at the point-of-entry terminal is unknown due to variable fare. The fare applicable to the transit rider may not be known at the time of the tap and could have a dollar value that varies with location, time of day, or other factors, or have no dollar value such as if associated with a pass purchased in advance or a free transfer. Ability for transit merchant to hot list a card quickly is critical in preventing recurring fraud. The ability to block a card so that it will be declined at every transit POE is critical in preventing use of a fraudulent card or fraudulent use of a payment card once it is known there was or could be fraud perpetrated with a tap. Transactions are predominantly low value (e.g., single fare ride). With Open Payments, the transit rider initiates payment for a single ride and gains entry using a single tap of his/her card. Acceptance of cards at transit points-of-entry is expected to increase the number of single ride purchases in the merchant system and on cardholders cards. Transit is a public service. As a public service, transit agencies cannot require payment devices for fare payment that would serve to limit access to transit. Transit has to provide a contactless card both for customers who do not have a card that can be used at a transit POE and for customers who prefer not to use their own card. 1 Magnetic stripe data (MSD) contactless cards are still in the market today, and accepted at transit non-emv terminals configured/deployed to process non-emv contactless transactions. However, MSD functionality is not addressed in this paper, since both the definition of the use case and the approach to developing the solution are EMV-based. U.S. Payments Forum 2017 Page 8

9 3 Description of Use Case 1: Pay As You Go / Card Provided below is the description of the Use Case 1 scenario that the Work Group was tasked with addressing through technical solutions, and the risks and challenges that arise from this scenario as seen from the transit merchant perspective. 3.1 Definition The customer taps a card at the POE to pay for a single ride through a Pay As You Go transaction and gain access to the subway or bus. The customer taps in only. The customer must receive a go/no go type prompt within a sub-second. 3.2 Transit Merchant Use Case 1 Requirements The unique features of the transit environment as described above create risks for the transit merchant under Use Case 1. For example, it was noted above that: (i) the POE cannot wait for the issuer authorization response prior to signaling the entry decision to the customer; (ii) the terminal could be offline and not able to conduct online authentication, let alone online authorization; and (iii) the POE will not be able to support CVM processing. All of these conditions increase counterfeit risk and/or card lost/stolen risk for the merchant. Additionally, receipt of the online authorization response after a customer has been allowed entry creates a new type of financial risk for transit agencies moving to open payments first tap risk or the risk of a decline response and not collecting fare payment for a ride that s been taken already. Generally, with open payments, there could be a higher probability of wrongly allowed customer entries and wrongly denied entries, opening up the merchant to not only financial risks, but also the risks of poor quality customer experience. In order to address the risks of Use Case 1, the requirements for a card to be securely processed at a transit POE within the scope of the Use Case 1 scenario from the transit merchant perspective are listed in Table 2 below. Table 2. Transit Merchant Requirements for Transit Open Payments Use Case 1 Index # Requirement M1 Solution must be able to validate that cards presented are genuine. M2 Solution must support acceptance/processing of a contactless card with No CVM transaction only. There is no fallback to magnetic stripe or other CVMs possible. M3 Solution must support processing of transaction when price is unknown at time of transaction. M4 Solution must support POE provision of go/no go customer entry prompt within a sub-second (typically no more than 500 milliseconds) of valid customer tap. POE should not need to connect to merchant host to make the go/no go entry M5 decision for customer. All necessary decisions should be available locally at the terminal. M6 Solution provides for secure transactions meeting EMVCo standards for authentication and authorization of chip transactions. M7 Solution must support merchant ability to identify transaction as PAYG or as Paid- In-Advance before an authorization request is sent. M8 Solution supports acceptance of all validly issued cards that meet transit requirements (e.g., meet M1 requirement above). U.S. Payments Forum 2017 Page 9

10 Index # Requirement M9 Solution is payment card agnostic. Solution does not limit ability to provide effective customer messaging (e.g., what M10 is shown to customer when a tap is approved or declined) at POE. Solution must be cost effective to deploy minimized cost of deployment at POE and merchant host, minimal to no deviation from payment networks contactless M11 related standards, minimal to no terminal kernel changes for implementing this use case. Solution preserves standard U.S. EMV routing choices through use of U.S. M12 Common Debit AID. Solution must be future proofed; it should allow support for possible future changes in the solution parameters to support additional use cases and, to the M13 extent possible, for possible future changes in the authentication and/or authorization processes. 3.3 Acquirer/Processor Transit Use Case 1 Requirements The requirements for a card to be securely processed at a transit POE within the Use Case 1 scenario from the acquirer/processor perspective are listed in Table 3 below. Table 3. Acquirer/Processor Requirements for Transit Open Payments Use Case 1 Index # Requirement A1 Able to identify and handle transactions when amount is unknown for PAYG transactions, meeting network transit message requirements and rules. A2 Solution must support acquirer/processor processing of deferred EMV authorization requests from transit merchant. A3 Solution does not directly impede processing ability to handle large volumes of authorization requests from transit merchant. A4 Solution must support single message and dual message, according to network requirement. A5 Solution must preserve standard U.S. EMV routing choices through use of U.S. Common Debit AID. Solution supports processing of authorization and clearing messages (dual or A6 single message transactions), for all EMV contactless enabled cards that support the solution. A7 POE used by transit merchants is EMV and/or payment network Level 1 and 2 certified. Solution must not add unnecessary complexity to the existing transit merchant A8 end-to-end transaction certification process with payment networks (Level 3 certification). A9 Support robust network for Certificate Authority Public Key life cycle management and loading into/removing from transit POE. Solution must support ability to pass on the business reason for negative A10 authorization responses to the transit merchant, to the extent provided by issuer or acquirer, without converting all to issuer decline. A11 Solution must support ability for processor to submit reversals or repeat authorizations for PAYG transactions for transit merchants. U.S. Payments Forum 2017 Page 10

11 3.4 Issuer Transit Use Case 1 Requirements The requirements for a contactless EMV card to be securely processed at a transit POE within the Use Case 1 scenario from the issuer perspective are listed in Table 4 below. Table 4. Issuer Requirements for Transit Open Payments Use Case 1 Index # I1 I2 I3 I4 Requirement Able to identify and handle transactions when amount is unknown for PAYG transactions, meeting network transit message requirements and rules. Solution does not impede issuer ability to handle large volumes of authorizations from transit merchant. Able to issue cards according to network guidelines while fulfilling proposed solution. Solution enables issuer to manage post-authorization customer service driven authorizations and reversals associated with original authorization request. May be transit agency initiated or cardholder-initiated via in-app or e-commerce channel. 4 Technical Functional Proposal 4.1 Approach to Developing the Solution Given the transit POE s inability to rely on real-time, online issuer authorizations to address counterfeit and credit risk, the approach would ideally afford Transit the same or better protections as provided by real-time online authorizations assuming a prescribed set of offline risk practices are performed and satisfied. 4.2 Three Pillars to a Secure Transaction: Card Authentication, Cardholder Verification, Financial Authorization Card Authentication. Card authentication is performed in an EMV-based process to prevent counterfeit fraud. The authentication process validates that the card being used in the transaction is genuine and was issued by the issuer. The authentication process may be supplemented by the merchant s list management process based on the merchant s deny list and the payment networks negative files. Cardholder Verification. Cardholder verification is performed in an EMV-based process to ensure that the cardholder is genuine and that the card has not been lost or stolen. Financial Authorization. Financial authorization is performed in an EMV-based process in order to ensure funding is available in the cardholder s account. 4.3 Step 1: Card Authentication Online and Offline Authentication There are two ways to ensure the card is genuine and not a clone or fake: online and offline authentication. U.S. Payments Forum 2017 Page 11

12 With online authentication, the issuer host verifies a cryptogram generated by the card, ensuring the card is legitimate due to the fact of using the same secret payment key present on the card and known to the issuer host. The challenge for Transit with this form of card authentication is that the data must reach the issuer host for validation. Using Offline Data Authentication (ODA) technology, which allows the terminal (instead of the issuer host) to validate the card being used for payment is genuine and not counterfeit, is one of the key attributes that contactless EMV offers the transit agencies. The diagram below demonstrates the difference between card authentication with and without ODA support (both illustrations assume No CVM as the cardholder verification method). POE Terminal With ODA support Initiate Transaction Real Time (at the terminal) Card Authentication Host Transaction Authorization POE Terminal Without ODA support Initiate Transaction Host Card Authentication (as part of) Transaction Authorization ODA allows the POE to determine the card s authenticity by rigorously validating unique card and transaction information in a secure manner. Most notably, ODA protects against cloned cards and wedge attacks, which provides the extra protections needed for the transit agency, issuer, and acquirer in a transit open payment environment. ODA uses a cryptographic algorithm called RSA, which is based on asymmetric cryptography (PKI Public Key Infrastructure) and is supported by the EMVCo specifications. Successful authentication at the POE does not mean the account is in good standing, or that an authorization will be approved. It just means that the card has passed the offline security checks and is determined to be an authentic card. Cardholder verification and financial authorization are still required for a transaction to be successfully authorized and approved. If a card fails an ODA authentication check, it will be because: The card is expired or in some way damaged, preventing security checks from taking place; or The card is fraudulent, e.g., cloned; or The card terminal has not been set up correctly; e.g., Certificate Authority Public Keys (CAPKs) may not be loaded properly into the terminal. In such cases as these, the transaction will terminate at the terminal and the customer is denied entry at the POE unless the customer utilizes another fare payment method. U.S. Payments Forum 2017 Page 12

13 4.3.2 Types of Offline Authentication There are three types of Offline Data Authentication (ODA): i. Static Data Authentication (SDA) The entry level of ODA in EMV. SDA is no longer accepted as an industry standard. This only protects against counterfeit and not skimming, and cards using SDA can be copied and reused. ii. Dynamic Data Authentication (DDA) Used for EMV and in some contactless implementations (where it is termed fdda for fast DDA) to protect against counterfeit and skimming. Each transaction is unique and the digital signature cannot be reused. iii. Combined DDA and Application Cryptogram Generation (CDA) Used for EMV and contactless implementations to protect against counterfeit, skimming and man-in-themiddle attacks (between the card and the terminal) Differences between Credit and Debit Card Authentication For the transit POE terminal to perform dynamic ODA, the card application selected at the time of tap at the POE has to support dynamic ODA. The AID of the application selected may support a variation of the ODA functionality as defined by the payment network providing the AID. Credit: Typically credit cards have only one AID payment application. Debit: Typically debit cards offer two AIDs, one to support transactions within the country and another to support global international networks. U.S. Debit Implementation The Transit POE terminal may select either the global AID or the U.S. Common AID, which can be routed to any payment network associated with the card as long as the AID selected provides the necessary functionality to facilitate ODA. Canada Debit Implementation For Canadian domestic POS acceptance, the Canada Application Selection Flag (ASF) in debit cards today typically points to the Interac AID. In this case, the Interac Association network is to provide the means of ODA as defined in the Interac Flash contactless specifications Solution In the transit environment, where connectivity is an issue, and if there is delayed authorization, ODA becomes a critical first step in risk mitigation. Without ODA, there s minimal ability to detect counterfeit cards. Transit agencies cannot effectively manage access to the transit network or limit their financial exposure if they cannot be assured of a card s authenticity each time the card is used at the POE terminal that is offline. CDA and fdda are the ideal options to be used for contactless open loop payments as they provide the highest level of protection for authenticating the card at the POE terminal Stakeholder Impact The North American market is online only with zero floor limits and does not require offline data authentication (or offline authorization) for contact-only cards. Some issuers, however, have chosen to issue DDA/CDA-capable cards. Enabling ODA capability is critical to ensuring security at the POE terminal and the integrity of the payment process. U.S. Payments Forum 2017 Page 13

14 How each network or issuer or acquirer or any other party chooses to support ODA is beyond the scope of this document. However, each payment network has a position with regard to supporting, recommending and requiring ODA for their issuers. Table 5 below provides the current position of each payment network with regard to ODA for contactless EMV transactions in North America irrespective of merchant vertical: Table 5. ODA Position by Payment Network Network: American Debit Discover Position: Express Networks Interac Mastercard Visa Type CDA CDA CDA CDA CDA fdda Supported Recommended Required No* No* No * This reflects the network s current position today. Whether the network changes its position in the future specifically for transit and/or all merchant verticals will depend on the future decision of each payment network. Issuers utilizing any of the above payment networks specifications would need to check with those networks for the corresponding support for ODA on the U.S. Common Debit AID. There are impacts from utilization of authentication at the POE on various stakeholders. Here are a few examples: Merchant: Implement ODA at the POE. Issuer: Authentication at the POE involves personalizing the card with public key certificates as supported by each of the payment networks, global and domestic, and managing their related lifecycles. Depending on whether the issuer already supports ODA, this may add to the issuer s cost and complexity to support ODA functionality. Acquirer: The acquirer must perform the provisioning and lifecycle management of each payment network s public key certificates into their transit merchant clients terminals. This includes the additional terminal testing and certification involved to demonstrate support for offline contactless acceptance. 4.4 Step 2: Cardholder Verification Each of the payment networks has established transaction amounts, which may vary by MCC (Merchant Category Code), above which cardholder verification must take place (either using signature, PIN or biometric) in order to protect merchants from lost/stolen chargebacks. If a transaction is below this threshold, then no cardholder verification is required. For transactions above this threshold amount, then CVM processing is required and performed based on what the card and terminal both support. Table 6 below describes various CVM options applicable to cards supported by EMV; the CVM option relevant to contactless open payments is discussed later in this section. For Use Case 1, other CVM options such as Consumer Device CVM (CDCVM) on mobile devices and biometric verification are not applicable. U.S. Payments Forum 2017 Page 14

15 Table 6. CVM Options Specific to Cards CVM Online PIN Signature No CVM Description The PIN Pad prompts the cardholder for a PIN and encrypts it using the same key used for magnetic stripe debit PIN encryption. The encrypted PIN block is sent to the issuer host in the online authorization message. Note: PIN can only be performed in a PCI PTS approved terminal. This method operates in the same manner as in the magnetic-stripe environment. The cardholder signs the transaction receipt and the merchant compares this signature to the signature on the card. This method operates in the same manner as in the magnetic-stripe environment where transaction authorization is independent of cardholder verification. No cardholder verification is usually supported in merchant environments, such as certain unattended low-value transaction environments (i.e., vending machines), quick service restaurants and other small ticket environments Differences between Credit and Debit Cardholder Verification There are no differences between debit and credit transaction processing from the cardholder verification perspective Solution The purchase amount associated with an individual Pay As You Go transaction is expected to be lower than any of the transaction amount thresholds (or CVM floor limits) that most payment networks have established before requiring cardholder verification of some type. This low-value transaction, coupled with the POE s inability to perform cardholder verification, means the only acceptable CVM is No CVM Stakeholder Impact No CVM is a standard CVM on all card types and supported in all terminal configurations, therefore its use at POE terminals should not impact the stakeholders, including Issuers, networks, acquirers, cardholders, or customer service. How each network or issuer or acquirer or any other party chooses to support No CVM is beyond the scope of this document. However, each payment network has a position with regard to supporting, recommending and requiring No CVM for their issuers. Table 7 below provides the position of each payment network with regard to No CVM as a verification method with regard to No CVM for contactless EMV transactions in North America irrespective of merchant vertical. 2 While not in the scope of Use Case 1, the mobile form factor may involve its own verification separate from what the POE requests, and does not involve interaction with the terminal. U.S. Payments Forum 2017 Page 15

16 Table 7. No CVM Position by Payment Network Network: American Debit Discover Position: Express Networks* Interac Mastercard Visa Supported 3 Recommended Required 4.5 Step 3: Financial Authorization As indicated earlier in this paper, one of the unique features of the transit retail environment is the need to ensure rider safety i.e., a payment process that supports a smooth or uninterrupted flow of riders through gated points of entry minimizing queuing at these points of entry. Ensuring rider safety requires sub-second transactions as measured from the time of the customer s tap to the time the customer receives a go/no go prompt to ensure safety-based throughput speeds. At today s typical network communication rates, an online authorization of a card results in a transaction time that is far greater than that acceptable at gated points of entry for transit. As a result, with a Pay As You Go transaction, it is expected that access to the transit service will have to be granted before funds can be secured with an online authorization. This is very different from traditional ticketing whereby payment is obtained before any travel occurs. Financial authorizations of contactless EMV transactions can be carried out offline to verify funding is available prior to the entry decision. However, the U.S. and Canada are online-only markets, with no offline solution available today in those markets and such a solution is not expected to be deployed in these markets in the foreseeable future. As a result, the Work Group did not further consider the offline authorization option for Transit Differences between Credit and Debit Authorization Support for online authorization: None, as both credit and debit are typically online authorized in the U.S. and Canada markets. Guarantee of payment to merchant: Prior to completion of online authorization, it is not possible to guarantee merchant receipt of funds using credit or debit. Relevant differences in this regard include (without limitation): Credit A credit limit is typically universally supported and is a large amount compared to a single ride transit fare. Debit Authorized based on account balance, and/or overdraft protection, or by stand-in amounts. Note: Not all cardholders elect to have overdraft protection. 3 No CVM for Interac A proprietary mechanism is used to ensure that no CVM is required for contactless payment within certain purchase amount limits. * Each debit network determines the parameters for its own No CVM support. U.S. Payments Forum 2017 Page 16

17 Transaction routing and processing: Credit Typically uses Dual Message System (DMS) network messages (authorization request message separate from clearing and settlement message) Debit 1. Authorization Request Message: To check account s Open to Buy position and to place a hold on funds Doesn t actually charge the account 2. Clearing and Settlement Message: Typically submitted in an offline batch file at end of merchant s processing day Charges account for amount of settlement transaction, which typically (may be some exceptions) must be less than or equal to the approved authorization amount Can support single or dual messaging transaction processing, dependent on the payment network. Dual message is where an authorization message is sent to perform status check or hold funds for a given time period, and followed by a financial message and match to the hold. Single message is where the account is authorized and debited immediately for funds. Pre-Authorizations: Used for credit and debit when final amount of transaction is not known at time of presenting payment form factor to payment terminal Credit Debit Used across multiple merchant types. Typically reserves funds up to the amount of the Pre-Authorization Request. May be some exceptions where final amount may be permitted to be a percentage over the preauthorized amount. Funds reserved. Depending on the merchant type; funds may be reserved for days, weeks, or longer. Multiple transactions involving different merchants may be completed against the same account while a Pre-Authorization Request remains open. Used across multiple merchant types. Typically places a hold on funds for the authorized amount. Typically, must be completed/settled within time period specified within the Pre-Authorization Request and merchant type, anywhere from one hour to one week, but can be longer. Funds can be, but may not be reserved dependent on the pre-authorization message. Multiple transactions involving different merchants may be completed against the same account while a Pre- Authorization Request remains open Liability and Dispute Resolution: The purpose of this solution is to reduce counterfeit fraud while maintaining transaction speed throughput at the POE. Liability and dispute resolution are handled based on payment network rules and are outside the scope of this document Solution As described above, with a Pay As You Go transaction, a real-time authorization is not possible to obtain prior to when the entry decision for a customer has to be made. This type of transaction then will require a delayed or deferred authorization process. U.S. Payments Forum 2017 Page 17

18 Delayed (or deferred) financial authorizations may occur at any time after a rider has been allowed to enter the transit service. This includes authorizations initiated at the time of entry, or when connectivity is restored after an interruption, or those performed a day or more later. In any event, a delayed authorization is deemed to have occurred whenever access to the transit network is provided before an online authorization response is received Stakeholder Impact How each network or issuer or acquirer or any other party chooses to support delayed or deferred financial authorization is beyond the scope of this document. However, each payment network has a position with regard to supporting, recommending and requiring delayed or deferred authorization for their issuers. Table 8 below provides the position of each payment network with regard to delayed or deferred Authorization for contactless EMV transactions in North America irrespective of merchant vertical. Table 8. Delayed or Deferred Financial Authorization Position by Payment Network Network: American Express Discover Debit Networks Interac Mastercard Visa Position: Supported * 4 Recommended No* 5 Required + No No* No* No 6 No No + This reflects the networks respective current positions today. Whether one or more of the networks change their position in the future specifically for transit and/or all merchant verticals will depend on the future decision of each payment network. Merchant: First Tap Risk: The biggest impact on transit of delayed or deferred authorization would be the new financial risk from non-assured payment. An authorization delayed for any reason exposes the transit agency to financial risk given the issuer may decline the transaction due to insufficient funds the first tap risk mentioned earlier and therefore, funding is not assured even though the customer already received transit service. In such event, the card account should be added to the transit agency s deny list until properly cleared. Depending on the amount of time required for the agency to add the card account to its deny list, however, there could be further financial risk from additional taps of the card. 4 Deferred authorization and Interac. There is nothing technically to stop a merchant from submitting an authorization request under deferred authorization today, although the merchant would have to accept the potential for issuer declines. 5 Deferred authorization recommended by Interac for Transit Open Payments 6 Payment network is currently reviewing whether or not support will be mandated. * Determined by the RID owner specifications and the operating rules for each debit network. Please see Merchant Processing During Communications Disruptions," Version April 2016, EMV Migration Forum. U.S. Payments Forum 2017 Page 18

19 Bank Holds: Agencies that charge a fixed fare for transit can seek a delayed authorization for the full fare amount upon entry. This ensures only exact funding is requested, but still poses the risk of nonpayment if the transaction is declined. Agencies that charge a variable fare, perhaps time or distance-based, have another challenge since the amount to authorize for at the time of entry is unknown. Any authorization performed at the time of entry is simply a best estimate. If the agency estimates too high, then it can adversely impact lowincome riders by securing more funds then are needed (resulting in not enough money for the rider s other expenses). Estimating too high may result in securing more funds than a cardholder can afford or trigger a decline due to low available funds. If the amount authorized is too low, then the agency risks inadequate funding for the travel it already provided. An alternative to estimating the authorization amount is to perform an account status check instead. An Account Status Check can be a $0 or $1 authorization sent to the issuer to identify if the account exists. While an approval isn t necessarily a guarantee of payment, the agency knows the issuer is continuing to allow the cardholder to transact. Depending on network rules, an approved status check can provide some degree of financial protection too. This occurs in the petroleum industry today, which also utilizes unattended terminals similar to transit. Solutions to First Tap Risk and Bank Holds in Other Industries: Automated fuel-dispensers (AFD) perform authorizations for $1 not knowing how much fuel will be dispensed. If the status check is approved, the gas station is protected up to $X amount, where X varies (and could be, for example, $50, or up to $100 today), based on payment network rules. This solution addressed the shared financial exposure between parties. A similar approach has been taken to reallocate first tap risk in the European transit market, between global payment networks and the UK s Transport for London (TFL). Other impacts: POE terminal logic for estimated authorization and/or account status verification Deny list management Need to inform customers of impact on issuer holds ( open to buy ) from card use at POE Customer service and passenger education Issuer: Customer service and cardholder education Network: Some networks: rule changes; no technical impact expected Other networks may require updates to permit end-of-day calculation of final amount(s) and clearing at that time and other special features of transit transaction processing 4.6 Transaction Flow Diagram The transaction flow for a Pay As You Go transaction based on the solutions for the three pillars (i.e., Steps 1, 2 and 3) is depicted in the diagram on the following page. U.S. Payments Forum 2017 Page 19

20 CUSTOMER taps Card on POE Card - POE mutually supported AID? Technical Solution for Use Case 1: Pay As You Go Transaction stopped Entry denied No Transaction stopped Entry denied No STEP 1: Card can authenticate offline? Out of scope for Use Case 1 Merchant List Management Transaction stopped Entry denied No STEP 2: No CVM Card-POE match? CUSTOMER allowed entry STEP 3: Online Authorization Deferred or Delayed Authorization Transit Host Issuer Host Out of scope for Use Case 1 Transaction declined No Transaction authorized? Transaction approved Transit Host Debt Recovery 1 st Tap Risk & liability agreements between transit merchants & issuers Aggregated Transaction Aggregation and/or Settlement U.S. Payments Forum 2017 Page 20

21 5 Conclusion The Pay As You Go/Card technical solution proposed in this paper delivers against the three pillars of a secure EMV transaction card authentication, cardholder verification and financial authorization. The following table describes at a high level the three pillars of a secure EMV transaction that are covered in more detail as part of the document. Table 9. Summary of Three Pillars of a Secure EMV Transaction as Described for the Use Case 1 Technical Solution Secure EMV Transaction Pillar Card authentication Cardholder verification Financial authorization Risk Prevented Counterfeit fraud Lost/stolen fraud Funding not available Use Case 1 Technical Solution Dynamic ODA Supplemented by merchant list management No CVM Network negative file updates Deny list management (using authorization response) Deferred (or delayed) authorization All technical criteria outlined in this white paper except where noted are found in and addressed by the existing payment network contactless EMV specifications. Readers of this document are encouraged to visit the applicable payment network s website or the EMVCo website for the most recent versions of contactless specifications. Contactless card issuers will need to consider the guidelines provided in this document when determining how cards are personalized if transit acceptance is a requirement of their portfolio. Table 10 below summarizes the stakeholder requirements listed in Tables 2, 3 and 4 above and indicates whether the proposed technical solution has addressed each requirement purely from a technological perspective. It is important to note that although a requirement is indicated as being addressed in the table below, the table does not address business and risk decisions that stakeholders will need to make which, as noted, are out of scope. Table 10. Stakeholder Requirements for Transit Open Payments Use Case 1 Addressed/Not Addressed by Solution Index # Requirement Addressed in Solution TRANSIT REQUIREMENTS M1 Solution must be able to validate that cards presented are genuine. M2 Solution must support acceptance/processing of a contactless with No CVM transaction only. There is no fallback to magnetic stripe or other CVMs possible. M3 Solution must support processing of transaction when price is unknown at time of transaction. U.S. Payments Forum 2017 Page 21