EMV® Payment Tokenisation - A Guide to Use Cases

EMV® Payment Tokenisation A Guide to Use Cases Version 2.2.1 January 2023

Legal Notice

Page i / xii This document is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document.

/ xii Revision Log – Version 2.2.1 The following changes have been made to the document since the publication of version 2.2:

• Addition of new use case variation: Token Service Provider in the Issuer Domain (Section 9.4) i Revision Log – Version 2.2.1. 1. 1. 1. 1.4. 1. 1. 1.6. 1.6. 1. 2. 2. 2. 2. 2. 2.5. 2.5. 3. 3. 4.

4.1.1 A1.

4.1.2 A2

/ xii 4.1.3 A3.

4.1.4 A4.

4.1.5 A5.

4.1.6 A6.

4.1.7 B1.

4.1.8 B2.

4.1.9 B3

4.1. 4. 4. 5. 5.1.1 5.1.2 5.1.3 5.1.4 C1. C2. C3. 5. 6. 6.1.1 6.1.2 D1. D2. 6. 8. 8.1.1 8.1.2 8.1.3 8.1.4 8.1. 8.

8.2.1 Use Case Overview – Problems Addressed & User Experience... 34 8.2.

Page v / xii 8.2.3 8.2.4 8.2.5 8.2.6 8.2. 8. 8.3.1 8.3.2 8.3.3 8.3.4 8.3.5 8.3.6 8.3.7 Use Case Overview – Problems Addressed & User Experience... 8. 8.4.1 8.4.2 8.4.3 8.4.4 8.4.5 8.4.6 8.4.7 Use Case Overview – Problems Addressed & User Experience... 8. 8.5.1 8.5.2 8.5.3 8.5.4 8.5.5 8.5.6 8.5.7 Use Case Overview – Problems Addressed & User Experience... 8. 8.6.1 8.6.2 8.6.3 8.6.4 8.6.5 8.6.6 8.6.7 Use Case Overview – Problems Addressed & User Experience... 8.

8.7.1 Use Case Overview – Problems Addressed & User Experience... 78 8.7.

/ xii 8.7.3 8.7.4 8.7.5 8.7.6 8.7. 8. 8.8.1 8.8.2 8.8.3 8.8.4 8.8.5 8.8.6 8.8.7 Use Case Overview – Problems Addressed & User Experience... 9. 9.1. 9.1. 9. 9.2.1 9.2.2 9.2.3 9.2.4 9.2.5 9.2.6 9.2.7 Use Case Overview – Problems Addressed & User Experience. 9. 9.3.1 9.3.2 9.3.3 9.3.4 9.3.5 9.3.6 9.3.7 Use Case Overview – Problems Addressed & User Experience. 9. 9.4.1 9.4.2 9.4.3 9.4.4 9.4.5 Use Case Overview – Problems Addressed & User Experience.

/ xii 9.4. 9.4. 10. 10. 10. 10.3. 10.3. 10.3. 10. 10. 10.5.

10.5.2 Use Case Lifecycle Management Relationships and Functions.. 128 10.5. 10. 10.6.

10.6.2 Use Case Lifecycle Management Relationships and Functions.. 132 10.6. 10. 10.7.

10.7.2 Use Case Lifecycle Management Relationships and Functions.. 138 10.7. 11. 11.

11.2.1 Use Case Overview – Problems Addressed & User Experience

143 11.2. 11.2. 11.2. 11.2. 11.2. 11.2. 11.

11.3.1 Use Case Overview – Problems Addressed & User Experience

151 11.3. 11.3. 11.3. 11.3.

/ xii 11.3. 11.3. 11. 11.

11.5.1 Use Case Overview – Problems Addressed & User Experience

158 11.5. 11.5. 11.5. 11.5. 11.5. 12. 12.1. 12.1. 12. 12.2. 12.2.

/ xii Figures Figure 2. Figure 2. Figure 2. Figure 2. Figure 2. Figure 2. Figure 2. Figure 3. Figure 3. Figure 3. Figure 3. Figure 4. Figure 5. Figure 6. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8.8: In-Application using a Consumer Device – Example Transaction Flow. 58 Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 8. Figure 9. Figure 9. Figure 9. Figure 9. Figure 9. Figure 9. Figure 9.

