What is a 3DS SDK? A 3DS SDK is a software library embedded in a merchant’s native mobile app that performs EMV 3-D Secure authentication without a browser redirect. It collects device data, encrypts it with the Directory Server’s key, and renders the challenge screen inside the app when the issuer requires one.
Canonical definition: A 3DS SDK is a software component integrated into a 3DS Requestor mobile app that, within the EMV 3-D Secure protocol, collects and encrypts device information and handles the challenge interaction without leaving the app.
It is the youngest of the four EMV 3DS components and the only one running on the end user’s device. This article explains what a 3DS SDK enables and which requirements – EMVCo approval and PCI security – matter for its provider.
3DS SDK – key takeaways:
- A 3DS SDK exists in two EMVCo specification variants: the Default-SDK (a complete library) and the Split-SDK (divided into client and server parts), both in the release aligned with EMV 3DS 2.3.1.1.
- The SDK collects device data per the separate EMV 3-D Secure SDK – Device Information specification (current data version 1.6) and encrypts it with the Directory Server’s public key, so that only the ACS can access it.
- The SDK never asks the user for consent to access data on its own – it must verify the consent and permissions granted to the 3DS Requestor app, in line with the SDK Device Information markings.
- A 3DS SDK product undergoes EMVCo approval (Default-SDK or Split-SDK testing in a recognised laboratory), and its security is assessed by the separate PCI 3DS SDK Security standard.
- The SDK must implement run-time integrity mechanisms – one of the hard security requirements assessed by the laboratory.
- Patronusec, an accredited QSA, supports 3DS component providers with environment security certification and assessment readiness.
Table of Contents
What is a 3DS SDK and how does it differ from a 3DS Server?
A 3DS SDK is a device-side library, embedded in the merchant’s mobile app (the 3DS Requestor App), that performs the client side of the EMV 3DS protocol: it collects device data and handles the challenge in the app. The 3DS Server runs on the merchant’s server side and builds messages to the payment network – two different components of the same protocol.
The division of roles becomes clear when you trace the flow. The mobile app with the 3DS SDK initiates the transaction: the SDK collects device information, encrypts it, and passes it to the app as authentication request parameters. The app sends these over its own channel to the merchant’s 3DS Server, which only then builds the AReq message and sends it to the Directory Server. When the issuer requires a challenge, the SDK renders its screen inside the app – with no jump to a browser, which harmed conversion in 3DS 1.0.
Historically, on a mobile device, authentication happened by opening the bank’s page in a browser (a WebView). EMV 3DS replaced this with a native SDK: the library renders challenge screens using native system components, handles push notifications and the bank’s biometrics, and the user never leaves the merchant’s app.
The 3DS SDK is the only EMV 3DS protocol component running on the end user’s device – which is why it alone falls under a dedicated security standard for software on consumer devices.
What does a 3DS SDK enable in practice?
A 3DS SDK performs three functions: it collects and encrypts device data for risk assessment, enables native authentication without a browser redirect, and renders the challenge interface inside the app. The result is authentication that is smooth for the user and richer in data for the issuer.
The concrete capabilities:
Device data collection
The SDK gathers the set of elements defined in the EMV 3-D Secure SDK – Device Information specification: system parameters, configuration, identifiers available within the app’s permissions. The rich data set feeds the ACS’s risk assessment and improves the odds of the frictionless path.
Encrypting data to the ACS
The SDK encrypts the collected information with the Directory Server’s public key, so that it stays unreadable as it passes through the app and the 3DS Server – only the ACS can decrypt it. This protects the cardholder’s privacy across the whole chain.
In-app challenge handling
When the ACS requires additional confirmation, the SDK renders the challenge screen natively: a one-time-code field, biometric confirmation, out-of-band authentication via the bank’s app. When done, the SDK hides the dialog itself and returns the result to the app.
Split-SDK support
For scenarios where part of the SDK logic moves to the server, EMVCo defines the Split-SDK – with separate testing and a Device Acknowledgement message extension by which the 3DS Server passes Split-SDK data to the ACS.
The rich device data set collected by the 3DS SDK is the main reason in-app authentication ends on the frictionless path more often than browser-based authentication.
An important privacy limitation: per the specification, the SDK never asks the user for consent to access sensitive data during authentication itself. The 3DS Requestor app is responsible for obtaining consent and permissions and for prominently disclosing the use of data to the user, in line with regulations and operating-system provider policies.
Which EMVCo requirements must a 3DS SDK meet?
A 3DS SDK must pass EMVCo approval under the process for 3DS components: conformance testing in the Default-SDK or Split-SDK variant, performed in an EMVCo-recognised laboratory, ending with the product’s entry on the approved list. Approval confirms conformance with the current protocol specification (2.3.1.1).
The key EMVCo reference documents for an SDK provider:
- EMV 3-D Secure – SDK Specification (Default-SDK and Split-SDK) – defines the information and requirements for app-based solutions,
- EMV 3-D Secure SDK – Device Information – specifies the format and representation of the data the SDK collects; the current data version is 1.6, aligned with the latest operating-system provider APIs,
- EMV 3-D Secure SDK Technical Guide – a practical guide to integrating the SDK with a 3DS Requestor app.
The product approval path mirrors the other 3DS components: registration with EMVCo, conformance testing on a recognised platform and in a laboratory, documentation submission, results review and publication on the approved list. SDK testing covers both the functional layer (flow correctness, data formats) and the required security mechanisms.
The variant distinction matters architecturally. The Default-SDK is a complete device-side library. The Split-SDK divides functions between client and server, letting the provider slim down the device part at the cost of additional communication – the provider chooses the variant based on the integration model and the app’s performance requirements.
Which PCI security requirements matter for a 3DS SDK?
The security of a 3DS SDK is assessed by a separate PCI standard: the PCI 3DS SDK Security Requirements and Assessment Procedures, evaluated by a specialist laboratory (a 3DS SDK Lab). This is a separate track from the PCI 3DS Core Security Standard, which covers ACS, DS and 3DS Server environments – the SDK has its own regime because it runs on the device beyond the provider’s control.
The characteristic SDK security requirements (per PCI SSC documentation and FAQ):
- Run-time integrity. The SDK must implement mechanisms that detect tampering while it runs – one of the hard requirements, whose sufficiency the 3DS SDK Lab assesses.
- Protection of collected data. Device data must be encrypted with the Directory Server’s public key so that it stays unreadable to the app, the 3DS Server and the whole path outside the ACS.
- Consent and permission discipline. The SDK does not initiate its own consent prompts; it verifies the consent and permissions granted to the 3DS Requestor app, in line with the Permission designations in the Device Information specification.
- Resilience to the device environment. The SDK must operate securely even on devices whose state the provider does not control – hence the emphasis on the library’s self-defence mechanisms rather than trust in the system.
PCI 3DS SDK Security is the only PCI standard assessing the security of a payment component that, by design, runs on a device beyond the organisation’s control – which is why it focuses on code self-defence rather than environmental controls.
Patronusec Insight: In our project experience, SDK providers most often conflate two separate assessment tracks. EMVCo approval confirms functional conformance with the protocol, while PCI 3DS SDK Security assesses the library’s resistance to tampering. These are two different laboratories, two different evidence sets and two different schedules. Before you budget for SDK certification, split these tracks in the project plan – treating them as a single line item is the most common cause of slippage.
Who needs a 3DS SDK and who provides it?
A 3DS SDK is needed by any organisation offering EMV 3DS authentication in a native mobile app: merchants with a shopping app, digital wallet providers, PSPs embedding payments in customers’ apps. The SDK provider is usually a specialist technology firm, a 3DS Server provider or a wallet provider.
The usage models in practice:
- A merchant with its own app embeds a ready, approved 3DS SDK to authenticate payments in the app instead of redirecting the user to a browser.
- A 3DS Server provider offers the SDK as part of a package: the customer gets a matched pair of client library and server service, simplifying integration.
- A digital wallet or super-app provider embeds the SDK to authenticate cards added to the wallet within a single, native experience.
For a provider building its own SDK, this is a complex product: it requires EMVCo approval, a PCI 3DS SDK Security assessment and maintained conformance with the evolving Device Information specification (successive data versions aligned with operating-system changes). This justifies the market dominance of specialist providers – building and maintaining a compliant SDK rarely pays off for a single merchant.
Patronusec supports 3DS component providers on the environment security track within its PCI 3DS certification service – from setting the boundary to assessment readiness.
Myth vs fact: what do people get wrong about the 3DS SDK?
MYTH: A 3DS SDK is the same as a 3DS Server, just on the phone.
FACT: A 3DS SDK runs on the user’s device and collects data and handles the challenge in the app. A 3DS Server runs on the merchant’s server side and builds messages to the payment network. They are two different components of the same protocol.
MYTH: The SDK asks the user for consent to access device data itself.
FACT: Per the specification, the SDK never initiates its own consent prompts during authentication. Obtaining consent and permissions and informing the user is the responsibility of the 3DS Requestor app.
MYTH: EMVCo approval is enough to deploy an SDK in production.
FACT: EMVCo approval confirms protocol conformance, but the SDK’s security is assessed by the separate PCI 3DS SDK Security standard in a specialist laboratory. These are two separate tracks.
MYTH: The merchant sees the device data the SDK collects.
FACT: The SDK encrypts data with the Directory Server’s public key so that only the ACS can decrypt it. The merchant and its 3DS Server forward it encrypted, with no visibility into it.
FAQ
How does the Default-SDK differ from the Split-SDK?
The Default-SDK is a complete library performing the SDK functions on the device side. The Split-SDK divides those functions between a client and a server part, letting the provider slim down the device component at the cost of extra communication. EMVCo defines separate test sets for both variants; the choice depends on the app’s architecture and performance needs.
Does every payment app need a 3DS SDK?
No – a 3DS SDK is needed for native EMV 3DS authentication in an app without a browser redirect. An app using browser-based authentication or handing payment to an external gateway can operate without its own SDK. The SDK makes sense where a smooth, native in-app experience matters.
Who can decrypt the device data the SDK collects?
Only the issuer’s ACS. The SDK encrypts the data with the Directory Server’s public key, and the DS private keys are managed by the payment network’s certificate authority. The 3DS Requestor app and the 3DS Server forward the data encrypted, with no visibility into it – which protects the cardholder’s privacy.
What is run-time integrity in a 3DS SDK?
It is a set of mechanisms by which the SDK detects attempts to tamper with its own operation while running on the device. PCI 3DS SDK Security requires their implementation, and the 3DS SDK Lab assesses whether a given solution is sufficient. It answers the fact that the SDK runs outside the provider’s controlled environment.
Does a 3DS SDK fall under the PCI 3DS Core Security Standard?
Not directly. ACS, DS and 3DS Server environments fall under the PCI 3DS Core Security Standard, while the SDK’s own security is assessed by the separate PCI 3DS SDK Security Requirements. These are separate documents and separate assessment tracks, matched to the different nature of the components (a server environment versus a library on a device).
What is the current 3DS SDK specification version?
Not directly. ACS, DS and 3DS Server environments fall under the PCI 3DS Core Security Standard, while the SDK’s own security is assessed by the separate PCI 3DS SDK Security Requirements. These are separate documents and separate assessment tracks, matched to the different nature of the components (a server environment versus a library on a device).
How does Patronusec help 3DS component providers?
We support the environment security track: we set the 3DE boundary, run a gap analysis against PCI 3DS and prepare the organisation for assessment. After a free scope-assessment call we present a fixed-price quote matched to the role and scope. For the SDK product certification itself we point to the right laboratories and help coordinate both tracks.
Recommend reading
A reading path for in-app authentication:
- What is 3-D Secure (3DS) – the roles of ACS, DS and 3DS Server – the foundation: how the whole protocol and its components work.
- MPoC, SPoC and CPoC: a revolution in secure mobile payments – other PCI standards for software on consumer devices.
- PCI Secure Software Framework (SSF): a key standard for payment software security – the wider context of payment software security.
3DS component security – free consultation
Patronusec, an accredited QSA, supports EMV 3DS component providers with PCI 3DS certification. If you are building or deploying a 3DS SDK, book a free scope-assessment call.
Book a consultation | PCI DSS certification | PCI gap analysis
