---
title: How 3D Secure Works
slug: how-3d-secure-works
docTags: 
createdAt: 2025-01-31T12:01:25.872Z
---

:::hint{type="info"}
We support all versions of the 3D Secure protocol up to and including version 3DS2.2
:::

In the 3D Secure 2 payment flow, the issuer will make a decision on whether they have enough authentication data to proceed with the transaction, or if they require the cardholder to further authenticate, meaning the transaction is to be **challenged**.

***

## To Challenge or Not To Challenge?

3D Secure 2 introduces **frictionless** authentication.

This is when the transaction is to be approved **without the need** for the cardholder to enter additional authentication details.

The acquirer, issuer, and card scheme are able to **exchange the necessary information** in the background, using the [device data](docId\:K7FnZbol73SsCtbct4NXM) .

***

### Frictionless Flow

The cardholder does not need to enter any additional authentication details. The transaction will follow the **frictionless&#x20;**&#x66;low.

![frictionless flow](https://api.archbee.com/api/optimize/QGXTyW3MgdNcMjdEa0v8r/PkRX0x-MZ66R5p0KAOKTf_frictionless-authentication-flow-hres.png)

***

### Challenge Flow

If additional SCA checks are required from the cardholder, the transaction will follow the **challenge** flow.

An iframe (or similar prompt) will be presented to the cardholder to input additional authentication (something the cardholder **knows**, **has&#x20;**&#x6F;r **is**),

![challenge flow](https://api.archbee.com/api/optimize/QGXTyW3MgdNcMjdEa0v8r/1Oebil47FtTkJUPoYsjJX_challenge-authentication-flow-hres.png)

***

## Device Data Collection

When authenticating a 3D Secure 2 card payment, Judopay collects **specific device data** captured via Judokit and our Android and iOS SDKs. We share these details with both the card network and issuing bank.

This is an (EMV) 3DS2 protocol requirement, enabling the card network and issuing bank to recognise repeat transactions from the same device, **mitigating transaction risk**.

***

### What Device Data is being Collected?

We have implemented the (EMV) 3DS2 protocol and collect the recommended **150 data elements&#x20;**&#x64;etailed in the **(EMV) 3-D Secure-SDK-Device Information Specification&#x20;**&#x64;ocument.&#x20;

See the [EMV Specifications & Associated Bulletins](https://www.emvco.com/specifications/) page to search for the latest specification document.
This information is used in risk analysis by the card schemes and card issuing banks.

Among the data elements collected by Judopay's Judokit are key browser details such as:

- IP address
- User agent
- Browser language
- System time zone
- Screen dimensions
- Colour depth

For in-app payments, our Android and iOS SDKs collect the following key details among others, recommended in the **(EMV) 3-D Secure-SDK-Device Information Specification**:

- App-specific device ID:
  - [identifierForVendor](https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor) on iOS
  - [ANDROID\_ID](https://developer.android.com/reference/android/provider/Settings.Secure#ANDROID_ID) on Android 8.0 or higher
    **Any apps installed on a previous version to Android 8.0, will observe a global ANDROID\_ID instead of an app-specific value.**
- Device model
- OS version
- System language
- System country
- System time zone
- Screen dimensions

The Android and iOS SDKs encrypt the device data using a key held by the card network. Judopay’s servers do not have access to this data.

As per the (EMV) 3DS2 protocol, the Android and iOS SDKs perform basic checks to detect rooted devices. Only the Boolean value representing whether the check succeeded or failed, is transmitted to the server.

The components of the Android SDK involved in 3DS2 transactions are obfuscated.

***

### When is the 3D Secure 2 Device Data Collected?

When the consumer taps the **PAY&#x20;**&#x62;utton, the payment flow is triggered. The device data is collected at the stage when you call **CARD\_PAYMENT**.

:::hint{type="info"}
Collecting device data is a **requirement of the (EMV) 3DS2 protocol** and is only triggered during the 3DS2 payment flow.
:::

