Skip to main content
Commerce Security Authority
Category: 3-D Secure

3DS SDK

Also known as: 3DS SDK, 3-D Secure Software Development Kit, EMV 3DS SDK, 3-D Secure SDK
Simply put

A 3DS SDK is software that a merchant embeds inside a mobile app to help authenticate a cardholder when they make an in-app purchase. It supports the EMV 3-D Secure process, which is intended to help reduce card-not-present fraud in e-commerce and mobile payments while aiming for a smoother checkout experience. It handles the exchange of information needed for authentication rather than performing the authorization or approval decision itself.

Formal definition

A 3DS SDK is a software development kit embedded in a merchant mobile application that facilitates cardholder authentication for EMV 3-D Secure (3DS 2.x) transactions, as defined in the EMVCo EMV 3-D Secure SDK specifications. It manages the app-side interactions of the 3DS message flow, supporting data collection for risk-based (frictionless) authentication and challenge flows intended to help mitigate card-not-present fraud. Security requirements and testing procedures for 3DS SDKs are governed by the PCI 3DS SDK Security Standard, which is distinct from PCI DSS and other PCI standards; the SDK addresses the authentication step and does not itself perform authorization, and its use does not eliminate fraud. Practitioners should confirm applicable requirements against the current published EMVCo and PCI 3DS SDK documents.

Why it matters

As commerce shifts increasingly toward mobile apps, cardholder authentication has to happen inside environments that differ substantially from browser-based checkout. A 3DS SDK gives merchants a standardized, testable component to support EMV 3-D Secure authentication directly within a mobile app, rather than relying on redirects or workarounds that can degrade the user experience. This matters because card-not-present transactions carry different fraud risks than card-present ones, and authentication at the app layer is one of the controls intended to help reduce that exposure.

The distinction between authentication and authorization is central to why this component exists and what it can be expected to do. A 3DS SDK handles the app-side exchange of information used in the EMV 3-D Secure flow; it does not perform authorization or make the approval decision, and its presence does not eliminate fraud. EMV 3-D Secure is intended to help mitigate card-not-present fraud and increase the security of e-commerce and mobile payments, but it addresses only the authentication step and should be understood as one layer within a broader fraud and security program.

Because the SDK sits inside merchant software and handles sensitive interactions, its security posture is governed by the PCI 3DS SDK Security Standard, which defines security requirements and testing procedures and is distinct from PCI DSS and other PCI standards. Practitioners should confirm applicable requirements against the current published EMVCo and PCI 3DS SDK documents rather than assuming a fixed set of controls, as standards and specifications are updated over time.

Who it's relevant to

Mobile app developers and merchants
Merchants building or maintaining mobile apps that accept card-not-present payments integrate a 3DS SDK to support in-app EMV 3-D Secure authentication. They are responsible for correct integration and for understanding that the SDK addresses authentication, not authorization, and does not eliminate fraud on its own.
Fraud and risk teams
Teams managing card-not-present fraud exposure rely on EMV 3-D Secure, supported by the SDK's data collection, to enable risk-based authentication decisions. They should treat it as one control within a layered program and weigh frictionless versus challenge flows against customer experience and residual fraud risk.
Compliance and security assessors
Those evaluating 3DS SDKs work against the PCI 3DS SDK Security Standard, which defines specific security requirements and testing procedures and is distinct from PCI DSS and other PCI standards. They should confirm scope and requirements against the current published EMVCo and PCI 3DS SDK documents.
SDK vendors and 3DS solution providers
Vendors that build 3DS SDKs for embedding in merchant apps design to the EMVCo EMV 3-D Secure SDK specifications and validate against the PCI 3DS SDK Security Standard, so that merchants can process EMV 3DS 2.x transactions with a tested, standards-aligned component.

Inside 3DS SDK

3DS SDK
A software development kit provided for integration into a merchant or wallet mobile application to enable EMV 3-D Secure authentication within the app. It is a component defined under the EMV 3-D Secure specification and governed, from a security validation standpoint, by the PCI 3DS SDK requirements, which are separate from PCI DSS.
Device and app data collection
Functionality used to gather device information from the consumer's device to support risk-based authentication and to inform the issuer's decision on whether to challenge the cardholder. What is collected and how it is handled depends on the implementation and applicable specifications.
Challenge flow handling
The SDK facilitates presentation of a challenge to the cardholder when the issuer requests one, such as prompting for additional verification, as part of the 3-D Secure authentication process. This addresses authentication at the transaction-approval stage and is distinct from EMV chip authentication, strong customer authentication frameworks, and general multi-factor authentication.
Secure communication interfaces
Interfaces used by the SDK to exchange data with other 3-D Secure components such as the 3DS Server and Directory Server. The security expectations for these interfaces fall under the relevant PCI 3DS security requirements rather than PCI DSS.

Common questions

Answers to the questions practitioners most commonly ask about 3DS SDK.

