PCI Watch

Tracking changes across the Payment Card Industry

EMV® Payment Tokenisation – Use Case Submission Template

v2.0
Payment Tokenisation

EMV® Payment Tokenisation Use Case Submission Template Version DOCPROPERTY Version * MERGEFORMAT 2.0 DOCPROPERTY "Publication Month" * MERGEFORMAT November 2020

Legal Notice

You are invited to submit this form as part of your participation in the EMVCo Associates Programme or Subscriber Programme. Submissions to EMVCo through this form are subject to the terms of the EMVCo Associates Programme Participation Agreement or EMVCo Subscription Agreement you have with EMVCo, as applicable. Revision Log – Version 2.0 The following changes have been made to the document since the publication of version DOCPROPERTY "Previous Published" * MERGEFORMAT 1.0: Minor editorial changes throughout document Changes to REF _Ref508137352 h * MERGEFORMAT Table 2.1, REF _Ref54790477 h * MERGEFORMAT Table 3.1, REF _Ref54790479 h * MERGEFORMAT Table 4.1 to replace "Actor" with "Actor (Roles)" to match the Entity / Role convention introduced in Version 2.0 of "A Guide to Use Cases" Updated language in Section REF _Ref54790645 r h 3 REF _Ref54790648 h Use Case Token Request for Token-on-File (Example) to match the language in Use Case 4: Card-On-File E-Commerce in " A Guide to Use Cases " Updated the example flow in REF _Ref501374955 h Figure 3. 1 to match the style of example flow diagram in troduced in Version 2.0 of "A Guide to Use Cases" Updated the steps in REF _Ref54790477 h * MERGEFORMAT Table 3.1 to match the new example flow in REF _Ref501374955 h Figure 3. 1 Added a new Alternative Flow [2] in REF _Ref54790477 h * MERGEFORMAT Table 3.1 Contents TOC o "1-3" h z t "Heading Centered 16,1" Legal Notice PAGEREF _Toc55852065 h i Revision Log – Version 2.0 PAGEREF _Toc55852066 h ii Contents PAGEREF _Toc55852067 h iii Figures PAGEREF _Toc55852068 h iv Tables PAGEREF _Toc55852069 h v 1

Purpose

PAGEREF _Toc55852070 h 1 1.1 Process of Submission Using This Template PAGEREF _Toc55852071 h 1 2 Use Case Template with Description PAGEREF _Toc55852072 h 3 3 Use Case Token Request for Token-on-File (Example) PAGEREF _Toc55852073 h 5 4 Use Case Blank Template PAGEREF _Toc55852074 h 8 Figures TOC h z c "Figure" Figure 3.1: Payment Tokenisation Use Case Diagram Example PAGEREF _Toc55852082 h 7 Figure 4.1: Accompanying Diagram PAGEREF _Toc55852083 h 9 Tables TOC h z c "Table" Table 2.1: Use Case Template –

Description

PAGEREF _Toc55852089 h 3 Table 3.1: Use Case Template – Example of Token Request for Token-on-File PAGEREF _Toc55852090 h 5 Table 4.1: Use Case Template – Blank to be completed by submitter PAGEREF _Toc55852091 h 8 TOC h z c " Annex Table" Purpose EMVCo is committed to receiving feedback as part of its ongoing industry specification activities through its Associates and Subscriber programmes. From version 2.1 onwards of the EMV<sup>®</sup> Payment Tokenisation Specification – Technical Framework, a separate document EMV® Payment Tokenisation – A Guide to Use Cases (" A Guide to Use Cases ") has been published. This is an informational supplement describing relationship models, example flow s and use case examples common to the Technical Framework. These use case examples exist to show the extent and flexibility of the Technical Framework. The y are not intended to be exhaustive or represent all possible usage scenarios supported by the Technical Framework. A number of use cases described may vary by payment industry implementation and as a result cannot be fully described. This document, EMV® Payment Tokenisation – Use Case Submission Template, defines a template that enables submission of Payment Tokenisation Use Case(s) to EMVCo. Any such submission is performed under the Legal Notice contained in this document. A submission will be considered for inclusion dependent on its appropriateness: In meeting EMVCo’s remit and constraints To the payment tokenisation ecosystem In adding value for the global payment industry EMVCo reserves the right not to progress any use case submission and may adjust content as necessary to meet the above criteria. A use case submission that is considered suitable will be modified and adjusted to fit the style of the use cases in "A Guide to Use Cases " and included in a subsequent or future version of the document. Additional information may be requested on any use case submission to enable detailed understanding of the content. Process of Submission Using This Template A submission will follow th is process: Fully complete the template and provide an accompanying diagram: Explain the use case in sufficient detail for assessment by the Tokenisation Working Group Read and note the details of the acknowledgement statement at the end of the template Submit the completed template using the EMVCo query system available to all EMVCo Associates and EMVCo Subscribers, marking the query as relating to Payment Tokenisation Respond to subsequent questions and requests for further information on the proposed use case as requested by EMVCo Use Case Template with Description This section provides the u se c ase template for Payment Tokenisation and instructions to fill out the template. The areas of the template are coloured as follows: Blue: to be filled out by the submitter of a use case Green: to be filled out by the submitter on a revision to a previously submitted use case Grey: for EMVCo use Table STYLEREF 1 s 2. SEQ Table * ARABIC s 1 1: Use Case Template – Description Submission ID: EMVC

  • INTERNAL USE ONLY Use Case Name: [Enter a short name for the Use Case. e.g. Merchant Token-on-File] Filename: EMVC
  • INTERNAL USE ONLY Existing/New: [ An Existing Use Case is one which is already implemented or is about to be.] Version:

