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, y compris sur les modèles de machine learning de Stripe. 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 explicitement vérifier l'existence d'un attribut ou d'un attribut de métadonnées, n'utilisez pas l'opérateur !=, mais plutôt la fonction is_missing. Saisissez cette fonction avec la clé de l'attribut ou des métadonnées susceptibles d'être manquants. Par exemple, vous pourriez rédiger une règle s'appliquant à tous les paiements pour lesquels vous n'avez pas accès à l'adresse e-mail du client :

• Review if is_missing(:email_domain:)
  

Autre possibilité, rédiger une règle s'appliquant à tous les paiements pour lesquels l'adresse e-mail du client n'est PAS manquante :

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

Règles Radar fréquemment utilisées

Voici une liste non exhaustive de règles Radar fréquemment utilisées, classées par objectif.

Règles qui contribuent à empêcher les tests de cartes bancaires ou la fraude à la carte bancaire

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

Règles susceptibles d'empêcher l'ouverture de plusieurs litiges à partir d'une même carte

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 suspicion de fraude 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

• cards_per_email_address

• cards_per_ip_address

• total_charges_per_ip

Les acteurs malveillants essaieront 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.

Sachez que vous pouvez également créer des règles personnalisées de type « Bloquer si refusé plus de 3 fois depuis une adresse IP donnée » pour réduire les attaques par test de carte.

Monétisation

Cartes bancaires dérobées (comportement inhabituel)

Dans ce vecteur de fraude, l'acteur malveillant utilise la carte dérobée et validée sur son appareil personnel ou sur un appareil servant à commettre une fraude.

Ce vecteur est généralement utilisé soit par des attaques de masse scriptées, soit, à moindre échelle, à l'aide de petites organisations frauduleuses spécialisées. Quoi qu'il en soit, l'utilisation d'attributs de règle qui mesurent le caractère récent d'un compte sur Stripe, comme email_first_time_seen_on_stripe, en association avec risk_score et d'autres caractéristiques, maintiennent ces tout nouveaux titulaires de cartes à distance. Par ailleurs, les restrictions de vitesse imposées aux adresses IP, adresses e-mail et cartes peuvent protéger davantage les marchands contre les attaques répétées par lesquelles des acteurs malveillants cherchent à monétiser des identifiants dérobés le plus vite possible.

Cartes bancaires volées (tentative de camouflage)

Dans ce vecteur de fraude, l'acteur malveillant utilise la carte dérobée et validée sur son appareil personnel ou sur un appareil servant à commettre une fraude ou a piraté un compte d'abonnement et accédé aux informations de carte bancaire enregistrées sur ce compte.

L'acteur malveillant s'efforcera de masquer sa présence en :

• utilisant le même nom que celui utilisé lors des transactions précédentes

• utilisant la même adresse de facturation que celle utilisée lors des transactions précédentes

• utilisant un VPN pour essayer de se faire passer pour le titulaire de carte d'origine. Il est susceptible d'utiliser un VPN le plaçant dans la même ville, voire dans le même quartier

• modifiant uniquement un détail mineur, comme l'adresse e-mail ou le numéro de téléphone

• modifiant l'adresse de livraison utilisée lors des transactions précédentes, dans le cas d'un bien physique, avec potentiellement une distance importante entre les adresses de facturation et de livraison (signal faible)

Cette stratégie de camouflage empêche d'identifier facilement l'auteur de la transaction (le titulaire d'origine de la carte ou un acteur malveillant qui a piraté le compte). Par conséquent, ce type de fraude met souvent plus de temps à être détecté, que ce soit par le marchand ou le titulaire de la carte d'origine.

La stratégie adoptée est la même : l'acteur malveillant essaiera d'extraire autant de valeur que possible des identifiants dérobés. Les règles qui utilisent les fonctionnalités de limite de vitesse, ainsi que l'attribut riskscore, et les règles de vérification cvccheck et zip check, peuvent vous protéger contre ce type de comportement.

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

Vérifications des fraudes

Pour élaborer les règles les plus efficaces possible, vous devez bien comprendre les activités frauduleuses sur votre compte et caractériser les différents types de vecteurs de fraude à l'œuvre. Voici quelques questions à vous poser :

• Y a-t-il des comptes qui, une fois ouverts, effectuent immédiatement des achats frauduleux à l'aide de nouvelles adresses e-mail et de nouveaux noms de titulaires de cartes ?

• Des acteurs malveillants ont-ils accès à des comptes anciens et effectuent-ils des achats d'un montant anormalement élevé ?

• La fraude a-t-elle tendance à utiliser des réseaux de cartes ou des pays d'émission de cartes donnés ?

• Constatez-vous des fraudes à grande vitesse, autrement dit plusieurs tentatives effectuées à l'aide de la même carte, adresse e-mail ou adresse IP dans un bref laps de temps ?

Des règles utilisant authorized_charges_per_card_number_hourly ou authorized_charges_per_ip_address_hourly pourraient être en mesure de traiter la fraude à grande vitesse à l'œuvre dans la capture d'écran ci-dessus.

Autres bonnes pratiques

Voici quelques bonnes pratiques supplémentaires qui vous aideront à optimiser la rédaction de vos règles 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.