1. Home
  2. Knowledge Base
  3. Ecommerce
  4. 3D Secure (3DS): Everything you need to know

3D Secure (3DS): Everything you need to know

What is 3DS?

There has been a significant rise in CNP (Card Not Present) and Ecommerce volumes the past few years, as more and more consumers move to offering payment acceptance online. Due to the nature of these transactions, there has been a corresponding rise in fraudulent activity.

CNP transactions naturally carry a greater risk when it comes to online fraud, namely due to the difficulty of identifying not only the identity of the purchaser, but whether the purchaser is in fact the authorised cardholder.

The 3D Secure Protocol (3DS) is designed to help protect the consumer by adding an authentication layer to prove that the cardholder used their card at the time of the transaction and also provide the merchant with protection against fraudulent chargebacks. In doing so, the liability is shifted from the merchant to the cardholders issuing bank.

It is important to note that for merchants, whilst 3DS provides protection against fraudulent chargebacks, this does not provide protection against other non-fraudulent consumer claims.

The point at which the liability shifts is dependent on a number of factors including who the card provider/issuer is, whether or not the card is registered in a 3DS program and also the response that is received from the transaction authorisation request.

How does the liability shift with 3DS?

Whether or not the liability shifts with 3DS, is dependent on two factors.

The initial step, is when the merchant sends a transaction authorisation request to the cardholders issuing bank to determine whether a specific card has been registered for 3DS. In order to do this, the merchant must have a certified 3DS platform (such as Pay.Link) which handles the authentication messaging with the bank via a 3DS secure vendor.

These authorisation requests return either a ‘Yes’ or ‘No’ as to whether the card is registered for 3DS, unless the card issuer is unable to provide the status of the card, in which case the response can be configured to either a) process the non-3DS registered card or b) decline the transaction.

If the merchant decides to process the non-3DS registered card, they accept the risk in doing so. The card schemes Visa/MasterCard differ on whether or not the liability has shifted from the merchant to the issuer.

During the second step, the actual 3DS cardholder authentication takes place. The request that is returned should be a definitive ‘Yes’ (authentication successful) or ‘No’ (authentication failed) unless a system/network error occurs, in which the response could return as ‘Authentication error’ or ‘Authentication attempted’.

Typically, 3DS operates as follows;

  • If the card issuer confirms that the card is registered for 3DS and the cardholder successfully authenticates the transaction, the liability shifts from the merchant to the card issuer (issuing bank).
  • If the card is registered for 3DS and cardholder authentication fails as a result of the issuing bank not responding, the liability shifts to the card issue and the merchant can proceed with the transaction.
  • If the issue confirms 3DS registration however the cardholder authentication fails, liability remains with the merchant and therefore we advise not to proceed with the transaction (unless the merchant accepts the risk).
  • Should a card be registered for 3DS however an error occurs during the authentication process at the merchants end (e.g network error), the liability remains with the merchant.

If there is no clear failure of the authentication step, is it at the merchants discretion as to whether they proceed with the transaction or not.

Was this article helpful?

Submit a Comment

Your email address will not be published. Required fields are marked *

Need Support?

Can't find the answer you're looking for?
Contact Support