0.1 Submitted By: [Organisation Name] Date Submitted: YYYY-MM-DD Updated By: [Organisation Name] Comment: [Include the reason for the updated use case here. Version should always be old version number + 0.1 (if previous version 0.1, new version is 0.2)] Date Updated: YYYY-MM-DD Starting Version:

0.2 Updated By: [Organisation Name] Comment: [Include the reason for the updated use case here. Version should always be old version number + 0.1 (if previous version 0.2, new version is 0.3)] Date Updated: YYYY-MM-DD Updated Version:

0.3 Description: [Provide a brief description of the reason for and outcome of this use case.] Actors (Roles): [An actor is a person or other entity external to the system being specified who interacts with the system and performs use cases to accomplish tasks. Different actors often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the actor that will be initiating this use case and any other actors who will participate in completing the use case. Where possible, w hen an entity is performing a specific Payment Tokenisation role, please give the role in parenthesis after the actor. For example, when a Merchant is performing the role of a Token Requestor, it should be written as Merchant (Token Requestor). ] Preconditions: [List any activities that must take place, or any conditions that must be true, before the use case can be started.] Trigger: [Identify the event that initiates the use case. This could be an external business event or system event that causes the use case to begin, or it could be the first step in the normal flow.] Normal Flow: [Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. If there is a related diagram, please refer to it here.] Alternative Flow [x]: [Document legitimate branches from the main flow to handle special conditions (also known as extensions). For each alternative flow reference, include the branching step number of the normal flow and the condition which must be true in order for this extension to be executed.] Note: Insert a new row in the table for each distinctive alternative flow. Post conditions: [Describe the state of the system at the conclusion of the use case execution. This s hould include both minimal outcome s (what must happen even if the actor’s goal is not achieved) and the success outcome s (what happens when the actor’s goal is achieved.] Exceptions: [Describe any anticipated error conditions that could occur during execution of the use case and define how the system is to respond to those conditions.] Includes: [List any other use cases that are included (called) by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality.] Notes: [List any additional comments about this use case or any remaining open issues, special requirements (on security, performance, legal, etc.) or TBDs (To Be Determined) that must be resolved.] Diagram name: [ Accompanying diagram to be provided for the Normal Flow. ] Diagram Version:

0.1 Acknowledgement: By submitting this form, the submitter acknowledge s and a grees that there is no obligation on EMVCo to include a submission using this template in " A Guide to Use Cases ". The submitter further acknowledges and agrees that submissions are subject to the terms of the EMVCo Associates Programme Participation Agreement or EMVCo Subscription Agreement, as applicable. Use Case Token Request for Token-on-File (Example) Note that this example is Use Case 4: Card-On-File E-Commerce in "A Guide to Use Cases". Table STYLEREF 1 s 3. SEQ Table * ARABIC s 1 1: Use Case Template – Example of Token Request for Token-on-Fil e Submission ID: EMVCo INTERNAL USE ONLY Use Case Name: Token Request for Token-on-File Filename: TokenRequest_TokenOnFile Existing/New: Existing Version:

0.1 Submitted By: EMVCo TWG Date Submitted: 2019-05-09 Updated By: Comment: Date Updated: Starting Version: Updated By: Comment: Date Updated: Updated Version: Description: A Consumer making an e-commerce purchase from a Merchant using the Merchant e-commerce environment ( application or website). The Consumer adds a payment credential by enter ing a PAN and related data into the Merchant e-commerce environment. The Merchant then makes a Token Request, using the resulting Payment Token. The Payment Token is then stored by the Merchant and the PAN (represented by the Payment Token) can be selected by the Consumer during future purchases. Actors (Roles): Consumer (Cardholder) Merchant (Token Requestor) Token Service Provider ( TSP) Card Issuer (Card Issuer) Preconditions: M erchant must register with the TSP as a Token Requestor and have received a Token Requestor ID. The Merchant operates an e-commerce environment which can either be web-based or application-based The Consumer does not have an account with the Merchant and needs to create one before a payment credential can be added The PAN that the Cardholder adds to the account in the Merchant e-commerce environment is eligible for Tokenisation Trigger: The Consumer creates an account with the Merchant and then selects "add card" i n the Merchant e-commerce environment. Normal Flow: Please see accompanying diagram. Consumer creates an account in the Merchant e-commerce environment Merchant e-commerce environment confirms account creation Consumer selects add card to add a payment credential to the account, enter ing the PAN and related data into the Merchant e-commerce environment The Merchant e-commerce environment provides the PAN and related data to the Merchant The Merchant (Token Requestor) chooses not to store the PAN and related data and uses it to initiate a Token Request to the T SP (using its Token Requestor ID) TSP carr ies out Token Assurance and requests that the Card Issuer undertakes ID&V Card Issuer responds to the TSP with its ID&V success result TSP complete s Token Issuance based on Card Issuer approval A Payment Token and its related data are delivered to the Merchant (Token Requestor) as the response to the Token Request Merchant stores the Payment Token and its related data for Consumer’s future use The Merchant notifies the Merchant e-commerce environment that the payment credential is now available for the Cardholder’s future use Consumer receives the success notification Alternative Flow [1]: Merchant already has the Card - o n-File and decides to request a Payment Token on behalf of the Consumer. In this case, flow starts at Step 5 and ends on Step 10. N ote: In this example, the t rigger for alternative flow 1 will be the Merchant i nitiating a Token Request on behalf of the Consumer. Alternative Flow [2]: The Consumer already has an account with the Merchant and has accessed the account on the Merchant e-commerce environment. In this case, flow starts at Step 3 and continues as normal. N ote: In this example, the t rigger for alternative flow 2 will be the Consumer selecting to add a card in the Merchant e-commerce environment. Alternative Flow [ 3 ]: 3. Consumer uses camera on Consumer Device to capture the necessary information on the Payment Card using the Merchant e-commerce environment (in this case, a Merchant application on the Consumer D evice). The Merchant application then collects the required information and forwards it to the Merchant. Note: T his is an example of a different method to accomplish the goal of Step 3 in the Normal Flow. Alternative Flow [ 4 ]: The Card Issuer responds to the TSP with its ID&V failure result Does not happen Failure response sent to the Merchant as the response to the Token Request Does not happen Does not happen The Consumer receives the Failure notification N ote: This is an example of an exception which alters the Normal Flow. Post conditions: The Consumer receives either Add Card Success/Failure Notification, and if it is the Success case, the Payment Token can be used for Payment processing. Exceptions: The PAN is not eligible for Payment Tokenisation. Includes: No s pecific Use Case included. Notes: The alternate flows are not shown in the attached diagram. Diagram name: Payment Tokenisation use case diagram example for template. Diagram Version:

0.1 Acknowledgement: By submitting this form, the submitter acknowledge s and a grees that there is no obligation on EMVCo to include a submission using this template in " A Guide to Use Cases ". The submitter further acknowledges and agrees that submissions are subject to the terms of the EMVCo Associates Programme Participation Agreement or EMVCo Subscription Agreement, as applicable. Figure STYLEREF 1 s 3. SEQ Figure * ARABIC s 1 1: Payment Tokenisation Use Case Diagram Example Please note that EMVCo will accept diagrams in any format. The specific format used in this example is consistent with that used in A Guide to Use Cases and was produced using the free online service www.websequencediagrams.com. Other free, online flow sequencing services are available and there is no requirement to use the same service as EMVCo. Use Case Blank Template Table STYLEREF 1 s 4. SEQ Table * ARABIC s 1 1: Use Case Template – Blank to be complet ed by submitter Submission ID: EMVC

  • INTERNAL USE ONLY Use Case Name: Filename: EMVC
  • INTERNAL USE ONLY Existing/New: Version:

0.1 Submitted By: Date Submitted: Updated By: Comment: Date Updated: Starting Version: Description: Actors (Roles): Preconditions: Trigger: Normal Flow: Please see a ccompanying diagram. xxxx xxxx xxxx Alternative Flow [x]: Post conditions: Exceptions: Includes: Notes: Diagram name: Diagram Version: Acknowledgement: By submitting this form, the submitter acknowledge s and a grees that there is no obligation on EMVCo to include a submission using this template in " A Guide to Use Cases ". The submitter further acknowledges and agrees that submissions are subject to the terms of the EMVCo Associates Programme Participation Agreement or EMVCo Subscription Agreement, as applicable. Figure STYLEREF 1 s 4. SEQ Figure * ARABIC s 1 1: Accompanying Diagram [Insert Diagram Here] *** END OF DOCUMENT ***