Comprendre authenfication réussie et autorisation refusée sur le code 59
Le support est souvent interrogé par des marchands qui disent qu'il est impossible d'avoir un code retour 59 pour suspicion de fraude alors que le porteur s'est correctement identifié.
Voici par exemple, la réclamation d'un marchand:
Je viens de constater que le paiement d'un très
ancien client parfaitement fiable avait été refusé pour "suspicion de
fraude", ce qui est sans aucun doute une erreur. Avez vous plus d'information sur la raison de cette
suspicion ?
D'abord nous ne faisons jamais d'erreur sur les codes retour émetteur. L'émetteur de la carte répond à la demande d'autorisation et son code retour n'est jamais modifié par la plateforme de paiement. On ne fait que le restituer.
Que fait l'authentification 3Dsecure?
A partir du numéro de carte et seulement du numéro de carte, nous interrogeons le Directory Serveur (DS) de la marque de la carte (soit Visa, MasterCard, AMEX ou bientôt le Directory Serveur du GIE CB qui a lancé le sien dans le cadre de la DSP2).
Cette interrogation n'utilise que le numéro de carte et rien d'autre parmi les données saisies par l'acheteur.
La réponse nous permet de savoir si la carte est enrôlée et de récupérer l'adresse du serveur d'authentification de l'émetteur de la carte.
Une fois que nous avons cette url, nous proposons au navigateur de l'acheteur de faire une redirection vers le serveur de l'émetteur de la carte (ACS). Dans cet appel, sont transmis le numéro de carte et la date d'expiration.
Certains ACS contrôlent la date d'expiration. D'autres non comme cela est le cas pour Atos.
Dans l'exemple ci-dessous, j'ai volontairement saisi une date erronée, mais je suis invité à m'authentifier. Pas de contrôle de date. Je ne sais pas dire si l'absence de contrôle a pour but de lutter contre la fraude et ne pas permettre aux fraudeurs de jouer avec la date. De toute façon l'ACS bloque la carte au bout de x tentatives infructueuses.
Par expérience, les ACS espagnols contrôlent eux la date et rejettent l'authentification en cas de date incorrecte.
Une fois authentifié, et une fois que l'internaute est revenu sur la plateforme de paiement, nous pouvons faire une demande d'autorisation en transmettant la date et le cryptogramme visuel (CVV) à l'acquéreur.
Avant cette étape le CVV n'a jamais été contrôlé, ni transmis à qui que ce soit.
En cas de CVV faux, l'émetteur utilise en général le code 59. Mais ce code n'est pas limité à ce seul cas.
En conclusion, le client est surement fiable, mais il s'est trompé dans sa saisie soit de la date ou plus vraisemblablement du CVV.
Commentaires
Enregistrer un commentaire