Ne pas confondre authentification de l'acheteur et autorisation

Nous avons souvent des réclamations de marchands qui nous expliquent que le porteur s'est correctement authentifié, mais que le paiement a été ensuite refusé et que c'est de notre faute.

L'authentification dans le cas de 3D Secure a pour but, comme son nom l'indique, de vérifier que l'acheteur est bien le porteur de la carte.
Différents procédés d'authentification existent à ce jour, mais pour respecter la DSP2, ces procédés vont se durcir, voire se compliquer, mais ce n'est pas le sujet de cet article.

Pour authentifier un porteur, on se base sur le numéro de carte et la date d'expiration de la carte.
Tous les serveurs d'authentification ne contrôlent pas la date d'expiration (vrai en Espagne, plutôt faux en France), mais à partir du numéro de carte, l'émetteur de la carte va contrôler que l'acheteur est vraiment le porteur.

A ce jour, la méthode la plus répandue (et plutôt déclarée non conforme à la DSP2) est le SMS.

Une fois que le porteur est authentifié, il revient sur la plateforme de paiement pour l'autorisation.

Deux choses importantes:
  • la plateforme de paiement ne gère pas l'authentification mais la délègue à l'émetteur (banque du porteur)
  • le cryptogramme n'est absolument pas contrôlé à ce stade et il n'est jamais envoyé au serveur d'authentification.

Une fois authentifié, nous récupérons dans le flux de réponse en cas d'authentification positive différents champs (XID, CAVV/UCAF, ACS version, TID..) qui nous permettent de faire une demande d'autorisation avec le CVV et les données 3DS.

Sans les champs en provenance du serveur d'authentification, il n'y aura jamais de transfert de garantie.
La bonne construction de la demande d'autorisation est vitale et l'envoi des tous ces champs spécifiques n'est pas forcément simple à traiter. Les agréments servent aussi à cela. 

Certains marchands appellent souvent le support pour nous expliquer que notre passerelle de paiement ne fonctionnent pas, car l'autorisation est refusée

Authentifier n'est pas autoriser

L'émetteur de la carte même si le porteur est authentifié va appliquer ses contrôles de solde, d'encours, de nombre de paiements sur la période, etc...

et bien évidemment générer des refus

Refus qui n'ont rien d'anormal mais que l'émetteur doit pouvoir expliquer à son porteur.
Nous ne savons en général jamais expliquer le code retour sauf quand il n'a pas argent sur son compte ou qu'il a dépassé son encours. 

Il est donc préférable , au lieu  de demander l'analyse des codes retour de refus, de conseiller votre client à contacter sa banque directement pour connaitre la raison du refus. (banque qui accusera souvent la plateforme, mais c'est juste l'histoire du service client qui ne veut pas être dérangé😉😉)

Commentaires