Les règles par défaut de Stripe utilisent le machine learning pour prédire et bloquer un nombre important de paiements frauduleux. Si vous cherchez à définir plus finement les paiements à examiner, autoriser ou bloquer pour personnaliser votre protection contre la fraude, les règles vous aideront à y parvenir efficacement.

Ce guide aborde divers sujets en lien avec les règles Radar. Il présente notamment plus de 100 exemples de règles et des bonnes pratiques en matière de tests rétroactifs, de syntaxe, etc.

Bonne lecture !

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

L'ordre dans lequel les règles sont énumérées sur votre page Radar est très significatif. Chaque paiement est évalué par les règles que vous avez créées, dans l'ordre suivant :

1. Règles d'authentification (3DS exigée) : règles qui déclenchent une authentification 3D Secure lorsqu'elles sont utilisées avec l'API Payment Intents ou Checkout. Que ces règles soient déclenchées ou non, les règles d'autorisation, de blocage et de vérification ne sont évaluées que dans un deuxième temps.
   
2. Règles d'autorisation : règles qui autorisent le traitement d'un paiement. Les règles d'autorisation sont à mettre en œuvre avec soin, car elles ont la priorité sur toutes les autres règles, à l'exclusion des règles 3DS. Seuls les marchands qui ont traité plus de 100 000 $ peuvent créer des règles d'autorisation.
   
3. Règles de blocage : règles qui bloquent un paiement et le rejettent. Si un paiement est refusé, il n'est pas pris en compte par les règles de vérification.
   
4. Règles de vérification : les paiements déclenchant ces règles sont traités, et le client débité, mais ils vous sont signalés afin que vous puissiez les réexaminer si vous le souhaitez.
   

Pour mieux comprendre, utilisons les règles suivantes comme exemple. Tous les paiements inférieurs à 10 $ seraient traités, car la première règle autorise ces paiements et aucune autre règle n'est donc testée. Par ailleurs, avec ces règles, un paiement de 1 500 $ effectué aux États-Unis avec un niveau de risque normal serait également autorisé, malgré la présence d'une règle de blocage des paiements supérieurs à 1 000 $. En effet, la deuxième règle de la liste autorise les paiements effectués aux États-Unis et dont le niveau de risque est normal. Une fois qu'une règle est déclenchée, aucune autre règle n'est testée.

• Autoriser les paiements inférieurs à $10

• Autoriser les paiements aux États-Unis et dont le niveau de risque est normal

• Bloquer les paiements dont le niveau de risque est high

• Bloquer les paiements greater than $1,000

• Vérifier les paiements effectués avec une carte émise outside the US

Tableau récapitulatif de la syntaxe des règles

Les règles ressemblent à du code SQL et vous pouvez faire appel à divers opérateurs en fonction du type de données que vous utilisez. Voici un tableau récapitulatif.

Si vous souhaitez vérifier explicitement l'existence d'un attribut, ou d'un attribut de métadonnées, utilisez la fonction is_missing plutôt que l'opérateur !=. Indiquez à cette fonction l'attribut ou la clé de métadonnées pouvant manquer. Vous pouvez par exemple rédiger une règle qui fait correspondre tous les paiements pour lesquels vous n'avez pas accès à l'adresse e-mail du client :

• Review if is_missing(:email_domain:)
  

Vous pouvez également rédiger une règle destinée à faire correspondre tous les paiements pour lesquels l'adresse e-mail du client est NON manquante :

• Review if !(is_missing(:email_domain:))
  

Rédaction de règles en langage naturel

Si vous souhaitez rédiger des règles plus facilement, ou que vous ne savez pas de façon sûre quels attributs utiliser pour traiter un scénario de fraude spécifique, l'outil Radar Assistant alimenté par IA peut convertir vos invites en langage naturel sous forme de règles spécifiées selon la syntaxe de Radar. Vous pouvez également tester à nouveau la règle directement à partir de Radar Assistant afin de voir comment elle se serait comportée historiquement avant sa mise en œuvre.

