Digital Payments Solutions Industry Considerations Wallets... · For now, the purpose of this document is in presenting a set of ‘high-level’ industry considerations that captures

1

Digital Payments Solutions

Industry Considerations Date : 29 June 2017

Unit Name: The UK Cards Association

Project Manager: Duncan McEwen

Business Owners: David Baker

Date of Final Approval: 28 June 2017

Approved by: Digital Transformation Steering Group (DTSG)

2

Version / Document History

Version No: Date: Author: Comments:

Draft 0.1 11.11.16 DM Skeleton Outline of the document

Draft 0.2 28.11.16 DM First Draft including Lifecycle Management and circulated to the DTSG (dated 03 March 2017).

Draft 0.3 26.04.17 DM Second Draft incorporating DTSG members comments (as received 26 April 2017) and circulated on 6th June 2017.

Draft 0.4 28.06.17 DM Third Draft incorporating DTSG members final comments (as received 28 June 2017).

v.1_FINAL 29.06.17 DM Final version copy ready for publication

3

Table of Contents

Executive Summary ........................................................................................... 4

1 Purpose ............................................................................................................. 5

1.1 Background ....................................................................................................... 5

1.2 Scope ................................................................................................................ 6

1.3 Definitions ......................................................................................................... 6

1.4 Governance ....................................................................................................... 6

2 UK Market Context ............................................................................................ 7

2.1 Card Payments ‘eco-system’ .............................................................................. 8

2.2 Tokenisation ...................................................................................................... 9

3 Lifecycle Stages ................................................................................................ 12

3.1 Overview and scope ........................................................................................ 12

3.2 Recruitment .................................................................................................... 14

3.3 Registration ..................................................................................................... 16

3.4 Issuance .......................................................................................................... 17

3.5 Personalisation ................................................................................................ 21

3.6 Activation ........................................................................................................ 24

3.7 Face-to-Face Payment Transactions ................................................................. 24

3.8 Acceptance at UK POS Face-to-Face ................................................................. 25

3.9 Transaction Exceptions .................................................................................... 26

3.10 Lost, Stolen & Replacements ............................................................................ 27

3.11 Portability ....................................................................................................... 28

3.12 Portability & Customer Service Management ................................................... 29

3.13 Service Termination ......................................................................................... 30

3.14 Compliance & Security ..................................................................................... 30

4 Lifecycle Considerations & Guidance ................................................................ 32

ANNEXES

Annex A: Glossary of terms ............................................................................................. 38

Annex B: Card/ Payment schemes Website Information .................................................. 42

Annex C: Standard 70 Book 1 Payment Transaction Scenarios ......................................... 43

Annex D: Card Industry Overview – Further Information ................................................. 46

Annex E: Reference Documents ...................................................................................... 47

4

Executive Summary The development and use of card payments is something that can no longer be described as ‘linear’, as retailers and financial institutions increasingly engage with their customers in the digital world. The use of the card payment as a financial instrument commonly used by consumers when interfacing with a range of industry sectors has not changed, but the assumption of how that interaction takes place is quickly evolving. Payments are now having to adapt in the digital space; where the expectation is for payments to be part of a seamless event that closes the transaction rather than being sat separately, and as an ‘out-of-band-step’, in the transaction process. This is far removed from the conventional habits of consumers going to the High Street to undertake a transaction as part of a well-established, formulaic and static in-store shopping experience. The onset of the internet, the connectivity infrastructure offered through the proliferation and use of mobile broadband, and coupled by the ubiquitous use of the mobile channel as a vehicle to access and download ‘content’, creates the notion of the ‘digital wallet’ as a conceptual ideal. Historically, this aspiration has centred on how the physical wallet might be replicated into some kind of digital equivalent, offering an array of applications (payment, loyalty, coupon redemption etc) capable of being ‘loaded’ and communicated through the mobile device. With the presumption that the future development, and progression of card payments would be crystallised as a form-factor ‘swap’ from the card to the mobile device at the point-of-sale (i.e. Mobile Contactless). However, the advance in technology, changing customer behaviour combined with the growing convergence between content, goods and services means this is fundamentally changing. Whereby, a digital wallet might be considered as recognition of an ‘acceptance mark’, a byword to denote a harmonised digital payment experience across any app, device or platform (e.g. MasterPass/ Visa Checkout). Or, where, its concept is seen as a ‘gateway service’ in which a host of commerce-enabled activities and different interactions can take place (e.g. WeChat/ Facebook Messenger). For now, the purpose of this document is in presenting a set of ‘high-level’ industry considerations that captures and extracts a cohesive grouping of good practices and behaviours, as have been deployed to operate in the proximity payments space. Our hope is this paper can be of practical benefit, offering a reference point for new entrants wishing, or eager, to launch services into the UK market thereby creating the ‘landscape of consistency’ that many wallet providers are looking for. It should be noted, and reiterated, that these are an informal set of ‘considerations’ and should in no way be mis-interpreted as providing any form of guarantee, nor constitutes a substitute for any existing accreditation or adherence to existing card scheme rules.

5

1. Purpose The main purpose of the document is in providing a coherent set of industry considerations that captures good practices, established conventions and behaviours now cemented in the UK market following the successful launch of various high profile digital wallet solutions in recent years1. Better protecting consumers from poor outcomes to help guard against sub-standard solutions from appearing and undermining consumer confidence to the detriment of all, but also defending the significant investments as have been made by the card payments industry, in facilitating the use of mobile contactless payments more generally. As well as helping to ensure that the integrity and use of card payments is considered and maintained at all times, irrespective of the payment channel chosen, which is only likely to diversify in the coming years ahead (e.g. contactless, mobile contactless, in-app, mobile-web browser and messaging). Finally, the document is offered as a way by which the regulatory community can better appreciate some of the wider trends that are now in situ (see below), as the notion of the ‘card’ changes, particularly in how the underlying rails are being re-calibrated, as technical developments (e.g. tokenisation) help to open-up the possibility for card payments to infiltrate into new industry sectors, payment channels and across an array of transaction environments.

1.1 Background The reason for a high level document such as this stems from a broader industry concern at the growing fragmentation and number of digital wallet solutions now operating in the UK, coupled with the practical difficulties in managing these integrations. As well as a shared apprehension at the increasing complexity that consumers and merchants face, when attempting to differentiate between what these competing offerings comprise, and how they operate at a practical level.

1 High profile digital wallet launches in the UK include; YoYo Wallet (7 Nov 2013), Apple Pay (14 July 2015), Android Pay (18 May 2016) and Samsung Pay (16 May 2017).

http://yoyowallet.com/founders.html

https://www.theguardian.com/technology/2015/jul/14/apple-pay-launches-uk-how-to-use

https://www.theguardian.com/technology/2016/may/18/android-pay-apple-samsung-pay-google

http://www.trustedreviews.com/news/what-is-samsung-pay

6

The idea of having a high-level document that could be referenced at the outset was felt a useful first-step to encourage future collaboration between an ever disparate set of stakeholders. A practical aim for doing so, is to avoid the poor execution of new digital payment solutions being launched, so undermining customer and/or merchant confidence, and damaging the reputation of digital wallet solutions more generally in the UK market. 1.2 Scope The evolution of ‘retail’ means that the general scope of the document has to be ‘open ended’ to acknowledge the use of where card payments are likely to operate, as part of an open-loop payment network, capable of serving multiple merchants across a range of industries and differing retail environments. 1.3 Definitions A comprehensive glossary of key terms is included elsewhere in this document at Annex A. 1.4 Governance The UK Cards Association will have overall governance control of the document on behalf of the Digital Transformation Steering Group (DTSG), which acts as the designated forum where collaborative discussions can occur around the future deployment of digital wallet solutions. Given the fast and changing nature of digital payments more generally, the document has to be made malleable enough to capture new developments, as behaviours change and other digital payment channels gain traction and prominence. It is intended that some kind of annual review process should be instigated, the final details of which are still to be determined, to ensure that the document remains fit-for-purpose with a change control process put in place updating the document to incorporate new market and regulatory developments. A subsidiary and concurrent development, borne out of any future governance process, is around the potential for an evaluation programme to co-exist in order to build a useful body of precedent that can be referenced to.

7

2. UK Market Context The UK market has always catered for a vibrant and diverse card payments market demonstrated by the variety of products and availability of choice that has long been provided to consumers, evidenced by the diversification of new digital products that have been introduced utilising the underlying card rails. This is fundamentally challenging the arbitrary, and once neat demarcation, around the existence of a card-present (CP) and card-not-present (CNP) distinction to where the physical concept of the retail outlet is substituted, in part, as the mobile phone becomes a primary means by which ‘commerce’ is facilitated. Whether this is ‘in-store’, ‘on-line’ or where certain goods/ services are being purchased from a multi-sided platform provider (e.g. Uber/ AirBnB) as part of the newly established sharing economy2. Meaning a range of specific and different ‘pre-requisites’ will be required when preparing for how a digital wallet service is ‘primed’, based on the environment in question, the technical interface in use, and the appropriate context in which the transaction takes place. The focus of the UK card industry’s collective efforts to date has centred on the introduction of ‘proximity payments’ through the implementation of NFC (and other connection modes (for example HCE), allowing the mobile phone to communicate with contactless enabled terminals in the same way as contactless EMV cards have long operated in the face-to-face shopping environment. This has made logical sense building on the secure transactions as have been provided by smart cards for the execution of applications through use of the ISO 14443 protocol standard; and thereby maintaining interoperability between mobile handsets and existing contactless card readers. To perform a mobile contactless payment transaction, an active mobile payment application on an NFC enabled mobile phone is presented to an active contactless reader, and a payment transaction is subsequently performed. The mobile issuance process has to a large extent been replicated, or at least been made to operate, in a similar fashion to existing procedures used for card issuance. Initially this focussed on promoting the use of SIM-SE based NFC payments. Where the payment credentials (i.e. cryptographic keys), are stored and reside in the Secure Element (SE)), and directly communicates with the NFC controller/ antennae enabling the phone to emulate that of a payment card. The provisioning aspect requires collaboration with the SIM owner (i.e. the mobile operator) for the issuing bank to be granted access, so as to be provisioned and personalised, before any transactions can take place. An alternative method is for this to be done remotely, via an OTA connection through a designated Trusted Service Manager (TSM). A significant change since October 2013 3 has been the possibility to instigate an EMV payment transaction from an application residing in the mobile phone’s operating system; removing many of the technical and commercial difficulties in having to engage with mobile operators, by avoiding the incurring of additional costs when managing the lifecycle of the payment product.

