Prévenir les tests frauduleux de cartes bancaires

Le test de cartes bancaires est une activité frauduleuse qui consiste à tenter de déterminer si les informations d’une carte volée peuvent être utilisées pour effectuer des achats. Pour ce faire, un fraudeur peut acheter des informations de cartes bancaires volées, puis tenter de valider ou d’effectuer un achat avec ces cartes pour déterminer lesquelles sont toujours valides. Cette technique est aussi appelée « carding », « test de compte », « énumération » ou « vérification de carte ».

Une activité frauduleuse telle que le test de cartes bancaires est une composante inévitable du commerce en ligne. Cependant, le test de cartes bancaires a des conséquences sur l’ensemble de l’écosystème des paiements. Les marchands, les réseaux de cartes et Stripe partagent la responsabilité d’éviter ce genre de situation. Chez Stripe, nous améliorons constamment nos outils et nos systèmes pour détecter et limiter la fraude, mais il est nécessaire de rester vigilant.

Fonctionnement des tests de cartes bancaires

Les testeurs de cartes bancaires utilisent à la fois la configuration des cartes et les paiements pour déterminer si les informations de cartes volées ou énumérées dont ils disposent sont valides ou non. Pour valider rapidement de nombreux numéros de cartes, les fraudeurs utilisent des scripts pour tester une grande quantité d’informations de cartes en une seule fois, et collectent les réponses de 3DS ou de l’émetteur pour valider quelles informations de cartes sont valides. Après avoir identifié les cartes valides, ils peuvent les encaisser auprès des marchands ou revendre les cartes confirmées sur le dark web.

• Configuration de la carte bancaire : c’est la méthode privilégiée des fraudeurs, car la validation et l’autorisation des cartes lors de leur configuration n’apparaissent généralement pas sur les relevés de compte des titulaires. Cela réduit la probabilité que les détenteurs de cartes bancaires remarquent et signalent l’activité frauduleuse.
• Paiements : les testeurs de cartes bancaires effectuent des paiements de faible montant, que les titulaires de cartes sont moins susceptibles de remarquer et de signaler comme frauduleux.

Conséquences du test de cartes bancaires

Le test de cartes bancaires entraîne de nombreuses conséquences négatives, dont certaines empirent au fil du temps :

• Litiges : les tests de carte bancaire génèrent parfois des paiements réussis. Les clients constatent alors ces paiements et les déclarent comme étant frauduleux, ce qui donne lieu à des alertes de suspicion de fraude ou même à des litiges pour fraude, qui vous coûtent du temps et de l’argent.
• Taux de refus de paiement plus élevé : les tests des cartes bancaires associent une augmentation du taux de refus de paiement à votre entreprise. Un taux de refus de paiement élevé peut ternir la réputation de votre entreprise auprès des émetteurs et des réseaux de cartes, et vos transactions peuvent par conséquent sembler plus risquées. Cela peut entraîner une hausse du nombre de paiements légitimes refusés, même une fois que cesse l’activité de test de cartes bancaires.
• Frais supplémentaires : les tests de cartes bancaires peuvent entraîner des frais supplémentaires, par exemple des frais d’authentification pour les plans tarifaires personnalisés et des frais de litige.
• Mobilisation de l’infrastructure : les tests des cartes bancaires génèrent habituellement de nombreuses requêtes et opérations sur le réseau. Ce trafic supplémentaire peut surcharger votre infrastructure au détriment de votre activité légitime.
• Intégrité de l’écosystème menacée : les tests des cartes bancaires ayant un impact négatif sur l’ensemble du système financier, Stripe et nos partenaires financiers souhaitent vous aider à y mettre un terme. Un grand nombre de tests des cartes bancaires entraînant des alertes de fraude ou des litiges pourrait, par exemple, vous obliger à participer aux programmes de surveillance des cartes.
• Réduction de la qualité des données pour le fonctionnement de votre entreprise : les recettes provenant des tests de cartes bancaires peuvent apparaître comme de nouveaux clients légitimes dans vos données, de sorte qu’il vous est difficile d’avoir une vision claire de la croissance réelle de votre entreprise.se.

Liste de contrôle des tests de cartes bancaires

Si votre intégration est la cible de testeurs de cartes bancaires, nous vous recommandons de prendre immédiatement les mesures suivantes :

• Identifiez le test de carte bancaire.
• Remboursez les paiements frauduleux pour éviter tout litige.
• Utilisez une intégration recommandée par Stripe ou ajoutez des limitations pour supprimer les tests des cartes bancaires.
• Surveillez votre intégration pour vous assurer que les limitations sont efficaces.

Identifier les tests de cartes bancaires

Vous pouvez identifier la plupart des tests frauduleux de cartes bancaires par une augmentation significative des échecs d’autorisation et de paiement. La plupart des attaques sont visibles dans votre Dashboard Stripe. Les symptômes les plus courants sont les suivants :