Règles de Radar couramment utilisées

Voici une liste non exhaustive de règles Radar couramment appliquées en fonction de différents objectifs.

Règles permettant d'éviter les tests ou l'encaissement de cartes

Règles qui contribuent à prévenir la fraude liée à des unités de gestion des stocks à risque

Cette règle impose la présence de métadonnées ou la transmission des informations sur l'unité de gestion des stocks en tant que description du paiement. Même si les paiements identifiés sont traités, et le client débité, ils vous sont signalés afin que vous puissiez les réexaminer si vous le souhaitez.

Règles qui empêchent d'abuser des périodes d'essai à l'aide de cartes bancaires prépayées

Analyse de votre fraude pour guider la création de règles

Passages en revue de la fraude

Pour élaborer les règles les plus efficaces possible, vous devez approfondir votre connaissance de l'activité frauduleuse menée sur votre compte. Il est important de caractériser les différents types de vecteurs de fraude présents. Posez-vous les quelques questions suivantes :

• Les comptes s'inscrivent-ils et effectuent-ils immédiatement des achats frauduleux en utilisant de nouvelles adresses e-mail et de nouveaux noms de titulaires de carte ?

• Des acteurs frauduleux accèdent-ils à des comptes anciens et effectuent-ils des achats pour des montants anormalement élevés ?

• La fraude vise-t-elle des réseaux de cartes ou des pays spécifiques ?

• Existe-t-il une fraude à haute fréquence, c'est-à-dire plusieurs tentatives perpétrées à partir de la même carte, de la même adresse e-mail ou de la même adresse IP durant une courte période ?

En examinant la fraude à haute fréquence qui se produit dans la capture d'écran ci-dessus, on voit que les règles qui appliquent la syntaxe authorized_charges_per_card_number_hourly ou authorized_charges_per_ip_address_hourly peuvent potentiellement contrer ce vecteur de fraude.

Apprenez à mieux connaître les facteurs de fraude

Les informations approfondies sur la fraude visent à identifier et à traiter rapidement leurs causes sans avoir à analyser manuellement les données de transaction. L'onglet Insights du Dashboard indique les principaux attributs associés aux transactions frauduleuses. De là, vous pouvez ajouter une règle destinée à traiter cet attribut directement depuis l'onglet Insights.

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

Type 1

Attributs post-autorisation : ces attributs sont accessibles à tous. Vous devez les encadrer par des doubles points, par exemple :cvc_check:.

Voici un exemple d'utilisation d'attributs post-autorisation :

• Block if :address_line1_check: != 'pass' Cette règle bloque tout paiement ne passant pas la vérification effectuée par l'émetteur de la carte, qui consiste à comparer la première ligne de l'adresse de facturation renseignée avec les informations dont il dispose au sujet du titulaire de la carte. Autrement dit, si le résultat de cette vérification est ‘unavailable’, si ces données ont été ‘unchecked’ par l'émetteur ou si les données sont ‘not_provided’ par l'émetteur, le paiement sera bloqué.
  

Type 2

Attributs standard : ces attributs sont accessibles à tous. Vous devez les encadrer par des doubles points, par exemple :card_bin: Nous avons réparti nos attributs standard en quatre catégories :

• Attributs basés sur la fréquence (utiles pour empêcher les tests de cartes bancaires ou la fraude à la carte bancaire)
  
• Attributs basés sur les informations de la carte bancaire
  
• Attributs basés sur les informations du paiement
  
• Attributs basés sur les informations du client
  

Certains attributs nécessitent des valeurs sous forme de chaînes, tandis que d'autres nécessitent des valeurs sous forme de nombres. Pour plus de clarté, nous avons donné un exemple pour chacun. Si l'attribut nécessite une chaîne, comme :card_bin:, vous verrez dans l'exemple que le nombre figure entre ‘ ’. Par exemple, :card_bin: = ‘424242’. S'il requiert un nombre, il ne comportera pas les symboles ‘ ’, par exemple :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 à la carte volée, les tests de cartes bancaires et la fraude à la carte bancaire.

