3-D Secure Protocol and Core Functions Specification – Browser-based
EMV®* 3-D Secure 2.0 Protocol and Core Functions Specification—Browser-based November 2015 * EMV is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification © 2009-2015 EMVCo, LLC (“EMVCo”). All rights reserved. Any and all uses of these Specifications is subject to the terms and conditions of the EMVCo Terms of Use agreement available at www.emvco.com. These Specifications are provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of these Specifications 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 these Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications 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 these Specifications 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 these Specifications.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification Revision Log—Version x.x The following changes have been made to XXX since the publication of Version XXX. Some of the numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins. The numbering of existing requirements did not change, unless explicitly stated otherwise. Incorporated changes described in the following Specification Updates: Other editorial changes: November 2015
©
http://www.emvco.com/specifications.aspx.
Revision Log—Version x.x EMV 3-D Secure 2.0 Protocol and Core Functions Specification
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2. 1. 3. 3.1. 3.1. 3. 3. 3.3. 3.3. 3.3. 3.3. 3.3. 3.3. 3.3. 3.3. 3.3. 3.3. 3. 3.4. 3.4. 3.4. 3.4. 3.4. 3.4. 3.4. 3.4. 3.4. 3.4. 3.4. 3.4. November 2015 Page v ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 3.4. 4. 4. 4.2. 5. 5.1. 5.1. 5. 5. 5.3. 5. 5.4. A. A. A.2.1 A.2.2 A.2.3 A.2. A. A.3.1 A.3.2 A.3.3 A.3. B. B. B. B. B.4. B.4.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification B. B. B.6.1 B.6.2 B.6.3 B.6.4 B.6.5 B.6.6 B.6. B. B.7.1 B.7.2 B.7.3 B.7.4 B.7. B. B.8.1 B.8.2 B.8.3 B.8. B. B.9.1 B.9.2 B.9.3 B.9. B. B.10. B.10. B.10. B.10. B. B.11. B.11. B.11. B.11. B. B.12. B.12. B.12. November 2015
©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification B.12. B. B.13. B.13. B.13. B.13. B. B.14. B.14. B.14. B.14. B.14.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification Figures Figure 3.1: Figure 3.2: Figure 4.1: Figure 4.2: Figure 5.1: Figure 5.2: Figure 5.3: Figure 5.4: Figure 5. Browser Options—Illustration of a Browser with a Lightbox UI format... Sample Knowledge Based Authentication User Interface (UI) Template46 November 2015
©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification Tables Table 5. Table A. Table A. Table A. Table A. Table A. Table B. Table B. Table B. Table B. Table B. Table B. Table B. Table B. Table B. Table B. Table B. Page x November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 1 Introduction 1.1 Document Organisation 1 Introduction 1.1 Document Organisation This document introduces the high-level concepts related to 3-D Secure 2.0 for browser-based authentication. It is not the 3-D Secure 2.0 specification in its entirety. This abbreviated document version includes: Chapter 3, Authentication Flows and Usage Scenarios (High Level)— introduces the two 3-D Secure authentication message flows. Chapter 4, Authentication Flow Requirements—describes in detail the main 3-D Secure authentication message flows. Chapter 5, Setup Overview—provides an overview of setup and configuration activities for entities to participate in 3-D Secure transactions. Annex A, 3-D Secure Field Descriptions—provides an alphabetically sorted list of the fields in the core 3-D Secure 2.0 messages applicable to browser, including field descriptions, name value pair (NVP), and in which messages the fields are present. Annex B, Message Descriptions—provides complete descriptions for each message, indicating which fields are included, conditions for inclusion, and order of fields in the messages, edit criteria, and field validation information. Future Versions: Currently, the 3-D Secure 2.0 Protocol and Core Functions Specification draft is split into two documents: Application-Based and Browser-Based. The 3DS TF is still working to determine the optimal layout of the final 3DS 2.0 specification and therefore the current layout might change. Note: As this document includes only excerpted chapters, some cross-references may be incomplete. November 2015
©
http://www.emvco.com/specifications.aspx.
2 Systems and Functional Overview 1.1 Document Organisation EMV 3-D Secure 2.0 Protocol and Core Functions Specification 2 Systems and Functional Overview This page intentionally left blank.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 3 Authentication Flows and Usage Scenarios Protocol and Core Functions Specification 3.1 Introduction to the 3-D Secure Flows 3 Authentication Flows and Usage Scenarios This chapter provides a high level introduction to the two 3-D Secure payment authentication flows: Frictionless Flow Challenge Flow In addition, it introduces the 3-D Secure messages that support the two flows.
3.1 Introduction to the 3-D Secure Flows 3.1.1 Frictionless Flow The 3-D Secure protocol enables more data to be passed between Merchants and Issuers to support enhanced risk-based decision making, thus minimising the necessity for a challenge authentication. Cardholders' device data and payment information is gathered by the Frictionless Flow so that a risk-based decision can be made to authenticate the Cardholder. The Frictionless Flow reduces Cardholder friction by integrating the authentication process seamlessly within the Merchant checkout. The Cardholder's experience, in this scenario, is to make a purchase in the Merchant's website and receive a successful confirmation from the Merchant. By definition, the Frictionless Flow does not require any additional Cardholder interaction during the purchase. The Frictionless Flow is the foundational flow that will always initiate a 3-D Secure authentication flow and will complete the authentication process, unless a challenge authentication is requested.
3.1.2 Challenge Flow During the execution of the Frictionless Flow, if the Access Control Server (ACS) recognises a situation that requires a challenge for the authentication, the Frictionless Flow transitions into the Challenge Flow using a specific challenge method. The reason that a challenge may be deemed necessary can be, for example, because the payment is deemed high risk, above certain thresholds, or there are country mandates (or regulations) in place. Merchants have the final decision on whether to let the ACS process the challenge or to terminate the authentication process and complete the transaction without authentication. Only when a challenge is requested by the Issuer, is the 3-D Secure user interface (UI) displayed to the Cardholder. November 2015
©
http://www.emvco.com/specifications.aspx.
2 Systems and Functional Overview 3.2 Authentication Messages EMV 3-D Secure 2.0 Protocol and Core Functions Specification 3.2 Authentication Messages The following are the messages defined for 3-D Secure: Authentication Request Message (AReq)—the initial message from the Merchant Integrator (MI) Server, requesting authentication of the Cardholder and providing payment, Cardholder, and device information for the transaction. There is only one AReq message per transaction. Authentication Response Message (ARes)—the ACS response to the AReq, indicating either that the Cardholder has been authenticated (success/fail), or that further information is required to authenticate the Cardholder (challenge). There is only one ARes message per transaction. Challenge Request Message (CReq)—the MI’s request for further processing to authenticate the Cardholder in a Challenge Flow. If the authentication is not completed with the ARes message, a CReq message (one per transaction), initiates the multiple back-and-forth attempts that may be required between the ACS and the Cardholder to complete authentication of the Cardholder. Challenge Response Message (CRes)—the ACS response to the CReq, indicating the ACS has made a determination and the merchant can close the 3DS authentication window Results Request Message (RReq)—sent by the ACS through the Directory Server (DS) to the MI Server, to transmit the results of the authentication to the MI Server. Results Response Message (RRes)—sent by the MI Server through the DS to the ACS, to acknowledge receipt of the RReq message. Preparation Request Message (PReq)—sent from the MI Server to the Directory Server to request the ACS version corresponding to the DS card ranges as well as an optional Browser ID URL—if one exists, in order to update the MI Server’s internal storage information. Preparation Response Message (PRes)—sent from the Directory Server to the MI Server in response to the PReq message. It is used to provide a list of the ACS version corresponding to the DS card ranges, as well as the Browser ID URL—if one exists, in order to update the MI Server’s internal storage information. Error Message—this message is used to provide additional information about an error that occurred during message processing between MI Server, DS, and ACS. For more information: Annex A contains descriptions for each message field.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 3 Authentication Flows and Usage Scenarios Protocol and Core Functions Specification 3.3 Frictionless Flow Overview Annex B contain message format and content information.
3.3 Frictionless Flow Overview In the Frictionless Flow, the ACS makes an authentication decision on the transaction using the information that is received in the AReq and from optional Browser Identification. No additional information or interaction with the Cardholder is needed to complete the authentication. The Frictionless Flow contains the following Steps: Note: The MI server shall make a call to registered DS servers every 24 hours at a minimum and store the results for use in subsequent 3DS transactions. Start of Purchase: The Cardholder initiates a purchase transaction using a Merchant website/Payment Solution Provider. Step 1: The Merchant Server initiates communications with the MI Server. Note: This may pass through other Merchant Environment components depending on implementation. Step 2: The MI Server determines ACS version and obtains the optional Browser ID URL. Step 3: The 3DS Method on the Merchant checkout page loads the Browser ID URL if present and captures necessary 3DS data that is entered by the Cardholder at checkout. Step 4: The Merchant server initiates communications with the MI Server. Step 5: The MI Server sends an AReq message to the DS which then routes the message to the appropriate ACS. Step 6: The ACS returns an ARes message to the DS which then routes the message to the MI Server. Step 7: The MI Server returns the response to the calling system with the appropriate data. Note: 3-D Secure processing ends here. Step 8: The Merchant proceeds with authorisation exchange with its Acquirer. Step 9: Payment Authorisation. November 2015
©
http://www.emvco.com/specifications.aspx.
2 Systems and Functional Overview 3.3 Frictionless Flow Overview EMV 3-D Secure 2.0 Protocol and Core Functions Specification Figure 3.1: Frictionless Flow Note: The MI Server has the ability to utilize a call to the DS using the PReq (Preparation Request) message to receive and store data about specific card ranges such as the ACS version as well as the Browser ID URL, if one exists. The contents shall expire and be refreshed at least every 24 hours.
3.3.1 Start of Purchase: Cardholder and Merchant Website/Payment Solution Provider The Cardholder initiates a purchase transaction on a Merchant website while using a web browser. During the checkout process, the Cardholder Account Number and other account details, and shipping and billing information, are typically provided to the Merchant either by Cardholder keyboard entry or these details are on file with the Merchant. While confirming the purchase, this information and the shopping cart details are available for the Merchant to include in the authentication request.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 3 Authentication Flows and Usage Scenarios Protocol and Core Functions Specification 3.3 Frictionless Flow Overview 3.3.2 Step 1: Merchant Server to MI Server The Merchant Server and/or the Merchant Environment initiates communications with the MI Server and provides the necessary 3-D Secure related information from the transaction to the MI Server. How information is provided depends on the implementation, but at minimum, all sensitive information is secured to the MI Server.
3.3.3 Step 2: The MI Server determines ACS version and Browser ID URL if present The Merchant working with the MI Server can determine immediately from the stored PRes data (i.e., using local storage) the 3-D Secure Version number supported by the ACS as well as obtain the Browser ID URL, if one exists for the requested card range. The MI Server passes the information back through the Merchant Environment.
3.3.4 Step 3: The 3DS Method on the Merchant checkout page loads the Browser ID URL, if present A 3DS method is a scripting call provided by the MI that is placed on the Merchant checkout page. Conditionally, if a Browser ID URL has been received from the PRes data for the account, the merchant environment shall generate a MI Transaction ID and pass into the 3DS Method. The 3DS Method loads the Browser ID URL which allows the ACS to obtain additional browser information to facilitate risk based decisioning. Note: The MI Transaction ID shall be the same as is passed in the AReq for this transaction.
3.3.5 Step 4: Merchant Server and MI Server The Merchant Server and/or the Merchant Environment initiate communications with the MI Server and provides the necessary 3-D Secure related information from the transaction to the MI Server, this includes the value of the generated MI Transaction ID used for Browser Identification. How information is provided depends on the implementation, but at minimum, all sensitive information is protected to the MI Server.
3.3.6 Step 5: MI Server through the DS to the ACS Using the information supplied by the Consumer in the Merchant website, the MI Server obtains the 3-D Secure related information from the Merchant Server. MI Server uses all of this information to create and send an AReq message to the DS, which then sends the message to the appropriate ACS. November 2015
©
http://www.emvco.com/specifications.aspx.
2 Systems and Functional Overview 3.4 Challenge Flow Overview EMV 3-D Secure 2.0 Protocol and Core Functions Specification 3.3.7 Step 6: ACS through the DS to the MI Server The ACS returns an ARes message to the DS, which then sends the message to the initiating MI Server. Before returning the response, the ACS evaluates the payment, Cardholder, and device authentication data provided and, for the Frictionless Flow, determines that the transaction does not require additional authentication.
3.3.8 Step 7: MI Server and Merchant Server The MI Server communicates the result of the ARes to the Merchant Server/Merchant web page. The Merchant determines how the interaction between these Merchant components is implemented. Note: 3-D Secure processing ends here.
3.3.9 Step 8: Merchant and Acquirer The Merchant can proceed with the authorisation exchange with its Acquirer. The Merchant, Acquirer, or Payment Processor can submit a traditional authorisation request, if appropriate.
3.3.10 Step 9: Payment Authorisation The Acquirer can process an authorisation with the Issuer through the payment network and return the authorisation results to the Merchant.
3.4 Challenge Flow Overview The Challenge Flow is utilised when the information that is received in the AReq message and supplemented by the conditional Browser Identification, does not satisfy the authentication requirements for this transaction, and the Cardholder is prompted for additional authentication data. The Challenge Flow is identical from a 3D Secure protocol perspective regardless of the challenge method chosen by the ACS for the authentication. This may include out of band authentication, where the cardholder is asked by the issuer to authenticate outside of the merchant’s browser (e.g. a mobile banking app). The first five Steps are identical to the Frictionless Flow. Steps 5 and 6 are identical from a flow perspective, although the result of the authentication for a Challenge Flow indicates that a Challenge is requested. The Challenge Flow contains the following Steps: Note: The MI server shall make a call to registered DS servers every 24 hours at a minimum and store the results for use in subsequent 3DS transactions.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 3 Authentication Flows and Usage Scenarios Protocol and Core Functions Specification 3.4 Challenge Flow Overview Start of Purchase: The Cardholder initiates a purchase transaction using a Merchant website/Payment Solution Provider. Step 1: The Merchant Server initiates communications with MI Server. Note: This may pass through other Merchant Environment components depending on implementation. Step 2: The MI Server determines ACS version and obtains the optional Browser ID URL. Step 3: The 3DS Method on the Merchant checkout page loads the Browser ID URL if present. Step 4: The Merchant Server initiates communications with the MI Server. Step 5: The MI Server sends an AReq message to the DS which then routes the message to the appropriate ACS. Step 6: The ACS returns an ARes message, indicating a challenge is requested, to the DS which then sends the message to the MI Server. Step 7: The MI Server responds to the Merchant Server with a CReq message that is posted through the Cardholder’s browser to the ACS URL provided in the ARes. Step 8: The ACS receives a CReq message and sends the authentication user interface to the Cardholder browser which may contain HTML, JavaScript, etc as required by the ACS. The Cardholder enters authentication data which is then validated by the ACS (this process of exchanging HTML will repeat until a determination is made by the ACS). The ACS then returns a CRes message by posting to the Notification URL. Step 9: The ACS sends an RReq message to the DS which then routes the message to the MI Server. Step 10: The MI Server receives an RReq message and returns an RRes message to the DS which then routes the message to the ACS. Note: 3-D Secure processing ends here. Step 11: The Merchant proceeds with authorisation exchange with its Acquirer. Step 12: Payment Authorisation. November 2015
©
http://www.emvco.com/specifications.aspx.
2 Systems and Functional Overview 3.4 Challenge Flow Overview EMV 3-D Secure 2.0 Protocol and Core Functions Specification Figure 3.2: Challenge Flow Note: The MI Server has the ability to utilize a call to the DS using the PReq (Preparation Request) message to receive and store data about specific card ranges such as the ACS version as well as the Browser ID URL, if one exists. The contents shall expire and be refreshed at least every 24 hours.
3.4.1 Start of Purchase: Cardholder and Merchant Website/Payment Solution Provider The Cardholder initiates a purchase transaction using a Merchant web page on a Consumer device. During the checkout process, the Cardholder Account Number and other account details, and shipping and billing information, are typically provided to the Merchant either by Cardholder keyboard entry or on file with the Merchant. While confirming the purchase, this information and shopping cart details are available for the Merchant to include in the authorisation request.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 3 Authentication Flows and Usage Scenarios Protocol and Core Functions Specification 3.4 Challenge Flow Overview 3.4.2 Step 1: Merchant Server to MI Server The Merchant Server and/or the Merchant Environment initiate communications with the MI Server and provides the necessary 3-D Secure related information from the transaction to the MI Server. As defined to Annex E, how information is provided depends on the implementation, but at minimum, all sensitive information is protected to the MI Server.
3.4.3 Step 2: The MI Server determines ACS version and Browser ID URL if present The merchant can determine immediately from the local storage the ACS Version number as well as the Browser ID URL, if one exists. The MI Server passes the information back through the merchant environment.
3.4.4 Step 3: The 3DS Method on the Merchant checkout page loads the Browser ID URL, if present A 3DS method is a scripting call provided by the MI that is placed on the Merchant checkout page. Conditionally, if a Browser ID URL has been received from the PRes data for the account, the merchant environment shall generate a MI Transaction ID and pass into the 3DS Method. The 3DS Method loads the Browser ID URL which allows the ACS to obtain additional browser information to facilitate risk based decisioning. Note: The MI Transaction ID shall be the same as is passed in the AReq for this transaction.
3.4.5 Step 4: MI Server and Merchant Server The Merchant Server and/or the Merchant Environment initiate communications with the MI Server and provides the necessary 3-D Secure related information from the transaction to the MI Server, this includes the value of the generated MI Transaction ID used for Browser Identification. How information is provided depends on the implementation, but at minimum, all sensitive information is protected to the MI Server.
3.4.6 Step 5: MI Server through DS to ACS Using the information supplied by the Consumer in the Merchant website, the MI Server obtains the 3-D Secure related information from the Merchant Server. MI Server uses all of this information to create and send an AReq message to the DS, which then sends the message to the appropriate ACS. November 2015
©
http://www.emvco.com/specifications.aspx.
2 Systems and Functional Overview 3.4 Challenge Flow Overview EMV 3-D Secure 2.0 Protocol and Core Functions Specification 3.4.7 Step 6: ACS through the DS to the MI Server The ACS returns an ARes message to the DS, which then sends the message to the MI Server. Before returning the response, the ACS evaluates the payment, Cardholder and device authentication data and, for the Challenge Flow, determines that additional data is required from the Cardholder to complete authentication. For example, the transaction is deemed to be of sufficient risk to require further authentication or there are banking regulations that require further authentication. The DS sends the ACS response to the MI Server.
3.4.8 Step 7: MI Server to ACS The MI Server responds to the request for 3-D Secure authentication from the calling system by sending a CReq message through the cardholder’s browser to the ACS.
3.4.9 Step 8: ACS to MI Server The ACS receives the CReq message and returns the authentication user interface to the Cardholder browser which may contain HTML JavaScript, etc., as required by the ACS. The Cardholder enters authentication data which is then validated by the ACS (this process of exchanging HTML will repeat until a determination is made by the ACS). The ACS then returns a CRes message to the MI Server.
3.4.10 Step 9: ACS through the DS to the MI Server The ACS sends an RReq message that can include the Authentication Value to the DS, which then sends the message to the appropriate MI Server using the MI URL sent within the AReq.
3.4.11 Step 10: MI Server through the DS to the ACS The MI Server receives the RReq and sends the RRes message to the DS, which then sends the message to the appropriate ACS. Note: 3-D Secure processing ends here.
3.4.12 Step 11: Merchant and Acquirer The Merchant can proceed with the authorisation exchange with its Acquirer. The Merchant, Acquirer, or Payment Processor can submit a traditional authorisation request, if appropriate.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 3 Authentication Flows and Usage Scenarios Protocol and Core Functions Specification 3.4 Challenge Flow Overview 3.4.13 Step 12: Payment Authorisation The Acquirer can process an authorisation with the Issuer through the payment network and returns the authorisation results to the Merchant. November 2015
©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 4 Authentication Flow Requirements 3.4 Challenge Flow Overview 4 Authentication Flow Requirements This chapter provides a detailed description of the requirements for the flows that were introduced in Chapter 3. For clarity, the actions for all entities involved in the 3-D Secure authentication process are described. However, the four entities covered by the 3-D Secure Protocol and Core Functions Browser Specification are the Merchant Server, MI Server, DS and ACS. The aforementioned entities are required to follow the specifications as written. Refer to the [TBD Browser Annex] for detailed requirements and implementation guidelines covering the 3DS Method. The two authentication flows defined for 3-D Secure payment authentication include: Frictionless Flow—for the Frictionless Flow, the ACS makes an authentication decision using the information that is received in the AReq and from optional Browser Identification. No additional information or interaction with the Cardholder is needed to complete the authentication. Challenge Flow—for the Challenge Flow, the ACS decides that the information received in the AReq message is insufficient to complete authentication. As a result, the Cardholder is prompted for additional authentication information. November 2015
©
http://www.emvco.com/specifications.aspx.
4 Authentication Flow Requirements 4.1 Frictionless Flow EMV 3-D Secure 2.0 Protocol and Core Functions Specification 4.1 Frictionless Flow Figure 4.1: Frictionless Flow Detailed For components within the Merchant Environment, this figure portrays a possible flow and does not preclude any specific Merchant implementation. The Frictionless Flow contains the following Steps: Note: The MI server shall make a call to registered DS servers every 24 hours at a minimum and store the results for use in subsequent 3DS transactions. Step 1 The Cardholder 1.1 The Cardholder makes an e-commerce purchase using a Merchant website using a browser on a Consumer device such as a PC, mobile device, etc.
1.2 After providing payment card, billing and shipping information, the Cardholder confirms the purchase. Step 2 The Merchant Server/Payment Services Provider 2.1 The Merchant Server/Payment Services Provider initiates communications with the MI Server and provides the necessary 3D Secure related information from the transaction to the MI Server to initiate 3-D Secure Cardholder authentication.
2.2 Depending on the Merchant Environment as outlined in Annex E, the payment information, shopping cart, and other information may be obtained.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 4 Authentication Flow Requirements 4.1 Frictionless Flow 2.3 The Merchant Server uses the PAN to determine the ACS Version number as well as the Browser ID URL, if one exists from the PRes data. The MI Server passes the information back through the Merchant Environment to the Merchant Server, generates the MI Transaction ID and passes with Browser ID URL. Step 3 The Merchant Environment The Merchant Environment shall:
3.1 The MI Transaction ID used in the 3DS method on the Merchant website must be identical to the one used in the MI Transaction ID field in the AReq message for each unique transaction.
3.2 Conditionally invoke 3DS Method on the merchant website if the ACS Version equals 2.0 and if a Browser ID URL exists for this transaction. Step 4 The Merchant Environment The Merchant Environment shall:
4.1 Obtain additional authentication information and populate in the following data element as appropriate: Transaction ID 4.2 Each request in the Merchant Environment shall have a server authenticated TLS session. The Merchant Environment may:
4.3 Obtain payment information and shopping cart information if it is gathered within the Merchant checkout flows. Note: Depending on checkout flows data may be entered through the Merchant Card on File (COF)/Merchant Server. The Merchant Environment shall:
4.4 Send the data to be included in the AReq message through the Merchant Environment to the MI Server. Step 5 The MI Server The MI Server shall:
5.1 Generate the MI Transaction ID
This ID will, for the MI Server, uniquely identify this transaction within all messages in the authentication process (AReq/ARes in the case of a Frictionless Flow).
5.2 Obtain Acquirer BIN and MI Reference Number
November 2015
©
http://www.emvco.com/specifications.aspx.
4 Authentication Flow Requirements 4.1 Frictionless Flow EMV 3-D Secure 2.0 Protocol and Core Functions Specification 5.3 Obtain all data elements from the Merchant Environment for the AReq.
5.4 Determine which DS corresponds to the payment system based on the Issuer BIN or Cardholder account information—if not already determined 5.5 Establish a secure link with the DS as defined in Chapter 7. If the connection cannot be established with the DS, the MI Server ends 3-D Secure processing.
5.6 Format the AReq message as defined in Annex B.6.
5.7 Send the AReq message to the payment system’s DS using the secured link established in Step 5.4. If the MI Server receives a failure when communicating with the DS or does not get a response within 4 seconds, then the MI Server ends 3-D Secure processing. Step 6 The DS The DS shall:
6.1 Receive the AReq from the MI Server.
6.2 Generate the DS Transaction ID
For the DS, the DS Transaction ID uniquely identifies the transaction in all subsequent messages in the authentication process (AReq/ARes in the case of a Frictionless Flow).
6.3 Validate the AReq message as defined in Annex B.6. If validation fails, then return an Error Message as defined in Annex B.14 and ends 3-D Secure processing.
6.4 Validate that the version number is within the current specification guidelines and, if not, create an Error Message as defined in Annex B.14 with the Error Code of 6 and ends 3-D Secure processing.
6.5 Validate the following data elements: that the MI Reference Number represents a participating MI Server. if not, then the DS sends an ARes message as described in Annex B.7 with the Transaction Status set to ‘N’ and iReq Code of 58 then ends 3-D Secure processing. that the Acquirer BIN represents a participating Acquirer if not, then the DS sends an ARes message as
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 4 Authentication Flow Requirements 4.1 Frictionless Flow 6.6 6.7 6.8 6.9 described in Annex B.7 with the Transaction Status set to ‘N’ and iReq Code of 58 then ends processing. that the Acquirer Merchant ID is related to the Acquirer BIN if not, then the DS sends an ARes message as described in Annex B.7 with the Transaction Status set to ‘N’ and iReq Code of 58 then ends processing. that the Merchant Category Code (MCC) is valid for the payment system if not then the DS sends an ARes message as described in Annex B.7 with the Transaction Status set to ‘N’ and iReq Code of 59 then ends 3-D Secure processing. If any of the other data elements not mentioned above are present but fail validation, then the DS formats an Error Message as defined in Annex B.14 with an Error Code of 5 with the name of the elements with format problems in the Error Description, sends the message to the MI Server, and ends 3-D Secure processing. If any of the required data elements are missing, then the DS formats an Error Message as defined in Annex Error! Reference source not found.with an Error Code of 3 with the name of the required element in the Error Description, sends the message to the MI Server, and ends 3-D Secure processing. Determine if the Cardholder Account Number received in the AReq is in a participating account range. If not, the DS formats an ARes message as described in Annex B.7 with the Transaction Status set to the appropriate value for the payment system. The DS returns the ARes message to the MI Server and ends 3-D Secure processing. Determine if the Cardholder Account Number is in an account range that has an ACS capable of processing 3-D Secure 2.0 messages. If not, the DS returns an ARes message as described in Annex B.7 with the Transaction Status set to the appropriate value for the payment system to the MI Server and ends 3-D Secure processing. Store the MI Server URL with the Transaction ID to be used for the RReq processing. Establish a secure link with the ACS. November 2015
©
http://www.emvco.com/specifications.aspx.
4 Authentication Flow Requirements 4.1 Frictionless Flow EMV 3-D Secure 2.0 Protocol and Core Functions Specification If the connection cannot be established with the ACS, the DS returns an ARes with an iReq Code of 98 and Transaction Status set to “N” and ends 3-D Secure processing. The DS may:
6.10 Maintain alternate URLs for the ACS, and if the first URL attempted is not available, the DS will attempt to connect to one of the alternate URLs. The DS shall:
6.11 Send the AReq to the ACS using the secured link established in Step 5.11. If the DS does not receive an ARes message from the ACS within 3 seconds or is unable to connect to the ACS URL, the DS formats an ARes with Transaction Status set to the appropriate response for the payment system or with an iReq set to 98 with an Invalid Request Description provide details of the issue. The DS returns the ARes message to the MI Server and ends 3-D Secure processing. Step 7 The ACS The ACS shall:
7.1 Receive the AReq message from the DS.
7.2 Validate the AReq message as defined in Annex B.6. If the device on which the authentication is being requested is not supported, then the ACS sends an ARes with the Transaction Status set to ‘U (indicating that the Authentication could not be performed) and iReq Code of 10 and ends 3-D Secure processing.
7.3 If any of the other data elements are present but fail validation, then the ACS formats an Error Message as defined in Annex B.14Error! Reference source not found. with an Error Code of 5 with the name of the elements with format problems in the Error Description, sends the message to the DS, and ends 3-D Secure processing.
7.4 If any of the required data elements are missing, then the ACS formats an Error Message as defined in Annex B.14Error! Reference source not found. with an Error Code of 3 with the name of the required element in the Error Description, sends the message to the DS, and ends 3-D Secure processing.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 4 Authentication Flow Requirements 4.1 Frictionless Flow 7.5 Generate the ACS Account ID. The DS will use this to uniquely identify the transaction in all possible messages in the authentication process (i.e., AReq/ARes, CReq/CRes, and RReq/RRes).
7.6 Use the Cardholder Account Number from the AReq message to determine whether authentication is available for the Cardholder. If the authentication for the Cardholder Account Number is not available, the ACS formats an ARes message as defined in Annex B.7 with the Transaction Status field set to the appropriate value for the payment system. The ACS returns the ARes message to the DS and ends 3-D Secure processing.
7.7 Evaluate the data received in the AReq message and determine whether the transaction is1: - authenticated (Transaction Status will be set to ‘Y’), the ACS generates an Authentication Value (AV) and formats the ARes message with the appropriate fields as defined in Annex B.7. - a Cardholder challenge is necessary to complete authentication (Transaction Status will be set to ‘C’)2. - further authentication will not be attempted (Transaction Status will be set to ‘N’)2, formats the ARes message with the appropriate fields as defined in Annex B.7. - authentication could not be completed, but a proof of authentication attempt (Authentication Value) was generated, (Transaction Status will be set to ‘A’) formats the ARes message with the appropriate fields as defined in Annex B.7.
- Authentication could not be completed, due to technical or other problem, (Transaction Status will be set to ‘U’ indicating that the Authentication could not be performed) formats the ARes message with the appropriate fields as defined in Annex B.7.
- Issuer is rejecting authentication and request that authorization not be attempted, (Transaction Status will be set to ‘R’) formats the ARes message with the appropriate fields as defined in Annex B.7. 1 The Decisioning process for this action is outside the scope of this spec. 2 Note: although not applicable to the Frictionless Flow, this Step is included for completeness. November 2015 © http://www.emvco.com/specifications.aspx. 4 Authentication Flow Requirements 4.1 Frictionless Flow EMV 3-D Secure 2.0 Protocol and Core Functions Specification 7.8 Send the ARes message to the DS using the secured link established in Step 6.8. Step 8 The DS The DS shall:
8.1 Receive, validate (as defined in Annex B.7 or B.14), and send the ARes or Error Message to the MI Server using the secured link established in Step 5.5.
8.2 Log transaction information as required by payment system program rules
Step 9 The MI Server The MI Server shall:
9.1 Receive and validate the ARes or Error Message as defined in Annex B.7 or Annex B.14. Note: MI Server error handling will vary depending on the implementation with the Merchant Environment.
9.2 For an authenticated transaction, ensure that the Transaction Status, Electronic Commerce Indicator (ECI) and Authentication Value as generated by the ACS are provided for the authorisation process.
9.3 If any of the other data elements are present but fail validation, then the MI Server ends 3-D Secure processing.
9.4 If any of the required data elements are missing, then the MI Server ends 3-D Secure processing.
9.5 Send the necessary information from the ARes message to the Merchant Environment. Step 10 The Merchant Environment The Merchant Environment shall:
10.1 Receive and validate the data from the ARes response or Error Message.
10.2 Convey the results of the ARes or Error Message to the Merchant Server or upon error end 3-D Secure processing. Step 11 The Merchant Web Server 11.1 The Merchant Web Server displays appropriate results to the Cardholder.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 4 Authentication Flow Requirements 4.2 Challenge Flow 4.2 Challenge Flow The Challenge Flow is utilised when the information that is received in the AReq message and supplemented by the optional Browser Identification Method, does not satisfy the authentication requirements, or regional regulation requirements for this transaction, and the Cardholder is prompted for additional authentication data. The Challenge Flow is identical from a 3-D Secure protocol perspective regardless of the challenge method chosen by the ACS for the authentication. The first six Steps (Step 1 to Step 6) are identical to the Frictionless Flow. Steps 7 and 8 are identical from a flow perspective, although the result of the authentication for a Challenge Flow indicates that a Challenge is requested.
4.2.1 Challenge Flow Figure 4.2: Challenge Flow Detailed Merchant Website Cardholder Browser Merchant Server MI Server DS ACS 1. Checkout with Purchase Info 3. Invoke ID Call 12.Request Credentials 2. Request 3DS 4. Initiate 3DS 5. Authentication Request 9. 3DS Response 8. Authentication Response 10. Challenge Request 11. Exchange HTML 6. Authentication Request 7. Authentication Response 12. Submit 14. POST Results RReq 15. Post Confirmation RRes 13. POST Results RReq 16. Post Confirmation RRes 17. Challenge Response Repeat until complete Close Window Note: Dashed arrows are not part of the 3-D Secure 2.0 protocol but are shown for clarity For components within the Merchant Environment, this figure portrays a possible flow and does not preclude any specific Merchant implementation. The Challenge Flow contains the following Steps: November 2015
©
http://www.emvco.com/specifications.aspx.
4 Authentication Flow Requirements 4.2 Challenge Flow EMV 3-D Secure 2.0 Protocol and Core Functions Specification Note: The MI server shall make a call to registered DS servers every 24 hours at a minimum and store the results for use in subsequent 3DS transactions. Step 1 The Cardholder This Step of the Challenge Flow is identical to Step 1 of the Frictionless Flow. Step 2 Merchant Server/Payment Solutions Provider This Step of the Challenge Flow is identical to Step 2 of the Frictionless Flow. Step 3 The Merchant Environment This Step of the Challenge Flow is identical to Step 3 of the Frictionless Flow. Step 4 The Merchant Environment This Step of the Challenge Flow is identical to Step 4Step 5 of the Frictionless Flow. Step 5 The MI Server This Step of the Challenge Flow is identical to Step 5 of the Frictionless Flow. Step 6 The DS This Step of the Challenge Flow is identical to Step 6 of the Frictionless Flow. Step 7 The ACS The ACS shall:
7.1 Receive the AReq message from the DS.
7.2 Validate the AReq message as defined in Annex B.6. If the device on which the authentication is being requested is not supported, then the ACS shall send an ARes message as described in Annex B.7 with the Transaction Status set to ‘U’ and iReq Code of 10 and ends processing. If any required data elements are present but fail validation, then the ACS formats an Error Message as described in Annex B.14 with an Error Code of 5 with the name of the elements with format problems in the Error Description, sends the message to the DS, and ends processing. If any of the required data elements are missing, then the ACS formats an Error Message as described in Annex B.14 with an Error Code of 3 with the name of the required element in the Error Description, sends the message to the DS, and ends processing.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 4 Authentication Flow Requirements 4.2 Challenge Flow 7.3 Generate the ACS Account ID. The ACS will use this to uniquely identify the transaction in all possible messages in the authentication process (e.g. AReq/ARes, CReq/CRes, and RReq/RRes).
7.4 Use the Cardholder Account Number from the AReq message to determine whether authentication is available for the Cardholder. If the authentication for the Cardholder Account Number is not available, the ACS formats an ARes message as defined in B.6 with the Transaction Status set to the appropriate response for the payment system. The ACS returns the ARes message to the DS and ends processing.
7.5 The ACS evaluates the values received in the AReq message and determines whether the transaction3: - is authenticated (Transaction Status set to ‘Y’) Note: This is Frictionless Flow. - requires a Cardholder challenge to complete authentication (Transaction Status set to ‘C’) - is not authenticated (Transaction Status set to ‘N’) - is not authenticated, but a proof of authentication attempt (Authentication Value) was generated. (Transaction Status set to ‘A’). is not authenticated, (Transaction Status set to ‘U’). is not authenticated because the Issuer is rejecting authentication and requesting that authorization not be attempted, (Transaction Status set to ‘R’).
7.6 If a challenge has been deemed necessary, the ACS confirms whether an acceptable challenge method is supported by the MI Server based on the following field received in the AReq message: Device Channel. a. If the Device Channel is not ‘02’(Browser), the ACS formats the ARes message and sets the Transaction Status to 'N', and formats the rest of the message with the appropriate fields as defined in Annex B.7 and ends processing. b. The ACS sets the Transaction Status field to ‘C’ for Challenge. c. The ACS sets the ACS URL field in the ARes that will be utilized in the ACS to Browser secure channel as defined in 3 The decisioning process for this action is outside the scope of this specification November 2015
©
http://www.emvco.com/specifications.aspx.
4 Authentication Flow Requirements 4.2 Challenge Flow EMV 3-D Secure 2.0 Protocol and Core Functions Specification Chapter 7.
7.7 Complete formatting of the ARes message as defined in Annex B.7.
7.8 Store the ACS Account ID and ACS Transaction ID for subsequent CReq processing.
7.9 Store the MI Transaction ID and DS Transaction ID for subsequent RReq processing.
7.10 Send the ARes message to the DS using the secure link established in Step 6.9 (as defined in the Frictionless Flow). Step 8 The DS The DS shall:
8.1 Receive and send the ARes or Error Message to MI Server using the secure link established in Step 6.9 (as defined in the Frictionless Flow).
8.2 Log transaction information as required by payment system program rules
Step 9 The MI Server The MI Server shall:
9.1 Receive and validate the ARes or Error Message as defined in Annex B.7 or Annex B.14. If any of the other data elements are present but fail validation, then end 3-D Secure processing. If any of the required data elements are missing, then end 3-D Secure processing.
9.2 Send necessary information from the ARes message to the Merchant Environment.
9.3 The MI Server formats the CReq message according to the format specified in Annex A.
9.4 The MI Server deflates and Base64-encodes the CReq message.
9.5 The ACS URL from the ARes will be used to transmit the CReq.
9.6 Constructs a form containing the CReq message, the Notification URL, and the MD (Merchant Data).
9.7 The MI Server passes the CReq through the cardholder browser to the ACS URL, by causing the cardholder browser to POST the form to the ACS. This is typically accomplished by using JavaScript.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 4 Authentication Flow Requirements 4.2 Challenge Flow Step 10 The ACS The ACS shall:
10.1 Receive and validate the CReq message If any required data elements are present but fail validation, then the ACS formats an Error Message as defined in Annex B.14 with an Error Code of 5 with the name of the elements with format problems in the Error Description, sends the message to the MI Server, and ends processing. If any of the required data elements are missing, then the ACS formats an Error Message as defined in Annex B.14 with an Error Code of 3 with the name of the required element in the Error Description, sends the message to the MI Server, and ends processing.
10.2 The ACS sends the authentication User Interface (UI) to the Cardholder Browser which may contain HTML, JavaScript, etc. Step 11 The Browser The Browser shall:
11.1 Display the user interface to the Cardholder
The Cardholder shall:
11.2 Enter authentication data which is then sent to the ACS over the established channel. Step 12 The Cardholder and ACS The ACS shall:
12.1 Validate the authentication data entered by the Cardholder:
- If the Cardholder has entered correct information:
- ACS sets the Transaction Status set to “Y”
- ACS generates the Authentication Value
- If the Cardholder has not entered correct information and authentication has failed:
- ACS sets the Transaction Status to ‘N’.
- The ACS sets the ECI value as defined by each payment system.
12.2 The process of exchanging HTML will repeat until a determination is made by the ACS. Step 13 The ACS and the DS The ACS shall:
13.1 Format the RReq message as defined in Annex B.10. November 2015
©
http://www.emvco.com/specifications.aspx.
4 Authentication Flow Requirements 4.2 Challenge Flow EMV 3-D Secure 2.0 Protocol and Core Functions Specification 13.2 Establish a secure link with the DS.
13.3 Send the RReq message to the DS
The DS shall:
13.4 Receive, validate, and log the RReq message as defined in B.10 If any required data elements are present but fail validation, then the DS formats an Error Message as defined in Annex B.14 with an Error Code of 5 with the name of the elements with format problems in the Error Description, sends the message to the ACS, and ends processing. If any of the required data elements are missing, then the DS formats an Error Message as defined in Annex B.14 with an Error Code of 3 with the name of the required element in the Error Description, sends the message to the ACS, and ends processing.
13.5 Establish a secure link with the MI Server using the URL in the MI URL data element extracted from the AReq and stored in Step 6.8 of the Frictionless Flow.
13.6 Send the RReq message to the MI Server using the secure link established in Step 13.5. Step 14 The MI Server The MI Server shall:
14.1 Receive and validate the RReq message as defined in B.10 If any required data elements are present but fail validation, then the MI Server formats an Error Message as defined in Annex B.14 with an Error Code of 5 with the name of the elements with format problems in the Error Description, sends the message to the DS, and ends processing. If any of the required data elements are missing, then the MI Server formats an Error Message as defined in Annex B.14 with an Error Code of 3 with the name of the required element in the Error Description, sends the message to the DS, and ends processing.
14.2 Format the RRes message as defined in Annex B.11 and send it to the DS using the secure link established in Step 13.5. Note: The Merchant can now proceed with Authorisation processing with its Acquirer. However, the Merchant may wish to first receive confirmation that the Cardholder has not abandoned the transaction. Step 15 The DS The DS shall:
15.1 Receive, validate as defined in Annex B.11, and log the RRes message.
November 2015 ©
http://www.emvco.com/specifications.aspx.
EMV 3-D Secure 2.0 Protocol and Core Functions Specification 4 Authentication Flow Requirements 4.2 Challenge Flow If any required data elements are p
Shown in part. Read the original for the full text.