3DS (3D Secure) technology was first introduced in 1999 to reduce fraud for online transactions. 3D Secure establishes a common communication protocol across the schemes with each scheme attaching its own rules and incentives for 3DS participation.

In its initial version, 3D Secure was viewed by many issuers and merchants as a bump to sales, rather than as a fraud-prevention solution.  This was largely due to its clumsy user experience. However, over the years, the 3DS protocol evolved and subsequently, version 2.0 was released providing a smoother, more frictionless solution with features such as mobile optimization and additional security layers that are designed to work with the technologies of today.

A Proactive Approach

Although 3DS 1.0 and 3DS 2.0 have coexisted for several years with both protocols (still) valid, Visa and Mastercard adopted a different, yet equally proactive, approach towards the adoption of 3DS 2.0. Chiefly, they decided to actively push merchants and issuers to adopt 3DS 2.0 in its highest version and in doing so, abandon 3DS 1.0 by several vectors of operation, the specifics of which will be presented in this article.

3D Secure: A Closer Look

With both schemes sporting the same objective, it’s interesting to note the different approaches taken by Visa and Mastercard to encourage issuers and merchants to implement 3DS 2.0:

Visa focused on issuer and acquirer compliance and assessment, while adding new testing environments to support 3DS 2.0. After ensuring issuer and acquirer readiness, Visa removed merchant fraud liability protection, thereby encouraging merchants to authenticate through Version 2.0. 

Mastercard, on the other hand, took the route of doubling 3DS. 1.0. authentication fees in addition to penalizing acquirers when their 3DS 2.0 ready merchants authenticate with 3DS 1.0, up to a certain level/percentage. They also penalized issuers whose BINs were not all enrolled with 3DS 2.0. This approach is followed by the slow de-commissioning of 3DS 1.0 until the scheme no longer supports it at all. 

Below is a list of all the steps each card scheme put in place to ‘encourage’ the transition from 3DS 1.0 to of 3DS 2.0:

3D secure process



  • Drive issuers to support new version of 3DS 2.1 and later 3DS 2.2
  • Track and assess issuer 3DS 2.0 readiness and performance
  • Mandate acquirers to ensure their e-com merchants can authenticate through 3DS 2.2


All the above steps ensure authentication with 3DS 2.2. For example, under Visa rules, merchants must use the highest version of 3D  Secure supported by the issuer. So, if an issuer supports 2.2. the merchant must also authenticate with 2.2. 

  • Merchant fraud liability protection on 3DS 2.0 transactions, even if European issuers are not live on 3DS 2.0.  This gives issuers incentive to implement 3DS 2.0 promptly to avoid exposing themselves to this risk. 
  • No merchant fraud liability with 3DS 1.0. The liability for fraudulent chargebacks (stolen or counterfeit cards) will not shift from the merchant to the card issuer.


Testing environments
  • Introduce new testing environments to 3DS 2.0 solutions, while discontinuing 3DS 1.0 testing environments. Before moving into production, testing simulation for the 3D secure process allows merchants to validate that the transaction won’t fail.




New fees have been introduced for 3DS 2.0 and SCA, to encourage acquirers and merchants to implement 3DS 2.0

  • A new fee is imposed on merchants sending issuers SCA exemption requests upon authorization without 3DS. This fee incentivizes merchants to send exemptions over 3DS 2.0 and not over authorization. 
  • Doubling 3DS 1.0 authentication fees. Makes 3DS 2.0 transactions more cost-effective.
  • Penalty for acquirers when their 3DS 2.0 merchants authenticate with 3DS 1.0 up to a certain level/percentage. With this step, merchants who support both 3DS 1.0 and 3DS 2.0 will most likely prefer to use 3DS 2.0. 


De-commissioning 3DS 1.0

  • Attempts transactions* will no longer be generated from the Mastercard 3DS 1.0 network. Issuers that still want to support Attempts must generate from their own ACS solution. *Transactions where the bank is not participating in 3DS but the Visa/Mastercard Attempts Server stands in on behalf of the issuing bank and silently authenticates the cardholder.
    • 3DS 1.0 account range/merchant registration to 3DS 1.0 will no longer be allowed.
    • No future processing of any 3DS 1.0 transactions for cardholder authentication.


Credorax’s 3DS 2.0 solution helps merchants trading in the EEA to comply with new SCA requirements under PSD2 by way of:

  • Full compliance with SCA, covering the three verification requirements: 

(1) Information the customer knows: password, PIN; 

(2) Something the customer possesses: card; 

(3) Something the customer is: biometrics – finger prints, facial recognition

  • Reduced fraud – This extra layer of security helps ensure that merchants accept card payments only from legitimate customers.
  • Increased conversion, relative to existing 3DS implementations.
  • User-friendly authentication improves customer experience by authenticating the shopper using various parameters available on the transaction or device and creating a frictionless checkout experience.

For more information on how Credorax can help you with your 3DS 2.0 requirements,

contact us