Aller au contenu principal
Tous les articles
Guide5 min de lecture

3-D Secure : ce qui fait échouer un paiement

3-D Secure et taux de réussite : pourquoi un paiement par carte échoue, les causes réelles par ordre de fréquence et ce que vous pouvez corriger.

« Le paiement a échoué. » C'est la phrase que voient vos clients, et c'est celle qui vous coûte des ventes. Derrière elle se cachent des causes très différentes, et toutes ne dépendent pas de vous — mais certaines, oui.

Ce qu'est vraiment 3-D Secure

Quand un client paie par carte, sa banque peut exiger qu'il prouve son identité : un code reçu par SMS, une validation dans l'application bancaire, parfois une empreinte digitale. C'est le 3-D Secure.

Ce n'est pas une option que vous activez ou non : c'est la banque de l'acheteur qui décide, transaction par transaction. Votre rôle se limite à ne pas casser le parcours pendant que cela se produit. Ce qui rassure l'acheteur avant même cette étape est détaillé dans paiement en ligne sécurisé.

Les causes d'échec, par ordre de fréquence

1. L'abandon pendant l'authentification. Le client ne reçoit pas le SMS, ne trouve pas son application, ou renonce. C'est de loin la première cause, et elle n'apparaît pas dans les statistiques comme un « refus » — le paiement reste simplement en attente puis expire.

2. Le refus de la banque émettrice. Provision insuffisante, plafond dépassé, carte bloquée pour l'international ou pour le paiement en ligne. Beaucoup de cartes marocaines sont, par défaut, fermées au paiement en ligne : le client doit l'activer auprès de sa banque, et il l'ignore souvent. Ce que le client peut faire face à ce refus, et le message à lui envoyer, sont détaillés dans carte refusée en paiement en ligne.

3. Les données de carte erronées. Un chiffre de trop, une date d'expiration passée, un cryptogramme mal recopié.

4. Le soupçon de fraude. Un montant inhabituel, une série de tentatives rapprochées, une carte déjà refusée plusieurs fois.

Ce que vous pouvez améliorer

Ne perdez pas le client pendant l'authentification. Si votre page se recharge, se ferme ou perd son état pendant que le client bascule vers son application bancaire, vous perdez la vente. Le checkout hébergé 3-D Secure gère ce cycle ; si vous construisez votre propre page avec le checkout direct de l'API, testez-le sur mobile, réseau lent, application bancaire tierce.

Affichez un état d'attente au retour. Le client revient sur votre site avant que le résultat ne soit connu. Une page qui affiche « échec » par défaut transforme un paiement en cours en vente perdue — le client ne réessaiera pas.

Dites la vraie cause quand vous la connaissez. « Vérifiez auprès de votre banque que votre carte est autorisée pour les achats en ligne » sauve des ventes que « Paiement refusé » perd définitivement.

Proposez une alternative. C'est la mesure la plus efficace de toutes : un lien de paiement en espèces, réglable en agence, récupère une part significative des clients dont la carte a été refusée.

Ce que vous ne pouvez pas changer

Le taux de refus des banques émettrices ne dépend pas de vous. Un plafond, une carte non ouverte à l'international, une politique de risque : ce sont des décisions de la banque du client. Sur un abonnement, un refus ne clôt pas l'échéance : son lien de paiement reste payable jusqu'à 14 jours après l'échéance, et le client reçoit un rappel par e-mail chaque jour ; voir impayés d'abonnement et relances.

En revanche, vous pouvez mesurer. Le portail montre, pour chaque lien et chaque session, où les acheteurs s'arrêtent — combien ont ouvert la page, combien ont saisi leur carte, combien sont allés au bout. Si la chute se produit avant la saisie, votre problème n'est pas la banque : c'est votre page. Si elle se produit après, la conversation à avoir est avec vos clients sur l'activation de leur carte.

Lire un refus : quatre cas concrets

« Authentification échouée » sur plusieurs cartes différentes, le même jour. Ce n'est probablement pas vos clients : vérifiez votre intégration — une session mal construite ou une redirection cassée produit exactement ce symptôme en série.

Un même client échoue trois fois, puis réussit depuis un autre navigateur. Le classique blocage de fenêtre surgissante ou de cookies tiers pendant l'authentification. Rien à corriger côté serveur ; un message d'aide sur votre page de paiement (« autorisez l'ouverture de la fenêtre de votre banque ») récupère une partie de ces ventes.

Des refus concentrés sur les petites heures. Les plafonds se réinitialisent, les batchs bancaires passent : une carte refusée à 23 h passe parfois à 8 h. Proposer de réessayer plus tard n'est pas un aveu d'échec, c'est un conseil pertinent.

Un taux d'échec stable qui monte brusquement. Comparez d'abord avec le volume : un pic d'échecs pendant une campagne publicitaire signale surtout des acheteurs nouveaux, moins habitués au 3-D Secure, pas une panne.

La checklist côté intégration

  • La page de paiement s'ouvre dans l'onglet principal, jamais dans une iframe cachée — l'authentification bancaire y est conçue pour être vue.
  • Le montant et le nom du commerce affichés sont exacts : c'est ce que la banque montre au porteur, et une incohérence fait abandonner.
  • Votre page de retour tolère les trois issues — réussite, échec, abandon — sans écran blanc.
  • La confirmation de commande s'appuie sur le webhook, pas sur le retour navigateur — voir réussir son intégration des webhooks.
  • Vous journalisez le motif de refus renvoyé par l'API, pas seulement « échec » : c'est lui qui rend les diagnostics ci-dessus possibles.

Une mesure vaut mieux qu'une intuition

Avant d'optimiser quoi que ce soit, regardez l'entonnoir. La plupart des « problèmes de 3-D Secure » que l'on nous rapporte sont, à l'examen, des abandons en amont : un formulaire trop long, un montant qui surprend, une page qui met huit secondes à s'afficher sur un réseau mobile.

Prochaine étape

Le plus sûr moyen de savoir comment votre parcours se comporte pendant l'authentification est de le dérouler vous-même : Commencer en mode test demande un nom, un e-mail professionnel et le nom de l'entreprise, puis un mot de passe choisi depuis le lien d'activation reçu par e-mail. Créez une clé de test depuis le portail et payez avec la carte de test 4918 9141 0719 5005 (CVV 123, code 3-D Secure 555) — gratuit, sans limite de durée. Le guide du paiement en ligne au Maroc replace ces réglages dans l'ensemble du parcours.

Écrit par Équipe ChariPay.

À lire ensuite

Technique5 min de lecture

Réussir son intégration des webhooks

Réussir son intégration des webhooks : les cinq erreurs qui reviennent dans presque toutes les intégrations, et le traitement en quinze lignes qui les évite.

Guide6 min de lecture

Lien de paiement ou checkout : lequel choisir

Lien de paiement ou checkout : deux façons d'encaisser en ligne, deux charges de travail, et les critères qui tranchent — volume, montant, équipe.

Prêt à essayer par vous-même ?

Créez votre compte et encaissez en mode test dès aujourd'hui : c'est gratuit, sans validation à attendre. Une question ? Notre équipe répond aux commerçants comme aux développeurs.

  • Gratuit, sans engagement
  • Mode test dès l'inscription
  • Aucune validation à attendre