DataDome

Ne sacrifiez pas l’expérience utilisateur pour la sécurité de votre API de paiement

Table des matières

Les bases de la sécurité des API de paiement

Les interfaces de programmation d’application (API) servent à prendre des mesures (par exemple, déclencher un paiement). Ce sont aussi des passerelles vers des données soigneusement organisées. Ce type de données structurées est généralement stocké dans des formats prédéfinis, notamment des bases de données, des tableurs ou des serveurs SQL, et représente une cible facile pour les pirates et les fraudeurs qui cherchent à extraire des informations spécifiques. Il est donc essentiel de protéger les données.

Sans protection adéquate, une API peut provoquer un accès non autorisé ou bien l’exposition de données sensibles, en particulier des informations personnelles identifiables (PII), des données financières, ou toute autre information confidentielle qu’elle gère. Les violations de données via les API peuvent entraîner une atteinte à la réputation, des pertes financières et des conséquences juridiques pour les entreprises.

Voyons comment les API de paiement peuvent sécuriser les transactions en ligne contre les bots et la fraude, et les impacts potentiels sur l’expérience utilisateur (UX).

Le défi : équilibrer efficacement la sécurité et l’expérience utilisateur

Les prestataires de services de paiement (PSP) s’intègrent aux sites e-commerce via des API pour accepter divers types de paiements et traiter les transactions de manière sécurisée. Les commerçants sont toutefois invités à mettre en place leurs propres outils de prévention de la fraude et d’authentification afin de protéger leurs systèmes contre des transactions frauduleuses qui peuvent s’avérer coûteuses.

Le PSP facture un montant considérable pour le traitement des transactions frauduleuses (qui résultent souvent du carding et du card cracking), même pour les transactions qui sont finalement refusées. Ajoutez à cela le coût des protocoles d’authentification tels que 3-D Secure (3DS), et vos coûts peuvent alors largement dépasser le prix d’une protection spécialisée contre les bots et la fraude.

Ce que vous voulez éviter, c’est de mettre en place un outil imprécis pour vous assurer que l’acheteur est bien le titulaire de la carte. Un mauvais outil de sécurité peut augmenter la frustration de l’expérience utilisateur (UX) sans pour autant sécuriser votre site contre les bots avancés.

Tous les outils impliqués dans le parcours client devraient avoir pour objectif de minimiser les frictions en supprimant les étapes inutiles (par exemple, qu’un humain soit obligé de résoudre un CAPTCHA). Il vous faut donc une solution très précise, capable de faire la différence entre les humains et les bots.

Utilisation des CAPTCHA dans la sécurité des paiements

Les CAPTCHA sont souvent appliqués à différents scénarios de paiement :

  1. Les mesures anti-fraude : il est possible d’intégrer un CAPTCHA pour valider l’identité de l’utilisateur avant que celui-ci ne procède au paiement. Les CAPTCHA peuvent également être combinés avec l’authentification à deux facteurs (2FA), et proposer un test une fois que les utilisateurs ont saisi leurs identifiants ou leur code d’authentification (mais avant qu’ils ne procèdent au paiement). L’objectif ici est de s’assurer que la demande de paiement provient d’un humain et d’empêcher les bots d’initier des transactions frauduleuses.
  2. La création et la vérification de compte : les CAPTCHA peuvent servir à vérifier que l’utilisateur qui crée un nouveau compte de paiement ou en modifie un existant (par exemple pour ajouter une méthode de paiement) est bien une personne réelle. Cela permet d’empêcher les bots de créer des comptes frauduleux ou d’utiliser des informations de paiement volées.
  3. La détection d’activité suspecte : l’utilisateur peut être invité à résoudre un CAPTCHA pour confirmer son authenticité si les autres protocoles de sécurité du système (comme la protection contre les bots et la fraude) détectent un comportement inhabituel, par exemple plusieurs tentatives de connexion échouées ou des demandes de paiement rapide.
  4. Les transactions à haut risque : les CAPTCHA peuvent ajouter une couche de sécurité supplémentaire en demandant aux utilisateurs de résoudre un CAPTCHA avant de procéder au paiement.

