What does 3D (Three Domain) Secure upgraded version 2 bring? Why was 3DS 2.0 originally introduced? In this article, we’ll focus on what technical changes this upgrade requires, as well as what different challenges you might come across in case there are existing 3DS integrations with merchants and acquirers in your system.
When introducing new versions of big software solutions, such upgrades need to bring along clear advantages, so they can balance the many resources needed for implementation. This is especially true in FinTech, where there is a large number of various systems integrations maintained by different entities (companies and institutions alike). Here, I will try to point out these advantages and the reasoning behind the introduction of 3DS 2 by EMV (Europay, Mastercard and Visa).
3D SECURE AND ITS INFRASTRUCTURE AT A GLANCE
Three Domain Secure (more often referred to as 3DS) is a security protocol that has been around in e-commerce for a while now (the first one was set up by Visa in 2001). It is an effort to increase security by adding authentication to online payments, i.e. to ensure the cardholder is really in possession of the card and actually authorizing the payment. European Commission made such authentication procedure mandatory in an effort to reduce online payment fraud.
The main elements of the 3DS infrastructure can be defined based on the role they have in the payment process. More precisely, they are identified based on which party involved in the process is responsible for maintaining them. These categories are known as domains:
- Issuer domain – the most important part of this domain is the Access Control Server (ACS), which is used to check whether the account and the associated card have 3DS enabled. It also facilitates the actual authentication process.
- Acquirer domain is responsible for collecting the payment data and relaying the messages containing this data between the merchant and the issuer. This also includes validating the integrity of the messages and preventing their modification during transmission.
- Interoperability domain is used for keeping some global data, and is usually maintained by the payment network. It includes assigning unique identification to 3DS transactions, providing transaction history data (e.g. those to be used in fraud detection), as well as providing signature certificates as an authority.
WHAT BROUGHT US TO 3DS VERSION 2?
The original implementation of 3DS has faced some criticism, mostly for being too intrusive and creating unnecessary friction during the checkout process, which greatly increased the chance for cart abandonment. Truth is - nobody likes remembering complicated passwords and “special characters are your friends” mantras.
In addition, online payments (known as card-not-present transactions) were sometimes incorrectly marked as fraudulent by banks’ fraud detection systems. Last but not least - there had been technical limitations with verifying the certificate of the HTML frame in which the password prompt pops up. It was very difficult for a customer to identify if the page is a phishing one.
This is when 3DS version 2 comes into the picture.
The second version was designed to provide more data to the issuers, in order to better calculate the risk of the transaction, as well as allow easier checkout. With the increased amount of data, issuers could feed that data to their fraud detection systems and greatly reduce the amount of false declines, which version 1 was notorious for. A more flexible system enabled so-called frictionless flows, which meant checkouts without the need for complicated passwords. Support for all devices enabling e-commerce payments which appeared in the meantime, most notably mobile devices, was also added.
CHANGES REQUIRED IN MERCHANT INTEGRATIONS
If you are – as we do – using a third-party provider of the 3DS system infrastructure, you might find yourself in a specific situation. The third-party providers are used because it would obviously be too expensive to maintain the whole 3DS infrastructure in-house. An alternative to these two options would be to use 3DS integrations of acquirers – but this would be expensive in another sense, because any changes would have to be done in many integrations.
Since we are integrated with a large number of acquirers, let me share our experience with you.
The biggest changes for us, with regards to merchant integration, have been:
- We needed to register every merchant using 3DS with our provider. This was not too complicated, but it required additional information from the merchant, and added another step to an already complicated merchant onboarding process (You can read more about this in my previous blog post).
- As already mentioned, version 2 collects much more data about the cardholder and the processed transaction. As a part of this data collection, a new step had to be added to the payment process. In this step, we collected information about the device used to make a certain payment, as well as the software details (browser, operating system, etc.). This is also known as device fingerprinting. Data collected this way is also stored as reference for future transactions.
- Another important change in the merchant interaction with our API - there was no enrolment check. Enrolment checks would have been the first call made to our 3DS API in the previous version, as their purpose is to check whether the card used for the payment is enabled for 3DS. In version 2, this is done in the same API call as the authentication itself.
As you can see, the latter two changes affect the very basics of integrations with merchants, because they require changes in which API endpoints they call and when. These changes are potentially complicated and expensive for merchants to implement.
CHANGES REQUIRED FROM THE PERSPECTIVE OF A PAYMENT PROCESSOR
After obtaining the cardholder authentication, there were not many changes in the authorization messages sent to the acquiring processors. We needed to add only an indication of which version of 3DS we are using and the directory server transaction identification. The idea was to make the changes only in the authentication flow - in fact, that is where they were necessary. This made upgrading and keeping acquirer integrations up-to-date much easier.
Nevertheless, other challenges and problems appeared during testing of the upgrade, concerning integrations with processors. You can read more about this in an upcoming blog post. Stay tuned!
Since not using 3DS is not an option, due to various regulations, the upgrade to 3DS had to bring specific improvements in areas where problems had been identified in the previous version. In my opinion, it duly delivered. The benefits clearly outweighed the costs of implementing all the necessary modifications. Since version 2 is already in production, there already have been improvements in cart conversion and shorter checkout times.
I would also point out that the development process of this upgrade provided more opportunities. It added value to in-house integration solutions, which can be offered to merchants by merchant integrators: such solutions turn out to be quite valuable when a big software upgrade requires significant API changes. In addition, it showed the importance of implementing integrations in a way they can easily be tested.