Scénarios
Vous pouvez utiliser l’API REST 3D Secure 2 pour authentifier un titulaire de carte pour les requêtes d’achat sans carte (CNP) en ligne. Vous pouvez ainsi traiter, via l’API Paiements par carte, des transactions mobiles ou basées sur un navigateur qui sont entièrement conformes aux normes 3D Secure 2 et SCA.
Flux de navigateur
Les exemples ci-dessous décrivent les étapes de certains processus typiques de l’API 3D Secure 2 basés sur un navigateur.
API à utiliser : 3D Secure 2 + Cartes
Ce scénario illustre un processus typique dans lequel l’émetteur de la carte n’impose pas de défi au titulaire de la carte et où ce dernier est authentifié avec succès. Ce nouveau flux rationalise l’expérience de paiement du consommateur en réduisant les étapes supplémentaires de vérification du client pour les transactions à faible risque.
Dans le scénario ci-dessus, le marchand utilise l’API 3D Secure 2 pour collecter l’empreinte digitale de l’appareil et authentifier le titulaire de la carte. L’émetteur de la carte détermine qu’il a reçu suffisamment de données contextuelles pour procéder à l’authentification sans demander de vérification supplémentaire de la part du client (défi) et renvoie status=COMPLETED, threeDResult=Y, et les paramètres authenticationId avec les autres champs. Dans ce cas, le marchand doit consulter la matrice Transfert de responsabilité pour déterminer s’il doit procéder ou non à la requête d’autorisation.
API à utiliser : 3D Secure 2 + Cartes
Ce scénario illustre un processus typique dans lequel l’émetteur de la carte n’impose pas de défi au titulaire de la carte et où ce dernier est authentifié avec succès.
Dans le scénario ci-dessus, le marchand utilise l’API 3D Secure 2 pour collecter l’empreinte digitale de l’appareil et authentifier le titulaire de la carte. L’émetteur de la carte considère la requête comme une transaction à haut risque et émet un défi. Les paramètres status=COMPLETED, threeDResult*=C et sdkChallengePayload sont renvoyés au marchand avec les autres champs. Le marchand transmet le sdkChallengePayload par le biais de la fonction challenge de la SDK JavaScript, puis recherche le résultat en utilisant le paramètre authenticationId une fois le défi terminé. En fonction du résultat, le marchand doit consulter la matrice Transfert de responsabilité pour déterminer s’il y a lieu de procéder à la requête d’autorisation.
* L’API 3D Secure 2 de Paysafe Group et la SDK JavaScript 3DS sont capables de prendre en charge les émetteurs de cartes qui ne sont pas encore passés de 3DS 1.0.2 à 3DS 1.0.2. La SDK JavaScript est capable d’interpréter les champs en fonction de la version 3DS utilisée et de gérer le flux en conséquence. Cette solution de repli est intégrée de manière transparente dans la SDK JavaScript, de sorte qu’il n’est pas nécessaire d’adapter le flux d’authentification.
Pendant la procédure de repli, le paramètre threeDResult est remplacé par le paramètre threeDEnrollment pour gérer la vérification de l’inscription requise pour 3DS 1.0.2.
- Si le serveur répertoire renvoie threeDEnrollment=N ou U et status=COMPLETED, l’authentification est terminée et le marchand doit consulter la matrice Transfert de responsabilité pour déterminer s’il y a lieu de procéder à la requête d’autorisation.
- Si le serveur répertoire renvoie threeDEnrollment=N ou U et status=COMPLETED, l’authentification est terminée et le marchand doit consulter la matrice de transfert de responsabilité pour déterminer s’il y a lieu de procéder à la requête d’autorisation.
- Si le serveur répertoire renvoie threeDEnrollment=Y et status=PENDING, l’émetteur de la carte a envoyé un défi au titulaire de la carte et le marchand doit poursuivre le flux de défi.
Flux mobiles
A venir!