Les règles par défaut de Stripe utilisent l’apprentissage automatique pour prédire et bloquer un nombre substantiel de Paiements frauduleux. Pour les entreprises qui ont besoin de plus de contrôle sur les Paiements à vérifier, autoriser ou bloquer, les règles sont un outil puissant pour personnaliser votre protection contre la fraude.

Ce guide couvre divers sujets liés aux règles Radar, notamment plus de 100 règles Radar que vous pouvez utiliser et les meilleures pratiques en matière de tests rétroactifs, de rédaction de règles, etc.

Commençons.

L’importance de l’ordre et de la hiérarchie des règles

L’ordre dans lequel les règles sont répertoriées sur votre page Radar est important. Chaque paiement est évalué par rapport aux règles que vous avez créées et exécutées dans l’ordre suivant :

1. Demander 3DS : Règles qui demandent une authentification 3D Secure lorsqu’elles sont utilisées avec l’API Payment Intents ou Checkout. Indépendamment des correspondances avec cette règle, les règles Autoriser, Bloquer et Examiner sont évaluées après.
   
2. Autoriser : Règles qui permettent le traitement d’un paiement. Les règles d’autorisation doivent être mises en place avec prudence, car elles prévalent sur toutes les autres règles, à l’exception des règles 3DS, et doivent être utilisées avec la plus grande prudence. Seuls les commerçants ayant traité plus de 100 000 $ peuvent rédiger des règles d’autorisation.
   
3. Bloquer : Règles qui bloquent un paiement et le rejettent. Si un paiement est rejeté, il n’est soumis à aucune règle de vérification.
   
4. Vérifier : Ces paiements sont toujours traités et facturés au client, mais ils sont signalés afin que vous puissiez les vérifier à nouveau si vous le souhaitez.
   

Pour illustrer cela, prenons l’exemple des règles suivantes. Tous les paiements inférieurs à 10 $ seraient traités. En effet, la première règle autorise le paiement, donc aucune autre règle n’est évaluée. Dans le même ordre d’idées, selon ces règles, un paiement de 1 500 dollars effectué aux États-Unis avec un niveau de risque normal serait également autorisé, malgré la règle bloquant les paiements supérieurs à 1 000 dollars. En effet, la deuxième règle de la liste autorise les paiements effectués aux États-Unis avec un niveau de risque normal. Une fois qu’une règle particulière est déclenchée, aucune autre règle n’est évaluée.

• Autoriser les paiements inférieurs à 10 $

• Autoriser les paiements aux États-Unis présentant un niveau de risque normal

• Bloquer les paiements présentant un niveau de risque élevé

• Bloquer les paiements supérieurs à 1 000 $

• Vérifier les paiements effectués avec une carte émise hors des États-Unis

Aide-mémoire sur le langage des règles

Les règles sont similaires à celles du langage SQL et vous pouvez utiliser différents opérateurs en fonction du type de données que vous utilisez pour créer votre règle. Voici un aide-mémoire.

Si vous souhaitez vérifier explicitement l’existence d’un attribut ou d’un attribut de métadonnées, n’utilisez pas l’opérateur !=, mais utilisez la fonction is_missing. Fournissez à cette fonction l’attribut ou la clé de métadonnées qui peut être manquante. Par exemple, vous pouvez écrire une règle pour faire correspondre tous les paiements pour lesquels vous n’avez pas accès à l’adresse de courriel d’un client :

• Vérifier si is_missing(:email_domain:)
  

Ou vous pouvez écrire une règle pour faire correspondre tous les paiements pour lesquels l’adresse de courriel d’un client n’est PAS manquante :

• Vérifier si !(is_missing(:email_domain:))
  

Rédiger des règles en langage naturel

Si vous souhaitez rédiger des règles plus facilement ou si vous ne savez pas quels attributs utiliser pour traiter un scénario de fraude spécifique, l’assistant Radar alimenté par l’IA traduira vos invites en langage naturel en règles dans la syntaxe de Radar. Vous pouvez également tester la règle directement à partir de l’assistant Radar, afin de voir comment elle aurait fonctionné par le passé avant de la mettre en place.

Règles de Radar les plus utilisées

Voici une liste non exhaustive des règles Radar les plus utilisées en fonction de différents objectifs.