2 PwC study found that in 2015 alone, five key sectors of the sharing economy generated platform revenues of nearly €4bn and facilitated €28bn of transactions within Europe. 3 Android KitKat 4.4 was introduced on 31 October 2013 and introduced a new, open architecture ‘host card emulation (HCE)’ for NFC payments.

http://www.pwc.co.uk/issues/megatrends/collisions/sharingeconomy/future-of-the-sharing-economy-in-europe-2016.html

http://www.pcadvisor.co.uk/feature/google-android/android-44-kitkat-release-date-new-features-upgrades-3445512/

8

These basic technological developments demonstrate how adept and dynamic the card payments industry has been in facilitating a different commercial model that enables the issuing banks to take greater responsibility to deliver, provision and manage their own individual payment applications. In doing so, this has helped cement a different type of commercial relationship through the creation of Token Service Providers (TSP). Granting both banks and merchants the opportunity to ‘plug’ into these services; offered as a layering technology, by which tokens can be delivered and used in transactions to significantly reduce the impact of card security data breaches. All of which is part of a wider change where payments are being better adapted to meet the newer ways and demands of transacting in the digital space. It should be noted that the operating rules, as associated with mobile payments, reside with the international card schemes, which forms the basis upon which those products are developed and deployed. 2.1 The card payments ’eco-system’ The use of card payments has traditionally been defined by the card schemes, working with EMV Co to provide technical interoperability at the point-of-sale which has created an easily identifiable contactless acceptance infrastructure in the UK. A key characteristic in how the retailing landscape is changing can be defined by the innovative business models and partnerships which have come to the fore in recent years, and in turn are creating very different value chains and commercial arrangements. The evolution of contactless payments has developed out of the use of contactless EMV card payments to include mobile NFC payments (using secure elements); HCE, combined elements (HCE/NFC), and the anticipated launches of newer hybrid-offerings (e.g. BLE/HCE). The landscape has changed markedly from an ‘operator controlled model’ to a much more fragmented marketplace (cross-refer to page 10), where no single business model prevails, yet all are becoming increasingly interconnected with one another, encouraging a variety of vendors, merchant types, applications, services and payment methods to be used. This is having a profound impact on the traditional four-party model, which in many ways is becoming an ‘n’ party model of sorts, with the number of constituent parts being commensurate to the delivery of the business proposition in question; a feature of what might be described as evidence of an emerging open-API economy.

9

All of which is being increasingly driven by the catalytic growth in mobile internet connectivity, and the fact the mobile device is being seen as a mechanism where platforms, delivery of content and payments converge and are consumed. What is clear is ‘commerce’ is being increasingly derived through the connected device, so creating what might be described as an ‘actual content’ shopping experience, based around maximising the convenience to the customer, which reflects how the concept of ‘retail’ is fast being turned into a ‘content’ and ‘content delivery’ proposition4. This is challenging the traditional notion of ownership, and of brand recognition more specifically, with OEM providers (and individual merchants) offering up wallet services that are being used by consumers in their engagement with merchants, and when making a mobile contactless payment; even though the funding account for making the purchase is linked to a card account as owned by the issuing bank. The practical impact for the card payments industry is that many more players are fast becoming integral elements, of what was once a much more simplified set of conversations between an established set of players. Perhaps, going forward, what we will see is a further move away from the ‘device’ being seen as the primary means by which the payment is enabled, and instead products being built and marketed around the ‘harmonisation’ of a wider digital payment experience. 2.2 Tokenisation The underlying purpose for the introduction of tokenisation is to improve the state of security by making digital payments more secure. Regardless of the tokenisation approaches a merchant, scheme, or issuer chooses to adopt, the practical benefits reside around preventing consumers from providing a payment credential for every online transaction by which arbitrary amounts of money can be withdrawn from an account if this information were compromised.

4 The concept has long been established in the telephony world, and relates to monetising digital content but is now becoming ‘enmeshed’ as part of the physical retail experience. What might be better described as an ‘actual content shopping experience’ and offered through a full range of ‘fulfilment’ opportunities and options (e.g. click & collect, doorstep delivery, physical download and/or platform access).

10

By having credit card numbers removed from off merchant servers, and instead transmitted directly from consumers to the acquirer, PSP, or the designated TSP (based on the commercial agreement in place), offers a better way for digital payments to be used, helping reduce the likelihood of any data security breaches.

Merchant services

It is important to separate out two distinct and different types of tokenisation. The first, relates to what might be described as Payment Card Industry (PCI) tokenisation for card-on-file data, which constitute security tokens that are stored in the merchants or acquirers systems after a transaction is complete, and as it travels through the point-of-sale environment on the acquiring side. This contrasts to what might be described as ‘network tokenisation’, which is operated through a standardised approach to EMVCo tokenisation for card payment transactions, and has become the de-facto choice for many of the OEM wallet offerings that have launched in the UK since July 20155. Part of the challenge facing merchants, is the array of tokenisation services that they are able to choose from, which allows for multiple providers to deliver separate services on their behalf. A full range of tokenisation offerings might comprise a service that simply tokenises the payment card data (i.e. a tokenisation provider), but could also include tokenising personal identifiable data (through the use of data security platforms), or, any number of data-sets that might be being offered up by the merchant based on the domain and payment channel in use (e.g. card-on-file, mobile NFC, remote (e-commerce/m-commerce)) warranting the services of a tokenisation integrator. This latter description denotes other services that are offered (e.g. management of tokenisation encryption and/or key management technologies) rather than being solely focussed on commoditising the risk-management element of the payment itself, through a ‘generation engine’ that substitutes the card PAN for a single use, or, limited set of tokenised PANs to secure the payment card data. Ultimately, and from the merchant’s perspective, the value that these services provide is in reducing the risk, and associated compliance costs, arising from any data-hack by devaluing the data as stored, or held, by them so that it is viewed as having little or no intrinsic value.

Card Schemes

The role as provided by the international card schemes has been to formally standardise, and help define the use of tokenisation through EMVCo. Thereby, offering a range of practical benefits which includes simplification and consistency for merchants; standardising a process that can be configured to combat rising e-commerce card-not-present (CNP) fraud6, as well as identifying new ‘use-cases’, and helping to support the deployment of interfacing technologies (e.g. NFC/ HCE), with supporting guidance by defining how tokens should be created in such scenarios. A recent and interesting development is how new commercial frameworks7 are being positioned to foster greater interoperability between competing TSP providers, creating an environment where tokenised payment credentials can be requested and provisioned into competing wallet solutions.

5 Cross-refer to Footnote 1 relating to high profile digital wallet launches in the UK since November 2013 6 Remote purchase fraud losses were £432mn (2016); an increase of 9% on £398 (2015) and accounts for 70% of card fraud. With £248bn spent online via card payments equating to 35% of all spending online. 7 http://www.pymnts.com/news/mobile-payments/2016/mastercard-and-visa-tag-team-tokens/

http://www.pymnts.com/news/mobile-payments/2016/mastercard-and-visa-tag-team-tokens/

11

Bank Issuers

From an issuing bank’s perspective regardless of what individual solution, or, set of solutions is chosen, these have to align to ensure their customers data, and the integrity of it, is being protected by identifying that the ‘correct’ consumer, device and payment application is in use at all times.

12

3. Lifecycle Stages

The idea of having a clearly defined, and specific set of lifecycle events, forces attention at placing the consumer at the heart of an ever complex and multi-faceted array of commercial relationships; whereby, the shopping experience is ultimately based on the payment instrument and technology best suited to the consumer’s needs. The document itself highlights a series of issues around the lifecycle management of any digital wallet solution which necessitates some form of cross-industry agreement to develop a more consistent user experience. Establishing these agreements should better streamline the integration efforts of card schemes and issuers by establishing certain industry considerations whose practical use can act as a high-level ‘checklist’ capturing what those good practices and customs are, and as have been established. The guidelines address a variety and full range of end-to-end lifecycle management events both from the consumer’s viewpoint, as well as the likely impact on an individual bank issuer’s management systems (e.g. Lost & Stolen, Customer Service Management, Service Termination, ID & Verification and Compliance & Security). 3.1 Overview and scope Digital payment solutions include all types of mobile and online wallet services ranging from the use of card-on-file solutions to mobile applications with varying functionality, including for example cardholder identification and authentication, payment credential management, and the selection/ use for in-store and remote payments. Any digital payment solution involves a number of organisations working together and requires collaboration at different and concurrent levels (e.g. service design and delivery, user experience, technical interoperability and adhering with the operating regulations of the respective schemes). The proposed lifecycle stages, as have been identified, are written to apply to any digital payment solution covering services from issuers, schemes, OS providers and/or online service providers.

Description of Lifecycle Management Stages

13

In terms of scope, and for the purposes of lifecycle management, relevant digital payment solutions are those that use a payment card account as their primary means when funding a purchase. The concept of the digital wallet simply represents a component of the overarching payment solution, constituting those services that allow the cardholder to manage their card payment credentials when a payment transaction is to be made. We believe it inevitable that card payments will soon encompass new digital payment solutions far beyond the confines of a simple digital wallet. In practice, there are a host of other competing funding types, similar to cards, that could easily be integrated (e.g. direct-to-bank account, charge-to-mobile or stored-value-account), which offer viable and alternative solutions to the current card payment proposition, but exist out-of-scope for this document. Typically wallets store and manage payment credentials in two main ways, either:

