Business Overview

The Split-SDK presents an alternative architecture approach to the Default-SDK. While it functions like the 3DS Default-SDK, as defined in the EMV® 3-D Secure—SDK Specification, what sets the Split-SDK apart is the division of the functionalities between a client-side component (Split-SDK Client) and a server-side component (Split-SDK Server).

The Split-SDK vendor has the choice of the split of functions and interfaces between the server side and client side. This approach not only facilitates development, but also minimises the need for frequent client-side updates, which makes it an ideal choice for Merchants with large-scale mobile application deployment.

Compared to the Default-SDK, the Split-SDK approach streamlines the development and maintenance efforts. For most SDK updates (i.e., bug fixing), the 3DS Requestor should be able to make the changes on the Split-SDK Server, thus reducing the need to push an application update to all Consumer Devices.
The Split-SDK architecture is declined in several variants to facilitate its integration and use in a wide range of e-commerce channels and devices, including IoT devices such as smart speakers. This adaptability ensures a consistent user experience across different platforms and devices, catering to evolving consumer preferences. Businesses can leverage this flexibility to reach new markets and engage with customers in innovative ways.

The only constraint in the split of the SDK functions between the server and the client is that the encryption of Cardholder inputs during a challenge must be performed by the Split-SDK Client. If the Split-SDK Client cannot securely encrypt the Cardholder inputs, the Split-SDK is flagged as Limited. For a Limited Split-SDK, the range of allowed Authentication Methods is limited to those that are dynamic (static Authentication Methods such as password are not supported).

By securing connections with the ACSs and encrypting sensitive Cardholder data, the Split-SDK ensures that transactions are conducted in a secure environment. From an ACS point of view, there are no functional differences between a Default-SDK and a Split-SDK, as message exchanges and challenge screen rendering are identical.

However, implementing the Split-SDK does come with some challenges, particularly involving Device Information. The Merchant and Split-SDK servers must provide accurate and reliable Device Information (Platform Provider-specific Parameters), in particular, Device ID and User ID, to maintain the efficiency of the ACS authentication process.

Benefits by Actor

Merchant
  • Having most of the updates and/or bug fixing centralised on the Split-SDK Server facilitates the operation as there is no need to update all the Split-SDK clients (and 3DS Requestor App) compared to the Default-SDK.
Issuer
  • The ACS directly receives an identifier for the Cardholder and for the Cardholder’s device, which facilitates risk analysis.