Contenu

CU10 - Paiement 3DS en direct

Le principe 

3D Secure est un protocole d'authentification fourni par les systèmes de cartes de crédit.
Le marchand peut demander un mot de passe au consommateur pour confirmer le paiement. Cette procédure permet d'authentifier le consommateur comme étant le porteur de la carte utilisée pour le paiement.  Elle permet de renforcer la sécurité et de transférer la responsabilité au consommateur de la carte en cas d'impayé.

L'authentification se fait en deux étapes : 

• vérification de l'enrôlement de la carte au système 3D Secure ;
• demande d'authentification du consommateur.

La mise en place de 3D Secure doit permettre aux e-marchands de réduire le montant de leurs impayés dus à la fraude, mais cette procédure réduit également le taux des paiements acceptés.

La technique

Cette page présente les deux web services  verifyEnrollment et doAuthorization  permettant d'effectuer une transaction 3DSecure en utilisant le mode interface direct de la solution de paiement Payline.

Pour plus d'information concernant le traitement 3D Secure, veuillez cliquer ici.

1. Votre client valide son panier afin que le marchand prépare la page web ou seront renseignés les données de paiement, en appelant le service Payline « doWebPayment». Un message « VEReq » (Verification enrollment request) permettant l’accès au Directory Serveur  vérifiera l’inscription de la carte dans l’annuaire contenant les cartes déclarées « enrôlées » 3-D Secure et et les URL des ACS correspondants. La réponse « VERes » (Verification enrollment response) contenant le résultat de l’authentification sera retourné au Merchand Plug-in (MPI) pour gérer le dialogue avec le Directory et l’ACS en vue de permettre à l’acheteur de s’authentifier.
2. La demande « PAReq » (Payer authentification request) permet l’accès à l’ACS de la banque du porteur et déclenchera la phase d’authentification.
3. La réponse « PARes »(Payer authentification response), contenant le résultat de l’authentification du porteur de la carte sera transmis au commerçant qui déclenchera une demande d’autorisation et de validation de paiement en appelant le service doAuthorizationRequest qui interrogera la banque acquéreur.
4. En fonction de la réponse de la banque (doAuthorizationResponse), le paiement sera enregistré ou non et la réponse sera transmise à l’acheteur.

Les services utilisés sont doWebPayment et getWebPaymentDetails. Vous devez mettre en place la configuration de notification serveur.

* nom de l'alias donné au contrat VAD du moyen de paiement

Une fois le verifyEnrollment effectué, l'authentification auprès du serveur ACS doit être effectuée. Pour cela, il est nécessaire d'envoyer les informations du verifyEnrollment sur le serveur d'authentification. Les informations attendues par le MPI sont :

• MD : suivi de la session : valeur à récupérer dans la réponse du verifyEnrollment
• PaReq : requête d'authentification : valeur à récupérer dans le verifyEnrollment
• TermURL : adresse où le serveur d'authentification envoie la réponse de l'authentification. Concrètement cette adresse doit être capable de récupérer un formulaire envoyé en « POST » et contenant la réponse de l'authentification de l'utilisateur.

Attention ces valeurs sont générés de manière dynamique et se renouvelleront pour chaque message.

Les services utilisés sont doWebPayment et getWebPaymentDetails. Vous devez mettre en place la configuration de notification serveur.

Exemple du centre administration