1. Autorisation : basé sur les autorisations accordées par l'émetteur
   
2. Paiement : basé sur les paiements
   
3. Refus : basé sur les refus par l'émetteur
   
4. Blocage : basé sur les blocages effectués par le machine learning de Radar
   

Il existe également des attributs basés sur l'issue du paiement, y compris des authentifications (basés sur les autorisations concluantes accordées par l'émetteur), des paiements (basés sur les tentatives de paiement), des refus (basés sur les refus par l'émetteur), des litiges (transactions antérieures contestées au motif d'une fraude) et des blocages (basés sur les blocages effectués par le machine learning de Radar). Les issues sont associées à une information relative au client (adresse e-mail, adresse IP, nom ou ID de client) pour former un attribut.

En outre, vous pouvez associer la fréquence d'une information de client (adresse e-mail, nom) avec la carte bancaire ou l'adresse IP utilisée dans le cadre d'une transaction. Autrement dit, deux types de règles de fréquence sont disponibles :

1. Basées sur l'issue du paiement (par ex., authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) dont l'issue est une autorisation réussie, une tentative de paiement, un refus, un litige ou un blocage
   
2. Basées sur les liens entre les informations du client et une carte ou une adresse IP (p. ex., name_count_for_card_weekly, email_count_for_ip_hourly)
   

Les règles de fréquence excluent le paiement en cours de traitement. Par exemple, authorized_charges_per_email_hourly correspond au nombre de tentatives de paiement antérieures réussies pour une adresse e-mail donnée au cours de l'heure écoulée. Par conséquent, pour la première tentative de paiement au cours d'une heure donnée et en lien avec une adresse e-mail donnée, authorized_charges_per_email_hourly a une valeur de 0. Si cette tentative réussit, la deuxième tentative de paiement effectuée au cours de la même heure et avec cette même adresse e-mail aura une valeur de 1, et ainsi de suite.

Attributs basés sur les informations de la carte

Attributs basés sur les informations du paiement

Attributs basés sur les informations du client

Voici un exemple d'utilisation des attributs standard :

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Si cette règle est appliquée, tout paiement effectué à l'aide d'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 placer deux doubles points avant et après les attributs standard, par exemple ::Customer Age::. Les attributs de métadonnées peuvent être manipulés sous forme de chaînes ou de nombres. Sous forme de chaînes, ils doivent respecter la casse.

Les métadonnées peuvent servir à créer des règles très élaborées, comme soumettre des paiements à des vérifications manuelles en fonction de l'unité de gestion des stocks achetée ou simplifier le processus pour les clients fidèles. Pour savoir comment transmettre plus de métadonnées, lisez ce guide.

La syntaxe des attributs de métadonnées obéit à la structure suivante :