Page x / xii Figure 9. Figure 9. Figure 9. Figure 9. Figure 10. Figure 10.2: Merchant Deletion of Payment Credential – Use Case Relationships 129 Figure 10. Figure 10. Figure 10. Figure 10. Figure 10. Figure 11. Figure 11. Figure 11. Figure 11. Figure 11. Figure 11. Figure 12. Figure 12. Figure 12. Figure 12.

/ xii Tables Table 1. Table 1. Table 4. Table 4. Table 5. Table 6. Table 7. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8.21: E-Commerce Guest Checkout – Token Presentment Characteristics... 73 Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8. Table 8.

/ xii Table 9. Table 9. Table 10. Table 10. Table 10. Table 10. Table 10. Table 11. Table 11. Table 11.3: SRC E-Commerce Transaction – Token Provisioning Characteristics 144 Table 11.4: SRC E-Commerce Transaction – Token Presentment Characteristics 145 Table 11.5: SRC E-Commerce Transaction – Token Processing Characteristics.. 145 Table 11. Table 11. Table 11. Table 11. Table 11. Table 11. Table 11. Table 11.

/ 174 1

Introduction

This document, EMV Payment Tokenisation – A Guide to Use Cases (referred to as “A Guide to Use Cases”), is an informational supplement to the EMV Payment Tokenisation Specification – Technical Framework, (referred to as the “Technical Framework”). It describes relationship models and use case examples common to the Technical Framework and is intended to be read in conjunction with the Technical Framework. The Technical Framework describes a common baseline set of roles and associated functions for Payment Tokenisation that can be adopted to meet the unique payment ecosystem requirements of international, regional, national or local implementations. 1.1

Scope

A Guide to Use Cases describes a limited number of use case examples, some of which are based on established EMV-defined technology:

• Proximity at Point of Sale (Section 8.2)
• Online Wallet (Section 8.3)
• In-Application using a Consumer Device (Section 8.4)
• Card-On-File E-Commerce (Section 8.5)
• E-Commerce Guest Checkout (Section 8.6)
• Third Party Service Provider (Section 8.7) Section 9 Use Case Variations provides some potential differences and variations to these initial use cases:
• Payment Tokenisation Aggregator (Section 9.1)
• Bulk Token Request (Section 9.2)
• Token Reference IDs (Section 9.3)
• Token Service Provider in the Issuer Domain (Section 9.4) Section 10 Payment Tokenisation Lifecycle Management describes Payment Token lifecycle management events and provides a limited number of lifecycle management use case examples:
• Merchant Deletion of Payment Credential (Section 10.5)
• Lost / Stolen Consumer Device (Section 10.6)
• PAN Replacement (Section 10.7) / 174 Section 11 Payment Tokenisation and Other EMV Technologies provides use case examples involving Payment Tokenisation and other EMV Technologies:
• SRC E-Commerce Transaction (Section 11.2)
• SRC Guest Checkout Section (11.3)
• Card-On-File E-Commerce with EMV 3DS Payment Authentication Section (11.5) Section 12 Payment Account Reference describes how Payment Account Reference (PAR) can link transactions made using both Payment Tokens and PAN and provides a limited number of use case examples:
• Transit Open Loop Payments (Section 12.1)
• Merchant Loyalty Schemes Section (12.2) 1.2 Overview A Guide to Use Cases introduces relationship models which describe potential relationships between the Payment Tokenisation roles. Various common use case examples are given, which include unique relationship models for each use case and example flows for the Issuance of a Payment Token and for transactions. The relationship models and use case examples presented are intended to provide guidance for Payment Tokenisation within existing payment ecosystems and the considerations associated with various usage scenarios. The relationship models and use case examples are neither definitive nor exhaustive since the associated usage scenarios may require additional considerations not provided here. The guidance provided in A Guide to Use Cases does not supersede the Technical Framework or policies and processes defined by a Token Programme. The relationship models are introduced in the following sections:
• Section 2 Token Programme Participants introduces the Token Programme Participants which feature in the relationship models
• Section 3 Relationship Model Descriptions introduces the basic relationship model, including how the Token Programme Participants fit into the models along with existing payment ecosystem participants such as Merchants
• The basic relationship model is described in more detail in the following sections. Each provides a detailed look at how the relationship model applies to specific common functions. Each model describes the specific relationships between the potential Token Programme Participants, describing the relationship itself and its function
• Section 4 Token Issuance and Token Provisioning
• Section 5 Token Presentment
• Section 6 Token Processing / 174
• Section 7 Payment Token Characteristics describes the characteristics of a Payment Token and how they might be determined for a specific use case The remainder of A Guide to Use Cases describes specific use case examples as follows:
• Section 8 Use Case Examples takes the detailed relationship models from Sections 4, 5 and 6 and applies them to specific use cases. Each use case example has a specific example of a Token Issuance / Token Provisioning flow (issuance flow) and a Token Presentment / Token Processing flow (transaction flow). These flows are based on defined preconditions, setup activities and other flow assumptions
• Section 9 Use Case Variations takes the detailed relationship models from Sections 4, 5 and 6 and shows how they may vary depending on the particular use case variation
• Section 10 Payment Tokenisation Lifecycle Management shows how the relationship model applies to lifecycle management. It describes how existing relationships between the potential Token Programme Participants are used for lifecycle management and the function(s) of those relationships
• Section 11 Payment Tokenisation and Other EMV Technologies shows how Payment Tokenisation can be used with other EMV Technologies, such as Secure Remote Commerce (SRC) and EMV® 3-D Secure (EMV 3DS). It describes how Payment Tokenisation roles map to entities / functions in the other EMV Technology
• Section 12 Payment Account Reference provides examples of how Payment Account Reference (PAR) can link transactions made using both Payment Tokens and PAN 1.3 Audience A Guide to Use Cases is intended for use by all participants in the payment ecosystem, such as Card Issuers, Merchants, Acquirers, Payment Systems, Payment Networks, Payment Processors, and third-party service providers. 1.4

