How 3D Secure Works

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 t he 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 how 3d secure works docid\ k7fnzbol73ssctbct4nxm frictionless flow the cardholder does not need to enter any additional authentication details t he transaction will follow the frictionless flow frictionless flow 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 or is ), challenge flow 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 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 identifierforvendor on ios 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 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