(i) In a cloud wallet which stores the payments credentials in an internet service for use in e-commerce transactions; and/or,

(ii) As contained in the consumers handset device which installs the payment credentials in a

device as owned by the consumer for use in e-commerce and card-present transactions. *A potential third model, as anticipated, is where the ‘wallet’ becomes integrated as part of a messaging platform, opening the potential for instant messaging apps to act as the primary ‘gateway’ by which a host of different interactions, and commercial opportunities can subsequently take place to offer a full range of services8. For the sake of consistency, and to align with standard industry terminology already in use, we have categorised the concept of ‘wallet solutions’ into two main types;

- ‘Pass-through wallets’ (e.g. Apple Pay, Android Pay, Samsung Pay) – solutions that provide payment card details directly to merchants to enable the merchant to submit the transaction.

- ‘Staged wallets’ (e.g. Yo-Yo Wallet, PayPal) – solutions that submit the transaction on behalf of merchants, following the exchange of cardholder, merchant, and transaction information using a format that is specific to the wallet service.

8 There have been a number of high profile integrations into the Facebook Messenger platform including Uber (16 Dec 2016) and TransferWise (21 February 2017). Other popular services adopting equivalent models include We Chat (China) and Go-JEK (Thailand).

https://newsroom.fb.com/news/2015/12/introducing-transportation-on-messenger/

https://venturebeat.com/2017/02/21/transferwise-launches-facebook-messenger-bot-for-easy-global-money-transfers/

14

The difference between how both models operate is set out below;

To accept transactions for e-commerce transactions (in a remote payment context) and card-present transactions (for in-store) a merchant has to have one; or, other of the following;

A merchant server; a service that enables payment credentials and transactions to be accepted over the internet; or,

PoS (Point of Sale); a merchant device that interfaces directly with a commerce device, to

exchange payment credentials and accept transactions. 3.2 Recruitment The recruitment of cardholders is competitive between Digital Payment Solution providers and resides outside the scope of these industry considerations. However, where a collaborative approach might prove useful is to indicate the type of information that should be being made available to cardholders during, and, as part, of the recruitment and registration process. A consistent approach might be for all supporting communication to be clear, comprehensive and concise; equating to the knowledge required by the cardholder to better understand and operate the digital payment solution in question. With mobile consumer devices the technology to accept transactions has the potential to include any interface available on the consumer device and on the PoS.

15

When the wallet service is a staged-wallet the choice of the technology being used is under the control of the wallet service itself, but should demonstrate that similar levels of usability and security protection to cardholders and merchants are being offered in turn. For other wallet services, interoperability may be important and for those wallets the use of contactless mobile payments should match with the PoS acceptance infrastructure as deployed in the UK. Therefore, differences between the Digital Payment Solution and a ‘normal’ plastic card service should be highlighted and explained. It is imperative that sufficient attention is given to ensure that customers are being properly informed. For example, to perform NFC style payments from the handset, some kind of app installation would have to occur requiring the user to first download and install a mobile application. This would correspond to the general experience and, level of expectation of most UK cardholders who relate and engage to payment products as they appear on plastic cards. 3.2.1 Proposed Industry Considerations Recruitment Status 1. The Digital Payment Solution must provide a clear

statement of the functionality offered and how it relates to the cardholder’s and merchant’s payment accounts.

Mandatory Industry Position

2. The Digital Payment Solution must have a privacy statement, clearly explaining what cardholder and merchant data is used and how data will be stored, transmitted and used. The privacy statement must define how data is shared between participants and, if appropriate, with external organisations.


3. The Digital Payment Solution must have a liability statement, clearly explaining cardholder’s and merchant’s liability in all payment scenarios. As the market expectation would be equivalent to a plastic card, the statement should explain any differences between plastic cards and the Digital Payment Solution.


4. The Digital Payment Solution must have a security statement, clearly explaining how cardholders and merchants are defended against fraud and what actions they need to follow to protect themselves from errors and fraud.


5. The Digital Payment Solution must have an eligibility statement, clearly explaining the preconditions for cardholders to use the solution. This will cover the types of funding card products that apply (such as, including whether cards outside of the UK) can be used, and the equipment (such as, consumer device) they need.


6. The Digital Payment Solution must provide a clear statement of the costs to be incurred by cardholders and merchants, including the potential cost impact for related services, such as mobile data costs.


16

3.3 Registration To provide an attractive proposition a digital wallet must be easy to set up, simple to use, and have the capability to work everywhere. Irrespective of the delivery method or technical interface in use (i.e NFC, HCE, QR/Barcode, SIM/SE) all centre on the consumers handset-device substituting the use of a plastic card and when being used for a payment transaction. This necessitates some type of device registration, as an added and needed registration step, to confirm that the handset device being registered is in the possession of the authorised account holder, and when the customer’s device is presented for the first time. When performing a NFC payment from the customers device, the user must first download and install a mobile app to create a wallet account with their chosen wallet service provider. It is advisable that mobile apps should only be downloaded and installed from the official app store9 of the platform in question, reducing the level of security on their handset and potentially exposing the handset to malware. Once an app is installed on the customer’s handset device, the user and device will need to be identified and authenticated before the device can be provisioned with their account details, usually by capturing the details from an existing plastic card to identify the funding payment card account. It is standard practice to use a mobile network message, such as making a voice-call or sending an SMS, containing a device activation code to the mobile number as being registered. If appropriate, a binary SMS can be targeted directly at the app in order to minimise user involvement. Alternatively, the initial identification of the customer requesting the device registration can be performed over a different channel (e.g. online banking, mobile banking app, call centre) that is separate from the handset device being registered. The user may be provided, through any of these supporting channels, with a user activation code that can be entered into the app and as part of the registration process. Once registration is complete, and the initial set of credentials has been loaded, the customer’s handset device should indicate it is now ready to make payments. The payment application is ‘primed’ to work across a variety of transaction environments; contactless payments for PoS, and remote payments (including in-app, and via mobile web browser). 3.3.1. Proposed Industry Considerations Registration Status 7. The Digital Payment Solution must provide guidance stating

how cardholders and merchants register for the solution and, if required, download software onto a consumer device. Guidance documents should be concise, easy to understand (i.e. with limited use of jargon) and specific to the solution.


8. The Digital Payment Service must provide instructions and rules for the mechanism used to capture cardholder and card registration data. For example, the mechanism may


9 The most recognisable of those ‘official’ app stores would likely include Android Marketplace, Google Play, Galaxy Apps, Windows App & Apple iStore.

17

be: card-on-file, keyed card details, via an issuer API or photographed plastic card. Card data must be deleted when no longer required, including all graphics.

9. If a consumer device is required, the Digital Payment Solution should provide a statement on its required configuration. This may include, for example, if ‘rooted’ devices can be used and the requirements for automatic installation of up-to-date security patches.

Recommended

10. The Digital Payment Solution should be available through recognised consumer facing channels, such as by factory installation or branded app stores for consumer device applications.

Recommended

11. The Digital Payment Solution should have controls that allow cardholders to recognise genuine consumer device applications and internet services.

Recommended

12. The Digital Payment Solution must provide a statement on the use of the solution for multiple users, both for users of the consumer devices on which services are used and for multiple users of a cardholder account.


13. If the Digital Payment Solution requires the cardholder to create an account with the Digital Wallet Service, the terms for its use should be clearly articulated and should be consistent with the terms of use for the payment credentials to be loaded into the wallet.

Recommended

3.4 Issuance Issuance, personalisation and activation are talked about in this context as being those designated processes that are required to link a wallet service to a cardholder payment account. It recognises how these elements, when taken together, represent the ‘generic’ process by which payment credentials are installed into the wallet service. Appropriate verification practices may include strong authentication of consumers ahead of credential re-provisioning and clear customer communications describing the responsibilities and liabilities for cardholders.

18

Recognition should also be made that the issued payment credentials themselves might have a limited usage based on the digital solution in question (e.g. the use of short-term keys in the context of HCE/ NFC) which may need to be refreshed as they are used and/ or, periodically updated, as they expire. The element associated with the issuance process can be summarised as follows:

- Identification & Verification – categorises how the issuer is able to approve the payment credential issuance to perform specific authorisation and/or management tasks. This can be based on risk management data from the wallet service provider and other sources, and out-of-band verification that the user making the request is the correct cardholder.

- Binding – Securely links the cardholder identification to the specific service or device, including attesting the device and establishing the cardholder verification methods used for the transaction authentication. Secure binding ensures the integrity of the solution can be managed over time.

- Personalisation – issue payment credentials to the wallet service for authenticated users and applying domain controls on the use of the credentials, to define the conditions under which a payment credential can be used.

Obviously, each of these elements are applicable to any Digital Payment Solution and/or wallet service, but may differ in how they are operationally deployed. The exact sequence, and data used, depends on the specific architecture and implementation in use (i.e. Secure Element, HCE, Cloud Wallet). 3.4.1 Mobile Consumer Device with Secure Element For a mobile wallet on a NFC consumer device and with a payment application residing on the SIM/SE the likely sequences would operate in the following way;

ID&V – Issuance Request

- ID&V begins with the cardholder requesting the issuance of a mobile contactless payment product to their handset.

- The wallet provider generates a risk score based on its relationship with the cardholder. As a minimum, the score should represent high, medium or low categories of risk and a reason code indicating why the relationship is scored as it is.

- The wallet provider should include other data external to its direct relationship such as current location of the handset and the capabilities of the handset and secure element to the Token Service Provider (TSP) associated with the card number.

- The TSP routes the request to the issuer, asking for an ‘approve’ or ‘decline’ decision.

ID&V – Verification - The issuer verifies the identification of the cardholder regardless of the risk-score provided by

the wallet provider.

- The user requesting issuance is authenticated as the cardholder and the owner of the handset by out of band verification methods (e.g. pre-shared secret code, online banking, call centre, bank branch, mobile banking app). The option selected is at the issuer’s discretion.