Règles à empêcher le test (frauduleux) de cartes ou l’encaissement de cartes

Règles permettant de prévenir la fraude avec des UGS connues pour être à risque

Cette règle exige des métadonnées ou la transmission d’informations sur les UGS comme description des frais. Ces paiements sont toujours traités et facturés au client, mais ils sont signalés afin que vous puissiez les vérifier.

Règles visant à prévenir les abus liés aux cartes prépayées

Analyser vos fraudes pour orienter la création de règles

Vérifications des fraudes

Pour établir les règles les plus efficaces, vous devez bien comprendre les activités frauduleuses sur votre compte. Il est important de caractériser les différents types de vecteurs de fraude présents. Voici quelques questions à vous poser :

• Des comptes sont-ils créés et utilisent-ils immédiatement de nouveaux courriels et noms de titulaires de carte pour effectuer des achats frauduleux?

• Des fraudeurs accèdent-ils à des comptes anciens et effectuent-ils des achats d’un montant anormalement élevé?

• La fraude touche-t-elle davantage certains réseaux de cartes ou certains pays?

• Y a-t-il des fraudes à haute vitesse, c’est-à-dire plusieurs tentatives à partir de la même carte, du même e-mail ou de la même adresse IP sur une courte période?

En examinant la fraude à haute vitesse qui apparaît dans la capture d’écran ci-dessus, les règles utilisant authorized_charges_per_card_number_hourly ou authorized_charges_per_ip_address_hourly pourraient potentiellement remédier à ce vecteur de fraude.

Mieux comprendre les facteurs de fraude

Les informations sur la fraude vous aident à identifier et à traiter rapidement les causes de la fraude sans avoir à analyser manuellement les données transactionnelles. L’onglet Informations du Dashboard affiche les principaux attributs associés aux transactions frauduleuses. À partir de là, vous pouvez ajouter une règle pour traiter cet attribut directement depuis l’onglet Informations.

Trois types d’attributs pour créer des règles

Type 1

Attributs de post-autorisation : Ceux-ci sont accessibles à tous. Lorsque vous utilisez ces attributs, vous devez ajouter des deux-points avant et après les attributs de post-autorisation, comme :cvc_check:.

Voici un exemple d’utilisation des attributs post-autorisation :

• Bloquer si :address_line1_check : != ’pass’ Avec cette règle en place, tout paiement sera bloqué s’il ne passe pas spécifiquement le contrôle effectué par l’émetteur de la carte pour vérifier que la première ligne de l’adresse de facturation fournie correspond aux informations dont il dispose dans ses dossiers pour le titulaire de la carte. Cela signifie que si cette vérification est « indisponible », si ces données n’ont pas été vérifiées par l’émetteur ou si elles n’ont pas été fournies (‘not_provided’) par l’émetteur, le paiement sera bloqué.
  

Type 2

Attributs standard : Ils sont accessibles à tous. Vous devez utiliser des deux-points avant et après les attributs standard, comme :card_bin:. Nous avons divisé nos attributs standard en quatre catégories :

• Attributs basés sur la fréquence — utiles pour empêcher les tests (frauduleux) de cartes ou l’encaissement des cartes
  
• Attributs basés sur les informations de la carte
  
• Attributs basés sur les informations de paiement
  
• Attributs basés sur les informations du client
  

Certains attributs requièrent des valeurs sous forme de chaînes de caractères, tandis que d’autres requièrent des valeurs sous forme de nombres. Nous avons fourni un exemple pour chaque attribut afin de clarifier ce point. Si l’attribut nécessite une chaîne de caractères comme :card_bin:, vous verrez dans l’exemple que le nombre se trouve entre ‘ ’. Par exemple, :card_bin: = ‘424242’, bien qu’il nécessite un nombre, il n’aura pas le ‘ ’ comme :amount_in_usd: > 250.

Attributs basés sur la fréquence

Il existe quatre types d’attributs basés sur la fréquence qui sont particulièrement utiles pour prévenir la fraude par carte volée, les tests (frauduleux) de cartes et l’encaissement de carte.

1. Autorisation : sur la base des autorisations accordées par l’émetteur
   
2. Frais : en fonction des frais
   
