Authentification 3DS 2.0

Le protocole 3D Secure 2.0 permet de s’assurer que la personne réalisant la transaction est bien le titulaire de la carte. La banque du client analyse les nombreux facteurs liés au paiement adressés par CentralPay (adresse IP, localisation, appareil utilisé…) et les compare aux données habituelles de son client :

• Si les données ne sont pas concordantes ou que le montant de la transaction est important, elle requière une identification manuelle via un code adressé par SMS ou via son application bancaire (« authentification forte » ou « SCA »)
• Sinon, elle autorise directement le paiement (« Frictionless »)

1. Caractéristiques

Il existe deux types de 3DS, selon si vous souhaitez initier une transaction classique (pour laquelle le porteur est présent) ou si vous exécutez une échéance de paiement récurrent (pour laquelle le porteur n’est pas présent) :

1.1. Le 3DS 2 « BRW » ou « Browser Authentication » (porteur participant – 1ère transaction)

Il représente la majorité des intégrations de 3DS 2. Il requiert l’authentification du client afin de vérifier qu’il est bien le porteur légitime de la carte au moment de la transaction. Il déclenche si nécessaire un challenge qui vérifie l’identité du porteur de carte (SCA).

👉 Découvrez comment intégrer le 3DS 2.0 BRW ➝

1.2. Le 3DS2 « 3RI Authentification » (porteur non participant – échéances de paiements récurrents)

Le 3DS Requestor Initiated (3RI) Authentications, ou Authentification Initialisée par le marchand, est utilisée lorsque le porteur n’est pas présent ou non participant.

Le 3RI offre la possibilité de générer les authentifications 3DS nécessaires sans que le client ne soit impliqué. Cela permet d’utiliser une authentification générée précédemment avec un client. Elle est utilisée dans les contextes suivants de paiements récurrents : Paiement fractionné, Abonnement, Refund, etc.

👉 Découvrez comment intégrer le 3DS 2.0 3RI ➝