How 3D Secure Works
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.
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 .
The cardholder does not need to enter any additional authentication details. The transaction will follow the frictionless 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 or is),

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.
We have implemented the (EMV) 3DS2 protocol and collect the recommended 150 data elements detailed in the (EMV) 3-D Secure-SDK-Device Information Specification document.
See the EMV Specifications & Associated Bulletins 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:
- 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 the consumer taps the PAY button, the payment flow is triggered. The device data is collected at the stage when you call CARD_PAYMENT.
Collecting device data is a requirement of the (EMV) 3DS2 protocol and is only triggered during the 3DS2 payment flow.