• ::[nom de l'attribut de métadonnée]:: [opérateur] [valeur_métadonnées]
  

Imaginons que des paiements aient les données clé-valeur suivantes stockées dans le champ des métadonnées :

Il est possible de créer une règle soumettant à une vérification les paiements répondant aux critères suivants.

• Review if ::Customer Age:: < 30
  

Vous pouvez également créer des règles à l'aide d'attributs de métadonnées et d'autres attributs pris en charge mentionnés dans ce document. Par exemple, vous pouvez élaborer une règle qui soumet un paiement à une vérification uniquement si l'ID de l'article est 5A381D et si le montant du paiement est supérieur à 1 000 US$.

• Review if ::Item ID:: = '5A381D' and :amount_in_usd: > 1000
  

Les attributs de métadonnées prennent également en charge l'opérateur IN pour inclure plusieurs valeurs. Par exemple, vous pouvez rédiger une règle qui soumet à une vérification un paiement si l'ID de catégorie est « groceries », « electronics » ou « clothing ».

• Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')
  

Il est possible d'utiliser l'opérateur INCLUDES avec des règles liées à des attributs de métadonnées et d'autres attributs de type chaîne pour inclure des sous-chaînes. Vous pourriez par exemple écrire une règle qui soumet un paiement à une vérification si l'ID d'article comprend la chaîne A381. Cette règle serait donc activée pour les ID « A381 », « 5A381D », « A381D », « 5A381 », etc.

• Review if ::Item ID:: INCLUDES 'A381'
  

Vous pouvez également accéder aux métadonnées à partir des objets client et destination (si ceux-ci sont utilisés aux fins d'un paiement donné). La syntaxe de ces attributs obéit à la structure suivante :

• ::[client|destination]:[nom attribut métadonnées]::[opérateur][valeur_métadonnées]:
  

Imaginons qu'un client présente les métadonnées suivantes :

Vous pourriez rédiger une règle qui autorise systématiquement les paiements si le champ de métadonnées Trusted du client est true.

• Allow if ::customer:Trusted:: = 'true'
  

Ou si une destination présente les métadonnées suivantes :

Vous pourriez créer une règle qui soumet un paiement à une vérification si le champ de métadonnées Category de la destination est new.

• Review if ::destination:Category:: = 'new'
  

Utilisation de listes préexistantes dans vos règles (par ex. listes d'autorisation, listes de blocage, etc.)

Vous pouvez faire référence à un groupe de valeurs dans vos règles à l'aide de listes préalablement créées (par ex. des listes d'autorisation ou de blocage). Si vous essayez de bloquer une liste d'adresses e-mail, il est ainsi préférable de créer une liste de blocage plutôt que de créer une règle pour chaque adresse e-mail.

Tous les alias de listes auxquelles vos règles font référence doivent commencer par @. Pour élaborer une règle faisant référence à une liste, vous devez respecter cette structure :

• {action} [attribut] in [liste]
  

Imaginons que vous ayez une liste de pays d'émission de cartes bancaires que vous souhaitez bloquer. Vous pourriez créer une règle reposant sur plusieurs clauses OR :

• Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'
  

Vous pourriez également rédiger une règle utilisant une liste intégrée :

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Vous pouvez également établir une liste de pays d'émission de cartes bancaires à bloquer, intitulée card_countries_to_block, y ajouter les pays de votre choix, puis y faire référence dans une règle :

• Block if :card_country: in @card_countries_to_block
  

Non seulement une règle utilisant une liste est plus concise, mais il est également plus facile de la modifier et d'y ajouter un grand nombre d'éléments.

Rédiger des règles complexes aux conditions multiples

Vous pouvez élaborer des conditions complexes en regroupant des conditions basiques à l'aide des opérateurs AND, OR et NOT. Vous pouvez également utiliser les symboles équivalents : &&, || et !. À l'image des langages de programmation comme C, Python et SQL, Stripe prend en charge la priorité des opérateurs standard (ordre des opérations). Par exemple, la condition complexe suivante :

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

est interprétée comme ceci :

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

Les groupements de sous-conditions au sein de conditions complexes sont également pris en charge à l'aide de parenthèses. Il est notamment possible de modifier l'exemple ci-dessus afin de changer 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})

Selon le placement des parenthèses, chacune de ces conditions complexes aboutit à des résultats différents.

Il est en outre possible d'utiliser la fonction is_missing dans des conjonctions OR ou des conjonctions AND :

• Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')
  

Vous pouvez également utiliser la fonction is_missing lorsque l'attribut n'est pas manquant. Dans cet exemple, celle-ci bloquera les paiements si l'attribut :ip_country: n'est PAS manquant et si l'adresse IP provient des États-Unis ou de Porto Rico.

• Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')
  

Test rétroactif des règles

