Service d'authentification du porteur (mode expert)

Présentation

Le Web Service PCI/Charge/Authenticate a pour but d'authentifier le porteur de la carte de paiement en utilisant le protocole d'authentification supporté par le moyen de paiement.

Le service authentifie le porteur de carte et renvoie les informations d'authentification à la fin du processus.

Protocoles supportés

D'autres protocoles d'authentification pourront éventuellement venir compléter cette liste.

Principe général

Le service adopte un principe de fonctionnement qui fait abstraction du protocole sous-jacent pour permettre une intégration unique, et non pas une intégration par protocole.

La cinématique générique d'une authentification complète peut être décomposée en plusieurs étapes :

• un appel initial au service PCI/Charge/Authenticate avec une réponse de type AuthenticationResult ou AuthenticationInstruction.
• si le retour est de type AuthenticationInstruction, c'est une opération qu'il convient de réaliser côté marchand :
  • création d'une iFrame visible ou invisible
  • dans l'iFrame, redirection du navigateur vers la cible avec un formulaire qui suit la définition présente dans l'instruction
  • interaction éventuelle avec le porteur de carte, ou le navigateur
  • page de retour du serveur distant qui émettra un événement JavaScript contenant le résultat de l'instruction
  • interception du résultat de l'instruction sous forme d'événement JavaScript dans la page parente
  • nouvel appel au service PCI/Charge/Authenticate avec le résultat signé de l'instruction obtenu via le navigateur
  • le service PCI/Charge/Authenticate renvoie alors à nouveau soit une instruction soit un résultat
• si le retour est de type AuthenticationResult, alors celui-ci contiendra le résultat d'authentification final et le processus est terminé.

Diagramme détaillé

Le diagramme suivant détaille un scénario générique de paiement avec une authentification: l'appel initial au service, une instruction, une interaction, un résultat final d'authentification et la fin du paiement.

Glossaire

3DS Method	Code JavaScript de l'ACS exécuté dans le navigateur de l'acheteur à des fins de fingerprinting.
3DS Requestor	Demandeur lors d'une authentification 3DS, généralement le marchand ou sa passerelle de paiement.
3DS Server	Serveur 3DS. Composant du domaine du 3DS Requestor qui démarre le processus 3DS v2 et communique avec le DS ou l'ACS lors de l'authentification de transactions. Il facilite l'interaction entre le 3DS Requestor et le DS.
ACS	Access Control Server. Composant qui vérifie si l'authentification est disponible pour un numéro de carte et authentifie des transactions spécifiques.
Application 3DS Requestor	Application sur dispositif mobile de l'acheteur qui peut traiter une transaction 3DS grâce à l'usage du SDK 3DS. L'application est possible grâce à l'intégration avec le SDK 3DS.
Challenge	Phase d'authentification interactive entre l'acheteur et sa banque (ACS).
CReq	Message 3DS v2 de demande d'authentification du porteur de carte, envoyé à l'ACS.
DS	Directory Server. Composant qui maintient la liste d'intervalles de cartes pour lesquels une authentification peut être disponible et qui permet aux MPIs / 3DS Servers / ACS de communiquer entre eux lors des authentifications.
Fingerprinting	Littéralement "prise d'empreinte". Identification de manière unique de l'acheteur grâce à des informations du navigateur.
SDK 3DS	Kit de développement 3D Secure. Composant software inclus dans une Application 3DS Requestor.
IAN	Notification de serveur à serveur qui permet d'obtenir le résultat de l'authentification (Instant Authentification Notification).
operationUrl	Url transmise à la méthode d'initialisation du script d'authentification kr-authenticate.js.
operationSessionId	Identifiant unique de la session d'authentification.