Back in 2001 VISA introduced 3D Secure (3DS) to provide issuers and merchants a way to authenticate the cardholder participating in eCommerce payments. This standard is now upgraded and referred to as 3D Secure 2.0 (3DS 2.0).
Initial introduction by EMVCo on 3D Secure 2.0 announced that 3D Secure 1.0 is in the phase-out stage and will no longer be supported after 31.12.2020.
This timeline crosses its path with the new PSD2 directive taking place and demanding further upgrades of 3D Secure. The result is 3D Secure 2.0 being fully compliant with PSD2 regulation on eCommerce and mobile payment channels.
A more detailed timeline leading to the current transition is explained in our previous blog post dealing with the issuer side of the transition process.
The prolongation of transition period is causing headaches for payment gateways since Payment Gateway is initiating 3D Secure transactions, but initial 3DS access points differ for 3DS1 and 3DS2 authentication. That means that Payment Gateway needs to be integrated with two APIs, but also manage the transaction logic. For instance, since initially PGW does not know whether the card is enrolled in 3DS1 or 3DS2 (or both), authentication must be first initiated in 3DS2. If 3DS2 authentication cannot proceed, PGW must initiate a 3DS1 transaction.
With Asseco 3DS Server Single Access Point Facade, Payment gateway needs to be integrated only with one API using one message protocol and initiating 3DS authentication transaction only once. In case when the card is not enrolled in the 3DS2, facade will initiate 3DS1 transaction to dedicated MPI (Merchant Plug-in), and provide the final Authentication Response to the Payment Gateway. Asseco 3DS Server Single Access Point Facade is flexible to be integrated not only with Asseco SEE MPI and Asseco SEE 3DSS, but also with third-party MPI and 3DSS.