References

The latest version of any reference, including all published amendments, applies unless a publication date is explicitly stated.

1.4.1 Published EMVCo Documents The documents in Table 1.1 contain provisions that are referenced in this guide and are available from www.emvco.com.

/ 174 Reference Table 1.1: EMVCo References Publication Name EMV 3DS EMV® 3-D Secure – Protocol and Core Functions Specification EMV Contactless EMV® Contactless Specifications for Payment Systems PAR White Paper EMV® White Paper on Payment Account Reference QR Code EMV® QR Code Specification for Payment Systems (EMV QRCPS) – Merchant-Presented Mode SRC EMV® Secure Remote Commerce Specification Technical Framework EMV® Payment Tokenisation Specification – Technical Framework Transaction Types EMV® Best Practices Document – Recommendations for EMV Processing for Industry-Specific Transaction Types 1.5

Definitions

For a list of defined terms used in A Guide to Use Cases, please refer to Table 1.3 in Section 1.5 of the Technical Framework.

1.6 Notational Conventions 1.6.1 Abbreviations The abbreviations listed in Table 1.2 are used in A Guide to Use Cases. Abbreviation ACS API AReq ARes Table 1.2: Abbreviations

Description

Access Control Server Application Programming Interface Authentication Request Authentication Response

/ 174 Abbreviation CDE DS ICC ID&V MST NFC PAN PAR PCI PCI DDS POS QR SDK Description Cardholder Data Environment Directory Server Integrated Circuit Card Identification and Verification Magnetic Secure Transmission Near Field Communication Primary Account Number Payment Account Reference Payment Card Industry Payment Card Industry Data Security Standard Point Of Sale Quick Response Software Development Kit 1.6.2 Terminology and Conventions A Guide to Use Cases uses the following words which have a specific meaning: Assumptions Assumptions for a given example flow are specific to that example flow, but not the wider use case. Different assumptions are part of the same use case but would refer to a different example flow. Consumer / Cardholder The terms Consumer and Cardholder are defined terms, as defined in the Technical Framework. They are used here in the following way. A Consumer may have access to multiple payment credentials (representing underlying Payment Accounts). Each use case flow begins with an interaction involving a Consumer. Whenever a Consumer selects a specific payment credential (represented by a PAN), the Consumer then assumes the role of the Cardholder for the remainder of that use case.

