Radar for Fraud Teams : Notions de base sur les règles

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.

  1. Introduction
  2. Limportance de lordre et de la hiérarchie des règles
  3. Tableau récapitulatif de la syntaxe des règles
  4. Règles Radar fréquemment utilisées
    1. Règles qui contribuent à empêcher les tests de cartes bancaires ou la fraude à la carte bancaire
    2. Règles qui contribuent à prévenir la fraude liée à des unités de gestion des stocks à risque
    3. Règles qui empêchent dabuser des périodes dessai à laide de cartes bancaires prépayées
    4. Règles susceptibles dempêcher louverture de plusieurs litiges à partir dune même carte
  5. Trois types dattributs pour créer des règles
    1. Type 1
    2. Type 2
    3. Attributs basés sur la fréquence
    4. Attributs basés sur les informations de la carte
    5. Attributs basés sur les informations du paiement
    6. Attributs basés sur les informations du client
    7. Type 3
  6. Utilisation de listes préexistantes dans vos règles (par ex. listes dautorisation, listes de blocage, etc.)
  7. Rédiger des règles complexes aux conditions multiples
  8. Test rétroactif des règles
    1. Test rétroactif dans le Dashboard
    2. Analyses rétroactives personnalisées
  9. Vecteurs de fraude courants
    1. Tests
    2. Monétisation
  10. Analyser vos fraudes pour orienter la création de règles
    1. Vérifications des fraudes
  11. Autres bonnes pratiques
    1. Importance de lutilisation de Stripe.js
  12. Conclusion
    1. Autres notes

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.

Opérateur
Chaîne
Méta-données
Pays
Numérique
Description
Exemple
=
Égal à

:card_country: = 'us'

!=
Différent de

:card_funding: != 'prepaid'

<
Inférieur à

:amount_in_gbp: < 10.00

>
Supérieur à

:amount_in_usd: > 500.00

<=
Inférieur ou égal à

:amount_in_eur:<= 100.00

>=
Supérieur ou égal à

:amount_in_cad: >= 10.00

IN
Est dans le groupe

:card_country: IN ('gb', 'ie')

INCLUDES
Contient la chaîne

:ip_address: INCLUDES '192.168'

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

Block if :total_charges_per_ip​_address_hourly: > 1

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.

Block if :blocked_charges_per_ip​_address_hourly: > 1

Pour une prévention renforcée contre le test de cartes bancaires, utilisez cette règle en même temps que :total_charges_per_ip_address_hourly:

Block if :total_charges_per​_card_number_hourly: > 1

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.

Block if :blocked_charges_per_card​_number_hourly: > 1

Pour une prévention renforcée contre les fraudes à la carte bancaire, utilisez cette règle en même temps que :total_charges_per_card_number_hourly:

Block if :address_zip_check: != 'pass'

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.

Block if :cvc_check:: != 'pass'

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.

Review if ::SKU Category:: IN ('baby formula', 'personal hygiene')

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.

Review if :charge_description: = 'Trial class'

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

Block if :card_funding: = 'prepaid' OR :card_funding: = 'unknown'

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.

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

Block if :prior_fraud_disputes_with​_card_count_all_time: > 0

Cette règle bloquera les transactions effectuées avec une carte bancaire ayant déjà présenté un litige.

Block if :prior_fraud_disputes_with​_card_yearly: > 0

Cette règle bloquera les transactions effectuées avec une carte bancaire ayant présenté un litige au cours de l'année précédente.

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

:address_line1_check:

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.

:address_zip_check:

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.

:cvc_check​:

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

pass

Les données fournies sont correctes.

fail

Les données fournies sont incorrectes.

unavailable

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.

unchecked

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.

not_provided

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.

  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.

Attribut
Description

:authorized_charges_per​_card_number_all_time:

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)

:authorized_charges_per​_card_number_weekly:

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)

:authorized_charges_per​_card_number_daily:

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)

:authorized_charges_per​_card_number_hourly:

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)

:authorized_charges_per​_email_all_time:

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)

:authorized_charges_per​_email_weekly:

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)

:authorized_charges_per​_email_daily:

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)

:authorized_charges_per​_email_hourly:

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)

:authorized_charges_per​_ip_address_all_time:

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)

:authorized_charges_per​_ip_address_weekly:

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)

:authorized_charges_per​_ip_address_daily:

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)

:authorized_charges_per​_ip_address_hourly:

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)

:authorized_charges_per​_customer_daily:

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

:authorized_charges_per​_customer_hourly:

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

:blocked_charges_per​_card_number_daily:

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

:blocked_charges_per​_card_number_hourly:

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

:blocked_charges_per​_customer_daily:

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

:blocked_charges_per​_customer_hourly:

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

:blocked_charges_per​_ip_address_daily:

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

:blocked_charges_per​_ip_address_hourly:

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

:total_charges_per​_card_number_daily:

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

