Frequently Asked Questions (FAQ)

Netcetera 3DS Server supports all exemptions via: Message extensions for Mastercard 2.1+ version and Authentication Request for all schemes 2.2.0 version programs. On the following link you can find details on the exemptions usage:

TransStatusReason=82 is a Mastercard specific value. It indicates that a challenge is mandated but could not be performed. This happens when in the request, messageCategory = 01 (PA, Payment) and threeDSRequestorChallengeInd = 04 (challenge mandated) but the ACS is unavailable, resulting in the DS throwing the error with transStatusreason = 82. The given issue needs to be troubleshooted with the ACS directly, such that they can check the given query and the reason for the provided response.

According to the EMVCo specification, 3DS Requestor ID and Name are unique identifiers, provided by the Schemes to each 3DS Requestor on an individual basis. Therefore, these two values should be either configured for each Merchant Acquirer in the Admin UI, or should be passed in the transaction payload as part of the Merchant data.

Every scheme has its own instructions about the format of these values. More scheme-specific details are provided here: 3DS Requestor Data.

We recommend following the pre-defined formats. Here, the number of characters and some special characters (if it contains any) are important and need to be considered.

The schemeId is not a mandatory field, however, in case a card is co-branded and hence found in more than one scheme card range, we need you to send the appropriate schemeId for the transaction. Otherwise, we cannot resolve which scheme we should process the request/transaction with.

From 2.5.3.0 version of Netcetera 3DS Server, in the case when the BIN is found in two schemes’ card ranges, (domestic and global) and if the schemeId is not provided, we will process the transaction via the global scheme network. That means, if you want to process through a domestic scheme, you must provide the schemeId.

The 3DS Server checks if a card range is enrolled in 3DS 2.x using the versioning flow. If the card range is enrolled, the transaction should be initiated with the corresponding 2.x protocol version. More information regarding the versioning method can be found here: 3DS Versioning.

The 3DS 2.0 flow is described in more detail here: 3DS 2.x API.

The first step in the flow is 3DS Versioning. The Versioning Response contains, among other fields, the threeDSMethodURL and threeDSMethodDataForm. Using the threeDSMethodData value found in the threeDSMethodDataForm, a request should be initiated to the threeDSMethodURL via an iframe.

Please see below an example of the threeDSMethodData form in the Versioning Response:

After the method completion, the Authentication flow is the next step. The transStatus field of the Authentication Response will indicate whether the transaction is frictionless or requires a challenge (transStatus='C'). In case of challenge, the base64EncodedChallengeRequest field from the Authentication Response should be taken, and a request initiated to the acsURL via an iframe. Here you can see authentication response samples.

After the challenge has been completed, the 3DS Server receives a Results Request from the DS, and generates a Result Response which is sent to the URL configured in the Admin UI. Simultaneously, a final Challenge Response message is sent from the ACS.

For more info on the implementation of browser based flow the Netcetera 3DS Web SDK can be used.

According to the EMVCo specification, the link between the Browser and the ACS for the 3DS Method is opened from a hidden iframe as part of the check-out page. It is used for the ACS to gather device information to be returned to the ACS. This includes the 3DS Server Transaction ID which enables the ACS to carry the information to the correct transaction. The 3DS Method allows for additional browser information to be gathered by an ACS prior to receiving the AReq message, to help facilitate the transaction risk assessment.

For the versioning responses that contain a 3DS Method URL, the 3DS Requestor should invoke the 3DS Method. The 3DS Method call should occur in advance of the AReq message, for the same transaction being sent to the ACS. The ACS will then interact with the Cardholder browser via the HTML iframe and then store the applicable values with the 3DS Server Transaction ID for use when the AReq message is received containing the same 3DS Server Transaction ID.

This means, that according to the specification, wherever you get a 3DS Method URL in the Versioning Response from the 3DS Server the browser should initiate a request to that URL using the threeDSMethodData that is also available in the response via an iframe.

Within the 3DS Method Request form, which is included in the versioning response, valuable information is requested to be sent from the Browser directly to the ACS. This information contains information about browser type, browser IP, browser language and many other information which help the ACS to apply risk transaction analysis. This risk assessment possibility increases the chance of a frictionless authentication, enabling a smoother experience for the user and a higher conversion rate. This is especially the case if a user shops more often with the same device, ideally with the same merchant. Our 3DS Server product provides the 3DS Method Request form and is offered as 3DS Web SDK lightweight JavaScript. It can easily be installed by importing the JavaScript in the html page.

