What's new with 3DS 2.2

3DS is a security protocol used to authenticate users to protect card-not-present transaction scenarios against fraud, stymie unauthorized transactions, and reduce chargebacks.

We've recently finished a feature-set allowing us to support the latest version of 3DS (Three-Domain Secure): 3DS 2.2. We already partially supported version 2.1.

Summary

Why was this necessary?

3DS 1 will be decommissioned late 2021 and no new BINS will be enrolled in 3DS 1 next year, 2022.

Upgrades that come with 3DS 2.2

  • Greater fraud prevention with 10x more data points Already in 3DS 2.1
  • MIT (Merchant Initiated Transactions) Already in 3DS 2.1
  • 3DS 2.2 allows greater number of options to authenticate New in 3DS 2.2
  • Allows the merchant to request additional exemption through the Acquirer New in 3DS 2.2

In Detail

According to the 3DS1 to 3DS2 Roadmap:

  • From October 2021, Card Schemes will start decommissioning 3DS 1
  • From 30 April 2022, no new BINS will be enrolled in 3DS 1

Already incorporated in 3DS 2.1

  • Greater fraud prevention with 10x more data points

    Allowing you to approve/decline transactions based on broader risk-level parameters rather than just basing outcomes on the SLI (Service Level Indicator)s.

  • MIT (Merchant Initiated Transactions)

    Also called 3RI (3DS Requestor Initiated) payments became possible with 3DS 2.1. However, different schemes had different implementations.

    3DS 2.2 goes a notch higher by standardizing the implementation and allowing more edge-case handling detailed below.

  • Transaction Risk Analysis is at limited capability

3DS 2.2 improvements

  • MIT (Merchant Initiated Transactions)

    As for partial shipments, for example, subsequent payments will be processed as 3RI Payments not necessitating initial authorization on the full amount as was the case for 3DS1.

  • Transaction Risk Analysis is now at full capability

3DS 2.2 new features

  • 3DS 2.2 allows greater number of options to authenticate

    By supporting authentication for transactions across a range of user interfaces (e.g. mobile apps) and devices, you are now able to deliver a richer streamlined user experience.

  • Allows the merchant to request additional exemption through the Acquirer

    PSPs can make full use of exemptions such as transaction risk analysis and trusted beneficiaries, by use of Delegated Authentication.

Implementation (API specific)

Transaction Outcomes

Now there are 3 transaction outcomes to expect:

  • Approve (Including transactions with Merchant Liability remaining with the merchant i.e. SLI 210)
  • Decline
  • Challenge or Soft Decline (Reason Code 65)

Data points (at the point of Transaction)

These data points are to be considered during a transaction process:

  • DE 48 SE 66 SF 1- Program Protocol (3DS1 or 3DS2)*
  • DE 48 SE 66 SF 2 – DS Transaction ID
  • DE 48 SE 43 – UCAF Leading Indicators*
  • DE 48 SE 42 – Security Level Indicator (SLI)*

* partially covered in Tutuka systems as at 24/06/2021 (DD/MM/YYYY)

Last Updated: 7/1/2021, 2:52:21 PM