Does the 3DS SDK perform the actual authentication or risk decision for a transaction?
No. The 3DS SDK is a component embedded in a merchant or 3DS Requestor mobile app that facilitates the 3-D Secure message flow between the app, the 3DS Server, and the issuer's Access Control Server (ACS). It handles device data collection and the presentation of any challenge, but the authentication risk decision is made by the issuer domain, typically the ACS, not by the SDK itself. Readers should confirm the roles of each 3DS component against the current PCI 3DS Core Security Standard and the applicable EMVCo 3-D Secure specification.
Is the 3DS SDK governed by PCI DSS?
Not directly. 3-D Secure and its components, including the SDK, fall under the PCI 3DS program and the EMVCo 3-D Secure specification, which are separate from PCI DSS. PCI DSS governs the protection of cardholder data in the broader payment environment. A given implementation may still have PCI DSS scope considerations depending on what data it touches, but the SDK's security requirements themselves derive from the 3DS framework rather than PCI DSS. Confirm applicability against the current published standards, as scope depends on implementation and validation.
How is the 3DS SDK integrated into a mobile app?
The SDK is typically incorporated into a native mobile app by the developer as part of the 3DS Requestor environment, where it works with a 3DS Server to initiate authentication requests and, when required, render challenge interfaces to the cardholder. The precise integration steps, supported platforms, and interface requirements are defined by the EMVCo 3-D Secure specification and the SDK provider. Verify the current requirements and any conformance obligations against the applicable published specifications rather than assuming a fixed process.
What is the difference between a frictionless flow and a challenge flow when using the SDK?
In a frictionless flow, the device and transaction data collected and transmitted through the SDK and 3DS Server are assessed by the issuer domain without requiring direct cardholder interaction. In a challenge flow, the issuer determines that additional verification is needed, and the SDK is used to present a challenge to the cardholder within the app. Which flow occurs is decided in the issuer domain based on its risk assessment, not by the SDK. The specific behaviors are defined in the EMVCo 3-D Secure specification.
Does implementing a 3DS SDK reduce fraud on its own?
The SDK is one part of a 3-D Secure authentication flow that is intended to help issuers assess and, where appropriate, verify cardholder identity in card-not-present transactions. It may help reduce certain card-not-present fraud, but no single control eliminates fraud, and detection-based decisioning in the issuer domain involves false-positive and false-negative trade-offs. The SDK also does not address other fraud types such as account takeover, first-party or friendly fraud, or synthetic identity fraud. Any liability implications are governed by card brand and network rules, which vary by region and change over time.
What security considerations apply to a 3DS SDK implementation?
Because the SDK operates within a mobile app and participates in the authentication message flow, its implementation is subject to the security requirements defined by the PCI 3DS program and the EMVCo 3-D Secure specification, which address matters such as the protection of data handled by the SDK and its interfaces. The exact controls, conformance, and validation expectations should be confirmed against the current published standards, as requirements differ between versions and specifications.

Common misconceptions

A 3DS SDK is validated under PCI DSS.
The 3DS SDK is associated with EMV 3-D Secure and its security is addressed under the PCI 3DS program requirements, which are separate from PCI DSS. PCI DSS, PA-DSS, the PCI Software Security Framework, and PCI 3DS are distinct standards, and readers should confirm applicable requirements against the current published standard.
Integrating a 3DS SDK prevents card-not-present fraud.
3-D Secure authentication is intended to help reduce certain card-not-present fraud by supporting cardholder authentication and, in some cases, liability shift, but it does not eliminate fraud. Liability shift and related rules are governed by card brand and network rules that vary by region and change over time, and it does not address other fraud types such as account takeover, friendly or first-party fraud, or synthetic identity fraud.
The 3DS SDK is just another form of encryption or tokenization for cardholder data.
The 3DS SDK supports authentication of a transaction and is not a data-protection mechanism like tokenization, encryption, truncation, masking, or hashing. Those techniques transform or reduce stored cardholder data differently and have different effects on PCI DSS scope depending on implementation and validation.

Best practices

Confirm which PCI standard applies to your 3DS SDK integration and validate against the current published version rather than assuming a fixed requirement number, since numbering and wording differ between versions.
Ensure any data collected by the SDK does not result in improper storage of sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PINs, which must not be stored after authorization even when encrypted.
Treat 3-D Secure as one layer within a broader fraud-prevention strategy, and combine it with other controls rather than relying on it alone to address card-not-present fraud.
Verify that communication between the SDK and other 3-D Secure components, such as the 3DS Server and Directory Server, meets the applicable PCI 3DS security requirements.
Monitor challenge flows for false-positive and false-negative trade-offs, recognizing that added friction can affect legitimate cardholders while gaps can allow fraudulent transactions.
Track changes to card brand and network rules on liability shift by region, and update integration and risk assumptions accordingly rather than relying on fixed assumptions.