What the 3DS Split-SDK Is and Which Implementations Need It
Most app-based 3DS integrations use a single SDK embedded in the merchant app. That model assumes a capable device running one of the two dominant mobile operating systems, with enough processing power to perform cryptographic operations locally.
Plenty of things that take card payments do not fit that description. The 3DS Split-SDK exists for them, and it is one of the least understood parts of the protocol, partly because most people never need it and partly because it has variants that behave quite differently.
The basic idea
The Split-SDK divides SDK functionality between a client component running in the consumer’s environment and a server component, rather than holding everything in the app. It is defined in its own specification alongside the standard SDK specification.
The practical effect is that the client side can be much lighter, which makes 3DS viable in environments where a full SDK is not.
Three client types, and the distinction matters
The Split-SDK has three client variants, and the difference between them determines which capabilities are available.
The native client runs as native code on the device.
The browser client and the shell client are coded as JavaScript executing in a browser iframe or a web view.
That implementation difference has a direct consequence. Because browser and web view environments can support the cryptographic functions of the 3DS SDK, those two variants can perform the cryptography themselves. The native client cannot always.
The Limited option
This is the part worth understanding properly, because it is where the real constraint sits.
The Limited option applies to devices that are not capable of supporting cryptographic functions such as key generation and encryption of challenge request messages.
It is only applicable to the native client. Because the browser and shell variants run in environments that can support 3DS cryptography, the Limited option is not applicable to them.
And there is a significant behavioural consequence: a Limited SDK or Limited Split-SDK only supports dynamic challenges. Static data, such as a password, is not supported.
Read that constraint against your authentication strategy. If your issuer challenge configuration relies on a static credential, a Limited implementation cannot present it. Dynamic challenges only means one-time passcodes, out-of-band approvals and similar, not anything the cardholder knows and types from memory.
For anyone evaluating whether a constrained device can participate in 3DS at all, that is the question to answer first, because it shapes the whole issuer-side experience rather than being an implementation detail.
Device data outside the two main platforms
The Split-SDK is closely tied to a specific part of the device information specification.
From version 1.6 of the SDK device information specification, the platform provider-specific parameters are specified for use with a Split-SDK implementation. In earlier versions those fields were acknowledged to be sent where the common parameters and the device platform-specific parameters were not applicable.
The intent is to enable device data sharing outside iOS and Android devices, which are typically attributed to Split-SDK usage.
There is also guidance for the reverse case. Where a standard default SDK identifies an operating system that is not aligned with the iOS or Android-specific fields, use of the platform provider-specific fields is encouraged, and EMVCo has said this will be clarified in a future version of the device information specification.
So if you are building for anything that is not a mainstream phone, this is the parameter set you will be populating.
How a Split-SDK behaves across protocol versions
A useful piece of cross-version guidance for mixed estates.
A Split-SDK certified to version 2.3.1.1 may be used in a version 2.2 authentication. In that case it behaves like a version 2.2 default SDK from the ACS point of view, which means all the version 2.2 interface requirements and challenge message formats should be supported.
There is an additional step attached. In that situation the 3DS Server should use the Device Acknowledgement Message Extension to indicate the use of the Split-SDK to the ACS.
That is worth flagging to anyone planning this, because the extension only works where the components in the path support it, so the cross-version arrangement has a dependency beyond the SDK itself.
One integrity detail
Where a Split-SDK is in use, an additional piece of signed content is present in the authentication request, generated by the Split-SDK and validated by the Directory Server. It is one of up to three places the SDK transaction identifier can appear in an app-based request, alongside the value supplied by the 3DS Server and the value inside the encrypted device data.
The identifier is present in the encrypted and signed content specifically to prevent replay attacks, and EMVCo strongly recommends the Directory Server verify that the value is the same across all three.
For an issuer, the presence of that signed content is also how you know a Split-SDK was involved, which is context worth having when interpreting device data that looks unusual.
Do you need it
Probably not, and that is the honest answer for most readers.
The Split-SDK earns its complexity where the consumer environment cannot host a full SDK: constrained or embedded devices, platforms outside iOS and Android, or architectures where the client must stay minimal. If your integration is a standard mobile app on a mainstream phone, the default SDK is the right choice and this article is background.
Where it does apply, the sequence of questions is: which client variant fits the environment, whether the device can support cryptographic functions or requires the Limited option, whether dynamic-only challenges are acceptable to the issuers you route to, and whether the platform provider-specific device parameters give the ACS enough to assess risk with.
Frequently Asked Questions
What is the Limited option for?
Devices that cannot support cryptographic functions such as key generation and encryption of challenge request messages. It applies only to the native client, because the browser and shell client variants run as JavaScript in environments that can support 3DS cryptography.
What can a Limited implementation not do?
Present static challenges. A Limited SDK or Limited Split-SDK supports only dynamic challenges, so anything relying on static data such as a password is unavailable. That constrains the issuer-side challenge experience, not just the client implementation.
Can a Split-SDK certified to a newer version work in an older environment?
Yes. A Split-SDK certified to version 2.3.1.1 may be used in a version 2.2 authentication, where it behaves like a version 2.2 default SDK from the ACS point of view, with the version 2.2 interface requirements and message formats supported. The 3DS Server should also use the Device Acknowledgement Message Extension to signal the Split-SDK to the ACS.
Which device data does a Split-SDK send?
The platform provider-specific parameters, specified from version 1.6 of the device information specification for use with Split-SDK implementations. Their purpose is to enable device data sharing outside iOS and Android devices.
Building 3DS into a non-standard client environment? ActiveSDK is the GPayments mobile 3DS SDK. Speak with a 3DS specialist about client architecture.