/ 174 Entity (Role) When an entity is performing a specific Payment Tokenisation role, this is denoted by writing the role in parenthesis after the entity. For example, when a mobile payment application is performing the role of a Token Requestor, it is written as mobile payment application (Token Requestor). Preconditions Preconditions for a given example flow are those which must occur in order for the use case to exist. Usage Scenario A specific instance of Technical Framework usage that has common, distinct characteristics such as technologies used, Token Presentment Mode utilised, etc. This is usually representing the presentment, acceptance and intended payment offering to Consumers/Cardholders in the ecosystem. Relationship Model A construct that describes relationships between each specific Payment Tokenisation role and describes the common set of functions. Use Case A specific example of utilisation of the Technical Framework within a usage scenario, showing specifics of relationships and interactions between Payment Tokenisation roles. It includes an example issuance flow showing Token Issuance / Token Provisioning and an example transaction flow showing Token Presentment / Token Processing.

1.7 Further Information Additional Payment Token information can be found at www.emvco.com.

/ 174 2 Token Programme Participants The Token Programme has an overarching responsibility, defining the processes, policies and registration programmes for the establishment and operation of a Payment Tokenisation ecosystem. Token Programme support of a usage scenario will include policies and processes to support the specifics of each use case. Each Token Programme may support some or all of the use cases contained within A Guide to Use Cases, as well as support use cases not described here. Figure 2.1 provides an overview of the Payment Tokenisation ecosystem. Figure 2.1: Payment Tokenisation Ecosystem Overview 2.1 Card Issuers A Token Programme includes participation of one or more Card Issuers. A Card Issuer that supports multiple Payment Systems may participate in multiple Token Programmes. This is illustrated in Figure 2.2, which shows an example of Card Issuers participating in one or more Token Programmes and interacting with one or more Token Service Providers. Card Issuer 2, which is shown in green, participates in both Token Programme A and Token Programme B, whereas Card Issuer 1 only participates in Token Programme A.

/ 174 Card Issuers that participate in multiple Token Programmes for a given use case will support the policies, processes and registration programmes of each Token Programme for that use case. Figure 2.2: Card Issuers 2.2 Token Service Providers The Technical Framework supports a variety of ways for Token Service Providers to participate in a Token Programme. The participation of a Token Service Provider or multiple Token Service Providers is subject to the policies of the Token Programme. Token Service Providers may provide support to a single or multiple Card Issuer(s) and participate in one or more Token Programmes. This is illustrated in Figure 2.3, where Token Service Provider 1, which is shown in green, participates in both Token Programme A and Token Programme B, whereas Token Service Provider 2 only participates in Token Programme B.

Figure 2.3: Token Service Providers

/ 174 2.3 Token Requestors Token Requestors may support a wide variety of use cases and may have a variety of relationships with Token Service Providers. Each Token Service Provider registers Token Requestors in accordance to the established processes of each Token Programme. Token Requestors may participate in one or more Token Programmes. This is illustrated by Token Requestor 2 (shown in green in Figure 2.4), which particpates in both Token Programme A and B whereas Token Requestor 1 and 3 only particpate in a single Token Programme (A and B respectively). This provides one example of the possible relationships between Token Service Providers and Token Requestors. For purposes of simplicity, the Card Issuers shown in Figure 2.3 have not been included in Figure 2.4.

Figure 2.4: Token Requestors

/ 174 2.4 Token Users The Token User is a Payment Tokenisation specific role. Token Users initiate Token Payment Requests with Payment Tokens which have been received from Token Requestors. The Token User will have a relationship with one or more Token Requestors. Token Requestors may define requirements for the use of Payment Tokens which they provide to Token Users. An example of the possible relationships between Token Users and Token Requestors is shown in Figure 2.5. In this figure, Merchant A is shown in green and participates in two distinct Token Programmes. When participating in Token Programme A, Merchant A interacts with Token Requestor 1 as Token User 1, while the same Merchant A interacts with Token Requestor 3 as Token User 6 when participating in Token Programme B. A second relationship example is illustrated by Merchant C, which is shown in grey. Merchant C only participates in Token Programme A, but interacts with two Token Requestors. It