Il convient de garder à l'esprit qu'une règle impose nécessairement un compromis entre prévention de la fraude et blocage de transactions légitimes (faux positifs). Le test rétroactif permet d'identifier les règles qui respectent votre tolérance au risque ou de trouver le juste milieu entre la prévention des litiges et l'augmentation des faux positifs. Pour estimer l'impact d'une règle, vous pouvez soumettre des combinaisons à un test rétroactif à l'aide des données des transactions des six mois précédents via le Dashboard Radar et effectuer des analyses plus ciblées, le but étant d'identifier les résultats de cette règle si elle avait été appliquée récemment.

Test rétroactif dans le Dashboard

Les définitions des paiements frauduleux et réussis varient selon le type de règle que vous testez :

Règle de blocage

• Contestés, ayant reçu une alerte de suspicion de fraude ou remboursés pour raison de fraude : paiements réussis qui ont été contestés ou remboursés pour cause de fraude ou paiements réussis soumis à une vérification qui ont été contestés ou remboursés pour cause de fraude

• Autres paiements réussis : paiements réussis qui n'ont été ni contestés ni remboursés pour cause de fraude ou paiements réussis soumis à une vérification et qui n'ont été ni contestés ni remboursés pour cause de fraude

• Tentatives de paiement ayant échoué : refusés par l'émetteur ou bloqués par Radar

Règle de vérification

• Contestés, ayant reçu une alerte de suspicion de fraude ou remboursés pour raison de fraude : paiements réussis qui ont été contestés ou remboursés pour cause de fraude

• Autres paiements réussis : paiements réussis qui n'ont été ni contestés ni remboursés pour cause de fraude

• Échouée(s) ou déjà placée(s) en vérification : refusés par l'émetteur, bloqués par Radar, ou paiements réussis soumis à une vérification (quel que soit l'état du litige ou du remboursement)

Règle d'autorisation

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

• Contestés, ayant reçu une alerte de suspicion de fraude ou remboursés pour raison de fraude : paiements réussis qui ont été contestés ou remboursés pour cause de fraude ou paiements réussis soumis à une vérification qui ont été contestés ou remboursés pour cause de 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 cause de fraude ou paiements réussis soumis à une vérification et qui n'ont été ni contestés ni remboursés pour cause de fraude

Analyses rétroactives personnalisées

La fonction de tests rétroactifs du Dashboard Radar est axée sur les transactions des six derniers mois et englobe les litiges, les alertes de suspicion de fraude et les paiements remboursés pour cause de fraude.

Il pourrait s'avérer utile de réaliser une analyse plus ciblée si, par exemple, vous risquez d'être placé dans un programme de surveillance de la fraude de Visa (exclusivement axé sur les alertes de suspicion de fraude) ou si vous constatez un pic récent des fraudes provenant des adresses IP d'un pays donné ou d'un type de portefeuille. Pour ce faire, vous pouvez créer une requête SQL dans Sigma ou exporter et analyser les rapports de données de paiement dans le Dashboard. Les tests rétroactifs personnalisés offrent une certaine flexibilité sur la période (au-delà de six mois) et des analyses plus ciblées (par exemple, vous pouvez vous concentrer uniquement sur les litiges ou les alertes de suspicion de fraude). L'exemple de requête ci-dessous effectue des tests rétroactifs sur les alertes de suspicion de fraude de Visa liées aux transactions d'un montant supérieur à 100 $. Elle serait utile dans l'hypothèse où vous constateriez que le nombre de fraudes sur les paiements d'un montant élevé a récemment augmenté et que des transactions présentant un score de risque élevé vous exposent à un programme de surveillance :

À l'aide des champs et des tables disponibles dans Sigma

with base as (
    select
        c.id,
        c.amount,
        c.captured,
        e.created as 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)
)

select 
    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

from base

Un test rétroactif sur les 60 derniers jours à partir de la création de l'alerte de fraude précoce se concentre sur les fraudes les plus récentes, tandis que le test rétroactif sur les 60 à 120 derniers jours de ventes non frauduleuses permet de relever les fraudes à l'état plus mature.

Vecteurs de fraude courants