• Un pic dans les échecs ou blocages de paiement. Vous pouvez observer les tendances sur la page d’accueil du Dashboard, consulter la vue de la liste des transactions et vous pouvez examiner les raisons du blocage sur la page des informations du paiement.
• Un pic de requêtes avec des erreurs 402. Vous pouvez observer le pic de volume sur la page Développeurs, examiner les erreurs 402 sur la page Logs des échecs ou écouter les webhooks et les réponses API, en particulier avec un résultat de « generic_decline ».
• Un pic de paiements suspects avec de faibles montants de transaction, souvent avec des noms de clients et des e-mails qui n’ont pas de sens. Pour éviter les litiges, nous recommandons de rembourser ces transactions suspectes si elles passent à travers les défenses existantes.

Paiement bloqué pour cause de suspicion de test de carte bancaire

Empêcher les tests de cartes bancaires

Les testeurs de cartes bancaires recourent à des techniques très diverses pour vous empêcher de bloquer leur activité frauduleuse. Par conséquent, de simples règles et filtres de pare-feu basés sur un sur un critère heuristique unique, comme les adresses IP ne suffisent généralement pas à empêcher les tests frauduleux de cartes bancaires.

Les testeurs de cartes bancaires peuvent utiliser votre clé publiable et s’en servir pour réessayer un grand nombre de paiements sur votre site Web. Vous disposez de deux stratégies principales pour atténuer les effets de ces attaques :

• Utiliser une intégration recommandée par Stripe : choisissez une intégration recommandée par Stripe pour bénéficier d’une protection contre le test des cartes bancaires dont nous connaissons l’efficacité.
• Mettre en place des contrôles : investissez dans un ensemble de contrôles qui empêchent les testeurs de cartes d’attaquer les endpoints vulnérables.

Outre la mise en œuvre de stratégies d’atténuation, vous devez vous assurer que vous conservez vos clés en toute sécurité et que vous ne publiez pas votre clé secrète. En cas de fuite ou de vol de vos informations d’identification, les testeurs de cartes peuvent créer des paiements et configurer des cartes à l’aide de votre clé secrète.

Utiliser une intégration recommandée par Stripe

Si vous utilisez le dernier Payment Element ou Checkout de Stripe, nous avons mis en place de nombreux contrôles automatisés et manuels pour limiter les tests de cartes bancaires, notamment des limiteurs de débit, des modèles de machine learning, des déclencheurs CAPTCHA, des examens continus, etc. Lorsque nous détectons que vous faites l’objet d’un test des cartes bancaires, nous choisissons dynamiquement des interventions pour supprimer l’attaque autant que possible, tout en permettant aux utilisateurs légitimes de réaliser des transactions sur votre compte avec un impact minimal. Ces paiements sont marqués Blocked by Stripe.

Cependant, l’efficacité des contrôles de Stripe dépend de votre intégration et des signaux que vous nous envoyez. Nous utilisons de nombreux signaux pour distinguer les paiements légitimes des tests des cartes bancaires. Bien que certains de ces indicateurs soient analysés automatiquement, la plupart dépendent des informations fournies par votre intégration. En règle générale, plus la quantité de données est importante, plus la prévention de la fraude sera efficace.

Nous vous recommandons d’utiliser l’une des intégrations recommandées par Stripe pour profiter de la protection automatisée basée sur les CAPTCHA. Les solutions CAPTCHA modernes appliquent des signaux multiples pour augmenter la friction pour les comportements à haut risque, tout en apparaissant presque invisibles pour les utilisateurs légitimes de votre service. Pour renoncer à notre intégration CAPTCHA, contactez le service d’assistance Stripe.

Tirez le meilleur parti de la protection contre le test de cartes bancaires de Stripe en utilisant l’une de nos intégrations de paiement recommandées. Si vous ne pouvez pas utiliser l’une de ces intégrations, intégrez le plus de données possibles ou mettez en œuvre vos propres contrôles. Les contrôles de test des cartes bancaires sont distincts de la protection contre les litiges pour fraude de Radar, mais ils bénéficient des mêmes signaux utilisés par Radar.

L’inclusion des informations suivantes avec vos paiements peut avoir un impact significatif sur les performances des modèles de test des cartes bancaires de Stripe. Nos intégrations recommandées vous permettent de recueillir ces informations, tandis que les intégrations directes peuvent avoir besoin d’inclure ces données manuellement.

• Détection avancée des fraudes Highest impact
• Adresse IP
• Adresse e-mail du client
• Nom du client
• Adresse de facturation

Contrôler l’implémentation

L’ajout de restrictions à des endpoints ciblés vous permet de supprimer et d’empêcher les tests des cartes bancaires. Les restrictions que vous mettez en place peuvent rendre les tests des cartes bancaires impraticables tout en ayant peu ou pas d’impact sur votre trafic légitime.

Les endpoints ciblés par les testeurs leur permettent généralement de réaliser les opérations suivantes :

• Enregistrer la carte bancaire.
• Effectuer un paiement.

Les mesures de sécurité spécifiques que vous ajoutez à votre intégration varient en fonction de votre situation et des besoins de votre entreprise. Nous décrivons ci-dessous plusieurs approches courantes.

Mettre en place un CAPTCHA

