Échec de 3D Secure avec une carte crypto : causes et solutions

Lors d'un achat en ligne ou du règlement d'un abonnement avec une carte de paiement en cryptoactifs, une situation déroutante peut se produire : le solde de la carte est suffisant, son numéro et sa date d'expiration ont été correctement saisis, mais la page de paiement affiche « 3D Secure authentication failed » ou « Authentication unsuccessful ». Il arrive même que le titulaire ait terminé la vérification de son identité sans que le paiement aboutisse.

Ces messages ne désignent pas nécessairement le même problème. La transaction peut avoir été interrompue pendant l'authentification 3D Secure, ou avoir franchi cette étape avant d'être refusée lors de l'autorisation du paiement.

Pour identifier la cause, il faut d'abord déterminer à quelle étape l'échec est survenu. Cela permet ensuite de savoir s'il convient de vérifier les paramètres de la carte, de contacter le commerçant ou de solliciter l'émetteur.

Que signifie réellement un échec d'authentification 3D Secure ?

3D Secure (3DS) est un protocole d'authentification destiné aux transactions par carte bancaire sur Internet, aujourd'hui principalement fondé sur la norme EMV 3-D Secure. Il permet aux commerçants, prestataires de services de paiement, réseaux de cartes et émetteurs d'échanger des informations d'authentification afin de contribuer à vérifier que la personne effectuant le paiement est autorisée à utiliser la carte.

Le service correspondant de Visa s'appelle Visa Secure, tandis que celui de Mastercard porte le nom de Mastercard Identity Check.

Une authentification 3DS classique emprunte généralement l'un de ces deux parcours :

• Parcours sans friction (Frictionless Flow) : l'émetteur évalue la transaction à partir de signaux de risque, notamment son montant, les informations relatives à l'appareil et les données du commerçant, sans intervention supplémentaire du titulaire.

• Parcours avec challenge (Challenge Flow) : le titulaire doit confirmer son identité par une action supplémentaire, par exemple en saisissant un code à usage unique (OTP), en approuvant l'opération dans l'application de l'émetteur ou en utilisant une autre méthode d'authentification prise en charge.

L'absence de fenêtre demandant un code ne signifie donc pas que le commerçant n'a pas utilisé 3DS. L'authentification a pu être effectuée en arrière-plan, ou ne pas avoir démarré correctement. Il faut examiner le résultat d'authentification transmis par le prestataire de services de paiement pour déterminer ce qui s'est réellement passé.

Pour une présentation technique de ces deux parcours, consultez le livre blanc d'EMVCo consacré à EMV 3-D Secure.

L'authentification et l'autorisation du paiement sont deux étapes distinctes

3DS assure l'authentification (Authentication), tandis que l'autorisation du paiement (Authorization) détermine si la transaction peut être approuvée.

Même lorsque le titulaire a correctement saisi son OTP ou confirmé son identité dans une application, l'émetteur peut encore refuser le paiement en raison d'un solde insuffisant, de plafonds de transaction, du statut de la carte ou de ses règles de contrôle des risques.

Cette distinction est particulièrement importante pour les cartes de paiement en cryptoactifs. Certains produits utilisent un solde préalablement approvisionné ; d'autres nécessitent une conversion des cryptoactifs au moment de l'achat ou calculent le montant disponible selon d'autres mécanismes de financement. Le fait qu'un compte affiche des avoirs en USDT ou en USDC ne signifie pas nécessairement que ces actifs peuvent être directement mobilisés pour autoriser la transaction en cours.

Si l'authentification a déjà réussi, les vérifications doivent porter sur le résultat de l'autorisation plutôt que sur l'obtention répétée de nouveaux codes.

Commencer par identifier ce qui s'est passé au moment du paiement

Le message « Payment Failed » affiché par un commerçant décrit souvent uniquement le résultat final du paiement, sans préciser l'erreur sous-jacente. Même si la page indique « 3DS Failed », il peut être nécessaire de vérifier les enregistrements d'authentification et d'autorisation.