La plupart des acteurs malveillants suivent le même mode opératoire en matière de fraude. Tout d'abord, ils vérifient la validité des informations de paiement dérobées (les cartes, par exemple). Ensuite, ils exploitent ces informations en achetant des biens physiques ou des services pour un usage personnel ou une revente (marchandises de luxe ou électroniques, services de livraison de repas, etc.), ou encore des services et produits qui facilitent la fraude (autrement dit, des services d'hébergement Web, des services d'envoi de spams, etc.).

Nous présentons ci-dessous les vecteurs de fraude les plus courants et expliquons comment les combattre avec des règles Radar.

Tests

Les tests des cartes bancaires consistent, pour des acteurs malveillants, à vérifier la validité de numéros de cartes volées, manuellement ou via un script. Cette phase de la fraude n'a pas pour but d'obtenir une marchandise physique ou un service, mais de confirmer si les cartes sont actives. Ces paiements prennent généralement la forme de transactions ou d'autorisations modiques. Ces tests sont généralement rapides et s'enchaînent sans délai. Les attributs de regroupement et de rapidité sont les plus utiles pour les bloquer :

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

Les acteurs malveillants tentent généralement de les contourner en créant de fausses adresses e-mail et en utilisant des adresses e-mail distinctes. Les plus chevronnés masqueront les adresses IP et utiliseront même plusieurs appareils pour transmettre des données uniques d'appareil. Face à ces menaces, il est important de bien connaître le comportement d'un client légitime. Des caractéristiques comme le domaine de messagerie et le pays de l'adresse IP, entre autres catégories génériques, peuvent vous aider à identifier les transactions à haut risque. De nombreux clients malveillants font appel à des domaines connus, gérés par des fournisseurs d'adresses e-mail bien établis, comme gmail.com. Il est aussi possible que vous tombiez sur des domaines comme gmail.comms ou gomail.co, qui tentent de masquer l'identité des acteurs malveillants. Le pays de la carte et le pays de l'adresse IP peuvent également servir à segmenter les clients et garantir que les transactions proviennent de régions propres à votre clientèle. Il peut s'avérer judicieux de bloquer ou d'examiner les transactions provenant d'autres régions.

Dernière fonctionnalité permettant de limiter ce type de test : la mise en place de CAPTCHA.

Dans Stripe Checkout, les défis CAPTCHA sont automatiquement affichés lorsque notre algorithme de machine learning détecte une attaque par test des cartes bancaires. Pour limiter ces attaques, Stripe utilise une série de contrôles manuels et automatiques, y compris des limiteurs de débit, des alertes et des vérifications systématiques, et entraîne des modèles pour détecter automatiquement les attaques. Ces modèles affichent des CAPTCHA uniquement lorsqu'une attaque par test des cartes bancaires est en cours. Ainsi, seuls les robots les voient : les utilisateurs légitimes n'y sont presque jamais confrontés. Cette méthode a permis aux entreprises qui utilisent Stripe Checkout de réduire les tests des cartes bancaires de pas moins de 80 %, avec un impact indétectable ou presque sur le taux de conversion.

Il est à noter que vous pouvez également configurer des règles personnalisées telles que « Bloquer un paiement si une adresse IP a déjà fait l'objet de plus de 3 refus », afin de réduire le risque d'attaques par test des cartes bancaires.

Extraction de valeur

Cartes bancaires volées (nouveau comportement)

Dans ce vecteur de fraude, l'acteur malveillant exploite la carte dérobée validée sur son appareil personnel ou sur un dispositif utilisé pour commettre la fraude.

Ce vecteur est généralement employé avec une intention abusive, soit par le biais d'attaques massives programmées, soit à plus petite échelle via des réseaux et des poches de fraude davantage ciblés. Dans tous les cas, le recours à des attributs de règles qui mesurent la nouveauté d'un compte sur Stripe, comme hours_since_email_first_seen_on_stripe, en combinaison avec un score de_risque et d'autres caractéristiques, permet de tenir ces nouveaux titulaires de cartes à distance. En outre, les restrictions de rapidité visant l'adresse IP, les adresses e-mail et les cartes sont de nature à mieux protéger les marchands contre les attaques massives au cours desquelles des acteurs frauduleux tentent de monnayer le plus rapidement possible les informations d'identification dérobées.

