Netcetera 3DS SDK API

The API of the Netcetera 3DS SDK complies with the API defined by the EMVCo 3DS SDK Specification document. This section describes how the Netcetera 3DS SDK can be used to perform 3DS Authentication of payment or non-payment transactions.


Instance of the Netcetera Android 3DS SDK implementation of ThreeDS2Service can be acquired by calling ThreeDS2ServiceInstance.get(). This implementation holds a single instance of the ThreeDS2Service and every invocation of ThreeDS2ServiceInstance.get() will return the same instance.


In order to use the ThreeDS2Service for further actions, it needs to be initialized with ThreeDS2Service.initialize(...).

contextInstance of Android application context. See Context.getApplicationContext documentation for more information.
configParametersInstance of ConfigParameters created during SDK Configuration.
localeString that represents the locale for the app’s user interface.
uiCustomizationInstance of UiCustomization created during SDK Configuration.

During initialization, security checks are performed and device information is collected. These parameters will be part of the Authentication and will be provided to the ACS via 3DS Server for risk analysis.

For more details about the security checks and their handling, refer to Security Features.

For more details on the device data that is collected, refer to EMVCo 3DS SDK Device Info Specification and EMVCo 3DS SDK Device Info Specification Version 1.4.


After the security checks are performed, the SDK provides the outcome as list of Warning objects.

To obtain the result of these security checks call ThreeDS2Service.getWarnings().

Each of the resulting Warning objects has a Severity with value of LOW, MEDIUM and HIGH and it is up to the integrator to decide whether and how to act on each of them. For more details, please refer to Security Warnings.

The resulting warnings will be provided as a part of Device Info in the Authentication.

Processing Screen

To indicate that a transaction is ongoing (such as ongoing Authentication Request or ongoing Challenge flow), a Processing Screen supplied by the 3DS SDK shall be shown by the requestor application. To get an instance of this processing screen, use Transaction.getProgressView(...). This method must be called from the main thread or else SdkRuntimeException will be thrown.

Processing Screen use cases and requirements for the requestor application:

  • (Required) EMVCo Requirement: While the 3DS Authentication Request is ongoing, the processing screen shall be shown for a minimum of two seconds by the requestor application, regardless of the authentication response time or result.
  • (Recommended) Netcetera 3DS SDK Requirement: If a 3DS Challenge flow is required after the Authentication Request, do not invoke ProgressView.hideProgress() before invoking Transaction.doChallenge(...) as this will lead to a flicker on the screen. The 3DS SDK uses the same processing screen for starting the challenge flow (invokes ProgressView.showProgress() internally if it is hidden). This processing screen is shown by the 3DS SDK until the appearance of the first challenge screen. Furthermore, assuming no exception has been thrown when invoking Transaction.doChallenge(...), the 3DS SDK will hide the processing screen once the challenge is finished (when any of the ChallengeStatusReceiver methods have been called).

These requirements shall be implemented by the 3DS SDK integrator. For example, reference the Netcetera Demo Merchant application.

Note: Calling any method on the ProgressView object will have no effect once a successful Transaction.doChallenge(...) method call has occurred (no exception has been thrown). In this case, the Netcetera 3DS SDK takes control and handles the state of the processing screen.


The 3DS Authentication flow starts with the authentication request that the 3DS Requestor Environment (Application or Library) sends to the 3DS Server. The 3DS Server uses that data to compose the AReq that is sent to the DS and further forwarded to the appropriate ACS.

The ACS evaluates the data provided in the AReq and responds with an ARes message to the DS, which then forwards the message to the 3DS Server. At the end the 3DS Server communicates the result of the ARes message back to the 3DS Requestor Environment.

The 3DS SDK generates authentication parameters that should be used for building the initial Authentication Request. All these parameters should be sent to the 3DS Server, in a format defined by the 3DS Server API. This parameters can be retrieved from the Transaction object.

To obtain instance of Transaction, ThreeDS2Service.createTransaction(...) method can be used.

directoryServerIDThe ID of the Directory Server that will be used. Make sure that there is already a configuration for this DS added in DS Configuration.
messageVersionProtocol version according to which the transaction shall be created. If null, the latest supported protocol version by the SDK will be used.