3. Refus de paiement : basé sur les refus de paiement de l’émetteur
   
4. Blocage : basé sur les blocages effectués par l’apprentissage automatique de Radar.
   

Il existe également des attributs basés sur le résultat des transactions, notamment les autorisations (basées sur les autorisations accordées par l’émetteur), les transactions (basées sur les tentatives de transaction), les refus (basés sur les refus de l’émetteur), les litiges (transactions antérieures contestées comme frauduleuses) et les blocages (basés sur les blocages effectués par l’apprentissage automatique de Radar). Les résultats sont combinés avec les coordonnées du client (courriel, adresse IP, nom ou identifiant client) pour former un attribut.

De plus, vous pouvez associer la fréquence d’un détail client (courriel, nom) à la carte ou à l’adresse IP utilisée lors d’une transaction. En d’autres termes, il existe deux types de règles de fréquence :

1. Basé sur le résultat de la facturation (par exemple, authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) où le résultat correspond à une autorisation réussie, une tentative de facturation, un refus, un litige ou un blocage
   
2. Basé sur les liens entre les informations du client et une carte ou une adresse IP (par exemple, nom_nombre_pour_carte_hebdomadaire, email_nombre_pour_ip_horaire)
   

Les règles de fréquence excluent le paiement que vous traitez actuellement. Par exemple, authorized_charges_per_email_hourly représente le nombre de tentatives de paiement réussies à partir d’un courriel au cours de l’heure précédente. Ainsi, pour la première tentative de facturation dans une heure donnée pour un courriel, authorized_charges_per_email_hourly a une valeur de 0. Si la première tentative réussit, la deuxième tentative de facturation dans la même heure à partir de ce courriel a une valeur de 1, et ainsi de suite.

Attributs basés sur les informations de la carte

Attributs basés sur les informations de paiement

Attributs basés sur les informations du client

Voici un exemple d’utilisation des attributs standard :

• Bloquer si :card_country: IN (’CA’, ’DE’, ’AE’)
  

Avec cette règle en vigueur, tout paiement effectué avec une carte émise au Canada, en Allemagne ou aux Émirats arabes unis sera bloqué.

Type 3

Attributs de métadonnées : ces attributs dépendront des métadonnées que vous envoyez à Stripe. Avec ces attributs, vous devez utiliser deux deux-points avant et après les attributs standard, comme ::Customer Age::. Les attributs de métadonnées peuvent fonctionner sous forme de chaînes de caractères ou de nombres. Lorsqu’ils sont utilisés sous forme de chaînes de caractères, les attributs de métadonnées sont sensibles à la casse.

Les métadonnées peuvent être utilisées pour créer des règles très puissantes, comme placer les frais en vérification manuelle en fonction de l’UGS achetée ou réduire les frictions pour les clients fidèles. Pour savoir comment transmettre davantage de métadonnées, consultez ce guide.

Les attributs de métadonnées sont écrits en suivant cette structure :

• ::[metadata attribute name]:: [operator] [metadata_value]
  

Supposons que nous ayons des paiements avec les données clé-valeur suivantes sauvegardées dans le champ de métadonnées :

Une règle peut être rédigée pour placer les paiements qui répondent aux critères suivants dans la vérification.

• Vérifier si ::Âge du client :: < 30
  

Vous pouvez aussi écrire des règles à l’aide des attributs des métadonnées et d’autres attributs pris en charge et mentionnés dans ce document. Par exemple, vous pouvez écrire une règle qui place un paiement en vérification uniquement si l’ID de poste correspond à 5A381D et si le montant du paiement dépasse 1 000 USD.

• Vérifier si ::Item ID:: = ’5A381D’ and :amount_in_usd: > 1000
  

Les attributs de métadonnées prennent également en charge l’opérateur IN pour effectuer des correspondances avec plusieurs valeurs. Par exemple, vous pouvez écrire une règle qui place un paiement en attente de vérification si l’ID de catégorie est « épicerie », « électronique » ou « vêtements ».

• Vérifier si ::Category ID:: IN (’groceries’, ’electronics’, ’clothing’)
  