Cartes bancaires volées (comportement de masquage)

Dans ce vecteur de fraude, l'acteur malveillant exploite la carte volée validée sur son appareil personnel ou sur un dispositif utilisé pour commettre une fraude, ou il est parvenu à détourner un compte d'abonnement et à obtenir ainsi l'accès aux informations de carte qui sont enregistrées sur le compte.

Pour masquer sa présence, l'acteur frauduleux tentera toutes sortes de stratagèmes :

• Utiliser le même nom que lors de transactions précédemment achevées.

• Utiliser la même adresse de facturation que lors de transactions précédemment achevées.

• Tenter de se faire passer pour le titulaire initial de la carte en passant par un VPN. Le fraudeur peut se trouver dans la même ville, voire parfois dans le même quartier.

• Ne modifier qu'un détail mineur, tel que l'adresse e-mail ou le numéro de téléphone.

• Modifier l'adresse d'expédition par rapport à des transactions antérieures, dans le cas d'un bien physique, en spécifiant un écart de distance potentiellement élevé entre les adresses de facturation et d'expédition. Il s'agit là d'un signal vague.

Le comportement de masquage décrit ci-dessus rend difficile l'identification de la personne qui effectue réellement la transaction : en effet s'agit-il du titulaire initial de la carte ou d'un acteur frauduleux qui a usurpé le compte ? Dans bien des cas, il en résulte que ce type de fraude passe plus longtemps inaperçu, tant pour le marchand que pour le titulaire initial.

La stratégie est identique : l'acteur frauduleux tente d'extraire autant de valeur que possible des informations d'identification dérobées. Les règles qui incluent des fonctionnalités de limitation de rapidité, alliées à un scorede risque ou à des échecs de vérificationdu code CVC ou du code postal, peuvent contribuer à vous prémunir contre ce comportement.

Autres bonnes pratiques

Voyons à présent d'autres bonnes pratiques pour vous aider à optimiser la rédaction de règles dans Radar.

Importance de l'utilisation de Stripe.js

• Incluez stripe.js sur l'ensemble du parcours de paiement pour optimiser le signalement des fraudes.
  
• Pour exploiter tout le potentiel de Radar sans allonger le temps de chargement des pages, chargez stripe.js de manière asynchrone sur les pages hors paiement.
  
• Le plus simple est de placer le code aux côtés des balises de script Google Analytics.
  
• La taille du paquet stripe.js complet est de 29,6 Ko au format gzippé.
  
  • À l'avenir, radar.js pourra être inclus séparément de stripe.js.
    

Conclusion

Avec les règles, vous pouvez considérablement personnaliser votre protection contre la fraude. En mettant en place une logique propre à votre activité de paiement et basée sur les bonnes pratiques énoncées dans ce guide, vous pouvez configurer la protection de Radar en fonction des besoins précis de votre entreprise.

Pour en savoir plus sur Radar for Fraud Teams, cliquez ici.

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

Autres notes

Radar for platforms

Vous êtes une plateforme qui utilise Stripe Connect ? Si la réponse est oui, les règles que vous créez s'appliquent uniquement aux paiements créés sur le compte de la plateforme (dans le langage de Connect, il s'agit des paiements indirects ou au nom d'un compte).
Les paiements créés directement sur le compte connecté sont soumis aux règles de ce compte.

Radar for Terminal

Les paiements Terminal ne sont pas vérifiés par Radar. Autrement dit, si vous utilisez Terminal, vous pouvez rédiger des règles basées sur la fréquence d'une adresse IP sans craindre que vos paiements par TPE soient bloqués.