/ 174 interacts with Token Requestor 1 as Token User 3 and with Token Requestor 2 as Token User 4. Figure 2.5: Token Users

/ 174 2.5 Payment Tokenisation Aggregators The Payment Tokenisation Aggregator is a Payment Tokenisation specific role. Payment Tokenisation Aggregators interact with one or more Token Service Providers in order to facilitate some or all Payment Token related activities by acting as a service provider on behalf of one or more Payment Tokenisation roles or existing ecosystem entities. The Technical Framework identifies the following specific types of Payment Tokenisation Aggregator. These are:

• Token Requestor Aggregator
• Card Issuer Aggregator 2.5.1 Token Requestor Aggregators Figure 2.6 shows several possible relationships. Token Requestor Aggregator 1 is shown in blue and only participates in Token Programme A, interacting with Token Requestors and Token Service Providers that are only participating in Token Programme A. Similarly, Token Requestor Aggregator 3 is shown in grey and only participates in Token Programme B, interacting with Token Requestors and Token Service Providers that are only participating in Token Programme B. In contrast, Token Requestor Aggregator 2 is shown in green and participates in both Token Programme A and B. When Token Requestor Aggregator 2 is interacting with Token Service Provider 1, it is participating in Token Programme A, while when interacting with Token Service Provider 2, it is participating in Token Programme B. In this example, Token Requestor Aggregator 2 is interacting with Token Requestor 3 in both these cases, with Token Requestor 3 participating in both Token Programme A and B. In addition, Figure 2.6 shows Token Service Provider 1 interacting directly with Token Requestor 1, while it interacts with Token Requestor 2 through Token Requestor Aggregator 1 (blue) and with Token Requestor 3 through Token Requestor Aggregator 2 (green). In contrast, Token Service Provider 2 only interacts with Token Requestors through Token Requestor Aggregators. / 174 Figure 2.6: Token Request Aggregators 2.5.2 Card Issuer Aggregators Figure 2.7 shows several possible relationships. Card Issuer Aggregator 1 is shown in blue and participates in Token Programme A, only interacting with Card Issuers and Token Service Providers that are participating in Token Programme A. Similarly, Card Issuer Aggregator 3 is shown in grey and participates in Token Programme B, only interacting with Card Issuers and Token Service Providers that are participating in Token Programme B. In contrast, Card Issuer Aggregator 2 is shown in green and participates in both Token Programme A and B. When Card Issuer Aggregator 2 is interacting with Token Service / 174 Provider 1, it is participating in Token Programme A, while when interacting with Token Service Provider 2, it is participating in Token Programme B. In this example, Card Issuer Aggregator 2 is interacting with Card Issuer 3 in both these cases, with Card Issuer 3 participating in both Token Programme A and B. In addition, Figure 2.7 shows Token Service Provider 1 interacting directly with Card Issuer 1, while it interacts with Card Issuer 2 through Card Issuer Aggregator 1 (blue) and with Card Issuer 3 through Card Issuer Aggregator 2 (green). In contrast, Token Service Provider 2 only interacts with Card Issuers through Card Issuer Aggregators. Figure 2.7: Card Issuer Aggregators / 174 3 Relationship Model Descriptions The introduction of Payment Tokenisation into an existing payment ecosystem requires consideration of usage scenarios. Within each Token Programme, many functions may be common across usage scenarios. These common functions are associated with processes that are grouped as follows:
• Token Issuance and Token Provisioning
• Token Presentment
• Token Processing Each process is comprised of functions performed in usage scenarios that may be applied as guidelines for use case examples (for a definition of usage scenarios and use cases, see Section 1.6.2 Terminology and Conventions). Not all processes may be present in any given usage scenario or use case example. The Technical Framework identifies a number of roles within the Payment Tokenisation ecosystem that carry out these functions and processes. Some are existing roles within the traditional payment ecosystem, and others are Payment Tokenisation specific roles defined by the Technical Framework. A Guide to Use Cases introduces a number of examples showing models demonstrating relationships between roles associated with Payment Tokenisation that represent the potential processes and functions performed. Some existing relationships are utilised by Payment Tokenisation, while others are specific to Payment Tokenisation. Each relationship is managed in accordance with the policies, processes and registration programmes of a specific Token Programme. Each example relationship model has a number of characteristics which have typical outcomes associated with specific use cases.