Ce tableau permet d'orienter les recherches, mais ne remplace pas les enregistrements de transaction. Lorsque la page du commerçant ne présente aucun code d'erreur précis, l'utilisateur ne peut généralement pas déterminer seul si l'échec s'est produit pendant l'authentification ou l'autorisation.

OTP non reçu : vérifier le compte du titulaire, pas seulement son profil sur la plateforme

Les codes à usage unique constituent une méthode courante pour les challenges 3DS, mais leur canal d'envoi dépend du service d'émission de la carte.

L'entreprise qui exploite la marque d'une carte crypto peut être différente de l'établissement qui l'émet effectivement. Le numéro de téléphone utilisé pour s'inscrire sur une plateforme de cryptoactifs n'est pas nécessairement celui associé au compte du titulaire pour recevoir les codes 3DS.

Si aucun OTP n'arrive, commencez par ouvrir l'interface officielle de gestion de la carte. Vérifiez le numéro de téléphone ou l'adresse e-mail enregistrés pour l'authentification des transactions, ainsi que le canal effectivement utilisé par le produit : SMS, e-mail ou application.

La non-réception d'un SMS peut être liée à l'acheminement international des messages, au filtrage de l'opérateur, à un changement de numéro ou à une défaillance du service d'envoi. La seule absence de message ne permet pas d'identifier le responsable.

Si la carte utilise des notifications push dans une application, assurez-vous d'être connecté à l'application officielle, que l'appareil dispose d'une connexion réseau et qu'aucune opération n'attend votre approbation. Certains parcours d'authentification n'envoient aucun SMS.

Si plusieurs codes sont reçus, ils peuvent correspondre à des sessions d'authentification différentes. Demander un nouveau code à plusieurs reprises peut invalider le précédent. La fermeture de la page de paiement peut également entraîner l'expiration de la session initiale.

Dans ce cas, vérifiez d'abord si la commande est toujours en cours de traitement et si des autorisations sont en attente sur la carte, avant de lancer un nouveau paiement. Il est inutile de poursuivre les tentatives sur une page dont la session a expiré.

Si les coordonnées sont correctes mais qu'aucune demande d'authentification ne parvient au titulaire, le fournisseur de la carte ou l'émetteur doit examiner l'état de l'envoi et le service d'authentification. Modifier à nouveau les coordonnées de facturation sur le site du commerçant ne résoudra pas ce problème.

La page d'authentification ne s'ouvre pas ou ne revient pas au commerçant

Un challenge 3DS ne dépend pas seulement de l'émetteur. Il suppose également une intégration correcte entre la page de paiement du commerçant et son prestataire de services de paiement.

Dans un navigateur, l'authentification peut se dérouler dans une fenêtre intégrée ou par redirection. Une fois la vérification effectuée par le titulaire, le système du commerçant doit encore traiter correctement son résultat pour que le paiement puisse continuer.

Si une fenêtre reste blanche, si la page se recharge sans fin ou si le retour au commerçant ne fonctionne pas après l'authentification, vérifiez les points suivants :

• La page de paiement a-t-elle été ouverte dans le navigateur intégré d'un réseau social ou d'une application de messagerie électronique ?

• Les extensions du navigateur, les bloqueurs de scripts ou les paramètres de confidentialité perturbent-ils la page d'authentification ?

• La connexion réseau a-t-elle été interrompue pendant la redirection ou l'authentification ?

• Après l'approbation dans l'application, la page de paiement initiale était-elle toujours active ?

Le test le plus simple consiste à ouvrir directement le site officiel du commerçant dans un navigateur classique, puis à réessayer le paiement après avoir vérifié l'état de la transaction initiale.

Il peut être utile d'écarter temporairement les interférences dues aux extensions du navigateur. En revanche, il ne faut pas ignorer les erreurs de certificat, les alertes de sécurité ou les redirections suspectes.

Si une même carte passe normalement l'authentification 3DS chez d'autres commerçants, mais rencontre systématiquement une erreur de page sur un site donné, les vérifications doivent porter en priorité sur l'intégration des paiements et le parcours d'authentification de ce commerçant.

