Menu

3DS 2.0

3D Secure 2 est une nouvelle solution d'authentification apportant une meilleure expérience pour les consommateurs, tout en limitant la fraude. En agrégeant et transmettant des données issues du contexte d'achat à l'émetteur de la carte, le consommateur est censé éviter les frictions liées à une authentification forte. L'émetteur de la carte (la banque) est ainsi en mesure de vérifier que le consommateur est bien la personne en train de payer. 

Ce service devait être initialement mis en place le 14 septembre 2019 mais a été repoussé en France à 2022.
Certains pays pourraient cependant l'intégrer plus rapidement.

C'est pourquoi chez Centralpay, nous sommes déjà prêts !

Ci-dessous quelques explications sur les fonctionnements qui diffèrent de la version 1.0 :

Auparavant pour réaliser une vente 3DS, vous utilisiez le checkEnrollement et obteniez la réponse si la carte était 3DS ou non. Et dans le cas où elle était bien 3DS, vous receviez les éléments pour permettre à l'utilisateur de s'authentifier auprès de sa banque.
Vous constaterez que le sujet s'est complexifié avec la version 2.0.

Nous vous donnons ici les principales étapes.

 

Les grandes étapes du 3D Secure 2.0 :

1) VERSIONING

  • Cette étape consiste à adresser le PAN de la carte à l'API Centralpay
  • En réponse : 
    • Si la carte n'est pas 3DS 2.0, l'opération se rejetée. Vous devrez alors reprendre la transaction en mode V1 avec la demande de checkEnrollement.
    • Si la carte est 3DS 2.0, vous recevrez un UUID identifiant l’opération jusqu’au résultat final + les données nécessaire pour réaliser le "3DS Method" (URL + base64)

2)3DS METHOD

  •  Vous devez faire générer une requête au navigateur client (1 formulaire intégré à un iFrame caché sert de prémisse d’appel dans lequel on insère la donnée base64)
  •   Cette fonction a pour but de poster la donnée base64 reçue du versioning vers l'ACS

3)3DS AUTHENTICATION

  •    Cette requête permet l'envoi des données contextuelles liées au porteur
  •    Réponse possibles d’un statut :
    •   Si OK : récupération des données à envoyer dans la transaction (identique 3DS V1)
    •   Si NOK : refus
    •   Si challenge : reçois  l’équivalent résultat checkEnrolement avec URL et base64

4) CHALLENGE

  • Vous devrez préparer l’Iframe servant à l’affichage du formulaire d’authentification
  • Puis poster le résultat vers l’ACS

5) REPONSE

  • Vous recevrez une notification de fin de challenge avec le statut OK ou KO
  • Le résultat du challenge intégrant les données 3DS dans le cas d'un Challenge OK sera reçu par Centralpay

6) RESULTAT

  •    Pour connaitre le contenu de la REPONSE au CHALLENGE, vous devrez adresser l’UUID identifiant la requête 3DS 2.0
    •   Si OK : récupération des données à envoyer dans la transaction (identique 3DS V1)
    •   Si NOK : refus

 

Pour une compréhension plus large du processus, voici un schéma global. Nous publierons prochainement les objets de l'API permettant d'initier les phases du processus décrit plus haut.