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 :
- 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.
- 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.
- 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.
- 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.
Opérateur
|
Chaîne
|
Méta-données
|
Pays
|
Numérique
|
Description
|
Exemple
|
---|---|---|---|---|---|---|
=
|
Égal à |
|
||||
!=
|
Différent de |
|
||||
<
|
Inférieur à |
|
||||
>
|
Supérieur à |
|
||||
<=
|
Inférieur ou égal à |
|
||||
>=
|
Supérieur ou égal à |
|
||||
IN
|
Est dans le groupe |
|
||||
INCLUDES
|
Contient la chaîne |
|
||||
LIKE
|
Correspond au modèle fourni |
|
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.
![](https://images.stripeassets.com/fzn2n1nzq965/2E0RvOCw4IyVcmD7Pqcdv0/fff500c887847f47cc2287c196dbc182/Screenshot_2024-04-18_at_3.11.00_PM.png?w=1611&q=80)
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
|
Cette règle permet de lutter contre le test des cartes bancaires. Si une adresse IP est autorisée plus d'une fois sur votre compte, les paiements seront bloqués. |
---|---|
|
Pour une prévention renforcée contre le test de cartes bancaires, utilisez cette règle en même temps que |
|
Cette règle permet de lutter contre les fraudes à la carte bancaire. Si un numéro de carte bancaire a été autorisé plus d'une fois sur votre compte au cours de la dernière heure, les paiements seront bloqués. |
|
Pour une prévention renforcée contre les fraudes à la carte bancaire, utilisez cette règle en même temps que |
|
Pour utiliser cette règle, veillez à recueillir le code postal dans votre formulaire de paiement. Si le code postal fourni ne correspond pas à celui qui figure dans les registres de l'émetteur de la carte, les paiements seront bloqués. |
|
Pour utiliser cette règle, veillez à recueillir le CVC dans votre formulaire de paiement. Si le CVC (ou CVV) ne correspond pas à celui qui figure dans les registres de l'émetteur de la carte, les paiements seront bloqués. |
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.
|
Supposons que vous gérez un supermarché et que vous nous envoyez des métadonnées avec la catégorie d'unité de gestion des stocks. Vous avez remarqué que les commandes comprenant des articles correspondant à la catégorie d'unité de gestion des stocks 'personal hygiene' ou 'baby formula' sont associées à des risques plus élevés. Cette règle enverra les commandes comportant ces articles dans la liste de vérification manuelle de votre Dashboard Stripe afin que vous puissiez les contrôler. Veuillez noter que le traitement des paiements et la facturation des clients seront tout de même effectués, sauf si vous annulez la commande manuellement. |
---|---|
|
Supposons que vous commercialisez deux produits ('Trial class' et '10 class package') et que vous envoyez à Stripe le nom du produit dans la description du paiement. Cette règle enverra les commandes dont la description correspond exactement à 'Trial class' dans la liste de vérification manuelle de votre Dashboard Stripe afin que vous puissiez les contrôler. Veuillez noter que le traitement des paiements et la facturation des clients seront tout de même effectués, sauf si vous annulez la commande manuellement. |
Règles qui empêchent d'abuser des périodes d'essai à l'aide de cartes bancaires prépayées
|
Supposons que vous êtes un commerçant en ligne qui propose des essais à domicile et que vous avez remarqué une augmentation soudaine d'utilisateurs frauduleux qui utilisent des cartes prépayées que vous ne pouvez pas débiter par la suite. Cette règle bloquera toutes les commandes qui ne sont pas réglées avec une carte de débit ou de crédit. |
---|
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 ?
![](https://images.stripeassets.com/fzn2n1nzq965/1z2Ibaq51UGdJelWS8WtYq/6e7b28e6d2f4a12ac7df62e9139cce49/Related_payments.png?w=1976&q=80)
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:.
Attributs
|
Description
|
---|---|
|
Vérification effectuée par l'émetteur de la carte pour comparer la première ligne de l'adresse de facturation fournie (généralement un numéro et un nom de rue) avec les informations dont il dispose sur le titulaire de la carte. |
|
Vérification effectuée par l'émetteur de la carte pour comparer le code postal fourni avec les informations dont il dispose sur le titulaire de la carte. |
|
Vérification effectuée par l'émetteur de la carte pour comparer le CVC (ou CVV) fourni avec les informations dont il dispose sur le titulaire de la carte. |
Valeurs possibles
|
Description
|
---|---|
|
Les données fournies sont correctes. |
|
Les données fournies sont incorrectes. |
|
L'émetteur de la carte du client ne vérifiera pas les données fournies. Les émetteurs de carte ou les pays ne prennent pas tous en charge la vérification d'adresse. |
|
Les données ont été fournies, mais n'ont pas encore été vérifiées. L'émetteur de la carte du client vérifiera à terme les données fournies. |
|
Les données n'ont pas été fournies à Stripe. |
Les valeurs doivent respecter les majuscules et minuscules. |
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.
- Autorisation : basé sur les autorisations accordées par l'émetteur
- Paiement : basé sur les paiements
- Refus : basé sur les refus par l'émetteur
- 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 :
- 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
- 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.
Attribut
|
Description
|
---|---|
|
Nombre de paiements ayant donné lieu à une autorisation pour cette carte bancaire sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette carte sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette carte sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette carte sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette adresse e-mail sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette adresse e-mail sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette adresse e-mail sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette adresse e-mail sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette adresse IP sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette adresse IP sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette adresse IP sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre de paiements ayant donné lieu à une autorisation pour cette adresse IP sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Nombre d'autorisations associées à un client sur votre compte dans les dernières 24 heures. (Cette valeur n'inclut pas le paiement en cours d'évaluation.) |
|
Nombre d'autorisations associés à un client sur votre compte au cours de la dernière heure. (Cette valeur n'inclut pas le paiement en cours d'évaluation.) |
|
Nombre de fois qu'un numéro de carte a été bloqué sur votre compte par les modèles de machine learning de Stripe dans les dernières 24 heures. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'un numéro de carte a été bloqué sur votre compte par les modèles de machine learning de Stripe au cours de la dernière heure. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'un client a été bloqué sur votre compte par les modèles de machine learning de Stripe dans les dernières 24 heures. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'un client a été bloqué sur votre compte par les modèles de machine learning de Stripe au cours de la dernière heure. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'une adresse IP a été bloquée sur votre compte par les modèles de machine learning de Stripe dans les dernières 24 heures. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'une adresse IP a été bloquée sur votre compte par les modèles de machine learning de Stripe au cours de la dernière heure. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de tentatives de paiement associées à une carte bancaire sur votre compte dans les dernières 24 heures. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de tentatives de paiement associées à une carte bancaire sur votre compte dans l'heure précédente. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de tentatives de paiement effectuées par un client sur votre compte dans les dernières 24 heures. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de tentatives de paiement effectuées par un client sur votre compte dans l'heure précédente. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de tentatives de paiement provenant d'une adresse IP sur votre compte dans les dernières 24 heures. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de tentatives de paiement provenant d'une adresse IP sur votre compte dans l'heure précédente. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'un numéro de carte a été refusé par l'émetteur de la carte sur votre compte dans les dernières 24 heures. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'un numéro de carte a été refusé par l'émetteur de la carte sur votre compte dans l'heure précédente. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'un client a été refusé par l'émetteur de la carte sur votre compte dans les dernières 24 heures. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'un client a été refusé par l'émetteur de la carte sur votre compte dans l'heure précédente. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'une adresse IP a été refusée par l'émetteur de la carte sur votre compte dans les dernières 24 heures. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de fois qu'une adresse IP a été refusée par l'émetteur de la carte sur votre compte dans l'heure précédente. Cette valeur n'inclut pas le paiement en cours d'évaluation (par exemple 4). |
|
Nombre de refus de paiement associés à cette adresse e-mail sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre de refus de paiement associés à cette adresse e-mail sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de refus de paiement associés à cette adresse e-mail sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre de refus de paiement associés à cette adresse e-mail sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de litiges pour fraude associés à des transactions sur votre compte à partir de cette adresse IP. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre de litiges pour fraude associés à des paiements provenant de cette adresse IP sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de litiges pour fraude associés à des paiements provenant de cette adresse IP sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre de litiges pour fraude associés à des paiements provenant de cette adresse IP sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Nombre d'adresses e-mail associées à cette carte bancaire dans les transactions effectuées sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre d'adresses e-mail associées à cette carte bancaire dans les transactions effectuées sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre d'adresses e-mail associées à cette carte bancaire dans les transactions effectuées sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre d'adresses e-mail associées à cette carte bancaire dans les transactions effectuées sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Nombre d'adresses e-mail associées à cette adresse IP dans les transactions effectuées sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre d'adresses e-mail associées à cette adresse IP dans les transactions effectuées sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre d'adresses e-mail associées à cette adresse IP dans les transactions effectuées sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre d'adresses e-mail associées à cette adresse IP dans les transactions effectuées sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de noms associés à cette carte bancaire dans les transactions effectuées sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre de noms associés à cette carte bancaire dans les transactions effectuées sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre de noms associés à cette carte bancaire dans les transactions effectuées sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre de noms associés à cette carte bancaire dans les transactions effectuées sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements pour cette carte bancaire sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements pour cette carte bancaire sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements pour cette carte bancaire sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements pour cette carte bancaire sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Le nombre total de paiements provenant de cette adresse e-mail sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements provenant de cette adresse e-mail sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements provenant de cette adresse e-mail sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements provenant de cette adresse e-mail sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements provenant de cette adresse IP sur votre compte. Prend en compte les paiements à partir de 2020. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements provenant de cette adresse IP sur votre compte au cours de la semaine précédente. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements provenant de cette adresse IP sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25) |
|
Nombre total de paiements provenant de cette adresse IP sur votre compte au cours de l'heure précédente. (Remarque : ne peut dépasser 25) |
Attributs basés sur les informations de la carte
Attribut
|
Description
|
---|---|
|
Numéro d'identification bancaire (BIN) de la carte bancaire utilisée pour effectuer le paiement. Il s'agit des six premiers chiffres du numéro de carte (par exemple '424242'). |
|
Marque de la carte utilisée pour effectuer le paiement. Les valeurs prises en charge sont : 'amex' (American Express), 'visa' (Visa), 'mc' (Mastercard), 'dscvr' (Discover), 'diners' (Diners Club), 'interac' (Interac), 'jcb' (JCB), et 'cup' (UnionPay). |
|
Code à deux lettres correspondant au pays d'émission de la carte bancaire (par exemple |
|
Empreinte d'identification de la carte bancaire utilisée pour effectuer le paiement. Chaque carte bancaire dispose d'une empreinte d'identification unique. Pour trouver cette information, accédez aux Paiements et examinez un paiement dans la section Moyen de paiement (par exemple 'VfE3rx3VlaQhS8Lp') en veillant à respecter les majuscules et minuscules. |
|
Indique s'il s'agit d'une carte prépayée, de débit ou de crédit. Les valeurs prises en charge sont : 'credit', 'debit', 'prepaid', 'unknown'. |
|
Le niveau de prise en charge de 3D Secure concernant la carte utilisée pour le paiement. Les valeurs prises en charge sont : 'required', 'recommended', 'optional', et 'not_supported'. |
Attributs basés sur les informations du paiement
Attribut
|
Description
|
---|---|
|
Montant du paiement, converti dans la devise exprimée au format xyz (par exemple |
|
Montant moyen (en USD) des tentatives de transaction pour la carte bancaire sur votre compte. Prend en compte les paiements à partir de 2020. |
|
Montant moyen (en USD) des transactions ayant donné lieu à une autorisation pour la carte bancaire sur votre compte. Prend en compte les paiements à partir de 2020. |
|
Niveau de risque d'un paiement donné, déterminé par Stripe. Les valeurs prises en charge sont : ‘normal’, ‘elevated’, ‘highest’ et ‘not_assessed’. |
|
Score de risque d'un paiement donné, déterminé par Stripe (par exemple > 50). Les valeurs se situent entre 0 (le moins risqué) et 100 (le plus risqué). Un score de risque supérieur ou égal à 65 correspond à un niveau de risque ‘elevated’, tandis qu'un score de risque supérieur ou égal à 75 correspond à un niveau de risque ‘highest’. |
|
Description fournie avec le paiement (par ex. ‘Class trial’). |
|
Indique s'il s'agit d'un paiement récurrent, par exemple dans le cas d'abonnements. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser |
|
Indique quand un paiement Stripe Billing n'est pas déclenché par une action directe de l'utilisateur ou que l'indicateur |
|
Type de portefeuille électronique utilisé pour stocker les informations de paiement. Les valeurs prises en charge sont : ‘android_pay’, ‘amex_express_checkout’, ‘apple_pay’, ‘masterpass’, ‘samsung_pay’, ‘unknown’, ’visa_checkout’, ‘none’. |
|
Pour les utilisateurs de Connect qui créent des paiements indirects, le compte de destination au nom duquel le paiement est effectué (par exemple ‘acct_19KCB9AlaaEw6AgR’). Veillez à respecter les majuscules et minuscules. |
|
Indique si le paiement est traité via Checkout. Cet attribut s'applique uniquement aux paiements traités par la nouvelle version de Checkout et ne capture pas les paiements traités sous l'ancienne version de Checkout. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser |
|
Indique si le paiement fait suite à une vérification 3D Secure avec authentification menée à son terme. L'authentification peut être basée sur le risque ou sur un défi. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser |
|
Indique si le paiement utilise une source 3D Secure source. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser |
|
Vrai si la responsabilité en matière de fraude a été transférée pour ce paiement. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser |
|
Nombre de secondes écoulées depuis que la carte bancaire utilisée pour le paiement a été utilisée pour la première fois sur votre compte. Prend en compte les paiements à partir de 2020. |
|
Nombre de secondes écoulées depuis la première authentification réussie de la carte associée au paiement sur votre compte. Prend en compte les paiements à partir de 2020. |
|
Montant total (en USD) des transactions réalisées avec cette carte bancaire ayant échoué (bloquées ou refusées) sur votre compte. Prend en compte les paiements à partir de 2020. |
|
Montant total (en USD) des transactions ayant donné lieu à une autorisation pour la carte bancaire sur votre compte. Prend en compte les paiements à partir de 2020. |
Attributs basés sur les informations du client
Attribut
|
Description
|
---|---|
|
Code à deux lettres correspondant au pays de l'adresse IP d'où provient le paiement (par exemple |
|
Indique l'adresse IP d'où provient le paiement (par exemple '192.168.0.1' pour une seule adresse IP, ou |
|
Indique si l'adresse IP d'où provient le paiement est un nœud de sortie proxy ou Tor connu. Ces informations sont mises à jour quotidiennement. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser |
|
Indique si l'adresse IP d'où provient le paiement a déjà été utilisée pour une connexion à votre compte Stripe. Cet attribut peut être utilisé pour signifier qu'il s'agit de votre adresse IP. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser |
|
Adresse e-mail fournie avec le paiement (par exemple 'user@example.com'). |
|
Le domaine de l'adresse e-mail fournie avec le paiement (par exemple 'example.com'). |
|
Indique si l'adresse e-mail fournie avec le paiement provient d'un fournisseur d'adresses e-mail à usage unique connu. Pour fournir cet attribut, Stripe conserve une liste de domaines correspondant à des adresses e-mail à usage unique. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser |
|
Adresse de facturation complète du titulaire de la carte (par exemple '510 Townsend, San Francisco, CA 94110'). |
|
Première ligne de l'adresse de facturation du titulaire de la carte (généralement un numéro et un nom de rue, par exemple '510 Townsend'). |
|
Deuxième ligne de l'adresse de facturation du titulaire de la carte (généralement un numéro d'appartement, par exemple 'Apt 5b'). |
|
Code postal de l'adresse de facturation du titulaire de la carte (par exemple '94110'). |
|
Ville de l'adresse de facturation du titulaire de la carte (par exemple 'San Francisco'). |
|
État de l'adresse de facturation du titulaire de la carte (par exemple 'CA'). |
|
Code à deux lettres correspondant au pays de l'adresse de facturation du titulaire de la carte (par exemple |
|
Nombre de secondes écoulées depuis que l'adresse e-mail fournie avec le paiement a été affichée pour la première fois sur votre compte. Prend en compte les paiements à partir de 2020. |
|
Nombre de secondes écoulées depuis que l'adresse e-mail fournie avec le paiement a été affichée pour la première fois sur Stripe. Prend en compte les paiements à partir de 2020. |
|
Adresse de livraison complète (par exemple '510 Townsend, San Francisco, CA 94110'). |
|
La première ligne de l'adresse de livraison (généralement un numéro et un nom de rue, par exemple '510 Townsend'). |
|
Deuxième ligne de l'adresse de livraison (généralement un numéro d'appartement, par exemple 'Apt 5b'). |
|
Code postal de l'adresse de livraison (par exemple '94110'). |
|
Ville de l'adresse de livraison (par exemple 'San Francisco'). |
|
État de l'adresse de livraison (par exemple 'CA'). |
|
Code à deux lettres correspondant au pays de l'adresse de livraison (par exemple |
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 :
Nom des métadonnées
|
Valeur des métadonnées
|
---|---|
Customer age
|
22 |
Item ID
|
5A381D |
Category ID
|
groceries |
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 :
Nom des métadonnées
|
Valeur des métadonnées
|
---|---|
Trusted
|
true |
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 :
Nom des métadonnées
|
Valeur des métadonnées
|
---|---|
Category
|
new |
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.
Remarque : les marchands établis dans l'UE doivent connaître le règlement sur le blocage géographique et ses interdictions relatives au blocage des paiements pour les clients des pays membres de l'UE. En savoir plus sur ce règlement.
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
![](https://images.stripeassets.com/fzn2n1nzq965/3DXNvXULUnqWFbn5Ir55NF/1ebb15a9eef5ba49e919b6c066783af9/Test_results__1_.png?w=2664&q=80)
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.
L'ajout d'un CAPTCHA géré par Stripe pour les utilisateurs de Checkout a réduit les tests de cartes de 80 %, avec un impact sur les taux d'autorisation inférieur à 2 points de base (0,02 %).
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.
Tunnel de paiement
|
|
---|---|
Inclure une référence explicite à vos Conditions d'utilisation du service dans le tunnel de paiement
|
En cas de contestation de paiement, fournissez une capture d'écran clairement identifiée de vos Conditions d'utilisation du service telles qu'elles apparaissent dans le tunnel de paiement, et expliquez en quoi elles sont pertinentes. Cela augmentera vos chances de remporter le litige. |
Valider le CVS et le code postal
|
Permet à l'émetteur de valider le titulaire de la carte. Peut augmenter vos chances de remporter un litige et permet souvent d'améliorer le taux d'autorisations. Il peut être judicieux de bloquer les paiements dont la vérification échoue. |
Recueillir autant d'informations que possible sur le client
|
La collecte de ces informations aide les émetteurs à évaluer votre dossier en cas de contestation de paiement, ce qui augmente vos chances de remporter le litige. Cette action démontre que vous avez fait preuve de la vigilance requise. |
Il est conseillé de recueillir les informations suivantes : nom du client, adresse e-mail, CVC et code postal, adresse de facturation complète, adresse IP, informations sur l'appareil utilisé, etc.
|
L'implémentation de Stripe.js permet à Radar de récupérer des informations sur l'adresse IP, l'appareil et le comportement du client afin d'améliorer la détection de la fraude. |
Interactions client
|
|
---|---|
Cartes de la liste de blocage présentant des contestations de paiement pour fraude
|
Si un client conteste un paiement pour fraude, ses prochains paiements risquent d'être également contestés. |
Rembourser les paiements suspects ou frauduleux
|
70 à 85 % des transactions figurant dans les rapports de fraude TC40 donnent lieu à des litiges, et seuls les remboursements en intégralité peuvent prévenir les litiges. |
Adopter une description claire pour le libellé de relevé bancaire
|
Permet de réduire le nombre de litiges associés aux transactions non reconnues. |
Importance de l'utilisation de Stripe.js
![](https://images.stripeassets.com/fzn2n1nzq965/74X36lTlA80oZNxgFVptEk/ce4de3423675886e24d346dcefd1c451/Screen_Shot_2022-04-05_at_11.57.23_AM.png?w=2078&q=80)
- 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.
- À 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.