L’opérateur INCLUDES peut être utilisé avec des règles pour les attributs de métadonnées et d’autres attributs de chaîne afin de faire correspondre des sous-chaînes. Par exemple, vous pouvez écrire une règle qui place un paiement en attente de vérification si l’ID de poste comprend la chaîne A381. Cela correspond à « A381 », « 5A381D », « A381D », « 5A381 », etc.

• Vérifier si ::Item ID:: INCLUDES ’A381’
  

Les métadonnées sont également accessibles sur les objets client et destination (si ceux-ci sont utilisés pour un paiement donné). Ces attributs sont écrits dans la structure suivante :

• ::[customer|destination]:[metadata attribute name]::[operator][metadata_value]:
  

Supposez que vous ayez un client avec les métadonnées suivantes :

Vous pourriez écrire une règle qui autorise les paiements si le champ des métadonnées Trusted du client est true.

• Autoriser si ::customer:Trusted:: = ’true’
  

Ou bien si vous aviez une destination avec les métadonnées suivantes :

Vous pourriez écrire une règle qui place un paiement en vérification si le champ des métadonnées Category de la destination est new.

• Vérifier si ::destination:Category:: = ’new’
  

Utilisation des listes enregistrées dans vos règles (par exemple, listes d’autorisation, listes de blocage)

Vous pouvez référencer un groupe de valeurs dans vos règles à l’aide de listes que vous avez préalablement créées (par exemple, des listes d’autorisation ou des listes de blocage). Si vous essayez de bloquer une liste de courriels, vous devez créer une liste de blocage plutôt que de créer plusieurs règles pour chaque courriel que vous souhaitez bloquer.

Tous les alias de liste référencés dans les règles doivent commencer par @. Pour créer une règle référençant une liste, vous devez respecter la structure suivante :

• {action} [attribut] dans [liste]
  

Par exemple, supposons que vous disposiez d’une liste de pays dont vous souhaitez bloquer les cartes. Vous pouvez rédiger une règle à l’aide de plusieurs clauses OR :

• Bloquer si :card_country: = ’CA’ OR :card_country: = ’DE’ OR :card_country: = ’AE’
  

Vous pouvez également écrire une règle à l’aide d’une liste en ligne :

• Bloquer si :card_country: IN (’CA’, ’DE’, ’AE’)
  

Vous pouvez également créer une liste des pays dont vous souhaitez bloquer les cartes, intitulée card_countries_to_block. Vous pouvez ensuite ajouter les pays de votre choix à cette liste et y faire référence dans une règle :

• Bloquer si :card_country: in @card_countries_to_block
  

Non seulement la règle utilisant une liste est plus concise, mais elle est également beaucoup plus facile à modifier et à compléter avec un grand nombre de postes.

Rédiger des règles complexes avec plusieurs conditions

Vous pouvez créer des conditions complexes en combinant des conditions de base à l’aide des opérateurs AND, OR et NOT. Vous pouvez également utiliser leurs équivalents symboliques : &&, || et ! respectivement. À l’instar des langages de programmation tels que C, Python et SQL, Stripe prend en charge la priorité standard des opérateurs (ordre des opérations). Par exemple, la condition complexe :

• {condition_X} OR NOT {condition_Y} AND {condition_Z}
  

est interprété comme :

• {condition_X} OR ((NOT {condition_Y}) AND {condition_Z})
  

Le regroupement sous-conditionnel avec des condition complexes est également pris en charge à l’aide de parenthèses. Par exemple, le premier exemple peut être corrigé pour modifier explicitement l’ordre d’évaluation des sous prédicats :