Les testeurs de cartes bancaires utilisent souvent des scripts automatisés que les CAPTCHA peuvent bloquer. Ces scripts sont particulièrement efficaces si vous n’utilisez pas l’une des intégrations recommandées qui prend en charge les CAPTCHA. Les solutions CAPTCHA modernes offrent des options pour les CAPTCHAS visibles et invisibles, en fonction de vos besoins. Si vous avez ajouté un CAPTCHA à votre intégration mais que les tests de cartes bancaires continuent, vérifiez les points suivants :

• Vérifiez que le CAPTCHA exige une validation sur toutes les requêtes qui permettent la validation des cartes ou les paiements avec Stripe.
• Consultez la documentation du CAPTCHA pour vous assurer que vous l’avez mis en œuvre côté serveur.
• Si vous utilisez une solution CAPTCHA qui fournit un score, réajustez le seuil à partir duquel vous empêchez les requêtes d’aboutir.
• Essayez une autre solution CAPTCHA. Passez par exemple d’un CAPTCHA invisible à un CAPTCHA visible. Ou utilisez une toute autre solution CAPTCHA complètement différente.

Limiter l’accès à votre formulaire de paiement

Plus il est facile pour les acteurs frauduleux d’atteindre votre formulaire de paiement (par exemple, en utilisant le paiement en tant qu’invité), plus il leur est facile d’exécuter des attaques de test des cartes bancaires. Vous pouvez réduire votre exposition aux testeurs de cartes en exigeant une validation de connexion ou de session avant qu’ils ne puissent effectuer un paiement. Certaines mesures de protection contre les attaques de type Cross-Site Request Forgery (CSRF) sont également efficaces contre certains types de tests des cartes bancaires, comme les tokens CSRF.

Ajouter des limites de débit

Dans certains cas, vous pouvez réduire les tests des cartes bancaires en ajoutant des limites de débit sur le réseau (par exemple, dans le front-end de votre boutique en ligne). Adaptez ces limites de débit pour mettre fin aux tests des cartes bancaires dont vous êtes victime. Par exemple, si les testeurs de cartes utilisent votre intégration pour valider les cartes en les associant aux nouveaux clients, vous pourriez les bloquer en limitant le nombre de nouveaux clients pouvant être créés par jour avec une même adresse IP.

En plus des limites de débit du réseau, vous pouvez ajouter des limites de débit à vos paiements et au tunnel de paiement du panier afin de détecter et d’empêcher tout comportement inhabituel, même après la connexion ou l’inscription.

Détecter et prévenir tout comportement inhabituel

Utilisez le Dashboard, des webhooks ou la surveillance continue avec Stripe Sigma ou Data Pipelines pour suivre les anomalies de votre trafic. Vous pouvez comparer le test des cartes bancaires au trafic légitime type, puis créer des filtres qui limitent ou empêchent uniquement le test des cartes bancaires. Vous pouvez par exemple apporter à votre système des modifications qui :

• Limiter le nombre de cartes bancaires pouvant être ajoutées à un compte
• Limitent le nombre de clients pouvant être créés avec une même adresse IP
• Limiter le nombre d’achats pouvant être effectués pour un même produit
• Limiter le nombre de clients du même type qui peuvent être créés
• Filtrent les requêtes avec certains agents utilisateur ou d’autres paramètres

Pour ce faire, vous pouvez utiliser des règles personnalisées dans Radar for Fraud Teams. Nous abordons ce sujet dans la section suivante.

Utiliser plusieurs limitations

Pour réduire les tests de cartes bancaires, il peut être judicieux de combiner plusieurs approches afin d’optimiser l’impact sur l’activité frauduleuse sans nuire au trafic légitime. Vous pouvez par exemple combiner des CAPTCHA et des limites de débit afin que la première tentative de paiement effectuée à partir d’une adresse IP réussisse, mais que les autres requêtes émises par cette même adresse dans les heures qui suivent exigent une vérification par captcha.

Effectuer les relances avec prudence

Les tentatives de paiement répétées à l’excès (« relance ») peuvent ressembler à des tests de cartes si elles se présentent sous forme de pics extrêmes avec un faible taux de réussite. Ces tentatives peuvent donc avoir un effet similaire sur votre entreprise à celui de véritables tests de cartes bancaires, notamment en incitant les émetteurs à durcir leur position en matière de risque. Assurez-vous qu’après un test des cartes bancaires, vous n’essayez pas de nouveau d’utiliser les cartes de clients frauduleux, ce qui reviendrait à répéter l’attaque initiale. Les Smart Retries de Stripe prennent déjà ce problème en considération.

Personnaliser la protection en fonction de votre appétit pour le risque

Au-delà des mesures d’atténuation mises en œuvre, nous vous recommandons d’affiner votre protection à l’aide de Radar, qui présente des règles de blocage intégrées basées sur les vérifications bancaires, telles que la vérification CVC.

Si vous comprenez le comportement de vos clients et souhaitez personnaliser en détail la vélocité des paiements, vous pouvez créer des règles personnalisées dans Radar for Fraud Teams.

Vous trouverez des exemples dans le guide Radar 101.