3DS Method Flow: The merchant sends a versioning request to the 3DS Server to find out whether a specific card is enrolled for 3DS 2.x. If this is true, then the 3DS Server will include the 3DS Method form within the Versioning Response including the ACS URL to the browser so that the browser can render the data form and initiate the request to the ACS. This data includes information which helps the ACS to risk assess. As soon as the ACS has gathered the browser/device it will let the 3DS Server know via the 3DS Method response.

Please look at the Excel file - Fields in 3DS - diff 21 vs 22.xlsx

We are expecting card schemes to start sending EMV 3DS 2.3.1 card ranges supported from both ACS and DS, which will result in highestCommonSupportedVersion field in Versioning response to be 2.3.1. In order to be ready for this, since 2.3.1 AReq format for some of the fields is slightly different than its predecessors 2.2.0 and 2.1.0 (please find the differences in the 'Overview of fields in 3DS - difference between 2.2 and 2.3.1 protocol versions' section below), you need to adapt the logic when sending AReq. There are few things to be taken into consideration:

• If you are ready and want to process transactions with EMV 2.3.1 protocol version, then first check whether 2.3.1 is highestCommonSupportedVersion in the Versioning response. If it is, then format the AReq accordingly to 2.3.1 format and set preferredProtocolVersion to 2.3.1. If it is not, then fallback to the highestCommonSupportedVersion returned in Versioning response and format the AReq accordingly.

Netcetera 3DS Server is certified by EMVCo for the 2.3.1 protocol version since March 2023. The LoA can be found here.

Successful processing of 2.3.1 transactions depends on all the 3DS component supporting that protocol version. Therefore, even though the Netcetera 3DS Server is EMVCo certified for the 2.3.1 protocol, there is a dependency to the Directory Server readiness to support such transactions, which can be individual for each scheme. When a Scheme (e.g. Visa, Mastercard) is ready to support 2.3.1 version and releases a guideline for integration, the certification process should be undergone, to additionally certify the Netcetera 3DS Server for that particular scheme. Once the 3DS Server is 2.3.1 certified with a scheme, it will be able to process 2.3.1 transactions for that specific scheme.

Decoupled Authentication Fallback is reaction to failing authentications due to system errors with a fallback solution. A 3DS Requestor can indicate whether it supports the fallback scenario of a decoupled authentication for the case in which the ACS recognizes a connection error that would prevent the cardholder to perform the challenge. Once the ACS detects such an issue it can choose to proceed with a decoupled authentication, which will result in a challenge request to the cardholder at a later point in time, once network issues no longer exist.

SPC (Secure Payment Confirmation) provides a method to perform a challenge using pre-established FIDO credentials when using a Browser. The SPC authentication can be initiated by the 3DS Requestor via an additional AReq/ARes message pair or by the ACS via a standard Browser Challenge Flow.

FIDO (Fast Identity Online) was born from the FIDO Alliance and has become a globally accepted authentication method. The major benefit for cardholders is the option to authenticate with security keys, facial recognition, their voice or fingerprint rather than using static or dynamic passwords. With EMV 3-D Secure 2.3.1, FIDO authentication is enabled within the 3DS browser flow, which means that cardholders can authenticate much faster and with less friction, while profiting from a very high security standard.

The new data fields introduced with EMV 3DS 2.3.1 (e.g. seller info, recurring data, EMVCo token information) support issuers with identifying and approving transactions. Business models using recurring transactions have expanded over time and could no longer fit into the existent flow. However, with the new protocol version, businesses can indicate their use case more precisely by e.g. stating that the recurring date varies and the recurring amount is not fixed. Similarly, the travel industry was involved in defining of data elements for travel message extensions, such that these businesses can be more precise about what the cardholder authenticates. Furthermore, the response sent from ACS back to the merchant can now include information as to which exemption was applied, indicated by a new data field in the authentication response. This will help merchants better understand the decision-making process when applying for exemptions.

Please look at the Excel file - Fields in 3DS - diff 22 vs 23.xlsx

If you are not ready or you do not plan to process transactions with EMV 2.3.1 protocol version, then you should send preferredProtocolVersion to version lower than 2.3.1 even if highestCommonSupportedVersion from the Versioning response is 2.3.1. If you send transaction with preferredProtocolVersion 2.3.1 (or latest) and AReq is not in 2.3.1 format, you will experience transactions failure. If you are sending latest as preferredProtocolVersion, then please adapt the logic on your side, since this option is now deprecated and will be removed after 6 months because of the differences between EMV 2.3.1 and 2.2.0 message format, and as previously mentioned, if AReq is in 2.2.0 format and preferredProtocolVersion is sent as latest, this will result in transactions failure if DS and ACS both supports the latest protocol version (2.3.1).