• ({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

• {condition_X} OR NOT ({condition_Y} AND {condition_Z})

En plaçant les parenthèses à des emplacements différents, chaque condition complexe donne des résultats différents.

La fonction is_missing peut également être utilisée dans les conjonctions OR ou AND :

• Vérifier si is_missing(:email_domain:) OR :email_domain: IN (’yopmail.net’, ’yandex.ru’)
  

Vous pouvez également utiliser la fonction is_missing lorsqu’il n’y a pas de manque, dans ce cas si elle bloque les paiements lorsque :ip_country: n’est PAS manquant et que l’adresse IP provient des États-Unis ou de Porto Rico.

• Bloquer si !(is_missing(:ip_country:))AND :ip_country: IN (’US’, ’PR’)
  

Règles de tests rétroactifs

En matière d’analyse des règles, il existe un compromis entre la prévention de la fraude et le blocage des transactions légitimes ou des faux positifs. Les tests rétroactifs permettent d’identifier les règles qui correspondent à votre appétit pour le risque ou qui offrent le juste équilibre entre les litiges évités et l’augmentation des faux positifs. Pour estimer l’impact d’une règle, vous pouvez effectuer des tests rétroactifs sur des combinaisons à l’aide des données transactionnelles des six derniers mois dans le Dashboard Radar et mener des analyses plus ciblées afin de comprendre comment la règle aurait fonctionné si elle avait été récemment mise en place.

Effectuer des tests rétroactifs dans le Dashboard

Les définitions de ce qui constitue un paiement frauduleux et d’autres paiements réussis diffèrent selon le type de règle que vous testez :

Règle de blocage

• Contestés, remboursés pour raison de fraude ou ayant fait l’objet d’une alerte de suspicion de fraude : Paiements réussis qui ont été contestés ou remboursés pour fraude ou frais réussis placés en attente de vérification qui ont été contestés ou remboursés pour fraude

• Autres paiements réussis : paiements réussis qui n’ont pas été contestés ou remboursés pour fraude ou paiements réussis soumis à examen et qui n’ont pas été contestés ou remboursés pour fraude

• Tentatives de paiement ayant échoué : refusées par l’émetteur ou bloquées par Radar

Règle de vérification

• Contestés, remboursés pour raison de fraude ou ayant fait l’objet d’une alerte de suspicion de fraude : paiements réussis qui ont été contestés ou remboursés pour fraude

• Autres paiements réussis : paiements réussis qui n’ont pas été contestés ou remboursés pour fraude.

• Échec ou déjà soumis à vérification : refusé par l’émetteur, bloqué par Radar, ou paiement réussi soumis à vérification (indépendamment de l’état du litige ou du remboursement)

Règle d’autorisation

• Bloqués par Stripe ou vos règles personnalisées : paiement bloqué par Radar

• Contestés, remboursés pour raison de fraude ou ayant fait l’objet d’une alerte de suspicion de fraude : Paiements réussis qui ont été contestés ou remboursés pour fraude ou frais réussis placés en attente de vérification qui ont été contestés ou remboursés pour fraude

• Autres paiements réussis ou refusés par la banque : refusés par l’émetteur, paiements réussis qui n’ont pas été contestés, ou remboursés pour fraude ou paiements réussis placés en attente de vérification et qui n’ont pas été contestés ou remboursés pour fraude

Effectuer des tests rétroactifs personnalisés

La fonctionnalité de tests rétroactifs dans le Dashboard Radar se concentre sur les transactions des six derniers mois et inclut les litiges, les alertes précoces de fraude et les frais remboursés pour cause de fraude.

Vous pouvez effectuer une analyse plus ciblée si, par exemple, vous risquez d’être identifié dans le cadre d’un programme de surveillance des fraudes Visa (axé exclusivement sur les alertes de suspicion de fraude) ou si vous constatez une récente augmentation des fraudes provenant d’un pays IP ou d’un type de portefeuille spécifique. Pour ce faire, vous pouvez créer une requête SQL dans Stripe Sigma ou exporter et analyser les rapports sur les données de paiement dans le tableau de bord. Les tests rétroactifs personnalisés offrent une grande flexibilité en termes de délais (au-delà de six mois) et permet des analyses plus ciblées (par exemple, vous pouvez vous concentrer uniquement sur les litiges ou les EFW). L’exemple de requête ci-dessous effectue des tests rétroactifs sur les alertes de suspicion de fraude Visa (EFW) pour les transactions supérieures à 100 $ si vous constatez, par exemple, que le volume de fraude a récemment augmenté pour les montants élevés et que les transactions présentant un indice de risque élevé ont créé un risque pour le programme de surveillance :

Utilisation des champs et des tableaux disponibles dans Stripe Sigma

dont la base est comme (
    sélectionner
        c.id,
        c.amount,
        c.captured,
        e.created comme efw_created
    from charges c
    left join early_fraud_warnings on e.charge_id = c._id
    where card_brand = ‘visa’
    and (c.amount / 100) >= 100
    and c.captured >= dateadd(‘day’, -180, current_date)
)

sélectionner 
    count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,

sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount

à partir de la base

Les tests rétroactifs effectués sur les 60 derniers jours à compter de la date de création de l’EFW permettent de cibler les fraudes les plus récentes, tandis que les tests rétroactifs effectués sur les 60 à 120 derniers jours de ventes non frauduleuses permettent aux fraudes d’atteindre leur pleine maturité.

Vecteurs de fraude courants

La plupart des fraudeurs suivent un schéma commun pour commettre leurs fraudes. Tout d’abord, ils vérifient la validité des informations de paiement volées (par exemple, les cartes). Une fois leur validité confirmée, ils utilisent ces identifiants pour obtenir des biens physiques à des fins personnelles ou de revente (articles de luxe ou appareils électroniques), des services à des fins personnelles ou de revente (services de livraison de repas) ou des services et produits facilitant la commission d’autres fraudes (services d’hébergement web, services d’envoi de pourriels, etc.).

Poursuivez votre lecture pour en savoir plus sur certains des vecteurs de fraude les plus courants et découvrir comment utiliser les règles Radar pour les atténuer.

Tests

Le test (frauduleux) de cartes se produit lorsque des fraudeurs utilisent des scripts ou des processus manuels pour vérifier si les numéros de carte volés sont toujours actifs. Cette phase de la fraude ne vise pas à obtenir un bien ou un service physique, mais à vérifier que les cartes sont actives. Ces transactions portent généralement sur des montants peu élevés ou des autorisations. Les tests sont généralement effectués à un rythme rapide et successif. Les attributs qui peuvent être utiles sont les fonctionnalités de regroupement et de vitesse, telles que :

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

Les fraudeurs tentent généralement de contourner ces mesures en créant de faux courriels et en utilisant des adresses électroniques distinctes. Les fraudeurs plus avancés masquent les adresses IP ou disposent même de plusieurs appareils afin de fournir des données uniques. À ce stade, il est important de connaître le comportement habituel et normal des clients. Des caractéristiques telles que le domaine de messagerie et le pays de l’adresse IP, entre autres catégories plus larges, peuvent aider à identifier les transactions à haut risque. De nombreux fraudeurs utilisent des domaines de messagerie populaires provenant de fournisseurs de messagerie établis, tels que gmail.com. Vous pouvez voir des domaines tels que gmail.comms ou gomail.co, qui tentent de masquer l’identité des fraudeurs. Le pays de la carte et le pays de l’adresse IP peuvent également être utilisés pour segmenter les clients et s’assurer que les transactions proviennent de zones typiques de votre base d’utilisateurs. Les transactions en dehors de ces zones peuvent être intéressantes à examiner ou à bloquer.

Une dernière fonctionnalité permettant de limiter ce comportement consiste à mettre en place un CAPTCHA.

Dans Stripe Checkout, des défis CAPTCHA sont automatiquement proposés lorsque notre système d’apprentissage automatique détecte une attaque par test (frauduleux) de cartes. Pour limiter les tests (frauduleux) de cartes, Stripe utilise une série de contrôles automatisés et manuels, notamment des limiteurs de débit, des alertes et des vérifications continues, ainsi que des modèles d’apprentissage pour détecter automatiquement les attaques. Ces modèles ne génèrent des défis que lorsqu’une attaque par test est en cours, de sorte que les utilisateurs réels ne voient presque jamais de CAPTCHA, contrairement aux robots. Cela a permis de réduire les tests (frauduleux) de cartes pour les entreprises utilisant Stripe Checkout de 80 %, sans impact détectable sur la conversion.

Notez que vous pouvez également rédiger des règles personnalisées telles que « Bloquer si refusé plus de 3 fois à partir d’une adresse IP donnée » afin de réduire les attaques par test de cartes.

Extraction de la valeur

Cartes de crédit volées (nouveau comportement)

Dans ce vecteur de fraude, l’auteur de la fraude utilise la carte volée validée sur son appareil personnel ou sur un appareil utilisé pour commettre la fraude.

Ce vecteur est généralement exploité de manière abusive soit par le biais d’attaques massives chiffrées, soit à plus petite échelle par des réseaux de fraudeurs et des poches de fraudeurs plus ciblés. Quoi qu’il en soit, l’utilisation d’attributs de règle qui mesurent la nouveauté d’un compte sur Stripe, comme hours_since_email_first_seen_on_stripe, en combinaison avec risk_score et d’autres fonctionnalités, permet de tenir à distance ces nouveaux titulaires de carte. De plus, les restrictions de vitesse sur les adresses IP, les e-mails et les cartes peuvent protéger davantage les commerçants contre les attaques de volume, dans lesquelles des fraudeurs tentent de monétiser le plus rapidement possible les identifiants volés.

Cartes de crédit volées (comportement de masquage)

Dans ce vecteur de fraude, l’auteur de la fraude utilise la carte volée validée sur son appareil personnel ou sur un appareil utilisé pour commettre la fraude ou l’auteur de la fraude a compromis un compte d’abonnement et a obtenu l’accès aux informations de carte de crédit sauvegardées dans le compte.

L’acteur frauduleux fera tout son possible pour masquer sa présence en :

• Utilisant le même nom que celui utilisé pour les transactions précédentes déjà effectuées

• Utilisant la même adresse de facturation que celle utilisée pour les transactions précédentes

• Utilisant un VPN pour faire croire qu’ils sont les titulaires originaux de la carte. Ils peuvent se connecter via VPN dans la même ville et parfois même dans le même quartier

• Modifiant uniquement un détail mineur, comme l’adresse de courriel ou le numéro de téléphone

• Modifiant l’adresse de livraison par rapport aux transactions précédentes, pour un bien physique, avec un écart potentiellement important entre l’adresse de facturation et l’adresse de livraison. Il s’agit d’un signal imprécis.

Le comportement de masquage décrit ci-dessus rend difficile l’identification de la personne qui effectue réellement la transaction : le titulaire original de la carte ou un fraudeur qui a piraté le compte. Cela signifie souvent que ce type de fraude passe inaperçu plus longtemps, tant pour le commerçant que pour le titulaire original de la carte.

La stratégie est ici la même : l’auteur de la fraude tentera d’extraire autant de valeur que possible des identifiants volés. Les règles qui utilisent des fonctionnalités de limitation de la vitesse, associées à riskscore, cvccheck fails ou zip check fails, peuvent aider à se protéger contre ce type de comportement.

Autres bonnes pratiques

Voici d’autres bonnes pratiques pour vous aider à optimiser la rédaction de règles dans Radar.

L’importance d’utiliser Stripe.js

• Inclure stripe.js dans l’intégralité du processus de paiement pour une détection maximale des fraudes
  
• Pour tirer le meilleur parti de Radar sans affecter le temps de chargement des pages, chargez stripe.js de manière asynchrone sur les pages non liées au paiement
  
• Le plus simple à placer à côté des balises de script Google Analytics
  
• La taille totale de l’offre stripe.js est de 29,6 ko compressé au format gzip
  
  • État futur : radar.js pourra être inclus séparément de stripe.js.
    

En conclusion

Les règles peuvent être un outil extrêmement puissant pour vous aider à personnaliser votre protection contre la fraude. En mettant en place une logique unique, inspirée des meilleures pratiques décrites dans ce guide, vous pouvez créer dans Radar une configuration de prévention de la fraude adaptée aux besoins spécifiques de votre entreprise.

Si vous souhaitez en savoir plus sur Radar for Fraud Teams, cliquez ici.

Si vous utilisez déjà Radar for Fraud Teams, consultez la page Règles de votre Dashboard pour commencer à rédiger des règles.

Autres remarques

Radar pour les plateformes

Êtes-vous une plateforme utilisant Stripe Connect? Si oui, toutes les règles que vous créez s’appliquent uniquement aux paiements créés sur le compte de la plateforme (dans les termes Connect, il s’agit des paiements destination ou on-behalf-of)
Les paiements créés directement sur le compte connecté sont soumis aux règles de ce compte.

Radar pour Terminal

Les paiements Terminal ne sont pas contrôlés par Radar. Cela signifie que si vous utilisez Terminal, vous pouvez rédiger des règles établies sur la fréquence IP sans vous soucier de bloquer vos paiements en personne.