L’impact négatif des CAPTCHA traditionnels sur l’expérience utilisateur (UX)

La plupart des utilisateurs de sites marchands et de voyage quittent généralement votre page au bout de trois secondes si elle ne s’est pas chargée, et abandonnent souvent leur panier par frustration. Des études montrent qu’ajouter des difficultés dans les dernières étapes du processus d’achat ou de paiement peut avoir un impact significatif sur les taux de conversion et les chiffres d’affaires. Par exemple, on estime qu’environ 21 % des paiements 3DS n’aboutissent pas, dont 8 % en raison de l’abandon de l’utilisateur.

La nature même des CAPTCHA traditionnels crée un blocage dans le parcours client. Des outils tels que le Google reCAPTCHA ont un impact important sur l’expérience utilisateur, car :

  • ils interrompent la navigation des utilisateurs dans votre parcours client ;
  • ils proposent peu d’options visuelles et sonores, et ne prennent donc pas en charge l’accessibilité ;
  • ils sont souvent longs à charger ou bien à résoudre, le temps moyen de résolution d’un reCAPTCHA étant d’environ 20 secondes ;
  • ils recueillent beaucoup d’informations clients et les utilisent à d’autres fins que la sécurité (augmentant le risque de violation de la confidentialité des données) ;
  • ils ne sont pas capables d’arrêter les bots tout seuls.

En fin de compte, vous ne voulez pas que les utilisateurs humains soient trop souvent confrontés à des tests CAPTCHA, en particulier lorsqu’ils valident la commande. De plus, les CAPTCHA seuls ne constituent pas une sécurité efficace contre les bots. Ainsi, quel que soit votre PSP, vous devez avant tout chercher à différencier les humains des bots, avant qu’ils n’atteignent votre API de paiement, avec le moins d’impact possible sur l’expérience utilisateur.

La sécurité de l’API de paiement de votre PSP n’est pas suffisante

Les entreprises en ligne ne peuvent pas se permettre de s’appuyer uniquement sur les mesures de sécurité mises en place par leurs prestataires de services de paiement pour protéger les API de paiement. La protection contre les bots et la fraude, notamment pour les points terminaux de paiement, devrait toujours être un dispositif multicouche. Vous ne pouvez pas protéger vos utilisateurs et votre entreprise uniquement avec un CAPTCHA, car celui-ci nuit à l’expérience de vos utilisateurs et laisse passer les bots avancés.

Les commerçants en ligne ont besoin de solutions automatisées intelligentes qui déterminent avec exactitude l’intention d’un utilisateur et n’ont recours à un CAPTCHA qu’en cas d’absolue nécessité, en se basant sur d’autres signaux collectés. Il est essentiel de comprendre l’intention de l’utilisateur pour distinguer les vrais clients des fraudeurs. L’intention ne peut être analysée qu’en examinant l’ensemble du parcours client, et pas seulement son comportement lorsqu’il atteint le PSP.

Utilisez DataDome pour sécuriser les API sans impacter l’expérience utilisateur

Le logiciel de lutte contre les attaques de bots DataDome protège les points de terminaison de l’API contre l’activité des bots malveillants avec une précision extrême. La solution réduit les risques de sécurité, renforce la confiance entre les commerçants et les partenaires, et permet aux entreprises de ne pas se voir bannir temporairement d’un PSP en protégeant l’échange de données sans compromettre la rapidité ou la précision.

La solution DataDome renforce les points d’accès aux données de l’API, et offre une défense solide contre les taux élevés de rétrofacturation, les attaques par force brute, le credential stuffing, les attaques DoS et le scraping.

Vous voulez découvrir comment DataDome peut protéger votre entreprise contre la fraude ? Essayez-le gratuitement pendant 30 jours ou réservez une démonstration dès aujourd’hui.