19

- Multiple verification methods should be used. Particularly where the data in the request indicates a higher risk. For example, where the wallet provider is unable to provide an adequate risk assessment this would require the issuing bank to undertake more checks to verify their customer.

- Following verification the issuer chooses to either approve or decline the issuance request. It is UK market policy that all provisioning requests must be approved by the issuer.

Binding

Once approved, the payment app (e.g. mobile contactless product), including the sensitive payment credentials, are loaded and can reside on the secure element where it is securely provisioned. This requires the instantiation of the payment application on the secure element by the wallet service provider who then hands over control of the application to the TSP. This links the identity of the handset and secure element with the identities of the cardholder account. 3.4.2 Mobile Consumer Device using Host Card Emulation (HCE) The typical issuance process for a mobile wallet, on a consumer device, with a payment application using HCE in the handset would likely operate in the following manner;

ID&V – Issuance Request - The issuance request follows mostly the same processes used for a mobile payment

application on a secure element device. The data as shared will be similar.

- Where it differs is around the environmental data (i.e. HCE allows the mobile device’s operating system to communicate directly over the NFC interface in card emulation mode). A reflection of the different platform and the type of wallet in use.

ID&V – Verification

- The issuer must identify and verify the user as the genuine cardholder for the account using

‘out-of-band’ methods. - The issuer approves or declines the requests and notifies the TSP of its decision.

Binding

The binding process for HCE links the identities of the handset and HCE payment application, with the identities of the cardholder account to ensure only the correct account credential are loaded into the application. 3.4.3 Mobile Consumer Device using a Cloud Digital Wallet A cloud digital wallet is usually designed for remote payments made via a web browser. This can range from simplistic card-on-file e-commerce type wallets (e.g. PayPal/ Amazon) to more feature-rich applications for use on mobile consumer devices for both in-store and in-app. The in-store user experience is better achieved through the transaction data exchange between a consumer device wallet app and a merchant terminal or merchant consumer device. Typically, wallet providers implement their own solutions (e.g. barcodes) by which the cloud wallet acts as a staged wallet.

20

The registration process for a cloud wallet may be solely browser based, by which the user keys in their card details (including the CVV code 10 on the reverse of the card). Or, where a mobile application is used to create a wallet account; with the details from an existing plastic card captured to identify the funding payment card account. The typical issuance process for EMV tokenised card payments being loaded into a cloud wallet service would likely operate in the following manner:

ID&V – Issuance Request

- The issuance request will be sent to the TSP by the wallet provider along with a risk score, based on the relationship of the wallet provider to the cardholder and how the card data was captured.

ID&V – Verification - On receiving a request from the TSP the issuer must identify and verify the user as the

genuine cardholder for the account using out of band methods.

- The issuer approves or declines the requests and notifies the TSP of its decision.

Binding The binding process for a cloud wallet links the identities of the cardholder with the attributes of the cardholder account to ensure only the correct account credential is loaded into the cloud wallet. If a consumer device app is used, the cloud wallet provider must ensure that the binding between the app, the consumer device and the cardholder wallet account is accurate and secure. 3.4.4. Proposed Industry Considerations

Identification and Verification (ID&V) Status 1. The issuer must always provide the decision (approve or

decline) for credential issuance on receipt of requests from wallet service providers for all types of Digital Payment Solutions.


2. The issuer should be able to base their approve or decline decision on multiple factors, including the type of payment solution, risk scores from other service providers, external risk management and identity data sources, location data for a consumer device, and the histories of the wallet service and cardholder relationships.

Recommended

3. The wallet service provider should provide a risk score and a reason code for all credential issuance requests, including the initial cardholder identification request.

Recommended

4. Directly comparable risk management data should be provided for each type of wallet. For example, all consumer device wallets on the same platform should provide the same type of data.

Recommended

5. The issuer must identify and verify the user as being the approved cardholder for the funding account requested in the Digital Payment Solution request.


6. Issuers should rely on at least two cardholder verification methods, including the use of an out-of-bound method.

Recommended

10 American Express uses a CSC (Card Security Code) which is a 4-digit code printed on the front of the card and not the more commonplace CVV (Card Verification Value) which is situated on the back of the card.

21

Verification methods can include authentication via: a call to a customer service centre, shared secrets over the voice or SMS channels, pre-registered mobile app, token authentication using an issued plastic card.

7. Issuers must not rely solely on an authentication call to a call-centre operator for user identification verification.


8. Issuers must have undertaken a risk management assessment of the verification methods used, identifying the key threats and vulnerabilities for each method and the countermeasures implemented to mitigate these risks.


Binding 9. The Digital Payment Solution should bind the cardholder

identification and the cardholder verification methods for transactions to the specific wallet service being used. The binding should enable risk management functions to determine if transaction information is consistent (such as, determining that the correct application is being used from the correct wallet).

Recommended

10. When the Digital Payment Solution uses a consumer device application, the binding should link the verified (attested) identification of the specific device and the specific app instance, with the cardholder identification and the verification methods used for cardholder authentication.

Recommended

11. The verification methods used for cardholder authentication should result in authentication equivalent to the strong authentication requirements being defined by the European Banking Authority (EBA) for compliance with EU PSD 2 regulations. This is expected to mean that at least two factors (i.e. from ‘know’, ‘have’ and ‘are’) will be required during authentication.

Recommended

3.5 Personalisation Personalisation is the mechanism by which the payment application is set up with the account information of the specific cardholder. There are standard mechanisms for payment application personalisation for contactless EMV applications. The technical control of personalisation is expected to be via a TSM. A common interface to different TSMs is not defined. The user of the device needs to be verified at the time of installation to ensure the user is the actual customer entitled to the payment service. Both the customer’s secure element and handset must be uniquely identified. 3.5.1 Mobile Consumer Device with Secure Element The technical control and distribution of the data used for the standard personalisation approach is defined within Global Platform. As a secure element is similar to a plastic card chip, the payment application can be personalised once for the entirety of the mobile card product by being a hardware secure element. For the service to work properly the banks customer requires a NFC enabled SIM in their mobile device in order for the service to be made operational.

22