À l'inverse, si plusieurs commerçants indépendants rencontrent des problèmes similaires, il devient pertinent de demander au fournisseur de la carte de contrôler le service d'authentification côté émetteur. Changer de navigateur peut résoudre une incompatibilité d'interface, mais pas une absence d'activation du service 3DS, une mauvaise configuration des canaux d'authentification ou une panne du système de l'émetteur.

Selon l'architecture EMV 3DS, le système 3DS du commerçant doit interagir avec le serveur de contrôle d'accès (Access Control Server, ACS) de l'émetteur pour réaliser l'authentification. L'ACS peut également être exploité par un prestataire mandaté par l'émetteur. Les titulaires n'ont généralement pas accès à ces échanges techniques, qui nécessitent donc une investigation du commerçant, du prestataire de services de paiement ou de l'émetteur.

Pourquoi certains commerçants exigent-ils une authentification et d'autres non ?

Il est courant qu'une même carte crypto suive des parcours 3DS différents selon le commerçant.

Le déclenchement de 3DS et l'éventuelle demande de challenge dépendent notamment de la configuration des paiements du commerçant, de l'évaluation des risques par l'émetteur, des règles des réseaux de cartes et des obligations réglementaires applicables.

Une transaction peut ainsi être authentifiée sans friction, tandis qu'une autre exige la saisie d'un OTP. Pour certains paiements en ligne, si le commerçant n'effectue pas l'authentification requise, l'émetteur peut refuser l'autorisation et demander une vérification supplémentaire de l'identité.

Stripe identifie l'un de ces refus liés à l'authentification par le code authentication_required. D'après sa documentation officielle des codes de refus, les intégrations de paiement doivent généralement prendre en charge la demande d'authentification et, si nécessaire, faire intervenir à nouveau le titulaire dans le parcours de paiement.

Toutefois, si la transaction a déjà fait l'objet d'une authentification réussie et que l'émetteur renvoie malgré tout authentication_required, Stripe recommande de contacter l'émetteur. Il serait incorrect d'en déduire que l'utilisateur doit simplement répéter indéfiniment l'authentification.

Dans les marchés soumis aux exigences d'authentification forte du client (Strong Customer Authentication, SCA), notamment l'Espace économique européen, les paiements en ligne par carte sont également encadrés par les règles réglementaires correspondantes. La SCA n'impose pas l'affichage d'une fenêtre de saisie de code pour chaque transaction. Les exemptions applicables et les modalités concrètes d'authentification peuvent modifier le parcours visible par l'utilisateur.

Il en va de même pour les abonnements. L'authentification du titulaire peut être nécessaire lors de la mise en place initiale, alors que des transactions ultérieures initiées par le commerçant et répondant aux conditions requises peuvent être exécutées sans nouvelle intervention du titulaire à chaque paiement.

« Card not enrolled » signifie-t-il que la carte ne prend pas en charge 3DS ?

Pas nécessairement.

Le message « Card not enrolled » peut correspondre à une inscription 3DS incomplète du compte du titulaire, à une configuration particulière du programme de cartes ou à l'incapacité du service d'authentification concerné à reconnaître la carte. La cause exacte doit être établie à partir des enregistrements d'erreur.

Une carte activée, une procédure KYC terminée ou la présence du logo Visa ou Mastercard ne suffisent pas, à elles seules, à démontrer que la carte dispose de la capacité d'authentification 3DS exigée par le commerçant.

Les cartes de paiement en cryptoactifs peuvent s'appuyer sur différents émetteurs et services d'authentification. Une même marque peut également présenter des configurations distinctes selon la région d'émission, le programme de cartes ou la version du produit.

Si le commerçant renvoie explicitement « 3D Secure not supported » ou « Card not enrolled », vous pouvez demander au fournisseur de la carte :

• Si la carte a été activée et inscrite auprès du service d'authentification 3DS applicable ;

• Quelles méthodes d'authentification le programme de cartes prend en charge et s'il existe des restrictions géographiques ou propres au produit ;