:total_charges_per​_card_number_hourly:

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

:total_charges_per​_customer_daily:

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

:total_charges_per​_customer_hourly:

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

:total_charges_per​_ip_address_daily:

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

:total_charges_per​_ip_address_hourly:

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

:declined_charges_per​_card_number_daily:

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

:declined_charges_per​_card_number_hourly:

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

:declined_charges_per​_customer_daily:

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

:declined_charges_per​_customer_hourly:

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

:declined_charges_per​_ip_address_daily:

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

:declined_charges_per​_ip_address_hourly:

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

:declined_charges_per​_email_all_time:

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)

:declined_charges_per​_email_weekly:

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)

:declined_charges_per​_email_daily:

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)

:declined_charges_per​_email_hourly:

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)

:dispute_count_on_ip_all_time:

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)

:dispute_count_on_ip_weekly:

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)

:dispute_count_on_ip_daily:

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)

:dispute_count_on_ip_hourly:

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)

:email_count_for​_card_all_time:

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)

:email_count_for​_card_weekly:

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)

:email_count_for​_card_daily:

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)

:email_count_for​_card_hourly:

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)

:email_count_for​_ip_all_time:

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)

:email_count_for​_ip_weekly:

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)

:email_count_for​_ip_daily:

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)

:email_count_for​_ip_hourly:

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)

:name_count_for​_card_all_time:

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)

:name_count_for​_card_weekly:

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)

:name_count_for​_card_daily:

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)

:name_count_for​_card_hourly:

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)

:total_charges_per​_card_number_all_time:

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)

:total_charges_per​_card_number_weekly:

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)

:total_charges_per​_card_number_daily:

Nombre total de paiements pour cette carte bancaire sur votre compte au cours du jour précédent. (Remarque : ne peut dépasser 25)

:total_charges_per​_card_number_hourly:

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)

:total_charges_per​_email_all_time:

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)

:total_charges_per​_email_weekly:

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)

:total_charges_per​_email_daily:

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)

:total_charges_per​_email_hourly:

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)

:total_charges_per​_ip_address_all_time:

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)

:total_charges_per​_ip_address_weekly:

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)

:total_charges_per​_ip_address_daily:

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)

:total_charges_per​_ip_address_hourly:

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

:card_bin:

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').

:card_brand:

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

:card_country:

Code à deux lettres correspondant au pays d'émission de la carte bancaire (par exemple US). Vous trouverez la liste des codes pays sur cette page. Pour indiquer plusieurs pays, utilisez l'opérateur IN : IN ('GB', 'DE', 'AE')

:card_fingerprint:

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.

:card_funding:

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

:card_3d_secure_support:

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

:amount_in_xyz:

Montant du paiement, converti dans la devise exprimée au format xyz (par exemple amount_in_usd). Indiquez l'une des devises prises en charge suivantes et Stripe calculera automatiquement le montant converti à utiliser : aud, brl, cad, chf, dkk, eur, gbp, hkd, inr, jpy, mxn, nok, nzd, ron, sek, sgd, ou usd. Ne précisez pas de sous-unités (par exemple, pas de cents pour une valeur en dollar comme celle-ci, :amount_in_usd: > 250)

:average_usd_amount​_attempted_on_card_all_time:

Montant moyen (en USD) des tentatives de transaction pour la carte bancaire sur votre compte. Prend en compte les paiements à partir de 2020.

:average_usd_amount​_successful_on_card_all_time:

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.

:risk_level:

Niveau de risque d'un paiement donné, déterminé par Stripe. Les valeurs prises en charge sont : ‘normal’, ‘elevated’, ‘highest’ et ‘not_assessed’.

:risk_score:

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

:charge_description:

Description fournie avec le paiement (par ex. ‘Class trial’).

:is_recurring:

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 :is_recurring: si c'est le cas et NOT :is_recurring: si ce n'est pas le cas. Vous ne pouvez pas utiliser !=.)

:is_off_session:

Indique quand un paiement Stripe Billing n'est pas déclenché par une action directe de l'utilisateur ou que l'indicateur off_session est défini lors de la confirmation du PaymentIntent. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser :is_off_session: si c'est le cas et NOT :is_off_session: si ce n'est pas le cas. Vous ne pouvez pas utiliser !=.)

:digital_wallet:

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

:destination:

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.

:is_checkout:

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 :is_checkout: si c'est le cas et NOT :is_checkout: si ce n'est pas le cas. Vous ne pouvez pas utiliser !=.)

:is_3d_secure​_authenticated:

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 :is_3d_secure_authenticated: si c'est le cas et NOT :is_3d_secure_authenticated: si ce n'est pas le cas. Vous ne pouvez pas utiliser !=.)

:is_3d_secure:

Indique si le paiement utilise une source 3D Secure source. (Il s'agit d'une valeur booléenne ; vous devez donc utiliser :is_3d_secure: si c'est le cas et NOT :is_3d_secure si ce n'est pas le cas. Vous ne pouvez pas utiliser !=).

:has_liability_shift:

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 :has_liability_shift: si c'est le cas et NOT :has_liability_shift si ce n'est pas le cas. Vous ne pouvez pas utiliser !=.)

:prior_fraud_disputes​_with_card_count_all_time:

Nombre total de paiements contestés de manière frauduleuse sur votre compte associés à la carte utilisée pour effectuer le paiement actuel, sur toute la durée. Les demandes et récupérations d'informations sont incluses.

:prior_fraud_disputes​_with_card_count_yearly:

Nombre total de paiements contestés de manière frauduleuse sur votre compte associés à la carte utilisée pour effectuer le paiement actuel, sur l'année précédente. Les demandes et récupérations d'informations sont incluses.

:seconds_since_card​_first_seen:

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.

:seconds_since_first_successful​_auth_on_card:

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.

:total_usd_amount_failed​_on_card_all_time:

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.

:total_usd_amount_successful​_on_card_all_time:

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

:ip_country:

Code à deux lettres correspondant au pays de l'adresse IP d'où provient le paiement (par exemple GB). Vous trouverez la liste des codes pays sur cette page. Pour indiquer plusieurs pays, utilisez l'opérateur IN : IN ('GB', 'DE', 'AE')

:ip_address:

Indique l'adresse IP d'où provient le paiement (par exemple '192.168.0.1' pour une seule adresse IP, ou INCLUDES '192.168' pour inclure toutes les adresses IP commençant par ces six chiffres si vous souhaitez effectuer une recherche plus large).

:is_anonymous_ip:

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 :is_anonymous_ip: si c'est le cas et NOT :is_anonymous_ip: si ce n'est pas le cas. Vous ne pouvez pas utiliser !=).

:is_my_login_ip:

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 :is_my_login_ip: si c'est le cas et NOT :is_my_login_ip: si ce n'est pas le cas. Vous ne pouvez pas utiliser !=.)

:email:

Adresse e-mail fournie avec le paiement (par exemple 'user@example.com').

:email_domain:

Le domaine de l'adresse e-mail fournie avec le paiement (par exemple 'example.com').

:is_disposable_email:

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 :is_disposable_email: si c'est le cas et NOT :is_disposable_email: si ce n'est pas le cas. Vous ne pouvez pas utiliser !=.)

:billing_address:

Adresse de facturation complète du titulaire de la carte (par exemple '510 Townsend, San Francisco, CA 94110').

:billing_address_line1:

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').

:billing_address_line2:

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').

:billing_address_postal_code:

Code postal de l'adresse de facturation du titulaire de la carte (par exemple '94110').

:billing_address_city:

Ville de l'adresse de facturation du titulaire de la carte (par exemple 'San Francisco').

:billing_address_state:

État de l'adresse de facturation du titulaire de la carte (par exemple 'CA').

:billing_address_country:

Code à deux lettres correspondant au pays de l'adresse de facturation du titulaire de la carte (par exemple US). Vous trouverez la liste des codes pays sur cette page. Pour indiquer plusieurs pays, utilisez l'opérateur IN : IN ('US', 'DE', 'AE').

:seconds_since​_email_first_seen:

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.

:seconds_since​_email_first_seen_on_stripe:

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.

:shipping_address:

Adresse de livraison complète (par exemple '510 Townsend, San Francisco, CA 94110').

:shipping_address_line1:

La première ligne de l'adresse de livraison (généralement un numéro et un nom de rue, par exemple '510 Townsend').

:shipping_address_line2:

Deuxième ligne de l'adresse de livraison (généralement un numéro d'appartement, par exemple 'Apt 5b').

:shipping_address_postal_code:

Code postal de l'adresse de livraison (par exemple '94110').

:shipping_address_city:

Ville de l'adresse de livraison (par exemple 'San Francisco').

:shipping_address_state:

État de l'adresse de livraison (par exemple 'CA').

:shipping_address_country:

Code à deux lettres correspondant au pays de l'adresse de livraison (par exemple US). Vous trouverez la liste des codes pays sur cette page. Pour indiquer plusieurs pays, utilisez l'opérateur IN : IN ('US', 'DE', 'AE').

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

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 fraude précoce 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 fraude précoce 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 fraude précoce 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 fraude précoces 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 fraude précoces) 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 fraude précoces). L'exemple de requête ci-dessous effectue des tests rétroactifs sur les alertes de fraude précoces 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

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

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 %).

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.

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

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

Envie de vous lancer? Contactez-nous ou créez un compte.

Créez un compte et commencez à accepter des paiements rapidement, sans avoir à signer de contrat ni à fournir vos coordonnées bancaires. Nous proposons également des solutions personnalisées pour les entreprises. N'hésitez pas à nous contacter à ce sujet!