The issuer gives authority to the TSP to generate the token PAN and the data required to personalise the application instantiated on the secure element in the binding step. The TSP personalises the secure element payment application with the tokenised account details generating the appropriate cryptographic key sets that will be used for offline data authentication and transaction cryptogram generation. The consumer device cardholder verification method (CDCVM) (e.g. mobile passcode/ fingerprint (i.e. Touch ID) used during payment transactions is created by the cardholder and is also personalised into the secure element payment application. Offering a secure enclave, as hosted on the SE, by which a variety of virtual identities can be further added to, and stored. Successful personalisation of the application enables the wallet service to select the payment application from a list of installed cards. Once the application is personalised, the application is ready to use, and the cardholder is able to perform different styles of transactions by offering EMV equivalent levels of security for either in-app or card-present style transactions. The capability of the wallet and handset software, dictate how it is used and the situations it can be used in. 3.5.2 Mobile Consumer Device using Host Card Emulation (HCE) The payment application is personalised with limited use payment credentials that are refreshed on a regular basis rather than being a one-off personalisation for the lifetime of the product, and as are used for secure elements, which operate as a secure storage environment. Meaning that once a payment key is used for a transaction it needs to be replaced with a new key. A key difference is that the EMV payment transaction is performed from an application residing in the mobile phone’s operating system. As such, no long term storage of sensitive data is appropriate which if not mitigated by the issuing bank, can present potential security and usability issues, because of the differentiated provisioning process that normally ensues. The issuer gives authority to the TSP to generate the device token PAN and data required to personalise the HCE payment application. The TSP personalises the payment application with the tokenised account details. The TSP generates the initial set of data and limited-use keys for transaction cryptogram generation (i.e. short term keys are made valid for a single and/or limited number of transactions). The CDCVM (e.g. mobile passcode/ fingerprint), which is to be used for payment transactions, is created by the cardholder and included in the personalisation data for the payment application. Please note that CDCVM preference data is also included in the personalisation data. Successful personalisation will allow the wallet service to present the payment application to the cardholder as an option from a list of installed cards. Once the application is personalised, the application is ready to use and the cardholder is able to perform transactions. In an EMV transaction cryptographic keys are usually stored in a protected environment in the device (e.g. SE) which is used by the payment device, through the use of a secret key, to generate each cryptogram and is typically valid for at least three years.

23

In the context of when a HCE style transaction is used as the preferred delivery method, new data and limited use keys must be regenerated with the payment application being re-personalised on a regular basis. As such, the HCE device will need to be provided with limited use-keys that are only valid for a limited number of transactions. Either method (i.e. a session key for one time use and/or limited use keys for a set number of transactions) are suitable when making retail payments. The main consideration is in the number of transactions a device can perform, before it needs to contact the issuer for a new set of limited use-key credentials. From the consumer’s perspective the customer will need to be aware that the device must connect periodically to their issuer’s server to receive payment credentials. Some kind of educational awareness piece might be needed for the customer to equate the requirement of having a network connection to download dynamic data from their issuing bank and for this to be delivered to the mobile phone ahead of, and prior to, the transaction. As well as the likely frequency of user authentication. 3.5.3 Mobile Consumer Device using a Cloud Digital Wallet Following approval and linking of identity information, tokenised payment credentials can be issued to the wallet from the cardholder on verification of the user as the cardholder. The payment credentials may involve the provision of card payment cryptographic keys for the tokenised card dependent on the capabilities of the cloud wallet provider and their relationship with the TSP. If cryptographic keys are to be provisioned, they need to be secured in encrypted form and only used on secure hardware during processing in the cloud wallet. The actual approach will be defined by the payment scheme so as to adhere with their security requirements. 3.5.4 Proposed Industry Considerations

Personalisation Status 12. The Digital Payment Solution must request and store

payment credentials in a secure manner appropriate to the type of wallet solution as required by the payment scheme associated with the card account.


13. Cardholder authentication with the issuer should be performed for the wallet payment credential personalisation. The verification methods used should provide strong authentication equivalent to those used during the binding of a wallet to the cardholder.

Recommended

14. The participants in the Digital Payment Solution should implement and agree payment credential (token) domain controls.

Recommended

15. The issuer or token service provider should provide the wallet service provider with a level of assurance applicable to the cardholder and their account for this wallet service. The meaning of the level of assurance should be agreed by all participants in the Digital Payment Solution.

Recommended

16. The Digital Payment Solution should provide a clear statement of any domain controls used to cardholders and merchants.

Recommended

24

3.6 Activation Activation is the process to verify that the personalisation process has worked sufficiently for the correct cardholder. The terms and conditions of the service should be accepted by customer on application activation. The terms and conditions should adhere to appropriate UK consumer protection regulations and guidelines. The principle requirement defined by EMVCo is that the settings as associated by the payment application payment product is always the choice of the cardholder not the application provider, wallet provider, or, other third party, such as the merchant. On activation, the cardholder verification method (CVM) used to allow higher value payments (HVP) on mobile, can be confirmed with the cardholder. 3.7 Face-to-Face Payment Transactions Any mobile contactless payment requires the user to ensure their wallet solution is correctly ‘primed’ prior to when the mobile is presented, and when the transaction is made, as part of a standard EMV contactless payment at the point-of-sale. The type(s) of ‘pre-requisites’ that the end-user should be made aware of would likely include the following;

• For the mobile device to have connective capability either to the internet, or a mobile network, so as to obtain a device PAN from the issuing bank and/or to download dynamic data (where this is appropriate) so that a sufficient number of tokens (for a mobile device using HCE) exists in order to complete the transaction.

• Confirmation that a payment card, from a card scheme (and as being accepted by the retailer), has been loaded onto the mobile device.

• The customer has correctly authenticated themselves (e.g. Touch ID/ Passcode etc) by

selecting the card-in-use.

• The mobile device has sufficient battery power. The consumer should have a sufficient degree of ‘product knowledge’ to understand whether the mobile device has to be physically activated, with connective capability, to perform the transaction based on the consumer’s preferred type of wallet solution.

• Any downloading of an app, and/or the mobile device itself, must meet standard issuer

security requirements (i.e. not rooted and/or jail-broken).

At a very basic level, and once the mobile device has been correctly ‘primed’, the contactless card can be presented (and tapped) on an active contactless reader. In a standard contactless card transaction the reader passes a limited data-set to the card. Even though mobile contactless payments have the capability of displaying a much richer set of information about a mobile contactless transaction (e.g. merchant name and other additional descriptive data elements) on the mobile phone and immediately following the transaction. EMV contactless specifications allow a reader message to be displayed to the cardholder, instructing them to place their card and to hold their card until being informed to remove it.

25

In the context of a mobile contactless payment a consumer device CVM (CDCVM) can be entered into the payment application on the mobile device, prior to when the payment transaction is performed. This allows for higher-value payment transactions (HVP) to be made. In practice, certain ‘caps’ can be placed on the transaction value limits (either by the issuer, acquirer or the merchant themselves) and will be configured to the contactless reader in question; which has a direct bearing on the user experience, coupled with whether the payment application is activated and made ready for use at the payment terminal. When using an active payment application on a mobile device, the basic user experiences can be described as follows;

• No CVM Required. For payment transactions of value equal to, or below the contactless CVM limit (£30), the consumer presents the mobile contactless device onto the contactless reader (similar to existing contactless card transactions). Based on the risk management data personalised in the terminal and the card application, the payment transaction may be subject to offline authentication only, or, may be sent to the issuer for authorisation online.

• Pre-entered CVM. For payment transactions of value above the contactless CVM limit, the user enters the CDCVM code on the mobile and then presents the mobile onto the contactless reader.

• CVM for Second Presentment. For payment transactions of a value above the contactless CVM limit (if the consumer has not entered the CDCVM code prior to the first presentment), the reader advises the consumer to enter their CVM code on their mobile and re-present the mobile back onto the reader, so as to re-start the payment transaction. This user experience is often referred to as the ‘two-tap’ approach.

The payment application is not personalised with a CDCVM, rather this requires the consumer to select a value on first use of the application, and after the consumer has authenticated themselves, to the issuer’s satisfaction. A simplified view of the processing steps required for each of the payment transaction scenarios (as have been outlined above), are set out in diagrammatic form11 at Annex C. Their primary purpose is to illustrate the key elements of the payment user experience, highlighting how these various processes differ from the cardholder’s perspective and point-of-view. The transaction confirmation methods are not defined in EMV specifications but are offered as part of card schemes implementation options. 3.8 Acceptance at UK POS Face-to-Face The introduction of mobile contactless acceptance is considered a complementary feature to any pre-existing acceptance infrastructure currently operating in the UK, rather than as a replacement to what has gone before. The basic premise in having a cardholder facing display, associated with the contactless acceptance device, is to show the amount of the transaction prior to the cardholder presenting their consumer device to initiate the payment. With the cardholder informed of the progress and outcome of the transaction through a combination of visual, audible and terminal messaging prompts.

11 Paragraph(s) 6.4.7.1 – 6.4.7.3 [Standard 70 – Book 1] Card Acceptor To Acquirer Interface Standards – Business Rules for Card Processing (April 2017)

26

The terminal user interface requirements, made specific to the cardholder user interface (rather than detailing the merchant user interface as found in Standard 70) are set out in the accompanying guide entitled ‘Contactless Terminal User Interface for Europe and the UK’12 as listed in Annex E. 3.9 Transaction Exceptions A basic assumption is that a mobile contactless payment should not have any lesser capability than a chip-based card transaction. A good example is where you have a standard contactless transaction which is declined because of insufficient off-line funds, it is usual in such instances for the cardholder to be asked to perform a Chip & PIN transaction. Where the same issue occurs in the context of a mobile contactless payment, the payment application residing on the handset should check to see if the counters need to be re-set, by contacting the issuer over the mobile data channel. Similarly, transactions can be declined for other reasons such as if the payment application is blocked or where online authorisation has failed. In which case, the reader messages, as defined in Standard 70, will apply offering a preferred set of reader messages. There are a number of nuances associated with the use, practicalities and interaction of a mobile contactless transaction means the working assumption in having ‘no lesser’ features does not necessarily apply. A small number of outstanding items require further consideration and clarification – these include:

• Cash Back For mobile contactless payments cash-back is not supported. The three scenarios where this may be proven relevant include;

- Where the value of the items is less than the CVM limit. - Where the value of the item is less than the CVM limit but with ‘cash-back’ exceeds the CVM

limit. - Where the value of the items exceed the CVM limit.

• Refunds Processing

Where a refund cannot be processed via a contact interface the individual product as associated with the card (i.e. Chip & PIN, Contactless, Mobile Contactless) defines the process that is undertaken to affect the refund. Arguably, there is a ‘dis-connect’ in most retailer staff’s education, between where a tokenised payment is presented, (i.e. the tokenised PAN) to matching what is shown on a paper receipt where the last ‘four digits’ of the consumer’s chosen card is presented as validation. No common cross-scheme refunds process exists in the UK market at present; though each of the respective schemes operating regulations have rules that are made specific to refunds, covering the scenario of where a refund is made when using a tokenised wallet service. All of which is predicated upon the customer presenting the same card and device (as each device will have a different ‘token’) as used for the purchase.

12 Version 1.6 (31 January 2007)

27

• Reversals

Reversals are used to ‘undo’ transactions that have been performed and usually where you have an ‘amount error’.

Unlike for contact card transactions there are no specific requirements as contained in Standard 70 for mobile contactless cards, which normally requires the terminal to produce a receipt for the cardholder showing that the original transaction has been voided. For clarification purposes the concept is supported as part of a standard terminal based process; and applies to all online authorised payments at the Point of Sale. However, this process does not require the customer to present their mobile for a ‘second-tap’ to undo the original transaction.

• Voice Referrals This relates to cardholders having access to likely information requested during the referral call (e.g. data not printed on the receipt, card security code etc). For mobile contactless transactions the use of any voice referral response offers a poor consumer experience and should be avoided. Rather any referral response should be treated as a ‘decline’ by the terminal. 3.10 Lost, Stolen & Replacements As with any mobile payment product, a fundamental concern is how to deal with lost or stolen devices. Especially in instances, where the loss of the device can lead to a lack of service for the cardholder raising the spectre of having the device compromised and used for fraudulent activity. Unlike a card, where the cardholder is usually minded to call the card issuer, a mobile device owner is unlikely to contact their bank in the first instance, when the problem is to do with their phone, and where the consequential loss is specific to certain proprietary features and other bespoke forms of intellectual property, residing on the mobile device. The mobile operators maintain a database, known as an Equipment Identity Register (EIR), in which they record the handset identifier (International Mobile Equipment Identity (IMEI)) of phones being reported as lost or stolen. Periodically checking the registered IMEI against the EIR, the issuer can determine if a device has been reported as lost or stolen. In such a scenario, and recognising that such a system is not infallible, it is recommended the mobile contactless payment service should be suspended until the user has been contacted, principally to confirm if the service should be terminated for that device. This approach when handling lost/stolen devices is based on the assumption and existence of a reasonably stable pattern of ownership, use and replacement of handsets. It should be recognised that in some communities and/or age demographics a greater degree of sharing/swapping of handsets is the norm, and security practices might need to be adjusted accordingly.

28

This emphasises that no overarching assumption should be made as to the on-going ownership of a handset. 3.10.1 Proposed Industry Considerations

Lost, Stolen & Replacements Status 1. The Digital Payment Solution must inform cardholders the

correct organisation to contact and the actions to be taken in the event of a lost and stolen wallet, including for account takeover.


2. Cardholders must have the ability to notify their issuer of a lost or stolen consumer device (and without the need for the consumer device).


3. Agreements and technical capabilities are established between service providers in the Digital Payment Solution to propagate a lost and stolen event throughout participants.

Recommended

4. The Digital Payment Solution should be able to suspend the use of cardholders’ wallets and credentials for a period of time before termination of the wallet, to allow for re-activation. Issuers should be able to view and agree the controls for suspension, termination and re-activation.

Recommended

5. Call centre verification of cardholders for re-activation must be of equivalent strength to the initial ID&V process undertaken on issuance.


6. Wallet Service Providers should implement controls to stop a wallet being suspended by a user who is not the cardholder.

Recommended

7. The Digital Wallet Solution suspension process should distinguish between lost and stolen, device fraud and fraud on the funding account.

Recommended

8. Replacement Digital Payment Solutions must follow the same registration and issuance processes as are required for new wallet services.


3.11 Portability Portability has two specific aspects when being considered as part of any Digital Payment Solution. Firstly, and at a superficial level, the concept of portability is something that has long been established in the telecoms sector, where users get the benefit of keeping the same number (better known as ‘operator portability‘) considered a key feature to facilitate competition. In particular, where a consumer wishes to upgrade, or seek to move to a different provider who is offering a more competitive package in return. A subset of this is in the way that removable modules might be moved to different consumer devices referred to as the portability of wallets. Second, the concept of portability has to be seen and considered in terms of what digital ‘content’ is also being ported across, including any residual goods or services13.

13 A good example is where you have an established and overarching industry process (e.g. Current Account Switch Service (CASS) which is triggered including its impact on supporting wallet services.

29

3.12 Portability & Customer Service Management As well as portability, the concept of customer service management is an integral part in helping create an optimal user-experience for the customer, as well as helping set an expectation in the way that Digital Payment Solutions are being managed in practice. The notion of customer service management potentially includes a wide spectrum of features, with individual elements potentially being offered and marketed as a competitive differential. The industry considerations, as are set out below, comprise a non-exhaustive list that should be being factored into any Digital Payment Solution, either already operating, or, wishing to enter into the UK market. 3.12.1 Proposed Industry Considerations

Portability & Customer Service Management Status Removable Modules 1. If removable modules in consumer devices are used for the

storage and/or processing of cardholder payment credentials, then the wallet service provider should inform the issuer of changes to consumer device identification. This is to be based on risk management agreements for the Digital Payment Solution.

Recommended

Locked Wallet Services 2. The Digital Payment Solution should lock the wallet service

following a defined number of successive failed user authentication attempts. All participants should be notified of locked services.


3. The Digital Payment Solution should provide a procedure to unlock a locked wallet service, using a fallback authentication method agreed between participants. If no fallback method is available, or all authentication methods are locked, then unlocking a wallet should be done with security equivalent to the initial issuance process.

Recommended

Change of Cardholder Authentication Value or Method 4. In order to change a cardholder authentication value or

method, the Digital Payment Solution must require the existing authentication method and value to be used to initiate the change process.


5. Participants in the Digital Payment Solution must have a defined and agreed risk management process on cardholder authentication change, which defines the circumstances when all participants are notified of the event. This should include fallback from a regular use method, such as a mobile biometric, to a method used irregularly, such as a device level passcode.


6. The Digital Payment Solution should make cardholders aware of the risks of using wallet services on multi-user consumer devices.

Recommended

Funding Account Events

30

7. When a lifecycle event occurs on the funding account for the card, the impact for Digital Payment Solution should be the same as the impact for plastic cards.14

Recommended

Notifications 8. Lifecycle events should be reported to the cardholder. This

should be via the cardholder selected electronic channel (e.g. SMS or email).

Recommended

3.13 Service Termination For the purposes of this paper, ‘service termination’ represents the use of a wallet solution, either located on a specific consumer device, or, an online service, when the cardholder has failed or is no longer meeting the eligibility requirements for when using the service. 3.13.1 Proposed Industry Considerations

Termination Status 1. Cardholders must have the ability to terminate the Digital

Payment Solution. Mandatory Industry Position

2. On termination, all cardholder and payment data should be removed from the wallet (both for cloud and consumer device wallets).

Recommended

3. The Digital Payment Solution must have clear a statement of the cardholder process and liability on termination.


3.14 Compliance & Security Digital Payment Solutions should meet the compliance requirements such that the integrity of the payment scheme and customer protections is maintained. The following comprises a list of some of the key industry compliance and security testing processes applicable to Digital Payment Solutions:

- PCI card payment industry requirements for issuance, data processing and PIN management

- EMVCo security requirements for transactions and software solutions - EBA-RTS regarding strong customer authentication requirements - GSMA handset compliance (including the Equipment Identity Register (EIR) - Data Protection & Privacy Reg(s) (e.g. General Data Protection Regulation)

In instances where new digital wallet solutions are being brought into the UK market, it should be able to show that credible and suitable testing has been undertaken at technical, operational and business procedural levels. The considerations, as proposed in this regard, are aimed at trying to protect all types of Digital Payment Solutions but also to encourage innovation.

14 This may not be the case for all Funding PAN (FPAN) Lifecycle Management (LCM) events. For example, FPAN renewal does not always change the token on the device. FPAN fraud, cancellation, suspension cases will impact token on the device. There are scheme specific considerations for FPAN versus Token LCM where there are mutual impacts. For the most part the LCM of FPAN is kept independent of the LCM of DPAN.

31

The ability of customers to negotiate and understand the implications of compliance is limited, but it is important that consumers understand any limitations as to the security of solutions, and their associated liabilities; in particular, what specific and practical actions should be taken. 3.14.1 Proposed Industry Considerations

Compliance Status 1. The Digital Payment Solution using technology covered by

current industry compliance requirements should have provable certification to industry body compliance requirements.

Recommended

2. A Digital Payment Solution using technology covered by current industry compliance requirements but without formal certification must have undergone provable testing equivalent to industry compliance requirements.


3. A Digital Payment Solution using technology that is not covered by current industry compliance requirements must identify where it is not covered and be able to demonstrate testing has been undertaken to a rigour deemed equivalent to current industry best practice.


4. A Digital Payment Solution introducing new or changing existing behaviour at PoS should identify the new behaviour and demonstrate that a suitable merchant communications and training programme is planned and being undertaken. This is to guard against the possibility that if a solution fails to work sufficiently well at PoS, the detriment impacts on all Digital Payment Solutions.


Security 5. To protect the integrity of a payment system, the Token

Service Provider, should have the ability to suspend or terminate all transactions for a range of token PANs. This would aim to ensure that in instances where there is a clear security breach, or, a compromise of security standards, mitigation can be applied across the whole service.

Recommended

32

4. Lifecycle Considerations & Guidance Recruitment Status 1. The Digital Payment Solution must provide a clear

statement of the functionality offered and how it relates to the cardholder’s and merchant’s payment accounts.


2. The Digital Payment Solution must have a privacy statement, clearly explaining what cardholder and merchant data is used and how data will be stored, transmitted and used. The privacy statement must define how data is shared between participants and, if appropriate, with external organisations.


3. The Digital Payment Solution must have a liability statement, clearly explaining cardholder’s and merchant’s liability in all payment scenarios. As the market expectation would be equivalent to a plastic card, the statement should explain any differences between plastic cards and the Digital Payment Solution.


4. The Digital Payment Solution must have a security statement, clearly explaining how cardholders and merchants are defended against fraud and what actions they need to follow to protect themselves from errors and fraud.


5. The Digital Payment Solution must have an eligibility statement, clearly explaining the preconditions for cardholders to use the solution. This will cover the types of funding card products that apply (such as, including whether cards outside of the UK) can be used, and the equipment (such as, consumer device) they need.


6. The Digital Payment Solution must provide a clear statement of the costs to be incurred by cardholders and merchants, including the potential cost impact for related services, such as mobile data costs.


Registration Status 7. The Digital Payment Solution must provide guidance

stating how cardholders and merchants register for the solution and, if required, download software onto a consumer device. Guidance documents should be concise, easy to understand (i.e. with limited use of jargon) and specific to the solution.


8. The Digital Payment Service must provide instructions and rules for the mechanism used to capture cardholder and card registration data. For example, the mechanism may be: card on file, keyed card details, via an issuer API or photographed plastic card. Card data must be deleted when no longer required, including all graphics.


9. If a consumer device is required, the Digital Payment Solution should provide a statement on its required configuration. This may include, for example, if ‘rooted’ devices can be used and the requirements for automatic installation of up to date security patches.

Recommended

10. The Digital Payment Solution should be available through recognised consumer facing channels, such as by factory installation or branded app stores for consumer device applications.

Recommended

11. The Digital Payment Solution should have controls that Recommended

33

allow cardholders to recognise genuine consumer device applications and internet services.

12. The Digital Payment Solution must provide a statement on the use of the solution for multiple users, both for users of the consumer devices on which services are used and for multiple users of a cardholder account.


13. If the Digital Payment Solution requires the cardholder to create an account with the Digital Wallet Service, the terms for its use should be clearly articulated and should be consistent with the terms of use for the payment credentials to be loaded into the wallet.

Recommended

Identification and Verification (ID&V) Status 1. The issuer must always provide the decision (approve or

decline) for credential issuance on receipt of requests from wallet service providers for all types of Digital Payment Solutions.


2. The issuer should be able to base their approve or decline decision on multiple factors, including the type of payment solution, risk scores from other service providers, external risk management and identity data sources, location data for a consumer device, and the histories of the wallet service and cardholder relationships.

Recommended

3. The wallet service provider should provide a risk score and a reason code for all credential issuance requests, including the initial cardholder identification request.

Recommended

4. Directly comparable risk management data should be provided for each type of wallet. For example, all consumer device wallets on the same platform should provide the same type of data.

Recommended

5. The issuer must identify and verify the user as being the approved cardholder for the funding account requested in the Digital Payment Solution request.


6. Issuers should rely on at least two cardholder verification methods, including the use of an out-of-bound method. Verification methods can include authentication via: a call to a customer service centre, shared secrets over the voice or SMS channels, pre-registered mobile app, token authentication using an issued plastic card.

Recommended

7. Issuers must not rely solely on an authentication call to a call-centre operator for user identification verification.


8. Issuers must have undertaken a risk management assessment of the verification methods used, identifying the key threats and vulnerabilities for each method and the countermeasures implemented to mitigate these risks.


Binding 9. The Digital Payment Solution should bind the cardholder

identification and the cardholder verification methods for transactions to the specific wallet service being used. The binding should enable risk management functions to determine if transaction information is consistent (such as, determining that the correct application is being used from the correct wallet).

Recommended

10. When the Digital Payment Solution uses a consumer device application, the binding should link the verified (attested) identification of the specific device and the specific app instance, with the cardholder identification and the verification methods used for cardholder

Recommended

34

authentication. 11. The verification methods used for cardholder

authentication should result in authentication equivalent to the strong authentication requirements being defined by the European Banking Authority (EBA) for compliance with EU PSD 2 regulations. This is expected to mean that at least two factors (i.e. from ‘know’, ‘have’ and ‘are’) will be required during authentication.

Recommended

Personalisation Status 12. The Digital Payment Solution must request and store

payment credentials in a secure manner appropriate to the type of wallet solution as required by the payment scheme associated with the card account.


13. Cardholder authentication with the issuer should be performed for the wallet payment credential personalisation. The verification methods used should provide strong authentication equivalent to those used during the binding of a wallet to the cardholder.

Recommended

14. The participants in the Digital Payment Solution should implement and agree payment credential (token) domain controls.

Recommended

15. The issuer of token service provider should provide the wallet service provider with a level of assurance applicable to the cardholder and their account for this wallet service. The meaning of the level of assurance should be agreed by all participants in the Digital Payment Solution.

Recommended

16. The Digital Payment Solution should provide a clear statement of any domain controls used to cardholders and merchants.

Recommended

Lost, Stolen & Replacements Status 1. The Digital Payment Solution must inform cardholders the

correct organisation to contact and the actions to be taken in the event of a lost and stolen wallet, including for account takeover.


2. Cardholders must have the ability to notify their issuer of a lost or stolen consumer device (and without the need for the consumer device).


3. Agreements and technical capabilities are established between service providers in the Digital Payment Solution to propagate a lost & stolen event throughout participants.

Recommended

4. The Digital Payment Solution should be able to suspend the use of cardholders’ wallets and credentials for a period of time before termination of the wallet, to allow for re-activation. Issuers should be able to view and agree the controls for suspension, termination and re-activation.

Recommended

5. Call centre verification of cardholders for re-activation must be of equivalent strength to the initial ID&V process undertaken on issuance.


6. Wallet Service Providers should implement controls to stop a wallet being suspended by a user who is not the cardholder.

Recommended

7. The Digital Wallet Solution suspension process should distinguish between lost and stolen, device fraud and fraud on the funding account.

Recommended

8. Replacement Digital Payment Solutions must follow the same registration and issuance processes as are required


35

for new wallet services. Portability & Customer Service Management Status Removable Modules 1. If removable modules in consumer devices are used for

the storage and/or processing of cardholder payment credentials, then the wallet service provider should inform the issuer of changes to consumer device identification. This is to be based on risk management agreements for the Digital Payment Solution.

Recommended

Locked Wallet Services 2. The Digital Payment Solution should lock the wallet

service following a defined number of successive failed user authentication attempts. All participants should be notified of locked services.


3. The Digital Payment Solution should provide a procedure to unlock a locked wallet service, using a fallback authentication method agreed between participants. If no fallback method is available or all authentication methods are locked, then unlocking a wallet should be done with security equivalent to the initial issuance process.

Recommended

Change of Cardholder Authentication Value or Method 4. In order to change a cardholder authentication value or

method, the Digital Payment Solution must require the existing authentication method and value to be used to initiate the change process.


5. Participants in the Digital Payment Solution must have a defined and agreed risk management process on cardholder authentication change, which defines the circumstances when all participants are notified of the event. This should include fallback from a regular use method, such as a mobile biometric, to a method used irregularly, such as a device level passcode.


6. The Digital Payment Solution should make cardholders aware of the risks of using wallet services on multi-user consumer devices.

Recommended

Funding Account Events 7. When a lifecycle event occurs on the funding account for

the card, the impact for Digital Payment Solution should be the same as the impact for plastic cards.

Recommended

Notifications 8. Lifecycle events should be reported to the cardholder.

This should be via the cardholder selected electronic channel (e.g. SMS or email).

Recommended

Termination Status 1. Cardholders must have the ability to terminate the Digital

Payment Solution. Mandatory Industry Position

2. On termination, all cardholder and payment data should be removed from the wallet (both for cloud and consumer device wallets).

Recommended

3. The Digital Payment Solution must have clear a statement of the cardholder process and liability on termination.


Compliance Status 1. The Digital Payment Solution using technology covered by

current industry compliance requirements should have provable certification to industry body compliance requirements.

Recommended

36

2. A Digital Payment Solution using technology covered by current industry compliance requirements but without formal certification must have undergone provable testing equivalent to industry compliance requirements.


3. A Digital Payment Solution using technology that is not covered by current industry compliance requirements must identify where it is not covered and be able to demonstrate testing has been undertaken to a rigour deemed equivalent to current industry best practice.


4. A Digital Payment Solution introducing new or changing existing behaviour at PoS should identify the new behaviour and demonstrate that a suitable merchant communications and training programme is planned and being undertaken. This is to guard against the possibility that if a solution fails to work sufficiently well at PoS, the detriment impacts on all Digital Payment Solutions.


Security Status 5. To protect the integrity of a payment system, the Token

Service Provider, should have the ability to suspend or terminate all transactions for a range of token PANs. This would aim to ensure that in instances where there is a clear security breach, or, a compromise of security standards, mitigation can be applied to across the whole service.

Recommended

37

ANNEXES

38

Annex A: Glossary of terms

UK Cards The UK Cards Association is the lead trade association for the card payments industry and accounts for the vast majority of debit and credit cards in the UK.

Acquirer

A Payment Service Provider, or one of their agents, that enters into a contractual relationship with a merchant and an issuer via the card payment scheme, for the purpose of accepting and processing card transactions.

Barcode

A 2D barcode is a machine-readable optical label that contains digital information and can be referred to as matrix barcodes. Examples include QR Codes and/or tag codes.

BLE

Bluetooth Low Energy (BLE) – a technology usually partnered with a BLE beacon that emits a Bluetooth Low Energy signal which transmits less data over shorter distances, and is primarily designed for periodic transfers (e.g. providing proximity in a retail store).

Card Emulation Mode Allows for the emulation of a contactless smart card. Card Not Present Transaction (CNP)

A remote purchase card-not-present transaction (CPN) is where the cardholder and the card are not present at the Point of Sale (PoS). Remote style purchases can be used for Mail Order, Telephone Order, as well as sales made over the internet.

Card Payment Credentials

Constitutes the relevant payment account related data that may include a code (e.g. mobile code) as provided by the issuer to their customer for identification/ authentication purposes.

Card Present Transaction (CP)

A card payment transaction when both the cardholder and the card are physically present to one another.

Card/ Payment Schemes

Owners of the payment scheme by which a bank, building or payment service provider can become a member and defines the set of rules to be applied within their network.

Cardholder Verification Method (CVM)

In the context of an EMV chip transaction the CVM is used to evaluate whether the person presenting a payment instrument such as a payment card is the legitimate card holder.

CVM Limit The CVM limit (£30 as it stands today) and as set by the international card schemes.

Card-on-file

Traditionally used when facilitating ecommerce transactions whereby payment data (e.g. credit card details) are securely stored on a server (i.e. in the form of a data file) to make paying bills and/or purchasing items easier.

Charge-to-mobile

Denotes payments that are normally charged to the consumer’s mobile phone bill either by carrier billing or text (e.g. PSMS).

Cloud Wallet Denotes where sensitive payment data is stored remotely on ‘cloud’ servers rather than residing in a physical data store.

Current Account Switching Service (CASS)

Launched in September 2013 and backed by the Current Account Switch Guarantee it covers most of the competitive current account market. The Current Account Switch Service is a free-to-use-service for consumers, small charities, small businesses, and small trusts making it possible to switch current accounts in a seven day period (however this does not include the actual account opening process).

Customer Device Cardholder Verification

Consumer Device Cardholder Verification Method (CDCVM) is the type of consumer verification method (CVM) supported by the international card schemes, and, as chosen by the consumer for the wallet service in question. This relates to what is meant by ‘CVM code’.

39

Method (CDCVM)

CVV

Card Verification Value (CVV) is an anti-fraud security feature. For Visa/Mastercard the three digit CVV number is printed on the signature panel on the back of the card.

Device Activation Code

A series of letters and digits that must be entered to authorize the user usually during some kind of software installation.

Device PAN A term used to denote where the token PAN is assigned to an individual device. Device Registration

The process by which the funding PAN is embedded into the EMV chip with its own keys, certificates and verification values.

Digital Payment Solution

This includes all types of mobile and online wallet services ranging from the use of ‘card-on-file’ type solutions to mobile applications with varying levels of sophistication and functionality.

Digital Wallet

The wallet represents a component of the overarching payment solution and constitutes those services that allow the cardholder to manage their card payment credentials when a payment transaction is made. The usage of the wallet is usually under the control of the consumer.

Direct-to-bank account

Electronic transactions which allow people to pay directly via their bank accounts. Products as launched in the UK market include Pingit, Paym & Zapp/ Pay-by-bank app (of which the official launch date is still to be confirmed).

EMV Contactless Card

EMV Contactless works by holding a contactless chip-enabled payment device (typically a card or smartphone) within the proximity of an EMV contactless-capable reader. The EMV standard, managed on behalf of the industry by EMVCo, allows cards and readers to be interoperable and used internationally.

EMV Payment Transaction

Covering payments as governed by EMV Integrated Circuit Card Specifications for payments systems consisting of American Express, Discover, JCB, Mastercard, Union Pay and Visa Inc.

Equipment Identity Register (EIR)

Provides a record for individual operators to prevent the use of stolen mobile devices and other banned equipment which is returned to a Central Equipment Identity Registers (CEIR) comprising a central database of IMEI numbers of ‘blacklisted’ handsets.

Form Factors This can cover a range of ‘devices’ and other ‘apparel wear’ and/or wearable variants including; mobiles, keys, fobs, stickers, watches etc.

Four Party Model

The issuer and acquirer are different entities, and this type of scheme is open for other institutions to join and issue their own cards. There are no limitations as to who may join the scheme, as long as the requirements of the scheme are met.

Global Platform

A non-profit association that operates the standard for managing applications on secure chip technology; maintaining the industry standard for end-to-end secure deployment and management solutions. For secure elements (SE) interoperability is achieved using the Global Platform standard.

HCE

Host Card Emulation (HCE) allows a mobile phone to act like a smart card and allows banks to launch NFC products without needing to make use of the SIM or other secure element. Allowing the mobile device operating system to communicate directly over the NFC interface. HCE is currently supported in Android KitKat 4.4, Blackberry OS 10 & Windows 10 Mobile

Higher Value Payments (HVP)

Any transaction exceeds the contactless limit (£30 at the time of writing) and must include customer verification. In the UK market this means this can only be made using a device that supports a method of customer authentication. This authentication process will take place on the customer device and may be through use of a passcode and/or biometric identifier (e.g. Fingerprint).

40

in-app payment

Application-based billing in this instance refers to a card payment, made in respect of any goods, services and/or in the acquisition of digital content, initiated as a result of a software application being resident on a PC, mobile phone, or other device (such as a tablet).

International Mobile Equipment Identity (IMEI)

International Mobile Equipment Identity (IMEI) is a 15-or-17 digit code that uniquely identifies mobile phone sets. The IMEI code can enable a GSM network to prevent a misplaced or stolen phone from initiating calls.

ISO 14443

The ISO standard for chip cards with contactless describing how contactless cards and terminals should work including several separate sections that consist of physical characteristics; radio frequency; signal interface; initialization; anti-collision; and transmission.

Issuer A Payment Service Provider that offers card associated branded payment cards directly to consumers.

Limited use keys See ‘Session Key’

Malware

The potential for smart devices to download applications containing malicious software (‘malware’) which may put consumers at risk incurring costs, or breaching data security, without their knowledge or consent.

Mobile-web browser payment

Where a card payment account can be used on the web embedding the JavaScript (JS) payment button into a merchants mobile web checkout, rather than the payment functionality only operating within the parameters of a previously downloaded app.

NFC

Near Field Communication (NFC) – a communication protocol as specified by ISO/IEC 18092, which allows contactless EMV devices to communicate with an EMV contactless capable reader.

Offline data authentication

The process by which transactions are authenticated between the terminal and the card. The type of ODA (either Static Data Authentication (SDA) or Dynamic Data Authentication (DDA)) as is supported by the card is indicated on the cards application interchange profile data element.

Operating system

Comprises software that communicates and operates computer hardware allowing programmes and applications to run and function.

Open API economy

Offers companies the ability to generate revenue by allowing software components to communicate with one another. As well as exposing the use of APIs as building blocks for 3rd party applications.

OTA connection

‘Over-the-air’ is a term that refers to services that can be assessed on a phone without the need for a USB cable or a local Bluetooth connection.

Out-of-band verification

Defines the processes where the payment verification process sits outside, and separate, to the rest of the buying experience. And usually differs based on the transaction environment. For physical proximity payments, inserting cards into readers, entering PINs are all practical examples. In the online space 3D Secure processes with the use of ‘pop-ups’ and keying of card information contrasts to the ‘one-click processes’ that are now commonplace.

Payment card account Where the funding account is linked to a prepaid, credit and/or debit card.

PCI-DSS

PCI-DSS is a global card payment security standard developed by the Payment Card Industry (PCI) Security Standards Council, and is presented as a set of six principles which encompass twelve specific requirements to which the international card schemes are responsible in managing the compliance programme. The standard applies to any organisations that stores, transmits or processes

41

cardholder information, including third party payment processors, merchants and acquirers.

PSP Payment Services Provider

Remote Payments

A payment made from a distance, without the buyer and seller being present at the same physical location, coming to denote transactions that can be bought and sold online.

Secure Element (SE)

A certified tamper-resistant platform capable of securely hosting applications and their confidential and cryptographic data (e.g. key management). Examples include universal integrated circuit cards (UICC), embedded secure elements, chip cards and secure digital cards.

Secure Hardware

A certified tamper resistant platform (either as held on a device or as a component part) and made capable of securely hosting applications and their confidential and cryptographic data (e.g. key management). Examples include universal integrated circuit cards (UICC), embedded secure elements, chip cards and secure digital cards.

Session key Relate to cryptographic keys that are made valid for one-off style transactions.

SIM

Subscriber Identification Module (SIM) is an integrated circuit that is intended to securely store the International Mobile Subscriber Identity (IMSI) number, and its related key which is used to identify and authenticate subscribers on mobile telephony devices.

SMS Short Messaging Service and more commonly referred to as a text message. Stored-Value-Account

A payments card with a monetary value stored on the card itself and not an external account maintained by a financial institution.

Token PAN The physical entity, or unique identification number, that substitutes the card PAN with a single-use or limited-use tokenised PAN.

Token Service Provider

An entity that is able to provide surrogate PAN values (i.e. payment tokens) to any registered token requestor.

Tokenisation The process of replacing sensitive data with surrogate values thereby significantly reducing the impact of card data breaches.

Tokenised payment credentials

The process by which a payment credential is tokenised enabling a EMV tokenised payment to be made. The TSP via access to the token vault can see the relationship between the original credential and all of its related tokens.

TPP A Third Party Payment processor that can potentially sit between the merchant and acquirer.

Transaction cryptogram generation

A cryptogram generated by the card following a transaction to validate the integrity of the transaction data.

Trusted Service Manager

Associated with SIM-SE NFC style payments. The role of any Trusted Service Manager is in acting as a neutral broker between MNOs, phone manufacturers and other entities controlling the secure element to enable service providers to distribute and manage contactless payment applications remotely, by allowing access to the secure element in NFC enabled handsets.

User Activation Code See ‘Device Activation Code’

42

Annex B: Card/ payment schemes Website Information The card/ payment schemes have websites that provide comprehensive details about the card services they offer and have dedicated sections for merchants that can provide additional help and guidance on accepting cards. American Express American Express’s website for merchant enquires Web form to apply to American Express to accept cards Diners Club Diners Club website for merchant enquiries Telephone: 0845 850 0195 JCB JCB Website MasterCard MasterCard’s website for merchant enquiries MasterCard’s SecureCode - details for merchants MasterCard’s Interchange Fees for Europe Visa Visa’s website for merchant enquiries Verified by Visa - details for merchants Visa’s Interchange Fees for Europe

https://www.americanexpress.com/uk/merchant/home/merchant_login.cgi

http://home3.americanexpress.com/uk/merchant/learn/form.asp?linknav=UK:Mer:Prospect:WorkingwithUs:OnlineForm

http://www.dinersclub.co.uk/en/contact/merchant.html

http://www.jcbcard.com/

http://www.mastercard.com/global/merchant/



http://www.visaeurope.com/en/businesses__retailers.aspx

http://www.theukcardsassociation.org.uk/wm_functions/fnc_get_document.asp?DocumentID=79&Filename=verifiedbyvisa_merchantdeploymentbestpractices.pdf

http://www.visaeurope.com/en/about_us/what_we_do/fees_and_interchange/interchange_fees.aspx

43

Annex C: Standard 70 Book 1 Payment Transaction Scenarios

44

45

46

Annex D: Card Industry Overview – Further Information Further general information on card acceptance can be found on The UK Cards Association website here: http://www.theukcardsassociation.org.uk/retailers/index.asp More specific information on contactless cards including transit and typical FAQs can be found here: http://www.theukcardsassociation.org.uk/contactless_transport/index.asp Visa Europe’s Operating Regulations are available online and the May 2015 update can be found here: www.visaeurope.com/media/images/veor_public%20v2-73-25288.pdf The implications of the other Card/ Payment Schemes Operating Regulations can be obtained by the Merchant speaking to their Acquirer.

http://www.theukcardsassociation.org.uk/retailers/index.asp

http://www.theukcardsassociation.org.uk/contactless_transport/index.asp

http://www.visaeurope.com/media/images/veor_public%20v2-73-25288.pdf

47

Annex E: Reference Document(s) A list of relevant and concurrent documentation that should be being cross-referred to include:

- Contactless Terminal User Interface for Europe and the UK [Version 1.6 – 31 January 2007]

- The UK Cards Association Mobile Contactless Steering Group [Version 0.3 – 22 March 2011]

- Mobile Contactless Steering Group – Mobile Payment User Experience [Version 1.0 – 31

January 2012]

- Mobile Contactless Steering Group – Standard 70 Transaction Types [Version 1.0 – 16 May 2012]

- White Paper: Requirements to Achieve Scalable Rollout of Mobile Contactless Payments in the UK [Version 1.0 - 3 August 2013]

- Report: Mobile Contactless Payments Specification Summary [Version 1.1 – 2 September 2013]

- HCE and SIM Secure Element – Discussion Paper from Consult Hyperion [June 2014]

- HCE and Tokenisation for Payment Services – Discussion Paper from Consult Hyperion/ GSMA [June 2014]

- The UK Cards Association – Host Card Emulation Best Practice [DRAFT, Version 0.3 – 6 July 2015]

- ERPB Final Report – Mobile and Card Based Contactless Proximity Payments [Version 1.1 – 5 November 2015]

- Standard 70 Book 1 – Card Acceptor to Acquirer Interface Standards – Business Rules for Card Processing [April 2017]