• Quelle procédure suivre pour compléter l'inscription, actualiser les informations de vérification ou réactiver le service.

Il faut aussi distinguer la prise en charge de 3DS des règles d'acceptation des cartes appliquées par le commerçant. Certains établissements refusent les cartes prépayées, virtuelles ou émises dans certaines régions. Une carte peut disposer d'un 3DS parfaitement opérationnel sans être acceptée par tous les commerçants.

L'authentification a réussi : pourquoi le paiement a-t-il été refusé ?

Si les enregistrements du commerçant ou de l'émetteur confirment la réussite de l'authentification 3DS, mais que le paiement a ensuite été refusé, les vérifications doivent se concentrer sur l'autorisation.

Pour les cartes crypto préapprovisionnées, le solde disponible, les plafonds de transaction et le statut du compte sont les premiers éléments à examiner. Pour les produits impliquant une conversion des cryptoactifs en temps réel ou d'autres mécanismes de financement, il convient aussi de vérifier la capacité de dépense effectivement disponible et les conditions d'utilisation des fonds.

Certains commerçants peuvent également demander une préautorisation ou soumettre un montant à autoriser différent du prix affiché. Ces cas relèvent toutefois de l'autorisation du paiement, et non d'un échec de l'authentification 3DS.

Si un montant apparaît en attente sur le compte de la carte alors que la page du commerçant annonce un échec du paiement, vérifiez d'abord la commande et l'état de l'autorisation. Répéter immédiatement l'opération pourrait générer des autorisations en double ou immobiliser temporairement plusieurs montants.

Pour approfondir les problèmes de solde, de restrictions imposées par les commerçants et de refus d'autorisation ordinaires, consultez le dossier d'UCard Radar sur les transactions refusées avec des cartes crypto.

En cas d'échecs répétés, ne multipliez pas les tentatives

Lorsqu'un même paiement échoue plusieurs fois, continuer à saisir des codes ou à soumettre de nouvelles demandes ne résout généralement pas les problèmes de configuration de l'authentification ou de connexion entre les systèmes. Cela peut aussi déclencher des limites sur le nombre de tentatives d'authentification.

Dans sa documentation de dépannage 3D Secure consacrée à l'émission de cartes, Adyen explique que, pour les cartes émises via son service, cinq échecs d'authentification consécutifs entraînent le blocage temporaire des nouvelles tentatives 3DS. Ce blocage est généralement levé automatiquement après une heure ; son équipe d'assistance peut également être contactée.

Adyen relie ce mécanisme aux obligations réglementaires de la directive PSD2. Cependant, le seuil de cinq échecs et le déblocage après une heure correspondent à des règles de mise en œuvre propres à ce prestataire. Ils ne peuvent pas être généralisés aux autres émetteurs.

Si la même erreur apparaît deux fois de suite, notamment lorsqu'un OTP est refusé, qu'un service d'authentification est indisponible ou qu'une restriction temporaire est signalée sur le compte, il vaut mieux interrompre les tentatives et examiner le message d'erreur ainsi que le statut de la carte.

Changer fréquemment d'adresse IP, déclarer une fausse région de résidence sur le compte ou renseigner des coordonnées de facturation inexactes ne permet pas non plus de corriger une configuration d'authentification défaillante. Ces pratiques peuvent au contraire déclencher des contrôles de sécurité supplémentaires.

Commerçant ou émetteur : qui contacter selon les informations disponibles ?

Le traitement des incidents liés aux cartes de paiement en cryptoactifs peut impliquer davantage d'intervenants que ne le laisse supposer l'interface utilisée par le titulaire.

Une plateforme de cryptoactifs peut gérer la marque et le service client, un établissement émetteur agréé assumer la responsabilité de l'émission, un processeur indépendant traiter les autorisations et un prestataire ACS spécialisé effectuer l'authentification 3DS.

L'application de la marque n'affiche donc pas nécessairement l'ensemble des tentatives d'authentification.

