3DS 2.0 Authentication

The 3D Secure 2.0 protocol ensures that the person performing the transaction is indeed the cardholder. The customer’s bank analyzes numerous payment-related factors sent by CentralPay (IP address, location, device used, etc.) and compares them with the customer’s usual data:

• If the data does not match or the transaction amount is significant, it requires manual identification via a code sent by SMS or via the banking application (“strong authentication” or “SCA”).
• Otherwise, it directly authorizes the payment (“Frictionless”).

1. Characteristics

There are two types of 3DS, depending on whether you wish to initiate a classic transaction (where the cardholder is present) or if you are executing a recurring payment installment (where the cardholder is not present):

1.1. 3DS 2 “BRW” or “Browser Authentication” (participating cardholder – 1st transaction)

It represents the majority of 3DS 2 integrations. It requires customer authentication to verify that they are the legitimate cardholder at the time of the transaction. It triggers a challenge if necessary to verify the cardholder’s identity (SCA).

👉 Discover how to integrate 3DS 2.0 BRW ➝

1.2. 3DS2 “3RI Authentication” (non-participating cardholder – recurring payment installments)

3DS Requestor Initiated (3RI) Authentication, or Merchant-Initiated Authentication, is used when the cardholder is not present or not participating.

3RI offers the possibility to generate the necessary 3DS authentications without customer involvement. This allows for the use of an authentication previously generated with a customer. It is used in the following recurring payment contexts: Split payment, Subscription, Refund, etc.

👉 Discover how to integrate 3DS 2.0 3RI ➝