The rise in eCommerce and mCommerce volumes over the last few years has seen a corresponding rise in fraud due to the card-not-present (CNP) nature of online payments.
The global average fraud rates for eCommerce sales (2015) were around 0.53%. This may not sound like a huge amount but if you take into account the fact that eCommerce sales are expected to reach $2.3 trillion by the end of 2017, which means the value of eCommerce fraud could rise to over $12 billion.
The majority of this fraud can be attributed to CNP transactions. In countries with a large presence of online merchants, CNP fraud makes up an overwhelming majority of the total fraud figures, as demonstrated by these stats for the UK (69%), Canada (79%) and Australia (77%).
(Source: US Payments Forum)
The extent of online fraud, however, is not surprising. CNP transactions carry a greater security risk not only because of the difficulty of verifying the identity of the purchaser but also of determining whether or not the purchaser is actually the authorised cardholder.
The 3D Secure protocol, which is one of the oldest and most robust technologies used in the fight against CNP online fraud, has been available since 2001.
Although the core purpose of the protocol is to protect the consumer by providing an authentication layer to prove that the cardholder used their card at the time of the transaction, it also offers protection for merchants against fraudulent chargebacks.
This protection comes in the form of a potential liability shift from the merchant to the card issuing bank.
It is important to remember that this protection is only provided for fraudulent chargebacks and does not apply to any non-fraudulent consumer claims.
The point at which the liability shift occurs is not the same in all instances and differs depending on factors such as the card provider, whether or not a specific card is already enrolled in a 3D Secure program and the response received from the authentication request.
So how does liability shift work with 3D Secure?
With the current version of the protocol (3DS1), whether or not a liability shift is permitted will depend on the results of two steps.
In the first step, the merchant sends a request to the cardholder’s issuing bank to find out if a specific card has been enrolled in its 3DS program. To do this, the merchant needs to implement a certified merchant plug-in, which will handle the authentication messaging with the bank, through a 3D Secure vendor, on their behalf.
Enrolment query requests will either be returned with a definitive ‘Yes’ or ‘No’ unless the card issuer is unable to provide the status of the card, in which case the response will come back as ‘unavailable’. If ‘Unavailable,’ Visa and MasterCard differ on whether or not liability has shifted from the merchant to the issuer.
In the second step the actual 3D Secure cardholder authentication takes place. Again, the request comes back with a definitive ‘Yes’ (authentication successful) or ‘No’ (authentication failed) unless a system or network error occurs, in which case the response could come back as ‘Authentication error’ or ‘Authentication attempted’.
A combination of the results of step one (card enrolment) and step two (authentication status) determine if liability shift is to occur.
Generally speaking, the rules are as follows:
- If a card issuer confirms that a card is enrolled under 3D Secure and the cardholder authentication is successful, then the liability shifts from the merchant to the card issuer (e.g. bank). The guidelines suggest that the merchant proceeds with authorisation of the payment.
- If the card is enrolled and the merchant attempts authentication of the cardholder but for any reason the issuing bank is unable to respond, the liability still shifts to the card issuer and the merchant can proceed with authorisation of the payment.
- If, however, the issuer confirms enrolment but the cardholder authentication process fails, liability remains with the merchant and the merchant is advised not to authorise the transaction.
- When a card is enrolled but an error occurs during the authentication process at the merchants end (such as a network error or the purchaser closes the pop-up /in-line window during the verification step), liability remains with the merchant.
In this case there is no clear failure of authentication and it is at the merchant’s discretion as to whether they wish to continue with the transaction or not.
- Similarly, if the issuer is unable to confirm the card enrolment status, no liability shift occurs and the responsibility lies with the merchant. Again, there is no definitive authentication failure so it is up to the merchant to determine the threat level and decide if the transaction should go ahead.
- The final situation is when the card issuer confirms that a specific card is NOT enrolled. In this instance, major card companies like Visa and MasterCard say that liability shift has occurred and the issuer will be liable for any fraudulent chargebacks.
Effects of 3D Secure 2 on liability shift
Although early adoption of 3DS2 is expected to take place in the latter stages of this year, it will mostly be a period of testing and refining of the protocol before it is fully rolled out.
The global program activation date is 12 April 2019 and until then the existing liability shift rules of the original 3DS1 protocol will stay in full effect.
However, there will be a minor change to liability shifts once 3DS2 is officially rolled out, which could have major benefits for merchants, protecting them against fraudulent chargebacks.
As it currently stands, if a merchant attempts authentication and the issuer supports 3DS2 but is unable to respond (system unavailable), the merchant will enjoy protection from fraudulent chargebacks.
If the issuing bank DOES NOT support 3DS2, no liability shift will occur and the responsibility will still be with the merchant. However, after 12 April 2019, this changes and the merchant will have full fraud-related chargeback protection, even if the issuer does not support 3DS2.
A buyer authentication solution, such as 3D Secure, is still the best way to reduce fraud in CNP purchases. It not only safeguards the consumer against fraudulent purchases but also offers a level of protection for the merchant through liability shift.
This level of protection will be extended with 3DS2, to add further value, and makes the protocol irreplaceable in today’s online economy.