After the Transaction object has been created, the AuthenticationRequestParameters can be obtained by calling Transaction.getAuthenticationRequestParameters().

The parameters that are part of the AuthenticationRequestParameters are defined in chapter 4.12 in the EMVCo 3DS SDK Specification.

Starting of Challenge Flow

If the ACS assesses the transaction as high-risk, above certain threshold or that it requires higher level of authentication, it forces a Challenge Flow communication.

In case of Challenge Flow, the 3DS Requestor calls Transaction.doChallenge(...), and the SDK takes over the Challenge process. This method must be called on the main thread and before Activity.onSaveInstanceState(...) or else SdkRuntimeException will be thrown.

Once a challenge has been started, invocation on Transaction.doChallenge(...) and Transaction.close() will result in SdkRuntimeException, but the Challenge Flow won't be interrupted nor the Transaction will be put in an invalid state. When any result comes through the ChallengeStatusReceiver, calling of Transaction.doChallenge(...) and Transaction.close() can be called again.

For security purposes, the Activity that hosts the Challenge UI will have screenshots disabled with setting FLAG_SECURE to the Window.

activityThe Activity that is in the foreground of the application.
challengeParametersInstance of ChallengeParameters created with values from the Authentication Response.
challengeStatusReceiverCallback object that implements ChallengeStatusReceiver. It will be notified about the challenge status.
timeOutTimeout interval (in minutes) within which the challenge process must be completed. The minimum timeout interval is defined to be 5 minutes.

Requestor App URL

Starting with version 2.2.0 of the EMV 3DS Specification Protocol, the application (requestor) integrating the 3DS SDK can be called from another (authentication) application during an OOB challenge flow to indicate completed OOB authentication. To use this feature, the requestor application should define its app url and provide it to the 3DS SDK.

The app url can be provided to the 3DS SDK in the challenge parameters via the ChallengeParameters.setThreeDSRequestorAppURL(String threeDSRequestorAppURL) method. The inclusion of the this value in the challenge parameters is optional. If the app url is provided for an irrelevant version of the 3DS Specification Protocol (example version 2.1.0), the 3DS SDK will ignore it.

In order for the 3DS SDK to catch the potential call from the issuer authentication application and act accordingly, the requestor application needs to update the current Intent of the Activity that is used for starting the challenge - Transaction.doChallenge(Activity currentActivity, ...). This can be achieved by overriding the Activity.onNewIntent(Intent intent) method and setting the current intent to the newly received one.

For further information on how to define the threeDSRequestorAppURL value, you can check the EMVCo 3DS Specification.

As an example on how to use and handle the app url on the application side, you can check the Netcetera Android 3DS SDK Demo Application Documentation or its source code.

Challenge Flow Results

After invoking Transaction.doChallenge(...), the Challenge Flow is started and the control of the UI is handed over to the 3DS SDK.

For the Netcetera Android 3DS SDK that means that the Activity provided via the Transaction.doChallenge(...) method should not be finished nor replaced by another Activity.

The DS Requestor has the control back when any of the callback methods from the ChallengeStatusReceiver are invoked.

Implement a callback that implements the ChallengeStatusReceiver interface.

When any of the callback methods of the ChallengeStatusReceiver are invoked, the challenge flow is considered finished. As a result, the 3DS SDK dismisses the challenge screen, closes the transaction, cleans up resources and gives the 3DS Requestor control over the UI.

Closing of the Transaction

After the 3DS Authentication has finished, the 3DS Requestor should close the Transaction by calling Transaction.close() in order to clear references and avoid possible memory leaks.

This method should only be called when the Transaction.doChallenge(...) method is not called in a transaction. If invoked during an ongoing challenge, this method will throw SDKRuntimeException. At the end of the challenge flow, the 3DS SDK takes responsibility to cleanup resources and therefore this method is not required to be called.

After the transaction is closed and resources are cleaned up, any further operation on the Transaction object will result in a SDKRuntimeException.

Cleanup of the ThreeDS2Service

Similar as closing a Transaction, in order to free up resources that are used by the ThreeDS2Service, the ThreeDS2Service.cleanup() shall be used. Once an instance of ThreeDS2Service has freed up the used resources, the instance is in the same state as a newly created ThreeDS2Service and it can be used once again, though it should previously go through the Initialization process.