3.1 Relationship Model Diagram Figure 3.1 displays all relationship models in a single diagram (for a definition of relationship model, see Section 1.6.2 Terminology and Conventions). These represent the various processes, showing the potential placement of the various Payment Tokenisation roles within the Payment Tokenisation ecosystem. This diagram represents a common configuration for Payment Tokenisation roles and their relationships by identifying the roles as boxes and relationships as lines. Note that not all roles and relationships may be present in any given usage scenario.

/ 174 Figure 3.1: Payment Token Ecosystem Relationship Model Token Programme Consumer C Card Issuer Cardholder A A B CA A Merchant Token User Authorised Entity A Token A C Requestor B Token Service Provider D Existing Payment D Ecosystem Entities (Authorisation) A Token Issuance B Token Provisioning C Token Presentment D Token Processing This diagram establishes a baseline representation which is the basis for the more detailed relationship model diagrams introduced in the following sections:

• Section 4 Token Issuance and Token Provisioning
• Section 5 Token Presentment
• Section 6 Token Processing / 174 3.2 Understanding the Relationship Model Diagram In Section 3.1 Relationship Model Diagram, the single diagram in Figure 3.1 gives all potential relationships between the various Payment Tokenisation roles within the Payment Tokenisation ecosystem. Where applicable, known entities that commonly perform the Payment Tokenisation role are included. Sometimes an additional, inner box is present within a larger, outer box. This occurs when an entity performs a specific role at some point during the process. For example, Figure 3.2 shows the Merchant / Token User. This is an example of a Merchant (shown by the outer box) performing the Payment Tokenisation role of Token User (shown by the inner box). When this is described in any text accompanying the figure, it is written as Merchant (Token User). Figure 3.2: Example Roles Merchant Token User The lines in Figure 3.1 represent relationships between entities/roles and not flows. Relationships can exist between entities, between roles and between entities and roles. These are denoted by the lines in the relationship diagrams, which may join the outer boxes or the inner boxes, depending on the precise relationship being described. For example, Figure 3.3 shows the relationship between the Cardholder (not the Consumer) and the Card Issuer. Figure 3.3: Example Relationships Consumer Card Issuer Cardholder A In certain relationship model diagrams, both a Token Requestor and a Token User are shown surrounded by a dashed line. This indicates that in certain use case examples, both roles can be present, while in other use cases, only the Token Requestor role is present. An example is given in Figure 3.4, where both the Token User and the Token Requestor are shown, with a Merchant performing the role of Token User and an Authorised Entity performing / 174 the role of Token Requestor. The relationship shown between the Token User and Token Requestor will not be present in use case examples which do not have a Token User. Figure 3.4: Token User Example Merchant Token User Authorised Entity A Token Requestor / 174 4 Token Issuance and Token Provisioning Token Issuance and Token Provisioning occurs after Token Generation in response to a Token Request from a registered Token Requestor with a valid Token Requestor ID. Considerations for the issuance of Payment Tokens include policies and processes for Token Assurance, Token Generation, Token Issuance, and Token Provisioning. This includes any implications of specific technologies and processes.

4.1 Token Issuance and Token Provisioning Relationships and Functions The possible relationships for Token Issuance and Token Provisioning are shown in Figure 4.1 and are dependent on the specific usage scenario. Not all relationships may be present in any given usage scenario. Note that the relationships in the figure do not imply flows between the entities shown and the numbers do not represent any specific order. Each relationship and how it may be utilised within Payment Tokenisation is described in the text following the figure, along with its function. Figure 4.1: Token Issuance (A) and Token Provisioning (B) Relationships A Token Issuance B Token Provisioning Consumer Card Issuer Cardholder A6 A2 Merchant Token User B2 A1 Authorised Entity Token B1 A3 Requestor A4 B3 A5 Token Service Provider

