# Protégez-vous contre les tests de cartes Apprenez-en davantage sur cette activité frauduleuse et découvrez comment vous en protéger. Le test frauduleux de cartes est un type d’activité frauduleuse au cours de laquelle quelqu’un tente de déterminer si les informations d’une carte volée sont valides pour pouvoir l’utiliser pour effectuer des achats. Un acteur frauduleux peut le faire en achetant des informations de carte de crédit volées, puis en tentant de valider ou d’effectuer des achats avec ces cartes pour déterminer quelles cartes sont encore valides. D’autres termes courants pour désigner le test frauduleux de cartes sont « cardage », « test de compte », « énumération » et « vérification de carte ». Les activités frauduleuses telles que les tests de cartes sont inévitables dans le commerce en ligne. Cependant, le test de cartes a des conséquences sur l’écosystème des paiements. Les marchands, les réseaux de cartes et Stripe partagent la responsabilité d’empêcher 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 Les testeurs de cartes utilisent à la fois la configuration de la carte et les paiements pour déterminer si les informations de carte volées ou énumérées qu’ils possèdent sont valides ou non. Pour valider rapidement de nombreux numéros de carte, les acteurs frauduleux utilisent des scripts pour tester un grand nombre d’informations de carte en même temps, et collectent les réponses 3DS ou de l’émetteur pour valider les informations de carte valides. Une fois qu’ils ont identifié les cartes valides, ils peuvent les encaisser auprès de marchands ou revendre les cartes confirmées sur le dark web. - **Configuration de la carte** : il s’agit d’une méthode privilégiée par les acteurs frauduleux, car la validation et les autorisations de la carte pendant sa configuration n’apparaissent généralement pas sur les relevés du titulaire de la carte. Cela réduit la probabilité que les titulaires de la carte remarquent et signalent l’activité frauduleuse. - \***Paiements** : les testeurs de cartes 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 Le test de cartes a de nombreux aspects négatifs, dont certains empirent au fil du temps : - **Litiges** : les tests de cartes 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](https://docs.stripe.com/disputes/measuring.md#early-fraud-warnings) ou même à des [litiges pour fraude](https://docs.stripe.com/disputes.md) qui vous coûtent du temps et de l’argent. - **Taux de refus de paiement plus élevés** : les tests de cartes entraînent un nombre important de refus pour votre entreprise. Un taux de refus élevé risque de nuire à la réputation de votre entreprise auprès des émetteurs de cartes et des réseaux de cartes, ce qui fait apparaître toutes vos transactions comme plus risquées. Cette situation peut entraîner une augmentation du taux de refus pour les paiements légitimes, même après la fin des tests de cartes. - **Frais supplémentaires** : les tests de cartes peuvent entraîner des frais supplémentaires, par exemple des frais d’authentification pour les offres tarifaires personnalisées et des frais de litige. - **Mobilisation de l’infrastructure** : les tests de cartes génèrent habituellement de nombreuses requêtes et opérations sur le réseau. Ce trafic supplémentaire peut surcharger votre infrastructure et perturber votre activité légitime. - **Intégrité de l’écosystème menacée** : les tests de cartes 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 entraînant des alertes de suspicion de fraude ou des litiges pourrait, par exemple, vous obliger à participer à des [programmes de surveillance des cartes](https://docs.stripe.com/disputes/monitoring-programs.md). - **Réduction de la qualité des données pour le fonctionnement de votre entreprise** : les revenus provenant des tests de cartes 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. ## Liste de vérification des tests de cartes Si votre intégration est la cible de testeurs de cartes, nous vous recommandons de prendre immédiatement les mesures suivantes : - [Identifiez](https://docs.stripe.com/disputes/prevention/card-testing.md#identify-card-testing) le test de carte. - [Remboursez](https://docs.stripe.com/refunds.md) les paiements frauduleux pour éviter tout litige. - [Utiliser une intégration recommandée par Stripe](https://docs.stripe.com/disputes/prevention/card-testing.md#optimize-integration) ou ajouter des [limitations](https://docs.stripe.com/disputes/prevention/card-testing.md#control-implementation) pour supprimer les tests des cartes. - Surveillez votre intégration pour vous assurer que les limitations sont efficaces. ## Identifier les tests de cartes Vous pouvez identifier la plupart des tests frauduleux de cartes par une augmentation significative des échecs d’autorisation et de paiement. La plupart des attaques sont visibles dans votre Dashboard Stripe. Les symptômes courants à surveiller sont les suivants : - **Un pic dans les échecs ou blocages de paiement.** Vous pouvez observer les tendances sur [la page d’accueil Dashboard](https://dashboard.stripe.com/dashboard), consulter la vue de la liste des [transactions](https://dashboard.stripe.com/payments) et 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](https://dashboard.stripe.com/developers), examiner les erreurs 402 sur la page [Journaux des échecs](https://dashboard.stripe.com/logs?error_type=card_error) ou écouter les liens de rappel HTTP et les réponses des API, en particulier avec un [résultat « generic_decline »](https://docs.stripe.com/declines/codes.md). - **Un pic de paiements suspects** avec de faibles montants de transaction, souvent avec des noms de clients et des courriels qui n’ont pas de sens. Pour éviter tout litige, nous vous recommandons de rembourser ces transactions suspectes si elles passent à travers les défenses existantes. ## Prévenir les tests de cartes Les testeurs de cartes 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. Les testeurs de cartes peuvent utiliser votre clé publique 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 : - **Utilisez une intégration Stripe recommandée** : choisissez une intégration recommandée par Stripe pour bénéficier d’une protection contre les tests de cartes dont nous savons qu’elle est efficace. - **Mise en œuvre des mesures de contrôle** : investissez dans un ensemble de mesures de contrôle qui empêchent les testeurs de cartes de s’attaquer aux points de terminaison 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. > Si vous n’êtes pas un développeur ou si vous utilisez un module d’extension ou une plateforme, la prévention et l’atténuation du test frauduleux de cartes nécessitent généralement des modifications au niveau du code. Montrez cette documentation au développeur ou au fournisseur qui a écrit le code et travaillez avec lui pour prévenir le test frauduleux de cartes. ### Utiliser une intégration recommandée par Stripe Si vous utilisez le composant Element Payment de Stripe ou Checkout le plus récent, de nombreux contrôles automatisés et manuels sont mis en place pour atténuer le test frauduleux de cartes, notamment des limiteurs de débit, des modèles d’IA, des déclencheurs CAPTCHA, des examens continus, etc. Lorsque nous détectons que vous subissez une attaque de test frauduleux de cartes, nous choisissons de façon dynamique les interventions visant à supprimer l’attaque autant que possible, tout en permettant aux utilisateurs légitimes d’effectuer des transactions sur votre compte avec un impact minime. Vous voyez ces paiements marqués comme `Bloqués par Stripe`. *Toutefois, l’efficacité des contrôles de Stripe dépend de votre intégration et des facteurs de risque que vous nous transmettez*. Nous utilisons de nombreux facteurs de risque pour distinguer les tests (frauduleux) de cartes des paiements légitimes. Bien que certains de ces facteurs soient calculés automatiquement, plusieurs dépendent des informations fournies par votre intégration. En général, plus votre intégration fournit de données, plus la prévention des tests de cartes est efficace. Nous recommandons d’utiliser l’une des [intégrations recommandées de Stripe](https://docs.stripe.com/payments/online-payments.md#compare-features-and-availability) pour bénéficier de la protection automatisée fondée sur [CAPTCHA](https://www.hcaptcha.com/). Les solutions CAPTCHA modernes utilisent plusieurs facteurs de risque pour augmenter les frictions en cas de comportements à risque élevé, tout en demeurant largement invisibles pour les utilisateurs et utilisatrices légitimes de votre service. Pour vous retirer de notre intégration CAPTCHA, veuillez communiquer avec le [service d’assistance de Stripe](https://support.stripe.com/contact/login). L’utilisation de l’une de nos intégrations de paiement recommandées vous permet de tirer pleinement parti de la prévention des tests de cartes Stripe. Si vous ne pouvez pas utiliser une intégration recommandée, fournissez autant de données que possible ou mettez en place vos propres contrôles. Bien que les contrôles contre les tests de cartes soient distincts de la protection de Radar contre les contestations frauduleuses, ils bénéficient [des mêmes facteurs de risque utilisés par Radar](https://docs.stripe.com/radar/optimize-risk-factors.md). L’inclusion des informations suivantes dans vos paiements peut avoir un impact significatif sur les performances des modèles de test frauduleux de cartes Stripe. Nos intégrations recommandées vous permettent de collecter ces informations, tandis que les intégrations directes peuvent avoir besoin d’inclure explicitement ces données. - [Détection avancée de la fraude](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection.md) (Impact maximal) - Adresse IP - Adresse de courriel du client - Nom du client - Adresse de facturation ### Mettre en œuvre des contrôles L’ajout de restrictions à des points de terminaison ciblés vous permet de supprimer et d’empêcher les tests frauduleux des cartes. Les restrictions que vous mettez en place peuvent rendre les tests des cartes impraticables tout en ayant peu ou pas d’impact sur votre trafic légitime. Les points de terminaison ciblés par les testeurs leur permettent généralement de réaliser les opérations suivantes : - Enregistrer la carte. - Effectuez 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 utilisent souvent des scripts automatisés que les CAPTCHA peuvent bloquer. Les scripts sont particulièrement efficaces si vous n’utilisez pas l’une des intégrations recommandées prenant 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 ne cessent pas pour autant, 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 de CAPTCHA. ### Limiter l’accès à votre formulaire de paiement Plus il est facile pour les fraudeurs d’accéder à votre formulaire de paiement (par exemple, en utilisant Guest checkout), plus il est facile pour eux d’effectuer des attaques de test (frauduleux) de cartes. Vous pouvez réduire votre exposition aux testeurs de cartes en exigeant la validation de connexion ou de session avant qu’ils puissent effectuer un paiement. Certaines des [mesures de protection contre les attaques](https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) de falsification de requêtes cross-site (CSRF) sont également efficaces contre certains types de tests (frauduleux) de cartes, tels que les jetons CSRF. ### Ajouter des limites de débit Dans certains cas, vous pouvez réduire les tests frauduleux de cartes en instaurant des limites de débit sur le réseau (par exemple, dans l’application frontale de votre boutique en ligne). Adaptez ces limites de façon à stopper les tests frauduleux des cartes 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 flux de paiement du panier afin de [détecter et d’empêcher tout comportement inhabituel](https://docs.stripe.com/disputes/prevention/card-testing.md#prevent-unusual-behavior), même après la connexion ou l’inscription. ### Détecter et prévenir tout comportement inhabituel Utilisez le Dashboard, les [liens de rappel HTTP](https://docs.stripe.com/webhooks.md) ou la surveillance continue avec [Stripe Sigma ou Data Pipelines](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) pour suivre les anomalies de votre trafic. Vous pouvez comparer l’activité des tests de cartes au trafic légitime typique, puis créer des filtres qui limitent ou empêchent uniquement l’activité des tests de cartes. Vous pouvez par exemple configurer votre système pour : - Limiter le nombre de cartes pouvant être ajoutées à un compte - Limiter le nombre de clients pouvant être créés avec une même adresse IP - Limiter le nombre d’achats pouvant être effectués avec le même produit - Limiter le nombre de clients du même type qui peuvent être créés - Filtrer les requêtes avec certains agents d’utilisateur ou autres paramètres Pour ce faire, vous pouvez utiliser des [règles personnalisées](https://docs.stripe.com/radar/rules/reference.md#velocity-rules) dans Radar, si [votre forfait](https://docs.stripe.com/radar/how-radar-works.md#compare-plans) prend en charge cette fonctionnalité. ### Utiliser plusieurs approches Pour réduire les tests frauduleux de cartes, il peut parfois ê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 excessives (relance) de paiements peuvent ressembler à un test frauduleux de cartes si elles surviennent lors de pics extrêmes avec un faible taux de réussite. La relance et les attaques réelles de test frauduleux de cartes peuvent avoir des effets similaires sur votre entreprise, y compris le durcissement de la position des émetteurs en matière de risque. Assurez-vous de ne pas continuer à réessayer des cartes configurées sur des clients frauduleux après une attaque de test frauduleux de cartes, car cela répète l’attaque d’origine. La fonctionnalité [Smart Retries](https://docs.stripe.com/billing/revenue-recovery/smart-retries.md#non-retryable-decline-codes) de Stripe prend déjà cela en compte. ### 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. Il présente des règles de blocage intégrées basées sur les [vérifications bancaires](https://docs.stripe.com/radar/rules.md#traditional-bank-checks), comme les contrôles *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number). Si vous comprenez le comportement de vos clients et souhaitez personnaliser en détail la vitesse des paiements, vous pouvez créer des [règles personnalisées](https://docs.stripe.com/radar/rules/reference.md#velocity-rules) dans Radar, à condition que [votre forfait](https://docs.stripe.com/radar/how-radar-works.md#compare-plans) prenne en charge cette fonctionnalité. Vous trouverez des exemples dans le [guide sur les notions de base Radar](https://stripe.com/guides/radar-rules-101#rules-that-help-prevent-card-testing-or-card-cashing). ## See also - [Détection avancée de la fraude](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection.md) - [Optimiser votre intégration Radar](https://docs.stripe.com/radar/optimize-risk-factors.md) - [Protéger vos clés](https://docs.stripe.com/keys-best-practices.md) - [Guide sur les notions de base de Radar](https://stripe.com/guides/radar-rules-101)