Computop KPI for 3-D Secure
We have taken care to make the optimization approaches of the new protocol measurable.
How are my payments made up?
The first two dashboards provide an overview of the proportions of the various protocols and their performance.
Proportion of payments according to the protocol
|non-3DS||Payments without 3DS|
|1.x||Payments using the "old" 3DS protocoll|
|2.x||Payments using the new 3DS protocoll|
You can hide different versions in the diagram by clicking on the icons in the table area, so that you can only see the comparison between 3DS 1.x and 3DS 2.x, for example:
Performance der Versionen
The diagram shows the volume of transactions by protocol and lists the results of the authentication as a bar chart. With a mouseover you can see a small table view of the breakdown.
The lower area shows you in a table according to the protocol version:
- Authentication failures
- Successful authentications
- Successful Attempts: 3DS was started, but the cardholder is not registered for 3DS
In addition to the total number, you can also see the number of transactions and the response codes depending on the protocol version.
Easy authentication: Frictionless
The greatest added value for customers and dealers, namely simple processing, comes from the introduction of so-called "frictionless" payments. The card issuer saves the end customer from having to authenticate. The "Authentication Type" diagram shows you how this feature performs.
On the right side you can see the results of the cardholder authentication at a glance.
Please note that the messages "Frictionless" and "Dynamic" are new components of 3DS 2: If you would like to shed light on this aspect, please select the protocol version 3D 2.x in the filters.
Description of the values:
Issuer has not prompted card holder to go through authentication process
Issuer challenges authentication with static password
Issuer challenges authentication with a dynamic password, usually SMS or TAN or OTP
|03||Out of Band|
Authentication is performed in another device, e.g. the user is shopping in desktop/laptop and the authentication is performed via the banking app on the mobile phone
Usually for MOTO transactions: the authentication is performed separately from the request
Authentication Type could not be retrieved.
Fallback means that 3-D Secure authentication via the new EMV 3-D Secure 2.x was not possible (e.g. issuer is not ready, cardholder has not yet registered). To save your checkout, our platform will switch to the older 3-D Secure 1.x. The table shows the sums of the payments that were processed with the incoming 3-D Secure version ("Started") and the 3-D Secure version used for authentication ("Processed").
Since this function is only available in the new protocol, please select "3DS Verion Started 2.x" as the filter
Country level analysis
We have prepared the following evaluation so that you can see details including the affected countries and payments. In addition to the map countries, you can see the development of the protocol usage in a timeline.
If you are interested in the key figures for a country, simply click on it in the list and you will see all the key figures for that country.
We will show you the development of this feature in the processing of so called "Soft Declines". These are credit card payments that have been automatically repeated after they have been rejected by the issuer with "Soft Decline". This means: the issuer rejects an authorization without customer authentication and insists on a 3-D Secure transaction. In addition to the number, you can also see successful authorizations via the different views.
Details on handling for a payment transaction that has been rejected with "Soft Decline" can be found on this page in the section: Soft decline handling.