/ 174 Note that certain relationships only apply to a limited number of use cases, while other relationships do not vary by use case (although they are not necessarily present in all use cases). These instances are noted in the individual relationship descriptions.

4.1.1 A1

Cardholder – Authorised Entity (Token Requestor) Relationship: The Cardholder may have an existing relationship with the authorised entity (Token Requestor) which can be utilised for Payment Tokenisation. Function: The Cardholder provides a PAN and related data to the authorised entity (Token Requestor) which triggers the Token Issuance Process. How the PAN and related data are provided depends on the Use Case. The authorised entity (Token Requestor) may involve the active participation of the Cardholder in Token Assurance as described in the Technical Framework, Section 6 Token Assurance Method. There are many Token Assurance Method variations possible within a use case and any Cardholder interaction for performing ID&V is outside the scope of the use case examples.

4.1.2 A2

Cardholder – Merchant (Token User) This relationship only applies when the Merchant is performing the role of Token User (see Section 8.7 Third Party Service Provider). Relationship: The Cardholder may have an existing relationship with the Merchant (Token User) which can be utilised for Payment Tokenisation. Function: The Cardholder provides a PAN and related data to the Merchant (Token User) which triggers the Token Issuance Process. How the PAN and related data are provided depends on the Use Case.

4.1.3 A3

Merchant (Token User) – Authorised Entity (Token Requestor) This relationship only applies when the Merchant is performing the role of Token User (see Section 8.7 Third Party Service Provider). Relationship: The Merchant (Token User) has an existing relationship with the authorised entity (Token Requestor) which can be utilised for Payment Tokenisation. Function: The Merchant (Token User) provides a PAN and related data to the authorised entity (Token Requestor), which triggers the Token Issuance process.

4.1.4 A4

Token Service Provider – Authorised Entity (Token Requestor) Relationship: The Token Service Provider provides Token Issuance services to the authorised entity (Token Requestor) on behalf of a Card Issuer. For each Token Request, the authorised entity (Token Requestor) identifies itself using the applicable registered Token Requestor ID assigned by the Token Service Provider.

/ 174 Function: The authorised entity (Token Requestor) initiates a Token Request with its assigned Token Requestor ID, using a PAN and related data.

4.1.5 A5

Card Issuer – Token Service Provider This relationship does not vary by use case. Relationship: The Card Issuer uses the Token Service Provider to provide Token Issuance and Token Provisioning services to Token Requestors. Function: The Token Service Provider may involve the Card Issuer in Token Assurance. For all issuance flows, it is assumed that the Card Issuer is performing ID&V as part of Token Assurance.

4.1.6 A6

Card Issuer – Cardholder This relationship does not vary by use case. Relationship: The existing Card Issuer – Cardholder relationship is utilised for the issuance of Payment Tokens. Function: The Card Issuer may involve the Cardholder in Token Assurance but any Cardholder interaction for performing ID&V is outside the scope of the use case examples.

4.1.7 B1

Token Service Provider – Authorised Entity (Token Requestor) Relationship: The Token Service Provider provides Token Provisioning services to the authorised entity (Token Requestor) on behalf of a Card Issuer. Function: After Token Issuance, the Token Service Provider delivers the Payment Token and related data to the authorised entity (Token Requestor), which, subject to the use case, either stores it in the Token Location or delivers it to the Token Location.

4.1.8 B2

Cardholder – Authorised Entity (Token Requestor) This relationship only applies to the Proximity at Point of Sale (Section 8.2) and In-Application using a Consumer Device (Section 8.4) use cases. Relationship: The authorised entity (Token Requestor) extends Token Provisioning services to the Cardholder. Function: The authorised entity (Token Requestor) delivers the Payment Token and related data to the Token Location.

4.1.9 B3

Merchant (Token User) – Authorised Entity (Token Requestor) This relationship only applies when the Merchant is performing the role of T