There are two possible adaptation in order to avoid having failed transactions:

• Always send 2.2.0 as a preferredProtocolVersion.
• Introduce a logic to choose preferredProtocolVersion out of highestCommonSupportedVersion returned in the Versioning response.

As a prerequisite for processing 3DS 2.x transactions, the acquirer should enroll the merchants to Mastercard using their ISSM tool (other schemes such as Visa, Amex, Diners do not require prior merchant enrollment). The merchants and acquirers can be configured in the Admin UI for each scheme, or alternatively the merchant data can be sent directly in the payload (please refer to the example models for AReq (3DS 2.x).

For 3DS 2, merchants’ enrollment is done via Mastercard ISSM tool. The Mastercard Merchant Enrollment API enables acquirers and their service providers to manage merchant participation in Mastercard Identity Check on EMV 3-D Secure (3DS 2.0). Acquirers and service providers can add or delete merchants directly in Mastercard ISSM by sending the enrollment data through API Interfaces, up to approximately 20,000. More details on the API can be found in Mastercard bulletin - AN 3264 - Identity Check Merchant Enrollment Application Program Interface.

The enrolment process from different vendors depends from the service provider MID structure. ISSM, the application tool for merchant enrolment does not allow duplicate MID/BIN entries. If the service providers all are using the same MID/BIN combo for the Areq then it only needs to be enrolled once.

Further information about the requestor data can be found here:

Visa provided information that they don’t require prior enrollment of merchants. The merchant information (id and name) should be part of self-assigned requestor information and should be sent during the Authentication Request message. We already have the service provider part of the requestor information. The attached 3DS requestor document provides more information on this topic.

Further information about the requestor data can be found here:

Amex does not require enrollment of merchants anymore.

Further information about the requestor data can be found here:

Onboarding of merchants with Discover/Diners is done by uploading an excel file with the merchant data. If the merchants are already enrolled in 1.0, Discover would need the information on the merchants that support 2.0 and vendors from which the transaction is processed (related with reference number).

Starting from October 2020 onwards, the merchant’s enrollment is not mandatory, and the merchant data can be provided directly in the request payload.

Similarly to Mastercard, if the 3DS Server is operated by two different service providers, there will be two different Operator IDs, which are associated with the merchant during the enrolment process.

Further information about the requestor data can be found here:

UnionPay does not have a merchant enrollment process, since they let the acquirer or processor manage their merchants. However, necessary data elements (e.g. the Acquirer Merchant ID) should be sent in the transaction payload.

If different vendors are processing with the same merchant, they need to make sure that the authentication and authorization match, meaning that the Acquirer Merchant ID used in the authentication should be consistent with the one in the authorization.

Further information about the requestor data can be found here:

Every enrollment of Acquirer/PSP requires a dedicated project towards JCB, where they perform a full authentication and authorization test plan. More information can be provided by JCB once the customer is identified.

If the acquirer merchant is not successfully registered with the scheme, the following error may appear:

Additional information about the requestor data can be found here:

The Digital Authentication Framework (DAF) outlines an approach for a consistent and verifiable set of transaction data that can increase issuer confidence and facilitate risk decisions that may lead to increased approval rates and lower fraud.

Merchants participating in DAF using EMV 3DS will need to:

• Support EMV 3DS 2.1 or higher (is enabled by Netcetera 3DS Server)
• Support the DAF message extension in the authentication layer (is enabled by Netcetera 3DS Server)
• Support Field 34 in authorization (Optional)
• Support Visa Merchant ID

In Europe where PSD2 SCA applies to a transaction, a merchant/TR can only submit a transaction (domestic/intra-regional) under the DAF if:

• SCA has been completed either:
  • Under the VisaDelegatedAuthenticationProgram(VDAP)
  • Under an agreement in force with issuers for SCA delegation
• Or:
  • The transaction is eligible for an Acquirer Strong Customer Authentication (SCA) exemption

For more information please contact your Visa representative.

Acquirers are responsible for registering their merchants for DAF EMV 3DS. To register for DAF EMV 3DS, a merchant’s acquirer must retrieve and confirm their Visa Merchant ID (VMID) with Visa. For details on program requirements or registration process please refer to the Digital Authentication Framework page of Visa Online (VOL). Issuers will be mandated to support Visa DAF starting from April 2023. Under the Digital Authentication Framework (DAF), issuers are liable for fraud on authenticated transactions that meet DAF requirements.

For more information please contact your Visa representative.