Accéder directement au contenu
Créez un compte
ou
connectez-vous
Le logo de la documentation Stripe
/
Demander à l’IA
Créer un compte
Connectez-vous
Commencer
Paiements
Revenus
Plateformes et places de marché
Gestion des fonds
Outils de développement
AperçuDécouvrez tous les produits
Commencer à développer
Commencer le développement
Exemples de projets
À propos des API
Développer avec des GML
Utiliser Stripe sans codage
Configurer Stripe
Créer un compte
Dashboard Web
Dashboard mobile
Migrer vers Stripe
Gérer le risque de fraude
Comprendre la fraude
    Aperçu
    Types de fraude
    Test de cartes
    Usurpation d'identité
    Contrôles de vérification
    Bonnes pratiques
Radar pour la protection contre la fraude
Gérer les litiges
Vérifier l'identité
AccueilCommencerUnderstand fraud

Protégez-vous contre les tests de cartes

Apprenez-en davantage sur cette activité frauduleuse et découvrez comment vous en protéger.

Copier la page

Le test frauduleux de cartes 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 de crédit 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 « cardage », « test de compte », « énumération » ou « 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 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 Web clandestin.

  • Configuration de la carte : 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 titulaires de cartes 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 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 de cartes 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.
  • 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.
  • 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 le test de carte.
  • Remboursez les paiements frauduleux pour éviter tout litige.
  • Utiliser une intégration recommandée par Stripe ou ajouter des limitations 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, consulter la vue de la liste des transactions 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, examiner les erreurs 402 sur la page Journaux des échecs ou écouter les liens de rappel HTTP et les réponses des API, en particulier avec un résultat « generic_decline ».
  • 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.
Identifier les tests de cartes

Paiement bloqué en raison d’une suspicion de test de carte

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 :

  • 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 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 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.

Avertissement

Vous n’êtes pas développeur? Vous utilisez un module d’extension ou une plateforme? La prévention et l’atténuation des tests de cartes nécessite généralement des modifications au niveau du code. Vous devez donc demander au développeur ou au prestataire qui a écrit le code de lire cette documentation et collaborer avec lui pour empêcher cette activité frauduleuse.

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 d’IA, des déclencheurs CAPTCHA, des examens continus, etc. Lorsque nous détectons que vous faites l’objet d’une attaque par test de cartes, nous choisissons dynamiquement les interventions visant à supprimer l’attaque autant que possible, tout en permettant aux utilisateurs légitimes d’effectuer des transactions sur votre compte avec le moins d’incidence possible. Ces paiements sont identifiés par le libellé Blocked by Stripe.

Toutefois, l’efficacité des contrôles de Stripe dépend de votre intégration et des signaux que vous nous envoyez. Nous utilisons de nombreux indicateurs pour distinguer les paiements légitimes des tests de cartes. Bien que nous calculions certains de ces indicateurs automatiquement, nombre d’entre eux 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 peut être 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.

L’utilisation de l’une de nos intégrations de paiement recommandées vous permet de tirer le meilleur parti de la protection contre le test de cartes de Stripe. Si vous ne pouvez pas utiliser l’une de ces intégrations, intégrez le plus de données possible ou mettez en œuvre vos propres contrôles. Les contrôles de test des cartes 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.

Le fait d’inclure les informations suivantes dans vos paiements peut avoir un impact significatif sur la performance des modèles de test des cartes de Stripe. Nos intégrations recommandées vous permettent de collecter ces informations, tandis que les intégrations directes peuvent nécessiter d’inclure manuellement ces données.

  • Détection avancée de la fraude Highest impact
  • 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 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. 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 par falsification des requêtes intersites (CSRF) sont également efficaces contre certains types de tests de cartes, comme 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, même après la connexion ou l’inscription.

Détecter et prévenir tout comportement inhabituel

Utilisez le Dashboard, les liens de rappel ou la surveillance continue avec Stripe Sigma ou Data Pipelines pour suivre les anomalies présentes dans votre trafic. Vous pouvez comparer un test de cartes au trafic légitime type, puis créer des filtres qui limitent ou empêchent uniquement cette activité frauduleuse. 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 dans Radar for Fraud Teams. Nous abordons ce sujet dans la section suivante.

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 relances de paiements excessives peuvent ressembler à des tests de cartes si elles se présentent sous la forme de pics extrêmes avec un faible taux de réussite. Les relances et les attaques réelles de tests de cartes peuvent avoir des effets similaires sur votre entreprise, notamment en incitant les émetteurs à durcir leur position en matière de risque. Veillez à ne pas essayer de nouveau d’utiliser les cartes de clients frauduleux après une attaque par test de cartes, car cela reproduit l’attaque initiale. Smart Retries de Stripe prend 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. Il présente des règles de blocage intégrées basées sur les vérifications bancaires, comme les contrôles CVC.

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

Vous trouverez des exemples dans le guide sur les notions de base Radar.

Voir aussi

  • Détection avancée de la fraude
  • Optimisez votre intégration Radar
  • Protéger vos clés
  • Guide sur les notions de base de Radar
Cette page vous a-t-elle été utile?
OuiNon
Besoin d'aide? Contactez le service d'assistance.
Rejoignez notre programme d'accès anticipé.
Consultez notre journal des modifications.
Des questions? Contactez l'équipe commerciale.
GML? Lire llms.txt.
Optimisé par Markdoc