Wireless Payment: Considerations for EMV Chip

EMV® White Paper Wireless Payment Considerations for Use of EMV Chip Version 1.0 29 November 2023 © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 2 / 43 Legal Notice This document is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or non-infringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 3 / 43 Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document. QR Code is a registered trademark of DENSO WAVE. Wi-Fi is a registered trademark of Wi-Fi Alliance. Bluetooth is a registered trademark of Bluetooth SIG, Inc. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 4 / 43 Contents 1 Executive Summary .............................................................................................. 8 2 Purpose and Scope............................................................................................... 9 2.1 Purpose ................................................................................................................. 9 2.2 Scope ..................................................................................................................... 9 2.3 Audience.............................................................................................................. 10 2.4 Background ......................................................................................................... 10 2.5 Problem Statement ............................................................................................. 11 2.6 Assumptions ....................................................................................................... 11 2.6.1 Use Cases ..................................................................................................... 11 2.6.2 Architecture .................................................................................................... 12 2.6.3 Use of EMV Chip Data ................................................................................... 13 2.6.4 Connection Setup........................................................................................... 14 3 Cardholder Involvement ..................................................................................... 15 3.1 Intent to Pay ........................................................................................................ 15 3.1.1 Explicit Intent.................................................................................................. 15 3.1.2 Implicit Intent .................................................................................................. 15 3.2 Cardholder Verification....................................................................................... 16 3.2.1 Communication of Cardholder Verification Status .......................................... 16 4 Card Involvement ................................................................................................ 17 5 Locality ................................................................................................................ 18 5.1 Determination of Locality ................................................................................... 18 5.1.2 Intrinsic to Wireless Technology ..................................................................... 19 5.1.3 Use of Ranging Information from Wireless Technology .................................. 20 5.1.4 Out of Band Data ........................................................................................... 22 5.1.4.1 GPS Location Data......................................................................22 5.1.4.2 Secondary Wireless Ranging.......................................................22 5.1.4.3 Environmental Data .....................................................................22 5.2 Communicating Locality..................................................................................... 23 5.2.1 New Point of Service Data Code .................................................................... 23 5.2.2 New Tag in ICC Data ..................................................................................... 23 © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 5 / 43 5.2.3 Incorporation Into Existing Data ..................................................................... 23 5.2.4 Integrity of Location Data ............................................................................... 24 5.2.4.1 Relay Attacks...............................................................................24 5.2.5 Identification of Correct Merchant/Point of Sale.............................................. 25 6 6.1 6.2 6.3 6.4 Data and Flows.................................................................................................... 26 Chip Data ............................................................................................................. 26 Application Selection.......................................................................................... 26 Payment Request ................................................................................................ 28 Payment Response ............................................................................................. 30 7 7.1 7.2 7.3 7.4 7.5 Technology Considerations ............................................................................... 33 Availability ........................................................................................................... 33 Interoperability .................................................................................................... 34 Establishing a Connection ................................................................................. 34 User Settings and Permissions.......................................................................... 36 Performance ........................................................................................................ 36 Annex A Examples of Locality Data .............................................................................. 38 A.1 Application Interface........................................................................................... 38 A.2 Geo Location ....................................................................................................... 38 A.3 Ranging Data ....................................................................................................... 39 Annex B References ....................................................................................................... 40 B.1 EMV Documents.................................................................................................. 40 B.2 ISO Standards ..................................................................................................... 40 Annex C Glossary ........................................................................................................... 41 C.1 Abbreviations ...................................................................................................... 41 C.2 Definitions ........................................................................................................... 41 © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 6 / 43 Tables Table 1 Payment Request Data .......................................................................................... 29 Table 2 Payment Response Data........................................................................................ 31 © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 7 / 43 Figures Figure 1 General Architecture ............................................................................................. 13 Figure 2 Access Point In Payment Zone ............................................................................. 20 Figure 3 Access Point Outside of Payment Zone ................................................................ 21 Figure 4 Relay Attack.......................................................................................................... 24 Figure 5 Simplified Contactless Transaction Flow ............................................................... 27 Figure 6 Potential Wireless Transaction Flow ..................................................................... 27 Figure 7 Wireless Application Selection .............................................................................. 28 © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 8 / 43 1 Executive Summary EMV Contactless technology has enabled face to face card payments to be made from mobile and wearable devices. Many of these devices support other wireless technologies such as Bluetooth wireless technology, Wi-Fi and Ultra-wideband (UWB). These wireless technologies open the potential for payment use cases where the cardholder only needs to be in the locality of the merchant, rather than in the immediate proximity of a terminal. This white paper provides information on how EMV chip technology may be used for transactions over wireless technologies to those considering the design and implementation of wireless payment solutions. These transactions can provide evidence of card and cardholder involvement and that the cardholder was in the locality of the merchant. It is not a specification or prescriptive document. The EMV Chip specifications, ([EMV Contact], [EMV Contactless]), provide for evidence of card involvement through card authentication mechanisms. Cardholder involvement includes both verifying the cardholder and establishing the cardholder’s intent to pay, the latter presenting both challenges and opportunities when wireless technology is used. The concept of locality is defined with consideration given to how to determine locality and how to communicate locality information to the cardholder device, the merchant system and the issuer. In addition, the use of locality information in protecting against relay attacks is addressed. The data which needs to be exchanged between the merchant system and cardholder device is outlined, including how application (card) selection may be optimised. Although this white paper does not address the details of the wireless technologies, some technical considerations are given related to different available technologies including availability, interoperability, connection establishment, user settings and permissions, and performance. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 9 / 43 2 Purpose and Scope The subject of this white paper is to address the potential for mobile devices and wearables to use wireless technologies for EMV Chip payments. 2.1 Purpose EMVCo has created specifications for chip card payments which have provided the foundation for globally interoperable and secure face to face payments. These specifications use the contact and contactless interfaces for ID-1 form factor smart cards based on the ISO/IEC 7816 and ISO/IEC 14443 standards. The use of contactless technology and its compatibility with NFC has allowed the expansion of cardholder devices from plastic cards to smart devices such as mobile phones and wearables that support Near Field Communication (NFC). These smart devices may also support longer range wireless interfaces which have the potential to enable new payment use cases. These use cases go beyond simply replicating contact/contactless card payment at a point-of-sale terminal, and may allow for EMV payment technology to be integrated into innovative shopping experiences. This is a rapidly evolving area, with considerable variation in the use cases expected, depending on the needs of the merchant. This white paper is written for those who are considering the development, design or implementation of such systems, highlighting some of the areas which should be taken into account for incorporation of EMV chip data into such systems. This white paper is not intended to be prescriptive, nor is it exhaustive – it does not attempt to address all areas which must be considered. In particular, implementers must be aware of and take into account any local regulations. 2.2 Scope Interoperability at the wireless bearer level is already well addressed by the device manufacturers and industry associations defining the wireless standards. There is not the same need for EMV specifications at the wireless protocol level to ensure interoperability, as was done by EMVCo defining aspects of the Level 1 communications for contactless ([EMV L1 Contactless]). Given the variability in the use cases and wireless interoperability being covered, EMVCo also does not see an immediate need for application layer EMV specifications based on a particular wireless protocol. There are however, general considerations for the use of EMV chip-based payment in wireless-based transactions and these are addressed in this white paper to help those defining and deploying wireless payment solutions. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 10 / 43 This white paper focuses on the use of EMV chip data, as would be used in a face-to-face transaction. Payments over wireless technologies based on remote payment technologies such as EMV Secure Remote Commerce or EMV 3DS are also possible; however, remote payment is not directly addressed in this white paper although some of the considerations may be applicable. 2.3 Audience This document is intended for: • those considering the introduction of wireless payment solutions • designers of wireless payment solutions • developers and implementers • wireless payment specification writers These include merchants, acquirers, issuers, system designers, vendors, industry associations and specification bodies. 2.4 Background The EMV chip specifications define a system for card payment which provides an identifier of the payment account (Primary Account Number [PAN]) along with other account related information (for example, the Expiry Date). Card Authentication Methods allow the card to be cryptographically authenticated as genuine. The EMV specifications also support verification of the cardholder through various Cardholder Verification Methods (CVM) including both online and offline PIN verification which provide evidence that the cardholder was involved in the transaction. The introduction of contactless removed the requirement of using an ID01 card as there was no longer a need to insert the card to align the contact plates. This enabled use of a variety of different form-factors, both passive (unpowered) such as key fobs and wrist bands, and active (powered) such as mobile devices, tablets and smart watches equipped with Near Field Communication (NFC). Many of the active devices support other wireless protocols in addition to NFC, and this offers the possibility of using these wireless protocols for EMV chip transactions. The longer range of these protocols (greater than the few centimetres of contactless) enables use cases beyond payment occurring at a point of sale. In reviewing these, it became clear that in many of these use cases the wireless connection is used for more than payment. There is typically a shopping/ordering phase, a payment phase, and a completion phase (e.g., confirmation, receipt), all of which may use the wireless connection. This differs from contact and contactless chip transactions where the communication channel between the card and the terminal is dedicated to the payment transaction. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 11 / 43 The phases outside of payment are not within the scope of EMVCo to define. With this in mind, and taking into account that the use cases are likely to be an area of considerable innovation, at the time of writing it is felt that a specification for wireless EMV payment is premature. However, there is useful guidance to be provided with respect to the payment phase in a wireless transaction. 2.5 Problem Statement The problem being addressed in this white paper is enabling an EMV chip-based payment using wireless technology between a cardholder device and a merchant system when the cardholder is in the locality of the merchant system. Such a payment needs to support mechanisms to provide evidence of: • Cardholder involvement • Card (including other form-factors) involvement • Card/cardholder presence in the locality of the merchant This white paper addresses: • the data that needs to be exchanged between the cardholder device and merchant system • security considerations for such a payment • some technology considerations for establishment of the wireless connection 2.6 Assumptions In order to simplify the white paper, a number of assumptions have been made regarding the nature of the use cases, the architecture of a wireless payment solution, the type of payment data exchanged and the setup of the wireless connection. These are believed to cover the majority of scenarios, but are not intended as requirements for all wireless payment solutions. They are provided to help in the understanding of this white paper. 2.6.1 Use Cases A Transaction may be viewed as consisting of three phases: © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 12 / 43 1. A shopping phase, where the user selects goods or services and the price is determined 2. A payment phase, initiated by the user’s intent to pay, for the payment data to be generated and exchanged between the cardholder device and the merchant system 3. A completion phase, where transaction records and other post payment information are exchanged (for example, the receipt or vouchers/coupons) In a traditional contact or contactless card transaction, the cardholder device is involved only in the payment phase, and communicates only for the exchange of payment data. The greater range of wireless technologies opens the possibility for the cardholder device to be involved in the shopping and/or completion phases in addition to the payment phase. The wireless channel established between the cardholder device and merchant system may be used for more than the payment phase. In order to support the shopping and completion phases, a merchant may choose to provide the user experience through a dedicated merchant app which the user may download onto their device. The download of the app, and potential associated user registration, provide a pre-established relationship between the user and the merchant. As the app is dedicated to a merchant (or group of merchants), these use cases are referred to in this white paper as “closed” use cases. This is in contrast to “open” use cases, where the cardholder device may be used to interact and pay with the merchant with no pre-established relationship. 2.6.2 Architecture This white paper does not define a required architecture but has assumed a general architecture as shown in Figure 1. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Cardholder device BLE Card data store UWB Wi-Fi etc (Merchant) Payment Apps Page 13 / 43 ICC Data Merchant Systems Merchant Acquirer Figure 1 General Architecture The cardholder device has one or more card applications (sets of credentials) personalised on the cardholder device, which are accessible to payment apps on the same device. The cardholder device communicates to the merchant systems via payment apps, which may be specific to a particular merchant (closed use cases) or may be merchant agnostic (open use cases). Each payment app uses one or more of the wireless technologies that the device supports to connect to the merchant systems and exchange data to be used for authorisation by the issuer (via the acquirer). As stated above, this is not a required architecture, but is provided to facilitate understanding of other aspects of the white paper. 2.6.3 Use of EMV Chip Data The focus of this paper is on the use of wireless technologies for payment in scenarios where the alternative is a face-to-face payment as covered by the EMV Chip specifications. For this reason, as shown in Figure 1, the data communicated to the acquirer is assumed to be chip data, that is, information contained within data element 55 (Integrated circuit card [ICC] related data) as defined in [ISO 8583] and described in [EMV Book 4]. Chip data contains transaction information provided by both the terminal/merchant system and the card, with an application cryptogram generated by the card to provide evidence of the card authenticity and data integrity. This is discussed further in section 6. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 14 / 43 2.6.4 Connection Setup For closed use cases, there is a merchant app which drives the experience between the cardholder and the merchant, and it is expected that the merchant app will be responsible for establishing the communication channel with the specific merchant system. The fact that the consumer has the merchant’s app open in the retail location indicates that the consumer intends to transact at that merchant. Depending on the communication technology, the parameters necessary to establish a connection can be assigned by the merchant and known in advance by the merchant app and the merchant system, thus enabling the connection to be established automatically without consumer intervention. For open use cases, parameters for the connection will be shared between multiple merchant systems; the consumer may need to explicitly choose which merchant they wish to transact with. With this in mind, and though the white paper discusses some considerations regarding the establishment of a wireless channel in section 7.3, the focus of this white paper is on payment data to be exchanged and how to secure this data. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 15 / 43 3 Cardholder Involvement “Cardholder Involvement” is the process of establishing that the genuine owner of the card account intends to make a particular payment with the card. This consists of two aspects: 1. Intent to pay 2. Cardholder verification 3.1 Intent to Pay Intent to pay is an action taken by the user to indicate that the card should be used for a specific payment, that is, that the user intends to pay with the card. In a contact chip card payment, the intent is expressed by inserting the card into a payment terminal. Similarly with contactless payment, it is tapping the card or cardholder device on a contactless payment terminal that signals the intent. In the wireless payment space, where there is not the same required physical proximity between a card device and terminal, alternative methods need to be used to establish the intent to pay. 3.1.1 Explicit Intent The expression of intent to pay may be due to an explicit action that the user takes on the payment device, for example actively enabling a payment app at the time of a transaction, or acknowledging a request to pay on the device. 3.1.2 Implicit Intent The intent to pay may be implicit, that is, the user takes an action which implies an intent to pay, without explicitly acknowledging it on the device at the time of payment. For example, a user entering a designated payment zone in a store or walking through an entry gate designated for automatic payment. Although the intent is implicit at the time of transaction, the cardholder device needs to be in a state where it is capable of payment, which will typically require some user interaction to ensure that the device is in a payment ready configuration. In addition, care must be taken to ensure that the action taken to imply intent is sufficiently definitive to prevent unintended payment. Implicit intent is likely to be more applicable to closed use cases where the user has opted in through the merchant app and has been made aware of what constitutes intent. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 16 / 43 3.2 Cardholder Verification Cardholder verification is the process by which the user of the card is verified as the genuine cardholder entitled to use the card for payment. Cardholder verification with a traditional chip card has typically occurred after the intent to pay, which occurs after or during the interaction between the card and the payment terminal, for example, through the entry of a PIN. More capable devices such as mobile phones and smart wearables, allow the use of cardholder device cardholder verification methods (CDCVM), where the cardholder performs the verification on their own device. This allows for the possibility of the CVM being performed before the interaction between the card and the merchant systems, and in some cases before or concurrent with the intent to pay. And in some of these cases, the cardholder verification may itself constitute, or be a part of the intent to pay, particularly where the validity of the cardholder verification is limited in time or location. Several examples are given below to illustrate this. • A user provides a biometric on a mobile device to enable a card for payment for 30 seconds. The biometric provides evidence that the user is the cardholder, and the short time for which the card is enabled indicates that the user is intending to make a payment. • A user enters a passcode on a smart watch to enable payment which remains valid as long as the user’s pulse is detected by the watch. The passcode provides evidence that the user is the cardholder, and the pulse detection that the user has not changed. The extended validity means that cardholder verification is not an intent to pay, as the user does not necessarily have any intention of immediately paying. • A user enters a store and opens the merchant’s app which enables them to pay without going to a checkout. Opening the merchant app prompts the user for cardholder verification of their chosen payment card. The cardholder verification, along with the user exiting the store (or passing through a payment zone), provides an intent to pay as the cardholder verification validity is limited to the merchant associated with the app and the store in which it was performed. 3.2.1 Communication of Cardholder Verification Status The communication of the CDCVM status to the card issuer (that is, whether or not CDCVM has been performed, and optionally how it was performed), is proprietary to the particular payment application which has been used. It is good practice to include the CDCVM status in the data used to generate the application cryptogram in order to cryptographically protect the integrity of the status. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 17 / 43 4 Card Involvement The card is able to provide evidence of its involvement in a transaction by generating an application cryptogram, that is, a dynamic value which is generated based on cryptographic keys securely stored in the card combined with data specific to the transaction (for example the transaction amount) and random data (unpredictable number) from the merchant terminal. Verifying this application cryptogram enables the issuer to validate that the transaction was performed by a genuine card, a process known as card authentication and that the transaction data it received was uncorrupted. For wireless payment, the existing mechanisms which are supported by the EMV Chip specifications may be used. A traditional contact or contactless card will communicate payment data when inserted or held in proximity to a card terminal. A smart device, such as a mobile phone or smart wearable, may prevent the communication of payment data unless certain conditions have been met, such as CDCVM successfully performed, or there has been explicit user intent. In these cases, the card authentication may convey more information than simply that a genuine card was used in the transaction. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 18 / 43 5 Locality This paper refers to the term “locality”. In this context, the term is used to mean that the cardholder and merchant are at the same location. Whilst this is analogous to saying that the cardholder is in proximity to, or in the vicinity of, the merchant, this paper uses locality to distinguish from other technologies (contactless, RFID) which are more traditionally associated with the other terms. EMVCo does not provide a strict definition of locality (e.g., within 20 metres or within 50 metres) as this may vary depending on the use case or payment system, but locality is intended to provide evidence that a transaction occurs at a physical merchant location. EMVCo does not specify how locality information must be used or communicated, but examples of its use include: • Enabling a cardholder device to determine that it is in the locality of a merchant (for example as a precondition to generating the payment transaction data) • Enabling a merchant system to determine that the cardholder device is in its locality in order to correctly code the authorisation message • Aiding in the determination of cardholder intent • Enabling the issuer to verify that the transaction took place in the locality of the merchant • Mitigating against relay attacks The very short communication range of contact (card must be physically in contact with the terminal) and contactless (card must be within a few centimetres of the terminal) chip transactions provide an implicit indication that the card is in the locality of the merchant. This information is typically conveyed to the issuer through the POS Entry Mode (data element 22 of ISO 8583). For wireless transactions the communication technology does not necessarily imply locality, particularly with wireless technologies such as Wi-Fi (especially mesh Wi-Fi systems) or mobile data. This leads to two questions for wireless transactions: 1. How to determine locality? 2. How to communicate locality information to the relevant parties? 5.1 Determination of Locality As noted above, the wireless communication technology over which a transaction is conducted does not necessarily imply locality. For example, a shopping mall may provide mesh Wi-Fi throughout the mall, which would cover many merchants. Even a shorter-range technology such as Bluetooth may extend into another merchant’s premises. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 19 / 43 As a result, additional measures may need to be taken to determine locality for a wireless transaction. Three potential methods are considered: 1. Locality is intrinsic to the wireless technology 2. Wireless technology supports accurate ranging 3. Use of out of band data These are described in more detail below. 5.1.2 Intrinsic to Wireless Technology Some of the wireless technologies have an inherently limited range, and therefore if the cardholder device and the merchant system are able to communicate it implies that the cardholder is in the locality of the merchant. This is analogous to the situation with EMV Contact and Contactless Chip transactions, where the communication technologies imply that the card is physically inserted into a terminal (contact) or within a few centimetres (contactless). Other wireless technologies typically have a range in the tens to hundreds of metres, and so do not provide the same level of indication of proximity, but an identification of the wireless technology in use may be sufficient for indicating locality. There are a number of considerations which need to be taken into account: • At best the technology gives a coarse indication of locality, precision being the maximum range of the technology. It does not necessarily imply that the cardholder is on the premises of the merchant as the communication range may extend beyond the merchant’s premises. • Different wireless technologies have different ranges; for example, Bluetooth has a range of up to 10 metres whereas Wi-Fi has a range of up to 100 metres. It is therefore necessary to indicate the particular wireless technology being used, not simply that it is wireless. • The wireless channel may be merchant-specific or general (e.g., a shopping mall WiFi service). The general channel may use the same wireless technology as the merchant-specific one, but may be extended using mesh or other techniques. The consumer device may not be aware whether or not the wireless channel is extended which may limit its use as an indication of locality. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 20 / 43 5.1.3 Use of Ranging Information from Wireless Technology Certain wireless technologies support secure ranging capabilities. For example, Ultrawideband (UWB) is able to securely determine range to within a few centimetres with protection against distance shortening attacks. In this case, the ranging data may be able to provide evidence of the cardholder being at a particular point in the store, e.g., at a particular till or within a designated payment zone. This may overcome some of the limitations of simply relying on identifying the wireless technology. Technologies that support ranging may have a role in determining a cardholder’s intention to pay (for example, the cardholder has entered a designated payment zone, or passed through a transit gate), and may also be used to identify a cardholder to associate them with a particular transaction (for example, the cardholder device is now in front of till number 8). It should be noted that if the cardholder device is to make use of this capability, the device must also have access to the ranging data. It is not sufficient for this to be known only by the merchant system. In some implementations, communication will be directly between a cardholder device and the point of interaction in the merchant system, for example, between the cardholder device and a payment zone. In this case, the ranging data directly indicates the separation between the cardholder device and the payment zone, as in Figure 2. Range Separation Cardholder Payment Zone Figure 2 Access Point In Payment Zone In other implementations a single infrastructure access point may be used to communicate with multiple cardholder devices, with the position of the cardholder devices being determined by triangulation, or if supported by the technology, using the angle of approach. This is illustrated in Figure 3. While this may enable the merchant system to determine that a cardholder is in a specific location, for example within 50 centimetres of a particular payment zone, the range between the communicating devices may be much greater. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 21 / 43 Range Θ angle of approach Cardholder Separation Payment Zone Figure 3 Access Point Outside of Payment Zone The merchant system has knowledge of the physical dimensions of the store and location and orientation of access points and payment zones, and is able to determine the separation using triangulation from the range and angle of approach; however, the cardholder device does not have this information, and is not able to determine the true separation between the user and the payment zone. In such a case, although there is a lot of precision in the ranging, this is not necessarily directly reflected into the locality data. It should be noted that the difference between the range to the access point and the distance to the payment zone may not be significant in determining locality – for example, a 10-metre distance to an access point when the cardholder is within 0.5 metres of a payment zone still provides evidence that the cardholder is in the locality of the merchant. Where this difference may be more significant is where the separation is used to convey the intent of the cardholder to pay. Ideally, the cardholder device will only respond to a payment request when the cardholder intends to pay for example, by entering a designated payment zone. If the cardholder device is unable to determine this has occurred, then it is likely to need an explicit acknowledgement of the payment request from the cardholder. In some use cases the explicit acknowledgement may be desirable; however, in closed use cases which aim at minimum friction (e.g., entering a transit system without the need to remove a phone from a pocket or bag), this difference between range and separation needs to be taken into account. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 22 / 43 Where the wireless technology is able to measure the angle of approach, then this may also be used to determine intent, for example, that the user is pointing their device towards the receiving merchant device whilst in a payment zone. Repeated polling of the range also enables the direction of travel of the cardholder device to be determined and may also be used in the determination of intent, for example, that the user is using a transit gate to enter rather than exit the transit system and is not merely standing close by. 5.1.4 Out of Band Data Mobile devices are highly capable and may incorporate information into the transaction data other than what is provided directly over the wireless payment channel, that is, out of band data. This out of band data may be used to associate the merchant and cardholder and provide evidence of locality. A number of examples of out of band data are given below. 5.1.4.1 GPS Location Data Mobile devices typically have access to location information from assisted GPS data. If a merchant system provides its location to the device as part of the transaction data, the mobile device may compare the two locations to calculate the distance between the devices and hence locality. 5.1.4.2 Secondary Wireless Ranging Wireless ranging data may be used from a secondary wireless channel (a different channel than the wireless channel used for payment). In this case, distance may be calculated as described in the previous section. For example, payment may be being completed over Wi-Fi, with a secondary UWB channel established with the merchant store to provide ranging data. 5.1.4.3 Environmental Data A merchant may provide data locally which the cardholder device includes in the calculation of transaction data, with the merchant inserting this into the data that is provided in the authorisation message. The issuer may then verify that the data received by the cardholder device is the same information provided by the merchant. If this information is regularly changed this would strengthen the evidence for the association and hence locality. Examples of how this may be done include: • A Bluetooth Low Energy device broadcasting a time-variable merchant-unique data string in the store • A number displayed when the consumer enters the store to be entered into a shopping app (This could be contained in a QR Code that a user scans to “check in” to the store.) © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 23 / 43 5.2 Communicating Locality For the locality information to be useful, it must be communicated to the parties who will make use of it, for example, the cardholder device, merchants and/or issuers. There are a number of options for what could be communicated, and how to do so. The options for the type of data to be communicated include: • A wireless technology indicator • A flag set by the cardholder device which indicates that the card considers this to be a “local transaction”, that is that the cardholder is in the locality of the merchant • Data indicating the distance between the cardholder device and the merchant • Other data such as a time-variable merchant-unique data string (e.g., The card and merchant demonstrate that they have broadcast/received the same merchant unique data, demonstrating that they are in the same location.) 5.2.1 New Point of Service Data Code ISO 8583 defines the Point of Service Data Code, (also known by other names such as POS Entry Mode, or PAN Entry Mode), which indicates the technology used for the merchant system to obtain the PAN. One option would be to create one or more new values to represent wireless technologies. This is not considered a viable option as this would require changes throughout the acceptance networks to ensure that it is able to flow from the merchant through to the issuer. It is likely that it would need to specify the particular technology, rather than simply “Wireless”. As new wireless technologies emerge, this would require additional values to be defined, requiring additional changes in the acceptance networks. This approach is limited to communicating a wireless technology indicator. 5.2.2 New Tag in ICC Data ISO 8583 defines the ICC Data Element. It would be possible for EMVCo to define a new tag with the locality information in the ICC Data. This would provide more flexibility in the data and could carry any of the various data options highlighted above. However, this is also likely to require changes in the acceptance networks in order to be reliably communicated. 5.2.3 Incorporation Into Existing Data Location data may also be incorporated into data fields which are currently used in the processing of EMV chip transactions, for example it could be incorporated into the Issuer Application Data. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 24 / 43 This is likely to have less impact on the acceptance networks, however space may be limited. Where the data is a flag, this may not have a significant impact, but some of the other options (distance, time-variable merchant-unique data) may need a larger amount of data, which needs to be balanced against use of the field for other functions. 5.2.4 Integrity of Location Data To be able to rely on the locality data, its integrity should be protected, for example to protect against relay attacks. 5.2.4.1 Relay Attacks A relay attack is a form of distributed man-in-the-middle attack, as illustrated in Figure 4, in which an attacker (in blue) conducts a fraudulent transaction between a genuine card and a genuine merchant terminal (in green) by relaying the data between them. Attack card device Card Attack Reader Device Remote communication Merchant Terminal Figure 4 Relay Attack The attack device consists of a reader device to communicate with a genuine card, and a card device which appears as a card to the genuine merchant terminal. Depending on the particular implementation, the attack may occur with or without the genuine cardholder’s interaction. The attack reader device may masquerade as a genuine terminal, may be a modification to a real terminal, or may be a hidden device for a contactless transaction. When the attack reader device has established communication with a card, the attacker uses the attack card device to conduct a transaction with a real merchant who is typically some distance away. Via a communication channel (such as a mobile data connection), the attacker passes through the data between the card and merchant terminal such that the card produces a genuine application cryptogram for the merchant terminal. As the attack reader device is under the control of the attacker, any amounts displayed may be manipulated. For example, a cardholder may believe they are buying a t-shirt for $10, whilst the attacker is performing a transaction for a higher amount with the merchant. The use of locality information may help deter relay attacks. For example, if both the cardholder and merchant are able to share their own understanding of the locality information, then it can be verified that these correspond as part of the authorisation. Other tools are also available in defending against relay attacks and should be used where appropriate. For example, in a closed use case, authenticating the merchant app, authenticating the merchant system before payment occurs, or requiring explicit intent. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 25 / 43 5.2.5 Identification of Correct Merchant/Point of Sale A contact or contactless transaction provides the association between the cardholder and the merchant, and indeed the particular point of sale of the merchant through the close proximity required for a transaction. As noted previously, a wireless transaction does not need that close proximity, and multiple points of sale, or even multiple merchants, may be within the communication range of the consumer device. Consequently, a payment solution using wireless technology should ensure that the consumer device is communicating with the merchant or merchant device that is relevant for the transaction. Examples of this are displaying the transaction details on the cardholder device and obtaining explicit consent before payment, and/or in a closed use case the merchant app may authenticate the merchant system. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 26 / 43 6 Data and Flows 6.1 Chip Data As this paper is for the use of wireless in a face-to-face environment, this section focuses on the use of EMV chip data (ICC Data) which is currently used in such acceptance environments. It should be noted that there is no technical requirement that data passed over a wireless interface must be chip data. The details of the data which must be passed by the merchant to the acquirer for processing are defined by the associated payment systems and payment networks; however, [EMV Book 4], section 12, defines a data set which should be sent over the acquirer interfaces. For the purposes of this white paper, to illustrate the use of EMV chip data, it is assumed that this data will need to be available to the merchant system in order to send an authorisation request. In the tables below showing the payment request and response, the following terminology is used: • R: Required in order to generate the data required for an authorisation message • C: Conditionally required, dependent on the requirements of the card applications of the supported brands • O: Optional 6.2 Application Selection In contact and contactless transactions, there is a significant number of messages (APDUs) exchanged between the terminal and card. This is partly due to the processing limitations which were inherent in smart cards, as well as the limitations of the message size of the contactless protocol. This is illustrated in Figure 5, where there is first an application selection process, including potential POI information ([EMV Entry Point]) being returned from the terminal. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 27 / 43 Figure 5 Simplified Contactless Transaction Flow Once the terminal has identified a specific application to interact with, it selects that application through its AID, and then there is exchange of the data needed by that particular application through the READ RECORDS, GPO and GEN AC commands. Moving to wireless, the expectation is that the cardholder device is more likely to be a smart device, and wireless protocols are not as limited on message size. This gives an opportunity to move towards a single Payment Request/Payment Response type interface as illustrated in figure 6. Figure 6 Potential Wireless Transaction Flow © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 28 / 43 The implication of this approach is that if the cardholder device supports multiple cards, the card selection needs to occur on the cardholder device. In order to enable that, rather than the cardholder device providing information about what card applications are available (provided by the PPSE in Figure 5), the merchant system must provide information about what payment brands are accepted. In addition, any POI information must also be passed in the payment request. This is illustrated in Figure 7. Figure 7 Wireless Application Selection In this case the Payment Request has fields for Accepted Brands (e.g., AIDs, or an equivalent representation), and optionally the POI Information. This is used by the Payment App (in conjunction with any user input), to select the particular card application. These fields are reflected in Table 1 Payment Request Data. 6.3 Payment Request There is not a uniform set of data that a card application requires from the terminal. Certain data elements are used by all card applications, but other data elements are only used by some applications. In the contactless flow this is controlled by whatever the selected application requests through a Data Object List (DOL). However, if this Request/Response mechanism is used, the data must be supplied before it is known what card application is being used. Therefore, the merchant system needs to supply all the relevant information to the card which could be required by card applications of all the brands1 which are supported by the merchant. 1 In this context, a brand corresponds to the Application Identifier (AID) of the payment applications accepted by the merchant. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 29 / 43 Table 1 Payment Request Data Data Element Presence Comments Amount, Authorised R Amount, Other R Transaction Currency Code R Terminal Country Code R Transaction Date R Transaction Type R Merchant Category Code C If required by any of the accepted brands. Unpredictable Number R Terminal Verification Results C If required by any of the accepted brands Terminal Capabilities C If required by any of the accepted brands Terminal Risk Management C If required by any of the accepted brands.2 Data POI Information O Merchant Selection Information R This will contain at a minimum a list of the brands accepted by the merchant. Terminal Locality data C Data from the terminal which may be used by the cardholder device in determining locality3 Some of the data in Table 1 is required on this interface, including the Amount (Authorised), Amount (Other), Transaction Country Code, Terminal Country Code, Transaction Date, Transaction Type and Unpredictable Number as these are used by all card applications. 2 May need to be an array of (brand, terminal risk management data) 3 Examples are given in Annex A. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 30 / 43 A number of other data elements are required by some card applications, but not all. These are marked as conditional depending on whether the data is required by any of the card applications associated with the payment brands that the merchant accepts. This includes Merchant Category Code, Terminal Risk Management Data, Terminal Verification Results and Terminal Capabilities. Care also needs to be taken where values are not necessarily the same across all payment systems. For example, Merchant Category Code is assigned based on payment system rules, which may vary between payment systems, so it is possible that a merchant may be assigned different MCC’s for different payment systems. Therefore, the MCC entry may need to be an array of [Brand, MCC] for the associated card applications which require the data. POI information is optional, depending on whether the merchant system wishes to convey any of this information. Application selection in contact and contactless is performed by the terminal. The card provides a prioritised list of available applications, and the terminal performs a matching against what the merchant accepts, then selects an application based on that (see [EMV Entry Point]). On a Payment Request/Payment Response, the selection is done on the cardholder device and therefore the merchant system will need to provide the Merchant Selection Information, a list of brands which are accepted, and other information which may affect selection of a suitable card application. The cardholder device will then need to select the appropriate card application based on user preferences, the Merchant Selection Information and the POI Information (such as terminal category or other data such as loyalty information). 6.4 Payment Response The Payment Response provides the ICC data generated by the card application selected by the cardholder device. As the card application is known at this point, it will only generate the data which is relevant to it. It is possible that some of the data fields provided in the payment response may differ from those used by the card app. For example, if the payment app allows the user to add a tip between the payment request and payment response. In this case the updated values must be returned in the payment response. It is noted that some of the data elements may not be relevant for wireless, but have been included to minimise the downstream impact in the acceptance networks through to the issuer. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 31 / 43 Table 2 Payment Response Data Data Element Presence Comments Amount, Authorised O Only needed if differing from the value in the Payment Request Amount, Other O Only needed if differing from the value in the Payment Request Transaction Currency Code O Only needed if differing from the value in the Payment Request Transaction Type O Only needed if differing from the value in the Payment Request Merchant Category Code O As used by selected card application Terminal Verification O Results Application Cryptogram R Expiration Date R Application Interchange R Profile Application Label R Name associated with the AID Application PAN C If not in Track 2 Equivalent Data. May be a payment token PAN Sequence Number O Application Preferred Name O Application Transaction R Counter Application Usage Control O Cryptogram Information Data O ARQC or AAC AID O Issuer Application Data O Payment Account Reference O If the Application PAN is a payment token, then the application may return the PAR. Track 2 Equivalent Data O CVM Results O © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 32 / 43 Data Element Application Effective Date Card locality data Presence Comments O O A data element from the card indicating locality4 Much of the information is optional depending on what the card application returns. Where the information is generated by the card application it needs to be returned in the payment response. Where the card has been tokenised, there is the possibility for the card to return the Payment Account Reference (PAR) in the response (see [EMV Token]). The above table is not necessarily an exhaustive list. It is likely that such transactions will be authorised online; however, some use cases may require offline data authentication, in which case the offline authentication data and supporting card certificate will need to be included. Likewise, if the underlying wireless bearer does not provide a sufficient level of protection for confidentiality, then this will need to be done at the application level, with relevant data for key exchange included in the request and response. 4 Card locality data is discussed further in Annex A. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 33 / 43 7 Technology Considerations The wireless communications technologies considered in this paper are Bluetooth and Bluetooth Low Energy (BLE), Wi-Fi and Ultra-wideband (UWB). Wi-Fi and Bluetooth/LE are well established technologies that are supported in nearly every consumer device and many merchant devices. Ultra-wideband is an emerging technology that is gaining increasing penetration, initially on high-end consumer devices but is expected to be more widely adopted in future. UWB support on traditional merchant devices and special purpose merchant devices is likely to be dependent on the introduction of services that can utilise its features. This section provides a high-level discussion of the following technology considerations: • Availability • Interoperability • Establishing a connection • User settings and permissions • Performance 7.1 Availability In order to be of practical use for payments, the wireless technology needs to be widely available in consumer devices, and in devices that may be used by merchants. Consumer devices are assumed to be mobile phones or smart wearable devices. Merchant devices may be mobile phones, tablets, traditional POS terminals (with enhanced connectivity), or special purpose devices. The availability of wireless technologies for each of these types of devices at the time of publication is considered below. • Mobile phones (consumer and merchant devices) • The communications technologies available in consumer smart phones provide the baseline for any wireless payment solution. • All current smart phones can be assumed to support high speed mobile data (e.g., GSM), Wi-Fi, Classic Bluetooth and BLE. • Ultra-wideband (UWB) is starting to be introduced in the latest generations of smart phones. • Smart wearables (consumer devices) • Smart wearables (such as smart watches) are generally paired with a mobile device for operation, supporting Classic Bluetooth and BLE. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 34 / 43 • In addition, smart wearables may support mobile data and/or Bluetooth. • UWB has been supported by some premium smart wearables since 2020. • Tablets (merchant device) • Wi-Fi, Classic Bluetooth and BLE are standard features of all modern tablets. • Some tablets support mobile data. • Ultra-wideband is not yet widely supported by major tablet vendors. • Traditional POS terminals (merchant device) • Traditional POS terminals are primarily designed to accept transactions via contact and contactless interfaces, as defined in EMV Book 1 - Application Independent ICC to Terminal Interface Requirements, and the EMV Contactless Interface Specification. Modern devices often support a range of wireless technologies, including mobile data, Wi-Fi, Classic Bluetooth and Bluetooth Low Energy (BLE). Additionally, some terminals may support expansion by inserting or attaching special modules. • Special purpose merchant devices • Wireless acceptance for technologies such as Classic Bluetooth, BLE or UWB could be enabled by installing special purpose devices in the merchant’s store. These devices need not be visible to the consumer, they need only support the required wireless technology and communicate as necessary to the merchant’s existing systems. 7.2 Interoperability For wireless payments, it is essential that the consumer device can communicate reliably and efficiently with the merchant device. It is highly likely that the consumer and merchant devices will originate from different manufacturers, and will have different communications drivers etc. In order to achieve interoperability in such a diverse environment, the communication protocol implementations should be qualified by relevant industry bodies such as the Wi-Fi Alliance (www.wi-fi.org), Bluetooth SIG (www.bluetooth.com) and FiRa (www.firaconsortium.org). 7.3 Establishing a Connection In order to be acceptable to consumers and merchants, establishing a connection between consumer and merchant devices should be as frictionless as possible. Connecting a consumer device to a merchant typically involves the following steps: • Identifying the network © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 35 / 43 • Optionally exchanging credentials, such as a Wi-Fi password or Bluetooth pairing code The extent to which the consumer is required to participate in these steps depends on several factors: • Open or closed Payment Service: • A consumer device application that is designed to connect to a single merchant’s system could automatically connect without requiring consumer interaction. For example, a BLE based solution could use merchant-specific advertisements and other identifiers, which would only be recognised by the merchant’s application in the consumer device. • A consumer device application that is not constrained to a single merchant or group of merchants is likely to require that the consumer explicitly chooses the merchant with which they wish to transact. • Constraints imposed by the consumer device operating system: • Consumer device operating systems typically require explicit consumer consent to connect to a new Wi-Fi network. • Constraints imposed by the communications protocol design or configuration: • Classic Bluetooth connections require pairing, which provides a range of security features depending on the options chosen. Pairing involves sharing of a PIN or other code, and establishment of cryptographic keys that are shared between the connected devices. The keys can be stored (bonding) to avoid having to pair with the same device for future connections. While the security features provided by pairing are useful, it may be too cumbersome for consumers to pair with every merchant device. • Pairing is optional for BLE, but if it is not used then any confidentiality or integrity protections would need to be implemented by the payment applications in consumer and merchant devices. • UWB implementations in consumer devices currently require that either network parameters are known in advance by consumer and merchant (an option which probably only works for closed single-merchant implementations), or UWB network parameters are shared via a second protocol before the UWB connection is established. • There are several standardised approaches to using secondary communication technologies which may be used to share credentials for connection, for example: • Bluetooth Secure Simple Pairing (see https://nfc-forum.org) uses NFC tags to share Bluetooth/BLE connection parameters). • Connection Handover Technical Specification (see https://nfc-forum.org) uses NFC tags to share Bluetooth or Wi-Fi connection parameters. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® White Paper Wireless Payment v1.0 Page 36 / 43 • Wi-Fi Easy Connect (see https://wi-fi.org) describes how Wi-Fi credentials can be se