EMV® 3-D Secure Approval – Test Requirements for 3DS Default-SDK and Split-SDK
Extracted document text
EMVCo's index flattens the document's layout, so this text is best used for searching and comparing versions rather than reading end-to-end.
This document is large; EMVCo's index truncates its extracted text, so the excerpt below is partial.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK Version 2.21 11 Jul 2025 © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Legal Notice Page iii This document summarizes EMVCo’s present plans for evaluation services and related policies and is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or non-infringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. 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. © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page iv Version 1.0 1.1 1.2 1.3 2.0 2.1 2.2 2.3 Revision Log Date 20 Mar 2020 24 Apr 2020 17 Jun 2020 27 Jul 2020 30 Nov 2020 29 Jan 2021 23 Mar 2021 14 May 2021 Description Initial version Editorial changes Clarification about screenshots management Clarification about DS Public keys and certificates Clarification about DS Public keys and certificates in §2.1.3 Added remarks about landscape mode in §2.1.4 New prerequisite about android permissions have been added in section §2.1.2 Security Permissions New sections to manage the new Split-SDK architecture [new] 1.1. Test Architecture for Default-SDK [new] 1.2. Test Architecture for Split-SDK [renamed] 2. Test Requirements for 3DS Default-SDK as SUT [new] 3. Test Requirements for Split-SDK/Native as SUT Message extension added into pArq message in section 3.2.1. Clarification about default-SDK non-iOS or non-Android Default-SDK solutions in section 1.1. New sections added: Security & Network connection, Use cases and API specifications Added remarks in §3.1 Added remarks in §3.1.1 Added remarks in §5.6 (RunTcId, and API) Added comments & remarks. Upgraded versions of [TEST_REQ_ALL_SUT] to version 2.1 © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page v Version 2.4 2.5 Date 18 June 2021 05 July 2021 Description Updated Test Requirements for 3DS Default-SDK as SUT New Section “2.1.5. Provide an OOB Authentication App (from 2.3 product only)” Updated Test Requirements for 3DS Split-SDK as SUT Updated section “3.1.1 Initialisation flow Management” o New field: 3DS Requestor App URL Updated section “3.1.2 Challenge User Data management” o Several clarification on field descriptions and conditions o Several new fields in CUD related to 2.3 testing o New section “Usage of Challenge_User_Data (CUD)” to explain how the CUD is used and implemented by the Test Client Agent o New requirement to implement OOB Authentication App (for 2.3 product only) Updated section Management” “3.1.3 Transaction Verdict o Several clarification on field descriptions and conditions o Corrections to indicate which fields are only applicable for Default-SDK Updated section “3.1.4 Visual Evidence Management, pErq (Screenshots, Video,…)” o Clarification about the format of the message pErq o Explanation about the screenshots to be performed Correction in 5.6.2.2 and in 5.6.2.4 [P3DS_IM-10] [T3DS-1012] Display of DS Logo during Processing Screen of AReq/ARes 2 new sections relative to predefined data with DS logo : For default-SDK products: see 2.1.5 For Split-SDK products: see 3.5.1 © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page vi Version 2.6 2.7 2.8 Date 05 May 2022 10 Jun 2022 22 Jul 2022 Description Changes relative to new Challenge Data Entry Box n°2 (from [3DS_Core_2.3.0]), impact: New field “textValue2” in “3.1.2 Challenge User Data management” New Test Requirement relative to Challenge Data Entry Autofill feature introduced in [3DS_Core_2.3.0], impacts: For Default-SDK : New section 2.1.6. Challenge Data Entry Autofill feature For Split-SDK : New section 3.5.2. Challenge Data Entry Autofill feature New sections to manage the other variants of Split-SDK architecture: [new] 1.3. Test Architecture for Split-SDK/Browser |new] 1.4. Test Architecture for Split-SDK/Shell [new] 4. Test Requirements for Split-SDK/Browser as SUT [new] 5. Test Requirements for Split-SDK/Shell as SUT Former sections applicable for Split-SDK: “Security & network connection” and “Use cases” have been shifted to the new document [Test_Harness_Split_SDK] and grouped into the section “Communication Test Requirement for Split-SDK” Former section applicable for Split-SDK: “API Specifications” have been shifted to the new document [Test_Harness_Split_SDK]. Section 4.1.5 - Provide an OOB Authentication App moved to TPP Test Requirements. P3DS_TP-374: Clarifications / Typo corrections: Sections 3.1.4 o Clarification on accepted values for pErq subfields o Correction of indexes for CReq [0-n] Upgrade references of 3DS specification from 2.3.0 to 2.3.1. Updates related to latest 2.3.1 Core specification Updated section “3.2.1. Authentication flow Management / A. Proprietary Authentication Request (pArq)” Updated section “3.2.1. Authentication flow Management / B. Proprietary Authentication Response (pArs)” © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page vii Version 2.9 2.10 2.11 2.12 Date 23 Sep 2022 28 Oct 2022 25 Nov 2022 14 Dec 2022 Description Upgraded version of reference document [TEST_REQ_ALL_SUT] and [Test_Harness_Split_SDK] Editorial changes to realign Split-SDK Variant terminology from 2.3.1 specifications. No content change. Only reformatting to latest EMVCo Template document In the pSrq message definition: (See changes in 3.1.3 Transaction Verdict Management) Changed the “p_isTransactionCompleted” field type from String to Boolean. Fixed the syntax of the examples. Updated version of referred documents: [TEST_REQ_ALL_SUT] [Test_Harness_Split_SDK] Updated version of referred documents: [TEST_REQ_ALL_SUT] [Test_Harness_Split_SDK] © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page viii Version 2.13 2.14 Date 27 Jan 2023 28 April 2023 Description P3DS_TP-473: In the pIni message definition: (See changes in 3.1.1 Initialisation flow Management) Added field “deviceUIMode”. P3DS_TP-474: In the Challenge User Data definition: (See changes in 3.1.2 Challenge User Data management) Clarified and correction of the format of the field “multipleSelectorIndices”. P3DS_TP-484 pErq related topics: - Reference of RFC 2388 has been replaced by the 7578 - Values for Type/Format have been clarified in 3.1.4 / A - Examples of pErq messages added in section 3.1.4 / B P3DS_TP-475 - New field “sdkMaxTimeout” added in pArq, see section 3.2.1. A - Proprietary Authentication Request (pArq) P3DS_TP-477 – the field “webAuthnCredList” is indicated as Conditional see “3.2.1. Authentication flow Management / B. Proprietary Authentication Response (pArs)” P3DS_TP-481 – the field “challengeHtmlData” and “simulateOobAuth” are indicated as conditional see “3.1.2 Challenge User Data management” P3DS_TP-482 – correction of the misspelling of the conditional part of the field “cancel”, see “3.1.2 Challenge User Data management” P3DS_TP-483 – the field “challengeHtmlData” is renamed “challengeHtmlData”, see “3.1.2 Challenge User Data management” P3DS_TP-459 : In order to help the implementation of the automation of the challenge user data action when ACS UI Type = 05 (HTML other) or 06 (HTML OOB), the acsHTML provided by the Test Plan includes a specific attribute ID for each tag relative to each listed button. See the notes in section “3.1.2 Challenge User Data management” for the fields: 18. actionAcsUiType_05HTML 19. actionAcsUiType_06HTML_OOB Updated version of referred documents: [Test_Harness_Split_SDK] P3DS_TP-498 : “sdkMaxTimeout” in pArq, is also applicable for 2.1 and 2.2 - see section 3.2.1. A - Proprietary Authentication Request (pArq) © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page ix Version 2.15 2.16 Date 30 June 2023 21 July 2023 Description P3DS_TP-552 new section added relative to oobAppURLInd definition for test purpose: Default-SDK: new section 2.1.7 Split-SDK/Native : new section 3.1.5 Split-SDK/Browser : new section 4.1.5 Split-SDK/Shell : new section 5.1.5 P3DS_TP-571 clarification regarding the Autofill feature with SMS OTP See update in section 2.1.6 See updated in section 3.5.2 Updated versions of referred documents: [Test_Harness_Split_SDK] [TEST_REQ_ALL_SUT] Updated versions of referred documents: [TEST_REQ_ALL_SUT] Update relative to product 2.2 which are supporting Bridging Message Extension in section “3.1.2.Challenge User Data management - A. Challenge User Data (CUD)” Updated conditional inclusion for these products for the fields 14, 15, 16 and 17. Look for “[Bridging_Mess_Ext]” to retrieve all the impacts 2.17 27 Oct 2023 Updated version of referred documents: [TEST_REQ_ALL_SUT] [Test_Harness_Split_SDK] 2.18 26 Apr 2024 Updated version of referred documents: [TEST_REQ_ALL_SUT] [Test_Harness_Split_SDK] [Bridging_Mess_Ext] 2.19 11 Oct 2024 Update from EMV® Specification Bulletin No. 255 v4 July 2024 : 3DS 2.1.0 is sunsetted All references to 3DS 2.1.0 are removed Updated version of referred documents: [TEST_REQ_ALL_SUT] © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page x Version 2.20 2.21 Date 30 Apr 2025 11 Jul 2025 Description P3DSMP-139: clarification about autofill feature in section 2.1.6 and 3.5.2 (support at least numerical OTP and rewording of “emulate” to a more appropriate sentence) P3DSIM-51: Visual validation limitation on iOS regarding the screen recording for the challenge data entry masking feature (see updated section 2.1.4 Visual Validations) © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page xi Contents 1 References....................................................................................................... 13 2 Introduction ..................................................................................................... 14 1.1. Test Architecture for Default-SDK............................................................. 14 1.2. Test Architecture for Split-SDK/Native ...................................................... 15 1.3. Test Architecture for Split-SDK/Browser ................................................... 17 1.4. Test Architecture for Split-SDK/Shell ........................................................ 18 2. Test Requirements for 3DS Default-SDK as SUT .......................................... 20 2.1. 3DS SDK default data or default behavior ................................................ 20 2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.5. 2.1.6. 2.1.7. TPP Requestor Application Integration ......................................... 20 Security Permissions .................................................................... 20 Additional Functionalities .............................................................. 21 Visual Validations.......................................................................... 21 Predefined data ............................................................................ 22 Challenge Data Entry Autofill feature ............................................ 22 OOB App URL Indicator definition................................................. 22 2.2. 3DS SDK Network configuration............................................................... 22 2.2.1. 3DS SDK connection with Test environment................................. 22 2.3. DS Public keys and certificates................................................................. 23 3. Test Requirements for Split-SDK/Native as SUT........................................... 24 3.1. Split-SDK/Native testing element: Test Client Agent................................. 24 3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.1.5. Initialisation flow Management ...................................................... 25 Challenge User Data management ............................................... 26 Transaction Verdict Management ................................................. 36 Visual Evidence Management, pErq (Screenshots, Video,…) ....... 39 OOB App URL Indicator definition................................................. 44 3.2. Split-SDK/Native testing element: Middleware.......................................... 44 3.2.1. Authentication flow Management .................................................. 45 3.3. Split-SDK/Native Network configuration.................................................... 46 3.3.1. Test Client Agent Connection with Test Environment.................... 46 3.3.2. Middleware Connection with Test Environment............................. 46 3.3.3. Split-SDK Server Connection with Test Environment .................... 46 3.4. DS Public keys and certificates................................................................. 47 3.5. Split-SDK/Native default data or default behavior ..................................... 47 3.5.1. 3DS Split-SDK Predefined data .................................................... 47 3.5.2. Challenge Data Entry Autofill feature ............................................ 47 © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page xii 3.6. Communication Test Requirements for Split-SDK/Native as SUT............. 47 4. Test Requirements for Split-SDK/Browser as SUT ....................................... 48 4.1. Split-SDK/Browser testing element: Test Client Agent and Middleware .... 48 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.1.5. Initialisation flow Management ...................................................... 49 Challenge User Data management ............................................... 50 Transaction Verdict Management ................................................. 50 Visual Evidence Management, pErq (Screenshots, Video,…) ....... 50 OOB App URL Indicator definition................................................. 50 4.2. Split-SDK/Browser Network configuration................................................. 50 4.2.1. Middleware Connection with Test Environment............................. 50 4.2.2. Split-SDK/Browser Server Connection with Test Environment ...... 51 4.3. DS Public keys and certificates................................................................. 51 4.4. Split-SDK/Browser default data or default behavior .................................. 51 4.5. Communication Test Requirements for Split-SDK/Browser as SUT.......... 51 5. Test Requirements for Split-SDK/Shell as SUT............................................. 52 5.1. Split-SDK/Shell testing element: Test Client Agent and Middleware ......... 52 5.1.1. 5.1.2. 5.1.3. 5.1.4. 5.1.5. Initialisation flow Management ...................................................... 53 Challenge User Data management ............................................... 53 Transaction Verdict Management ................................................. 53 Visual Evidence Management, pErq (Screenshots, Video,…) ....... 54 OOB App URL Indicator definition................................................. 54 5.2. Split-SDK/Shell Network configuration...................................................... 54 5.2.1. Test Client Agent Connection with Test Environment.................... 54 5.2.2. Middleware Connection with Test Environment............................. 54 5.2.3. Split-SDK/Shell Server Connection with Test Environment ........... 54 5.3. DS Public keys and certificates................................................................. 55 5.4. Split-SDK/Shell default data or default behavior ....................................... 55 5.5. Communication Test Requirements for Split-SDK/Shell as SUT............... 55 © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 13 / 56 1 References Short name [TEST_REQ_ALL_SUT] [Test_Harness_Split_SDK] [3DS_Core_2.2.0] [3DS_SDK_Spec_2.2.0] [3DS_Core_2.3.1] [3DS_SDK_Spec_2.3.1] [3DS_Split_SDK_Spec_2.3.1] [Bridging_Mess_Ext] Reference Document Test Requirements for all Systems Under Test EMV® 3-D Secure – Test Harness for Split-SDK as System Under Test EMV® 3-D Secure Protocol and Core Functions Specification EMVCo EMV® 3-D Secure – SDK Specification EMVCo EMV® 3-D Secure Protocol and Core Functions Specification EMVCo EMV® 3-D Secure – SDK Specification EMVCo EMV® 3-D Secure – Split-SDK Specification EMVCo EMV® 3-D Secure – Bridging Message Extension Version / Date v2.14 / 11 Oct 2024 v1.15 / 11 Jul 2025 v2.2.0 / nov-2018 v2.2.0 / nov-2018 v2.3.1.1 / May-2023 v2.3.1.1 / May-2023 v2.3.1.1 / May-2023 v2.0 / Nov-2023 © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 14 / 56 2 Introduction This document describes test requirements for 3DS SDK as System Under Test. In the 3DS 2.3 specification [3DS_Core_2.3.1], when refers to the 3DS SDK, EMVCo has defined two options for a 3DS SDK implementation. The two options are as follows: 1. Default SDK—Software component designed as an SDK that is integrated into a 3DS Requestor App. This SDK option is defined in the [3DS_SDK_Spec_2.x.0], in which is referred to as the 3DS SDK. 2. Split-SDK— Client-server implementation of the 3DS SDK. Some functions of the SplitSDK entity can be performed by either a Split-SDK Client or a Split-SDK Server or, in some situations, both. The Split-SDK has multiple variants depending on the Consumer Device and the 3DS Requestor Environment. These variants include the SplitSDK/Native, Split-SDK/Shell, and Split-SDK/Browser, and each is defined in the EMV 3-D Secure—Split-SDK Specification. The following sections describes the Test Architecture for Default-SDK and for Split-SDK. The Test Requirements for the System Under Test are expressed: for Default-SDK in section “2. Test Requirements for 3DS Default-SDK as SUT”. for Split-SDK/Native in section “3. Test Requirements for Split-SDK/Native as SUT”. for Split-SDK/Browser in section “4. Test Requirements for Split-SDK/Browser as SUT”. for Split-SDK/Shell in section “5. Test Requirements for Split-SDK/Shell as SUT”. 1.1. Test Architecture for Default-SDK © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 15 / 56 The System Under Test is the Default-SDK. The 3DS Test Plan is based on the following interfaces: Initialisation flow o Data for createTransaction o Scripting information (Challenge User Data) o Indicates if screenshot are required Authentication flow Challenge flow (CReq/CRes) Transaction verdict and screenshots The Test Platform Provider are in charge of implementing the TPP Requestor Application for iOS or Android solutions. For non-iOS and non-Android solutions, the TPP Requestor Application shall be provided by the default-SDK Product Provider (see details in 2.1.3) The Test Requirements for Default-SDK are detailed in section “2. Test Requirements for 3DS Default-SDK as SUT”. 1.2. Test Architecture for Split-SDK/Native © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 16 / 56 The System Under Test is composed with the 4 elements (which have proprietary interfaces): Test Client Agent SDK Client SDK Server Middleware The 3DS Test Plan is based on the following interfaces: Initialisation flow o Data for createTransaction o Scripting information (Challenge User Data) o Indicates if screenshot are required Authentication flow (for test purpose) Challenge flow (CReq/CRes) Transaction verdict and screenshots The SDK Product Provider is in charge of implementing the Test Client Agent and the Middleware. The Test Requirements for Split-SDK/Native are detailed in section “3. Test Requirements for Split-SDK/Native as SUT”. © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 1.3. Test Architecture for Split-SDK/Browser Page 17 / 56 The System Under Test is composed with the 4 elements (which have proprietary interfaces): Merchant Web Page including Test Client Agent Challenge Window iframe with Split-SDK/Browser Client SDK Server Middleware The 3DS Test Plan is based on the following interfaces: Initialisation flow o Data for createTransaction o Scripting information (Challenge User Data) o Indicates if screenshot are required Authentication flow (for test purpose) Challenge flow (CReq/CRes) Transaction verdict and screenshots The SDK Product Provider is in charge of implementing the Merchant Web Page including Test Client Agent and the Middleware. © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 18 / 56 The Test Requirements for Split-SDK/Browser are detailed in section “4. Test Requirements for Split-SDK/Browser as SUT”. 1.4. Test Architecture for Split-SDK/Shell The System Under Test is composed with the 4 elements (which have proprietary interfaces): Test Client Agent Split-SDK/Shell with JS Split-SDK/Shell SDK Server Middleware The 3DS Test Plan is based on the following interfaces: Initialisation flow o Data for createTransaction o Scripting information (Challenge User Data) o Indicates if screenshot are required Authentication flow (for test purpose) Challenge flow (CReq/CRes) © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 19 / 56 Transaction verdict and screenshots The SDK Product Provider is in charge of implementing the Test Client Agent and the Middleware. The Test Requirements for Split-SDK/Shell are detailed in section “5. Test Requirements for Split-SDK/Shell as SUT”. © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 20 / 56 2. Test Requirements for 3DS Default-SDK as SUT 2.1. 3DS SDK default data or default behavior 2.1.1. TPP Requestor Application Integration The SDK must integrate with the TPP Requestor Application to facilitate automation of test case execution for the supported operating systems (initially Android and iOS). This TPP Requestor Application will be communicated with the SDK directly during the set-up phase. Besides the integration with the TPP Requestor Application the SDK needs to implement Challenge Listeners and allow certain security permissions to facilitate automation during testing. The purpose of these Challenge Listeners is to extract the required information supplied during challenges and allow the Test Environment to properly populate/validate challenge data fields as required during testing. 2.1.2. Security Permissions Certain security permissions are required to allow for specific functionality needed during testing. The SDK shall grant the following permissions to the TPP Requestor Application during testing:
• If it is possible for the TPP Requestor Application to perform screenshot (no restriction due to 3DS SDK nor to Operating System) o To capture screenshots. This means security requirement SE08 as described in the 3DS SDK Specifications [3DS_SDK_Spec_2.x.0] will be intentionally bypassed. Please also see section 3.5.10 of the 3DS Technical Guide [3DS_SDK_Guide_2.x.0] for more information on disabling screen capture. SE08 should only be bypassed during EMVCo functional testing.
• If it is impossible for the TPP Requestor Application to perform screenshot (restriction due to 3DS SDK or to Operating System) o For the test cases dealing with screenshots, 3DS SDK Product Provider is in charge to perform screenshots with another mean than TPP Requestor App, and to provide these assets to TPP.
• To inject data into challenge text views using the Challenge Listeners (see previous section).
• For Android OS o The permission 'Installation time permissions: android.permission.ACCESS_WIFI_STATE' has NOT been granted o The permission 'Installation time permissions: android.permission.BLUETOOTH' has been granted. © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 21 / 56 o The permissions during android.permission.ACCESS_NETWORK_STATE android.permission.INTERNET. o The following Run-time permission have been granted: android.permission.SEND_SMS, android.permission.READ_PHONE_STATE android.permission.READ_PHONE_NUMBERS installation: and 2.1.3. Additional Functionalities Other additional functionalities are required:
• Be capable of retrieving/loading the EMVCo DS CA public key o The DS public keys and Certificates are provided by the Test Platform Provider. o Test Platform Provider also indicates the associated RIDs for the DS public Keys depending on the algorithm (RSA, EC).
• In case that the SDK is based on iOS or Android OS solution, the Product Provider should use the provided TPP Requestor Application. In any other case of non-iOS or non-Android solutions the Product Provider should create their own reference application (assuming the specification of the Requestor App is provided by TPP). 2.1.4. Visual Validations In order to validate that the 3DS SDK renders the proper UI based on the CRes message received from the ACS, the Test Plan contains a number of UI related test cases that require visual validation. To avoid that the screenshots captured by the TPP Requestor App do not include all UI elements due to the screen size of the (mobile) device used for testing, it is recommended that the Product Provider first executes test case TC_SDK_10026_001 to ensure the captured screenshot contains all UI data elements provided by the ACS. In case not all UI elements (including the expandable text areas at the bottom of the screen) fit on the screen, it is strongly recommended to use a device with a larger screen size and/or higher resolution to avoid delays during the review of the test results performed by the Test Lab. Furthermore, it is advised to pay attention during the pre-compliance testing, that all screenshots present in the Test Platform – either automatically captured by the TPP Requestor App, or manually uploaded by the Product Provider – always contain all UI elements. The remarks included in this section apply to both portrait mode and landscape mode related test cases. The example shown above is for portrait mode as can be recognized from the figure showing the Challenge UI which is part of test case TC_SDK_10026_001. For a similar landscape mode example, test case TC_SDK_10026_002 can be used. Regarding the PP evidence for the challenge entry box masking feature described in [3DS_Core_2.3.1], as the device OS can prevent from recording the masked field, the SDK Provider shall provide as evidence the screens or video recorded with another means (i.e. not recorded by the device under test). © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 22 / 56 2.1.5. Predefined data For test purpose, it shall be configured in predefined data, of the Default-SDK products, the definition of the DS logo. By the way, it will be considered as “requested” to provide the DS logo into the processing screen, as indicated in [Req 143] in [3DS_Core_2.x.0]. [Req 143] The 3DS SDK shall for the AReq/ARes message exchange: If requested, integrate the DS logo into the Processing screen. 2.1.6. Challenge Data Entry Autofill feature From [3DS_Core_2.3.1], the autofill feature is managed through 2 fields in CRes challengeDataEntryAutofill and challengeDataEntryAutofillType. This is applicable for both Challenge Text Box (1) and Challenge Text Box 2. The autofill feature is applicable for 2 type “01 = SMS OTP” and “02 = Password”. The SDK product have to support at least Numerical values for OTP. For the test purpose, the SDK product have to set up the configuration to make the autofill feature works and behaves as a challenge data entry is always provided when autofill feature is activated (either for Challenge Text Box 1 or for Challenge Text Box 2 or for both), whatever the autofill type (SMS OTP or Password). The Device shall be prepared to allow the autofill feature to be operational for the 2 autofill types: SMS or Password. 2.1.7. OOB App URL Indicator definition Even if the merchant or SDK vendor can decide to not support the 3DS Requestor App URL and OOB App URL in the production environment, the SDK product shall set the OOB App URL Indicator (See oobAppURLInd in [3DS_Core_2.3.1]) to ‘01’ (supported) in all CReq for the sake of EMVCo testing. 2.2. 3DS SDK Network configuration 2.2.1. 3DS SDK connection with Test environment 3DS SDK is connected with the following elements in Test Environment: 3DS REQUESTOR App ACS The 3DS Requestor App is provided by Test Platform Providers and shall be integrated with SDK (See 2.1.1 “TPP Requestor Application Integration”). © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 23 / 56 2.3. DS Public keys and certificates The DS public keys and Certificates are provided by the Test Platform Provider. Test Platform Provider also indicates the associated RIDs for the DS public Keys depending on the algorithm (RSA, EC). © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 24 / 56 3. Test Requirements for Split-SDK/Native as SUT This section list the Test Requirements for 3DS Split-SDK as System Under Tests regarding the different topics: Split-SDK/Native testing element: Test Client Agent (3.1) Split-SDK/Native testing element: Middleware (3.2) Split-SDK/Native Network configuration (3.3) DS Public keys and certificates (3.4) 3.1. Split-SDK/Native testing element: Test Client Agent A B C D The Test Client Agent is provided by the Split-SDK product provider. The Test Client Agent is in charge to manage the interaction with Split-SDK Client. The Test Client Agent is in charge to manage the communication with Test Environment: A: The initialization flow (see section 3.1.1) C: The transaction verdict (see section 3.1.3) D: The screenshots (see section 3.1.4) The Test Client Agent is in charge to manage the internal behavior regarding the challenge data input (emulation of cardholder input for automatic execution) B: The challenge user data management (see section 3.1.2) The Test Environment provides a simulation or emulation of the ACS which used public HTTPS endpoint and expects the exact CReq/Cres formats. The Test Environment provides a simulation or emulation of the 3DS Server which used a specific HTTPS endpoint and supported authentication flow pArq/pArs messages formats. © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 25 / 56 3.1.1. Initialisation flow Management The initialization flow provide several kinds of information through the Proprietary Initialisation Request message (pIni): 1) Data for createTransaction a. RID - DS Server ID (EC or RSA) b. messageVersion 2) Scripting Information : Challenge User Data (CUD) 3) Indication for screenshot required 4) 3DS Requestor App URL (when present it is used by OOB Authentication App) 5) Device UI Mode (expected screen orientation) The Test Client Agent is in charge to initiate the transaction with Split-SDK Client according to the “data for createTransaction”. The Test Client Agent will store the scripting information Challenge User Data, which will be used to manage the internal behavior regarding the challenge data : emulation of cardholder input for automatic execution (see details in section 3.1.2. Challenge User Data management). This storage can be stored in persistent or non persistent memory according to the Test Client Agent design. The Test Client Agent knows if, for the current test execution, screenshot have to be performed by itself and provided at the end of the test execution to Test Environment (See details in section 3.1.4. Visual Evidence Management, pErq (Screenshots) A. Proprietary Initialization Request (pIni) № Field Presence Type/Format Accepted Value 1. messageType R Length: 4 character pIni JSON Data Type: String 2. messageVersion R messageVersion to use to create a transaction 3. dsRID R RID - DS Server ID (EC or RSA) 4. challengeUserData O Array of CUD (details in section ”3.1.2. Challenge User Data management”) 5. screenshotRequired O Boolean « true » or « false » 6. threeDSRequestorAppURL O Length: Variable, maximum 2048 characters JSON Data Type: String Value accepted: Universal App Link © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 26 / 56 7. deviceUIMode O 01 = Indicates the user interface Portrait mode the ACS will present to the Cardholder for a 02 = Landscape challenge. Length: 2 numeric characters JSON Data Type: String 3.1.2. Challenge User Data management The Scripting information are transmitted during the Initialisation flow through the Challenge User Data (array of CUD – see detail of the structure below) by the Test Environment to the Test Client Agent. The Test Client Agent have to emulate the Cardholder User Interaction and to perform interaction the Split-SDK Client according to what is specified in the script information described below. The Split-SDK provider will also need to implement a simple OOB Authentication App on the same device as the SDK-Client for test purpose. The OOB Authentication App is specified in the second section below. A. Challenge User Data (CUD) № Field Presence Type/Format/Accepted Value Conditional inclusion 1 order R Provides the index of the application of the Challenge User Data in the list JSON Data Type : Integer Starts with 0 (Indicates the first Challenge User Data to process) 2 uiType R The UI Type concerned by the Challenge User Data information Length: 2 characters JSON Data Type: String Values accepted:
• 01 = Text
• 02 = Single Select
• 03 = Multi Select
• 04 = OOB © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 27 / 56 № Field 3 cancel 4 textValue 4bis textValue2 5 challengeHtmlData 6 simulateOobAuth Presence C O O C C Type/Format/Accepted Value
• 05 = HTML
• 06 = HTML OOB (only from 2.3)
• 07 = Information (only from 2.3) Indicates if a click to ‘cancel’ is performed JSON Data Type: Boolean Values accepted:
• true
• false Conditional inclusion Absent if any of these fields is present: actionAcsUiType_01OTP actionAcsUiType_02Select actionAcsUiType_03MultiSelect actionAcsUiType_04OOB actionAcsUiType_05HTML actionAcsUiType_06HTML_OO B Indicate the challenge to be provided in Challenge Entry Box n°1 Length: 45 characters JSON Data Type: String Indicate the challenge to be provided in Challenge Entry Box n°2 Length: 45 characters JSON Data Type: String Indicate the challenge to be provided Length: 100 characters JSON Data Type: String Indicates that the OOB App is opened by Test Environment to perform a authentication It emulates the fact that Cardholder wait 3 seconds and launch manually the OOB Authentication App on the same device as the 3DS Requestor App to actionAcsUiType_07Info Optional if ‘uiType’ = 01 and ‘cancel’ absent or false Absent otherwise For 2.3 SDK products Optional if ‘uiType’ = 01 and ‘cancel’ absent or false Absent otherwise Required if ‘uiType’ = 05 or 06 and ‘cancel’ absent or false Absent otherwise Required if ‘uiType’ = 04 or 06 and ‘cancel’ absent or false Absent otherwise © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 28 / 56 № Field Presence Type/Format/Accepted Value Conditional inclusion perform the authentication OOB Note: “manually” means without clicking on the relative button to oobAppLabel JSON Data Type: Boolean Values accepted:
• true
• false 7 whitelistingDataEntr R y Indicates if the cardholder gives consent to Whitelist (in 2.2) or to Trust List (from 2.3) and tick the corresponding option JSON Data Type: Boolean Values accepted:
• true
• false 8 delayCardholderInpu R t Indicates that the Requestor App shall wait X minutes before sending the answer. JSON Data Type: Integer 9 singleSelectorIndex C Indicates the index of choice when there is a selection. Required if ‘uiType’ = 02 and ‘cancel’ absent or false JSON Data Type: String Absent otherwise 0 is the first position 10 httpMethod O (only 2.1 and 2.2) indicate how to provide the answer “challengeHtmlData”. See explanation below. Based on mechanism specified in [Req 37] of [3DS_SDK_Spec_2.2.0], and, in [Req 413] of [3DS_Core_2.3.1] Required if ‘uiType’ = 05 and ‘cancel’ absent or false Absent otherwise JSON Data Type: String Values accepted : © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 29 / 56 № Field Presence Type/Format/Accepted Value Conditional inclusion « GET » 11 captureScreenshots O indicates that the TPP Requestor App shall perform screenshots. Boolean 12 multipleSelectorIndice C s Indicates the indexes of choice when there is a multi selection Required if ‘uiType’ = 03 and ‘cancel’ absent or false JSON Data Type: Array of Absent otherwise Objects The object contains: order Index of a choice. 0 is the first position. JSON Data Type: String isSelected Indicates whether the corresponding choice is selected. JSON Data Type: Boolean 13 deviceBindingDataE R (for 2.3 Indicates if the cardholder ntry and later) gives consent to bind the device to the PAN (from 2.3) and tick the corresponding option. JSON Data Type: Boolean Values accepted:
• true
• false 14 actionAcsUiType_01O C (for 2.3 Indicate on which button For 2.1 and 2.2 SDK TP and later) the click is performed products Length: 2 characters Absent JSON Data Type: String Values accepted: 00 = Do nothing Default implicit value = “01” if ‘uiType’ = 01 and ‘cancel’ absent or false © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 30 / 56 № Field Presence Type/Format/Accepted Value Conditional inclusion 01 = Click on the button For 2.3 SDK products “submitAuthenticationLab or 2.2 SDK Products el” supporting 02 = Click on the button [Bridging_Mess_Ext] “resendInformationLabel” Required if ‘uiType’ = 03 = Click on the button 01 and ‘cancel’ “challengeAddLabel” absent or false Absent otherwise 15 actionAcsUiType_02Se C (for 2.3 Indicate on which button For 2.1 and 2.2 SDK lect and later) the click is performed products Length: 2 characters Absent JSON Data Type: String Values accepted: 00 = Do nothing 01 = Click on the button “submitAuthenticationLab el” 03 = Click on the button “challengeAddLabel” Default implicit value = “01” if ‘uiType’ = 02 and ‘cancel’ absent or false For 2.3 SDK products or 2.2 SDK Products supporting [Bridging_Mess_Ext] Required if ‘uiType’ = 02 and ‘cancel’ absent or false Absent otherwise 16 actionAcsUiType_03M C (for 2.3 Indicate on which button For 2.1 and 2.2 SDK ultiSelect and later) the click is performed products Length: 2 characters JSON Data Type: String Values accepted: 00 = Do nothing 01 = Click on the button “submitAuthenticationLab el” 03 = Click on the button “challengeAddLabel” Absent Default implicit value = “01” if ‘uiType’ = 03 and ‘cancel’ absent or false For 2.3 SDK products or 2.2 SDK Products supporting [Bridging_Mess_Ext] Required if ‘uiType’ = 03 and ‘cancel’ absent or false Absent otherwise © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 31 / 56 № Field Presence Type/Format/Accepted Value Conditional inclusion 17 actionAcsUiType_04O C (for 2.3 Indicate on which button For 2.1 and 2.2 SDK OB and later) the click is performed products Length: 2 characters Absent JSON Data Type: String Values accepted: 00 = Do nothing Default implicit value = “01” if ‘uiType’ = 04 and ‘cancel’ absent or false 01 = Click on the button “oobContinueLabel” 02 = Click on the button “oobAppLabel” 03 = Click on the button “challengeAddLabel” For 2.3 SDK products or 2.2 SDK Products supporting [Bridging_Mess_Ext] Required if ‘uiType’ = 04 and ‘cancel’ absent or false Absent otherwise 18 actionAcsUiType_05H C (for 2.3 Indicate on which button For 2.1 and 2.2 SDK TML and later) the click is performed products Length: 2 characters Absent JSON Data Type: String Values accepted: Indicate on which button the click is performed Default implicit value = “01” if ‘uiType’ = 05 and ‘cancel’ absent or false Length: 2 characters For 2.3 SDK products JSON Data Type: String Values accepted: 00 = Do nothing 01 = Click on the button “submitAuthenticationLab el” Required if ‘uiType’ = 05 and ‘cancel’ absent or false Absent otherwise Note: for test UI automation, the acsHTML provided by the Test Plan include a specific attribute ID for each tag relative to each listed button. © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 32 / 56 № Field Presence Type/Format/Accepted Value Conditional inclusion For the action “01” : the acsHTML contains the tag 19 actionAcsUiType_06H C (for 2.3 Indicate on which button For 2.1 and 2.2 SDK TML_OOB and later) the click is performed products Length: 2 characters Absent JSON Data Type: String Values accepted: 00 = Do nothing 01 = Click on the button “oobContinueLabel” 02 = Click on the button “oobAppLabel” 03 = Click on the button “challengeAddLabel” Note: for test UI automation, the acsHTML provided by the Test Plan includes a specific attribute ID for each tag relative to each listed button. Default implicit value = “01” if ‘uiType’ = 06 and ‘cancel’ absent or false For 2.3 SDK products Required if ‘uiType’ = 06 and ‘cancel’ absent or false Absent otherwise For the action “01” : acsHTML contains the tag For the action “02” : acsHTML contains the tag For the action “03” : acsHTML contains the tag 20 actionAcsUiType_07In C (for 2.3 Indicate on which button For 2.1 and 2.2 SDK fo and later) the click is performed products Length: 2 characters Absent JSON Data Type: String Values accepted: 00 = Do nothing Default implicit value = “01” if ‘uiType’ = 07 and ‘cancel’ absent or false © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 33 / 56 № Field 21 actionOS Presence C (for 2.3 and later) Type/Format/Accepted Value 01 = Click on the button “infoContinueLabel” 03 = Click on the button “challengeAddLabel” Indicates that the Test Environment need to set the SDK Ui in foreground regarding the device OS. It emulates the fact that Cardholder waits 3 seconds manually select the SDK Ui by himself Note: “manually” means somehow that the OOB Authentication App has not switched automatically to 3DS Requestor App URL Length: 2 characters JSON Data Type: String Values accepted: 00 = Do nothing 01 = Set the SDK Ui in foreground Conditional inclusion For 2.3 SDK products Required if ‘uiType’ = 07 and ‘cancel’ absent or false Absent otherwise For 2.1 and 2.2 SDK products Absent Default implicit value = “01” if ‘uiType’ = 04 (OOB) or 06 (HTML OOB) and ‘cancel’ absent or false For 2.3 SDK products Required if ‘uiType’ = 04 (OOB) or 06 (HTML OOB) and ‘cancel’ absent or false Absent otherwise Usage of Challenge_User_Data (CUD) A. Cancellation cases : When “cancel” = true (it can apply to any ‘uiType’ values) It emulates that the fact that the user click on Cancel button (and do not perform anything else) B. Non Cancellation cases : “cancel” is either equal to false or absent If ‘delayCardholderInput’ is different from 0, then the corresponding delay applies (whatever ‘uiType’ values) If ‘whitelistingDataEntry’ is equal to ‘true’ then the corresponding option shall be ticked (whatever ‘uiType’ values) If ‘deviceBindingDataEntry’ is equal to ‘true’ then the corresponding option shall be ticked (whatever ‘uiType’ values) If “uiType” = “01” (Text), the following process shall occur in order: © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 34 / 56 1) Fill the challenge entry field in ChallengeEntryBox n°1 with ‘textValue’ and/or the challenge entry field in ChallengeEntryBox n°2 with ‘textValue2’ 2) Perform the action indicated in ‘actionAcsUiType_01OTP’ (consider the value ‘01’ as default behavior if absent) If “uiType” = “02” (Single Select) 1) Select the item indicated at index ‘singleSelectorIndex’ 2) Perform the action indicated in ‘actionAcsUiType_02Select’ (consider the value ‘01’ as default behavior if absent) If “uiType” = “03” (Multi Select) 1) Select the item indicated at index ‘multipleSelectorIndices’ 2) Perform the action indicated in ‘actionAcsUiType_03MultiSelect’ (consider the value ‘01’ as default behavior if absent) If “uiType” = “04” (OOB) 1) Perform the action indicated in ‘actionAcsUiType_04OOB’ (consider the value ‘01’ as default behavior if absent) 2) If ‘simulateOobAuth’ is equal to ‘true’ then the Test Environment waits 3 seconds and launch independently the OOB Authentication App and set it in foreground 3) Perform the action indicated in ‘actionOS’ (consider the value ‘00’ as default behavior if absent) For instance: If ‘actionOS’ is equal to ‘01’ then the test environment waits 3 seconds and switches intentionally to set SDK Ui in foreground If “uiType” = “05” (HTML), use the HTML Action GET mechanism to perform the following actions: This mechanism is specified in [Req 37] of the 3DS Specifications [3DS_SDK_Spec_2.2.0], and, in [Req 413] of [3DS_Core_2.3.1]. 1) The cardholder response is emulated with the value of ‘challengeHtmlData’ Example: if ‘challengeHtmlData’ is equal to “submit=verify”, then the cardholder response is “HTTPS://EMV3DS/challenge?submit=verify” If “uiType” = “06” (HTML OOB) (only from 2.3) use the HTML Action GET mechanism to perform the following actions: This mechanism is specified in [Req 413] of [3DS_Core_2.3.1]. 1) The cardholder response is emulated with the value of ‘challengeHtmlData’ Example: if ‘challengeHtmlData’ is equal to “submit=Complete”, then the cardholder response is “HTTPS://EMV3DS/challenge?submit=Complete” © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 35 / 56 2) If ‘simulateOobAuth’ is equal to ‘true’ then the Test Environment waits 3 seconds and launch independently the OOB Authentication App 3) Perform the action indicated in ‘actionOS’ (consider the value ‘01’ as default behavior if absent) For instance: If ‘actionOS’ is equal to ‘01’ then the test environment waits 3 seconds and switches intentionally to set SDK Ui in foreground If “uiType” = “07” (Information) (only from 2.3) 1) Perform the action indicated in ‘actionAcsUiType_07Info’ (consider the value ‘01’ as default behavior if absent) B. OOB Authentication App (from 2.3 product only) The Split-SDK provider needs to implement an OOB Authentication App for test purpose with the following requirements (As specified in 3DS Spec [3DS_Core_2.3.1] section 3.2.2): The OOB Authentication App is accessible through a specific OOB App URL on the same device (this URL have to be provided to TPP for test plan configuration) When launched the OOB Authentication App comes in foreground. As this OOB Authentication App is only for automated test purpose, the behavior of this application is simple: no break, not waiting any cardholder input, during 3 seconds (to allow to have a human verification that the OOB Authentication App is launched and visible in foreground) and ends. o For instance, it would be enough that the application makes a display during 3 seconds of the text “OOB Authentication App is launched and works fine” and then moves forward until the end of its execution without any break and no cardholder interaction At the end: o If the field 3DS Requestor App URL is present in pIni message (Cf 3.1.1. Initialisation flow Management) then (as specified in 3DS Spec [3DS_Core_2.3.1] section 3.2.2.2): The OOB Authentication App uses the 3DS Requestor App URL to automatically transfer control to the 3DS Requestor App when the OOB Authentication App has concluded the Cardholder interaction When the OOB Authentication App invokes the 3DS Requestor App URL, the device OS switches to the 3DS Requestor App that moves to the foreground. The 3DS Requestor App transfers the control back to the 3DS SDK. o If the field 3DS Requestor App URL is NOT present in pIni message (Cf 3.1.1. Initialisation flow Management) then: The OOB Authentication App remain in foreground, not waiting any cardholder input © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 36 / 56 3.1.3. Transaction Verdict Management At the end of the transaction, the Test Client Agent is in charge to provide the Transaction verdict to the Test Environment, through the Proprietary Status Request message pSrq. A. Proprietary Status Request (pSrq) № Field Presence Type/Format Conditional inclusion 1. messageType R Length: 4 character JSON Data Type: String Values accepted: “pSrq“ 2. messageVersion R According to [3DS_Core_2.x.0] 3. p_messageVersion R 1.0.5 4. threeDSServerTransID R According to [3DS_Core_2.x.0] 5. p_isTransactionComplet R ed Type : Boolean Values accepted: true or false 6. p_challengeCancel C Based on [3DS_SDK_Spec_2.x.0] This field is set based on Default-SDK Specification when the callback object ChallengeStatusRecei ver is used and the cancelled method is called (“If the Cardholder taps the Back button (hardware or software) or Cancel button”) Only applicable for DefaultSDK product. Absent for any SplitSDK product Length: 2 numeric characters; Values accepted: 01: cancel the transaction 7. p_challengeTimeout C Based on [3DS_SDK_Spec_2.x.0] This field is set based on Default-SDK Specification when the callback object ChallengeStatusRec eiver is used and timedout method is called. Only applicable for DefaultSDK product. Absent for any SplitSDK product Type : Boolean © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 37 / 56 № Field Presence Type/Format Conditional inclusion Values accepted: true 8. p_protocolErrorCode C Based on [3DS_SDK_Spec_2.x.0] This field is set based on Default-SDK Specification when The protocolError method is called when the 3DS SDK receives such an error message. Only applicable for DefaultSDK product. Absent for any SplitSDK product Type : see [3DS_SDK_Spec_2.x.0] 9. p_protocolErrorMessag C e Based on [3DS_SDK_Spec_2.x.0] This field is set based on Default-SDK Specification when The protocolError method is called when the 3DS SDK receives such an error message. Only applicable for DefaultSDK product. Absent for any SplitSDK product Type : see [3DS_SDK_Spec_2.x.0] 10 p_runtimeErrorCode C . Based on [3DS_SDK_Spec_2.x.0] This field is set based on Default-SDK Specification when The runTimeError method is called when the 3DS SDK receives such an error message. Only applicable for DefaultSDK product. Absent for any SplitSDK product Type : see [3DS_SDK_Spec_2.x.0] 11 p_runtimeErrorMessage C . Based on [3DS_SDK_Spec_2.x.0] This field is set based on Default-SDK Specification when The runTimeError method is called when the 3DS SDK receives such an error message. Only applicable for DefaultSDK product. Absent for any SplitSDK product © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 38 / 56 № Field Presence Type/Format Type : see [3DS_SDK_Spec_2.x.0] Conditional inclusion pSrq example message 1. Challenge Completed Scenario (either Y or N) Called when the challenge process (that is, the transaction) is completed. When a transaction is completed, a transaction status shall be available. So the pSrq would be: { "messageType" : "pSrq", "messageVersion" : "2.2.0", "p_isTransactionCompleted" : true, "p_messageVersion" : "1.0.5", "threeDSServerTransID" : "7d20e188-e05d-40c1-b74c8d53106f1acb" } or { "messageType" : "pSrq", "messageVersion" : "2.2.0", "p_isTransactionCompleted" : false, "p_messageVersion" : "1.0.5", "threeDSServerTransID" : "7d20e188-e05d-40c1-b74c-8d53106f1acb" } 2. Challenge Cancel Scenario (only applicable to Default-SDK products) Called when the Cardholder selects the option to cancel the transaction on the challenge screen. So the pSrq would be: { "messageType" : "pSrq", "messageVersion" : "2.2.0", "p_challengeCancel" : "01", "p_isTransactionCompleted" : false, "p_messageVersion" : "1.0.5", "threeDSServerTransID" : "2b03a052-524b-491c-9d40-c315d5263c2c" } 3. Challenge Timeout Scenario (only applicable to Default-SDK products) Called when the challenge process reaches or exceeds the timeout interval that is specified during the doChallenge call on the 3DS SDK. So the pSrq would be: { "messageType" : "pSrq", "messageVersion" : "2.2.0", "p_challengeTimeout" : "true", "p_isTransactionCompleted" : false, "p_messageVersion" : "1.0.5", "threeDSServerTransID" : "2b03a052-524b-491c-9d40-c315d5263c2c" } 4. Challenge Protocol Error Scenario (only applicable to Default-SDK products) Called when the 3DS SDK receives an EMV 3-D Secure specifications [3DS_SDK_Spec_2.x.0] - defined error message from the ACS. So the pSrq would be: { "messageType" : "pSrq", "messageVersion" : "2.2.0", "p_protocolErrorCode" : "999", "p_protocolErrorMessage" : "ACS Exception", "p_isTransactionCompleted" : false, "p_messageVersion" : "1.0.5", "threeDSServerTransID" : "2b03a052-524b-491c-9d40c315d5263c2c" } 5. Challenge Runtime Error Scenario (only applicable to Default-SDK products) Called when the 3DS SDK encounters errors during the challenge process. These errors include all errors except those covered by the protocolError method. So the pSrq would be: © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 39 / 56 { "messageType" : "pSrq", "messageVersion" : "2.2.0", "p_runtimeErrorCode" : "999", "p_runtimeErrorMessage" : "Runtime Exception", "p_isTransactionCompleted" : false, "p_messageVersion" : "1.0.5", "threeDSServerTransID" : "2b03a052-524b-491c-9d40c315d5263c2c" } 3.1.4. Visual Evidence Management, pErq (Screenshots, Video,…) A. Proprietary Evidence Request (pErq) № Field Description Presence Type/Format Accepted URL Value 1. Video O multipart/form- [root_url_endpoint_path]/video data 2. sdk initialization O multipart/form- [root_url_endpoint_path]/screen/init data 3. CRes rendering O view multipart/form- [root_url_endpoint_path]/screen/cres/[0- data n] * 4. CReq with User O Data before being sent multipart/form- [root_url_endpoint_path]/screen/creq/[0- data n] * 5. sdk process view O multipart/form- [root_url_endpoint_path]/screen/process data 6. OOB app overlay O multipart/form- [root_url_endpoint_path]/screen/oob/[0- data n] * * visual evidences should be indexed in a incremental and chronological order The visual evidence endpoint content type is defined in rfc 7578 (Returning Values from Forms: multipart/form-data). The RFC describes type, format, data. One or multi of them have to be selected according to the design of the System Under Test. In the initialization flow, the field "screenshotRequired” is indicating if evidence have to be taken by the Test Client Agent (Cf .3.1.1). The evidence to validate the expected value requested by the test plan used a transfer object (image or video, at least one format shall be provided by Test Client Agent, preferably the video, both can also be provided). If it is impossible for the Test Client Agent to perform screenshot (restriction due to 3DS SDK or to Operating System) o For the test cases dealing with screenshots, 3DS SDK Product Provider is in charge to perform screenshots with another mean than Test Client Agent, and to provide these assets to TPP. The format of screenshots will be indicated during the execution of the test by the visual Evidence format and depend on the capabilities of the Test Client Agent. The way to provide the screenshots of all evidence from Test Client Agent to the Test Environment is managed by the pErq message. If a video is recorded, then it shall be shared under the path “../video” © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 40 / 56 If screenshots are performed, they have to be structured as indicated below: Under the path “../screen/init”, the sdk initialization screenshot is stored o It matches with the first processing screen o For example : Sample App-based Processing Screen—Portrait Under the path “../screen/cres/[0-n]”, the screenshots of CRes rendering view are stored (each CRes rendering view is indexed) o It is the SDK rendering view before the cardholder filled it o For example: Sample Native UI OTP/Text Template – Portrait Under the path “../screen/creq/[0-n]”, the screenshot just before sending CReq with User Data are stored (each CReq rendering view is indexed) o It is the SDK rendering view after the cardholder filled it o For example: Sample Native UI OTP/Text Template © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 41 / 56 Under the path “../screen/process”, the screenshots just after sending CReq with the processing indicator o It is the SDK rendering view after the cardholder click on a button o For example: Sample Native UI OTP/Text Template Under the path “../screen/oob/[0-n]”, the screenshots after the cardholder have clicked on the button linked to ‘oobAppUrl’. It may be either the OOB Authentication App display or any other display that is performed at that moment B. Examples of pErq messages In these examples, the [root_url_endpoint_path] is equal to ‘https://tpp.com/visual/evidence/endpoint’. Video © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Secure Approval Test Requirements for 3DS Default-SDK and Split-SDK v2.21 Page 42 / 56 POST /visual/evidence/endpoint/video HTTP/1.1 Accept: text/plain, application/json Content-Type: multipart/form-data;boundary=F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB RunTcId: d50dc32b-c723-49ae-aeca-8e29bb1b3ea3 Content-Length: 51000 Host: tpp.com … --F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB Content-Disposition: form-data; name="video"; filename="video.mp4" Content-Type: application/octet-stream Content-Length: 50000 --F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB SDK initialization POST /visual/evidence/endpoint/screen/init HTTP/1.1 Accept: text/plain, application/json Content-Type: multipart/form-data;boundary=F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB RunTcId: d50dc32b-c723-49ae-aeca-8e29bb1b3ea3 Content-Length: 10000 Host: tpp.com … --F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB Content-Disposition: form-data; name="sdk_init_screen"; filename="init.png" Content-Type: application/octet-stream Content-Length: 90000 --F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB Cres rendering views POST /visual/evidence/endpoint/screen/cres/0 HTTP/1.1 Accept: text/plain, application/json Content-Type: multipart/form-data;boundary=F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB RunTcId: d50dc32b-c723-49ae-aeca-8e29bb1b3ea3 Content-Length: 10000 Host: tpp.com … --F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB Content-Disposition: form-data; name="cres_screen_0"; filename="cres_0.png" Content-Type: application/octet-stream Content-Length: 90000 --F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB POST /visual/evidence/endpoint/screen/cres/1 HTTP/1.1 Accept: text/plain, application/json Content-Type: multipart/form-data;boundary=F5O4iEdbpRcUAz9FRYOJlWAzqUZNMx5gB RunTcId: d50dc32b-c723-49ae-aeca-8e29bb1b3ea3 Content-Length: 10000 Host: tpp.com … © 2020-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.
EMV® 3-D Se