Le service Adyen Issuing en fournit un exemple. Sa documentation officielle de dépannage précise que, lorsqu'une authentification 3DS échoue et empêche la transaction de dépasser cette étape, la demande d'autorisation n'est pas envoyée à Adyen. Aucune demande d'autorisation transmise ni aucun webhook correspondant n'est donc généré, et la transaction n'apparaît pas dans la liste Payments d'Adyen Customer Area. Il s'agit d'un cas de traitement propre à Adyen Issuing, qui ne permet pas de supposer que toutes les cartes crypto ou tous les autres émetteurs appliquent le même système d'enregistrement.

Ainsi, l'absence d'une transaction dans l'historique de la carte ne prouve pas que le commerçant n'a pas tenté de déclencher une authentification 3DS.

L'interlocuteur à privilégier dépend du problème constaté :

Avant de contacter l'assistance, rassemblez la date et l'heure de la transaction avec le fuseau horaire, le nom du commerçant, le montant et la devise, les quatre derniers chiffres de la carte, le message d'erreur exact, l'étape atteinte dans le parcours d'authentification, ainsi que le statut de la commande et des autorisations en attente.

Vous pouvez poser directement la question suivante au commerçant :

Pouvez-vous confirmer si une authentification 3D Secure a été déclenchée pour cette transaction, quel en est le résultat final et si le paiement a atteint l'étape d'autorisation ? Si l'authentification a échoué, pourriez-vous communiquer le code d'erreur correspondant ou la raison de cet échec ?

Ces renseignements sont généralement plus utiles pour localiser le problème qu'une simple question sur la raison pour laquelle le paiement ne fonctionne pas.

Comment interpréter les codes transStatus de 3DS ?

Si l'assistance technique du commerçant peut fournir des enregistrements d'authentification détaillés, ceux-ci peuvent contenir le champ transStatus d'EMV 3DS.

Ce champ reflète le statut de l'authentification ou de la vérification du compte. Son interprétation et son affichage peuvent toutefois varier selon l'étape du message, la version du protocole et le prestataire.

Les statuts C et D ne doivent pas être considérés automatiquement comme des échecs définitifs. De même, A et I ne sont pas équivalents à Y. Pour établir si l'authentification a finalement été menée à bien, il faut tenir compte de l'étape du message, des résultats associés et du traitement effectué par le prestataire de services de paiement.

D'après la spécification du protocole 3DS publiée par EMVCo, I signifie Informational Only et indique que la préférence de challenge formulée par le demandeur 3DS a été prise en compte. Cela ne signifie pas que le titulaire a terminé son authentification.

À l'inverse, la documentation de référence de l'API 3D Secure 2 d'Adyen décrit I comme « Authentication / exemption granted by Issuer », c'est-à-dire une authentification approuvée ou une exemption accordée par l'émetteur. Cette formulation propre à l'interface d'Adyen ne doit pas être confondue avec la définition du protocole EMV 3DS. Une exemption d'authentification ne doit pas non plus être assimilée à une authentification réussie au sens du statut Y. La documentation présente également les codes transStatusReason, que les équipes techniques des commerçants peuvent exploiter pour approfondir leur analyse.

Les titulaires ne peuvent généralement pas consulter directement ces champs, mais ils peuvent demander au commerçant de confirmer le résultat définitif de l'authentification. Si celle-ci a réussi, il faut ensuite vérifier si une demande d'autorisation a été envoyée et si l'émetteur l'a refusée.

Lorsque vous transmettez des captures d'écran ou des informations de transaction, ne communiquez que les données indispensables, après masquage des éléments sensibles. Ne divulguez jamais votre numéro de carte complet, votre CVV, votre mot de passe, un code OTP ou la phrase de récupération de votre portefeuille.

Pour les personnes qui utilisent régulièrement une carte crypto pour régler des abonnements, des achats transfrontaliers ou des services en ligne, il est utile de vérifier avant toute nouvelle demande de carte si 3DS est disponible, quels canaux d'authentification sont employés et qui assure l'assistance en cas d'échec. Ces informations renseignent davantage sur la qualité de la prise en charge du produit au quotidien qu'une simple mention indiquant la prise en charge des « paiements en ligne dans le monde entier ».