Règles de protection contre la fraude
Utilisez les règles de prévention de la fraude pour protéger votre entreprise.
Les règles de prévention de la fraude vous permettent d’agir chaque fois qu’un paiement correspond à certains critères.
Stripe Radar fournit des règles intégrées visant à aider tous les utilisateurs de Stripe à détecter et à se prémunir contre les risques de fraude.
Les utilisateurs de Radar for Fraud Teams peuvent utiliser le Dashboard pour créer des règles personnalisées basées sur la logique métier unique de votre entreprise. Par exemple, vous pouvez :
- Demander 3D Secure (3DS) pour tous les paiements qui le prennent en charge et sont effectués par un nouveau client
- Autoriser tous les paiements provenant de l’adresse IP de votre centre d’appels
- Bloquer les paiements réalisés depuis un emplacement ou une carte émise en dehors de votre pays
- Vérifier tous les paiements de plus de 1 000 USD réalisés à l’aide d’une carte bancaire prépayée
Mise en garde
Les marchands de l’UE peuvent être concernés par le règlement sur le géoblocage et les interdictions de bloquer les paiements de clients établis dans les États membres de l’UE.
Règles intégrées
Les règles suivantes sont disponibles par défaut pour tous les utilisateurs de Radar.
Vérification des risques effectuée par le machine learning
Stripe Radar et Stripe Radar for Fraud Teams fournissent l’ensemble de règles par défaut ci-dessous, basées sur les recommandations de nos modèles de machine learning :
Block if :risk_level: = 'highest'
Cette règle bloque les paiements présentant un risque élevé de fraude et empêche leur traitement. Elle est activée par défaut pour les utilisateurs de Radar ou de Radar for Fraud Teams.
Review if :risk_level: = 'elevated'
Le comportement par défaut de Stripe Radar for Fraud Teams consiste à placer sous examen les paiements soupçonnés de présenter un risque élevé de fraude.
Vérifications traditionnelles de carte bancaire
Un paiement peut aboutir même lorsque la vérification du CVC ou de l’adresse (AVS) échoue, car les émetteurs évaluent de nombreux indicateurs avant de décider d’autoriser un paiement. L’émetteur d’une carte peut néanmoins considérer comme légitime un paiement qui échoue à la vérification du code CVC ou du code postal, et l’approuver.
Vous pouvez activer les règles intégrées à Radar pour bloquer certains paiements approuvés par l’émetteur de la carte. Lorsqu’elles sont activées, ces règles affectent également l’association d’une carte à un client, ainsi que la création d’un client, si vous créez la carte et le client en même temps.
Règles intégrées pour demander 3D Secure
Avec 3DS , les clients sont invités à s’authentifier une nouvelle fois pour finaliser leur achat. La responsabilité de la fraude pour les paiements authentifiés par 3DS passe généralement du vendeur à l’émetteur. Cela signifie que dans la plupart des cas, le vendeur n’est pas responsable des frais liés à la fraude pour ces paiements.
Stripe gère automatiquement les codes de refus de paiement indirect indiquant que 3DS est requis par les émetteurs. Nous déclenchons également l’authentification 3DS si nécessaire, conformément aux réglementations telles que l’authentification forte du client (SCA) imposée par la DSP2. La désactivation de Radar n’empêche pas le déclenchement de 3DS en cas de nécessité.
Stripe propose trois règles désactivées par défaut que vous pouvez activer pour demander dynamiquement l’authentification 3DS lors de l’utilisation de Radar avec Payment Intents ou Setup Intents :
Request 3D Secure if 3D Secure is recommended for card- Règle désactivée par défaut. Si elle est activée, le client est invité à s’authentifier via 3DS lorsque Stripe estime que l’authentification 3DS peut avoir lieu avec un impact minimal sur les taux de conversion.
- Activez cette option si vous souhaitez maximiser le nombre de paiements avec transfert de responsabilité.
Request 3D Secure if 3D Secure is supported for card- Disabled by default. Enabling this rule prompts the customer for 3DS authentication as long as their card supports it.
- Utilisez cette règle plutôt que la règle précédente pour optimiser le nombre de paiements avec transfert de responsabilité. Sachez toutefois que cette exigence supplémentaire peut réduire les taux de conversion.
Request 3D Secure if 3D Secure is required for cardObsolète- Enabling this rule prompts the customer for 3DS authentication if the card historically required 3DS.
- Regardless of this rule, Stripe automatically triggers 3DS:
- If a soft decline code indicates the issuer requires 3DS.
- In adherence to regulations such as PSD2’s Strong Customer Authentication mandate.
Because 3DS requires your customer to go through an additional layer of authentication, indiscriminate use of 3DS might lower conversion rates.
Le fait d’exiger 3DS ne signifie pas nécessairement que l’émetteur effectue une authentification 3DS. Pour en savoir plus, consultez la documentation dédiée à 3D Secure.
Règles personnalisées pour exiger 3D Secure et agir en fonction de résultats spécifiques
Après la tentative d’authentification 3DS, si vous disposez de Radar for Fraud Teams, vous pouvez évaluer le résultat dans les règles d’autorisation, de blocage et de vérification.
Voici les attributs les plus importants pour les règles Radar personnalisées :
is_3d_securedéfini sur true si la carte est prise en charge, si l’authentification 3DS a été tentée par l’émetteur, et si l’authentification de l’utilisateur n’a pas échoué. Nous recommandons généralement de l’utiliser dans les règles de blocage.is_3d_secure_authenticateddéfini sur true en cas de tentative d’authentification 3DS par l’émetteur et de réussite de l’authentification de l’utilisateur. L’utilisation de cet attribut dans une règle de blocage exclut les transactions légitimes qui peuvent bénéficier d’une exemption de la SCA ou qui ne relèvent pas d’un échec clair ou d’une authentification réussie, comme les erreurs de traitement.has_liability_shift, défini sur true si Stripe s’attend à ce que le paiement soit couvert par la règle de transfert de responsabilité. Cela peut ne pas toujours être la même que 3DS, par exemple avec Apple Pay dans certaines régions.
Pour les règles personnalisées, nous vous recommandons d’activer ou de désactiver les règles Request 3DS et Block en fonction de votre tolérance au risque. Cependant, ne bloquez pas les transactions pour lesquelles 3DS n’est pas pris en charge, par exemple en cas d’utilisation de certains portefeuilles.
Voici quelques exemples de procédures pour différents cas d’usage :
Exiger 3D Secure en fonction du niveau de risque Radar
Vous souhaitez utiliser Radar afin d’exiger 3DS pour tous les paiements en fonction du niveau de risque Radar et au-delà d’un certain montant.
| Règle Radar | Description |
|---|---|
Request 3D Secure if :risk_level: != | Cette règle vérifie le niveau de risque de Radar, puis exige 3DS pour tous les paiements présentant un niveau de risque élevé ou dépassant un certain montant. |
Dans ce cas, sans règle de blocage, les cartes ou portefeuilles qui ne prennent pas en charge 3DS ne sont pas bloqués. Les tentatives d’authentification 3DS qui échouent n’entraînent pas l’authentification du paiement.
Toujours exiger 3D Secure en fonction du niveau de risque Radar
Vous souhaitez utiliser Radar afin d’exiger 3DS pour tous les paiements si le niveau de risque Radar est élevé ou très élevé, et au-delà d’un certain montant. Si les cartes ne prennent pas en charge 3DS, vous ne devez pas les accepter.
| Règle Radar | Description |
|---|---|
Request 3D Secure if :risk_level: != | Cette règle vérifie le niveau de risque de Radar, puis exige 3DS pour tous les paiements présentant un niveau de risque élevé ou dépassant un certain montant. |
Block if not :is_3d_secure: and :risk_level: != | Cette règle bloque les paiements sans flux 3DS qui présentent un niveau de risque élevé ou très élevé à partir d’un certain montant. Cependant, elle accepte les transactions légitimes qui peuvent bénéficier d’une exemption de la SCA ou ne pas correspondre à un échec ou à une authentification réussie (par exemple, attempt_). Elle accepte les paiements hors session tels que les paiements d’abonnement récurrents et les portefeuilles comme Apple Pay ou Google Pay. |
Accepter uniquement les transactions authentifiées par 3D Secure si 3D Secure est pris en charge
Vous comptez sur Stripe pour déclencher 3DS si nécessaire dans des cas où l’authentification forte du client (SCA) est requise, mais vous ne souhaitez pas accepter les cas particuliers comme les erreurs de traitement.
| Règle Radar | Description |
|---|---|
Block if :is_3d_secure: and not :is_3d_secure_authenticated: | Cette règle bloque les paiements lorsque la carte exige 3DS et qu’une tentative 3DS a été effectuée, mais que l’utilisateur n’a pas réussi à s’authentifier. Les cartes qui ne prennent pas en charge 3DS, les exemptions de la SCA, les paiements hors session (tels que les paiements d’abonnements récurrents), et les portefeuilles (comme Apple Pay ou Google Pay) sont acceptés. |
Exiger 3D Secure en fonction de métadonnées
Vous souhaitez utiliser Radar afin d’exiger 3DS pour tous les paiements avec un attribut de métadonnées personnalisé.
| Règle Radar | Description |
|---|---|
Request 3D Secure if ::foo:: = | Cette règle vérifie une condition de métadonnées, puis exige 3DS. Pour vérifier les métadonnées du client, vous pouvez remplacer ::foo:: = 'bar' par une valeur du type ::customer:trusted:: = 'false'. |
Dans ce cas, sans règle de blocage, les cartes ou portefeuilles qui ne prennent pas en charge 3DS ne sont pas bloqués. Les tentatives d’authentification 3DS qui échouent n’entraînent pas l’authentification du paiement.
Toujours exiger 3D Secure en fonction des métadonnées
Vous souhaitez utiliser Radar afin d’exiger 3DS pour tous les paiements avec un attribut de métadonnées personnalisé et bloquer les cartes qui ne prennent pas en charge cette authentification.
| Règle Radar | Description |
|---|---|
Request 3D Secure if ::foo:: = | Cette règle vérifie une condition de métadonnées, puis exige 3DS. Pour vérifier les métadonnées du client, vous pouvez remplacer ::foo:: = 'bar' par une valeur du type ::customer:trusted:: = 'false'. |
Block if ::foo:: = | Cette règle bloque les paiements sans flux 3DS disposant d’un attribut de métadonnées personnalisé. Cependant, elle accepte les transactions légitimes qui peuvent bénéficier d’une exemption de la SCA ou ne pas correspondre à un échec ou à une authentification réussie (par exemple, attempt_). Elle accepte les paiements hors session (tels que les paiements d’abonnement récurrents) et les portefeuilles (comme Apple Pay ou Google Pay). |
Exiger 3D Secure pour toutes les nouvelles cartes et vérifier si 3D Secure n’est pas pris en charge
Vous souhaitez utiliser Radar afin d’exiger 3DS sur toutes les nouvelles cartes et vérifier manuellement les paiements des cartes qui ne prennent pas en charge 3DS.
| Règle Radar | Description |
|---|---|
Request 3D Secure if is_missing(:seconds_since_card_first_seen:) | Cette règle permet d’exiger 3DS pour toutes les cartes qui n’ont pas encore été utilisées sur votre compte. Pour simplifier l’expérience utilisateur, vous pouvez ajouter une condition supplémentaire de façon à exiger 3DS uniquement si :risk_level: != . |
Request 3D Secure if :is_new_card_on_customer: | Pouvant être utilisée comme alternative à la règle ci-dessus, cette règle permet d’exiger 3DS pour toutes les cartes qui n’ont pas encore été utilisées sur un objet Customer donné. Pour simplifier l’expérience utilisateur, vous pouvez ajouter une condition supplémentaire de façon à exiger 3DS uniquement si :risk_level: != . |
Review if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | Cette règle marque les paiements qui n’étaient pas pris en charge par 3DS alors que cette méthode était attendue, en vue d’un examen manuel. Elle ignore les paiements hors session (tels que les paiements d’abonnement récurrents) et les portefeuilles (comme Apple Pay ou Google Pay). Les paiements marqués pour examen continuent de faire l’objet d’une autorisation et peuvent donc donner lieu à des signaux supplémentaires, tels que des vérifications CVC de l’émetteur. |
Dans ce cas, sans règle de blocage, les cartes ou portefeuilles qui ne prennent pas en charge 3DS ne sont pas bloqués. Les tentatives d’authentification 3DS qui échouent n’entraînent pas l’authentification du paiement.
Toujours exiger 3D Secure pour les émetteurs de certains pays
Utilisez Radar afin de demander 3DS pour tous les paiements des émetteurs de cartes provenant de pays figurant sur une liste personnalisée et bloquer les cartes qui ne prennent pas en charge cette authentification.
| Règle Radar | Description |
|---|---|
Request 3D Secure if :card_country: in @enforce_3ds_list | Cette règle fait respecter une condition basée sur les émetteurs de cartes provenant de différents pays et les compare à une liste personnalisée. S’ils y figurent, elle exige l’authentification 3DS. |
Block if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != | Cette règle bloque les paiements sans flux 3DS provenant des pays de la liste personnalisée. Cependant, elle accepte les transactions légitimes qui peuvent bénéficier d’une exemption de la SCA ou ne pas correspondre à un échec ou à une authentification réussie (par exemple, attempt_). Elle accepte les paiements hors session (tels que les paiements d’abonnement récurrents) et les portefeuilles (comme Apple Pay ou Google Pay). |
Toujours exiger 3D Secure en fonction du niveau de risque Radar et passer en revue les cas particuliers
Vous souhaitez utiliser Radar afin de demander 3DS pour tous les paiements selon le niveau de risque Radar et bloquer les cartes qui ne prennent pas en charge 3DS, tout en examinant manuellement les cas particuliers.
| Règle Radar | Description |
|---|---|
Request 3D Secure if :risk_level: != | Cette règle vérifie le niveau de risque de Radar, puis exige 3DS pour tous les paiements présentant un niveau de risque élevé ou dépassant un certain montant. |
Block if not :is_3d_secure: and :risk_level: != | Cette règle bloque les paiements sans flux 3DS qui présentent un niveau de risque élevé ou très élevé à partir d’un certain montant. Cependant, elle accepte les transactions légitimes qui peuvent bénéficier d’une exemption de la SCA. Elle accepte les paiements hors session (tels que les paiements d’abonnement récurrents) et les portefeuilles (comme Apple Pay ou Google Pay). |
Review if not :is_3d_secure_authenticated: and :risk_level: != | Cette règle marque pour vérification manuelle les paiements qui utilisaient 3DS, mais qui n’ont pas abouti à un flux entièrement authentifié. Cela permet d’examiner les cas particuliers tels que attempt_ et de marquer les paiements légitimes malgré les exemptions de la SCA. Les règles de vérification étant évaluées après les règles de blocage, les cartes qui ne prennent pas en charge 3DS sont bloquées. |
Quand créer des règles
Les règles par défaut de Stripe peuvent bloquer un nombre important de paiements frauduleux. Les entreprises qui ont besoin de mieux contrôler les paiements qu’elles souhaitent vérifier, autoriser ou bloquer peuvent rédiger des règles personnalisées via Radar for Fraud Teams.
Tenez compte des questions suivantes lorsque vous décidez d’activer ou non les règles personnalisées :
- Considérez-vous que certaines fonctionnalités ou certains comportements d’utilisateur sont plus risqués (par exemple, l’utilisation d’une adresse e-mail éphémère) ?
- Souhaitez-vous mettre en place des règles basées sur les montants des paiements ou le niveau de risque perçu (par exemple, vérifier automatiquement les paiements de plus de 500 USD ou autoriser automatiquement les paiements de moins de 5 USD) ?
- Vos paiements contestés et remboursés existants présentent-ils des caractéristiques communes (par exemple, des montants, des types de cartes bancaires ou des pays similaires) ?
- Souhaitez-vous migrer des règles existantes vers Stripe ? Un grand nombre de ces règles peuvent déjà être couvertes par les modèles d’apprentissage automatique de Stripe, et vous pouvez évaluer les performances de notre système pour votre entreprise avant de le personnaliser.
Comment créer des règles efficaces
Si les règles peuvent vous aider à automatiser vos flux de travail existants, elles peuvent également avoir un impact négatif sur votre activité si elles sont utilisées de manière incorrecte. Par exemple, une règle peut automatiquement autoriser un grand nombre de paiements frauduleux ou bloquer un grand nombre de paiements légitimes si elle n’est pas configurée correctement.
Gardez les éléments suivants à l’esprit lorsque vous définissez des règles :
- Les règles ne s’appliquent qu’aux paiements futurs et non à ceux ayant déjà été traités.
- Les règles Request 3DS s’appliquent uniquement lors de l’utilisation de Stripe Checkout, Payment Intents, ou Setup Intents, et sont évaluées avant les règles de vérification, de blocage et d’autorisation.
- Avant de mettre en œuvre une règle de blocage pour bloquer tous les paiements répondant à ses critères, demandez-vous si vous ne préférez pas d’abord vérifier ces paiements.
- Les règles d’autorisation ne doivent être mises en œuvre que très rarement, car elles remplacent les règles par défaut de Stripe ainsi que toute autre règle personnalisée correspondant aux mêmes critères.
- Vous pouvez créer un maximum de 200 règles, de tout type, par compte.
Créer des règles
Vous pouvez ajouter et gérer des règles à partir de l’onglet Règles de la page Radar du Dashboard.
Pour ajouter une règle :
- Cliquez sur + Ajouter une règle.
- Choisissez le type de règle dans le sous-menu.
- Dans l’éditeur de règles, créez une règle en utilisant la syntaxe
{action} if {attribute} {operator} {value}selon laquelle :{action}: comment Radar réagit lorsque les critères de la règle sont remplis. Cette valeur est préremplie en fonction du type de règle que vous avez choisi.{attribute}: l’élément de la transaction à évaluer, tel que le montant ou le type de carte bancaire. Commencez la saisie par:pour ouvrir une liste d’attributs valides. Vous pouvez également évaluer vos métadonnées personnalisées en les entourant de deux points, par exemple::product_.sku:: {operator}: comment comparer l’attribut à la valeur, par exemple=,>,!=, etc.{value}: la valeur de l’attribut à évaluer.
- Cliquez sur Tester la règle.
- Corrigez les erreurs de validation détectées, le cas échéant.
- Sur la page Vérifier la nouvelle règle, examinez les performances de cette règle par rapport à vos transactions récentes afin de confirmer si vous souhaitez l’activer.
- Cliquez sur Ajouter une règle pour commencer à appliquer cette règle à toutes les transactions futures.
Utiliser l’assistant Radar
L’éditeur de règles de Stripe intègre un assistant LLM qui crée une règle Radar à partir d’une invite en langage naturel.
Pour utiliser l’assistant Radar :
- Dans l’onglet Règles de la page Radar du Dashboard, cliquez sur + Ajouter une règle.
- Choisissez le type de règle dans le sous-menu.
- Dans l’éditeur de règles, cliquez sur Assistant Radar.
Écriture manuelle de règles
Assistant Radar
- Dans le champ message, saisissez votre demande de règle. Vous pouvez demander à :
- Examiner les paiements pour lesquels le pays de la carte et de l’adresse IP sont différents.
- Bloquer les paiements par carte Discover de plus de 1000 $
- Autoriser les paiements à partir d’adresses e-mail de type stripe.com.
- Lorsque l’assistant renvoie sa suggestion, vous pouvez soit saisir une commande supplémentaire pour réajuster la règle, soit cliquer sur Tester la règle pour analyser sa performance par rapport à l’historique de vos transactions récentes.
- Lorsque vous la règle vous convient, cliquez sur Ajouter une règle afin de l’activer pour toutes les transactions futures.
Consentement à l’entrainement des données : en utilisant l’assistant Radar, vous acceptez que Stripe puisse enregistrer et utiliser vos messages de chat pour entraîner et améliorer les fonctionnalités de l’assistant Radar. Si vous ne souhaitez pas que vos messages de chat soient utilisés à cette fin, rédigez des règles manuellement.
En savoir plus sur les services d’IA de Stripe.
Règles de vérification
Stripe traite toujours les paiements normalement lorsqu’ils répondent aux critères d’une règle de vérification. Toutefois, nous les plaçons dans votre file d’attente de vérification afin que votre équipe puisse les examiner de plus près. La définition d’une règle trop générale risque de placer un trop grand nombre de paiements dans votre file d’attente de vérification et donc de ralentir vos clients et de surcharger votre équipe de vérification.
L’interface de test des règles Stripe effectue une simulation sur les paiements des 6 derniers mois afin de déterminer combien de paiements légitimes, frauduleux et bloqués auraient été affectés par la règle si elle avait été appliquée. Lorsque vous testez une règle sur les paiements des 6 derniers mois, assurez-vous que :
- Le volume global de paiements est faible. La vérification de ces paiements ne devrait pas créer de surcharge pour votre équipe.
- Les réviseurs humains ajoutent de la valeur. Un réviseur humain peut généralement identifier si un paiement est frauduleux avec plus de certitude que le système automatisé.
- La règle combine les paiements réussis et les paiements remboursés ou contestés. Cela signifie qu’une inspection supplémentaire de ces types de paiements peut aider à différencier les paiements légitimes des paiements frauduleux.
Voici un exemple d’amélioration d’une règle de vérification créée par une entreprise qui souhaite vérifier les cartes de crédit prépayées.
| Règle d’origine | Règle améliorée |
|---|---|
Review if :card_funding: = | Review if :is_disposable_email: and :card_funding: = |
| Trop générale : aboutit à un nombre excessif de vérifications | Plus spécifique : nombre inférieur de vérifications |
Règles de blocage
Vous pouvez utiliser des règles de blocage pour bloquer les paiements que vous pensez être frauduleux, ou en fonction de restrictions mises en place par votre entreprise (par exemple, blocage des paiements par cartes bancaires prépayées). Si vous ne savez pas comment appliquer des règles de blocage, nous vous recommandons d’utiliser une règle de vérification pour soumettre les paiements concernés pour vérification. Après avoir pris le temps d’examiner ces paiements pour y détecter d’éventuels faux positifs, vous pouvez confirmer si vous souhaitez plutôt créer une règle de blocage.
Les règles de blocage ont un impact sur les paiements frauduleux et les paiements réussis, mais pas sur les paiements déjà bloqués. Lorsque vous testez une règle, veillez à :
- Minimiser les faux positifs. Au cours des tests, Stripe identifie le nombre de paiements réussis et contestés qui auraient correspondu à la règle. Une règle de blocage efficace entraîne le blocage de beaucoup plus de paiements frauduleux que de paiements légitimes.
- Minimiser les règles inutiles. Si votre règle semble très performante, mais qu’elle est déjà couverte par une règle existante, votre nouvelle règle n’est peut-être pas nécessaire. De même, si les résultats des tests semblent mitigés, envisagez d’appliquer une règle de vérification à la place afin de pouvoir recueillir davantage d’informations sur ces types de paiements.
Voici un exemple d’amélioration d’une règle de blocage créée par une entreprise qui subit un niveau élevé de fraudes provenant de paiements réalisés en dehors des États-Unis :
| Règle d’origine | Règle améliorée |
|---|---|
Block if :card_country: != | Block if :card_country: != |
| Trop générale : nombre élevé de paiements légitimes bloqués | Plus spécifique : nombre inférieur de vérifications |
Règles d’autorisation
Les règles d’autorisation remplacent toutes vos autres règles, c’est pourquoi vous devez les utiliser avec prudence. De nombreuses entreprises peuvent ne pas avoir besoin d’appliquer des règles d’autorisation. Si vous craignez qu’une règle d’autorisation puisse laisser passer ne serait-ce qu’un petit nombre de paiements frauduleux, envisagez de procéder à des réajustements afin de restreindre davantage ces règles avant de les appliquer.
Les règles d’autorisation s’appliquent à tous les nouveaux paiements dès que vous créez la règle. Cela inclut tous les paiements qui sont similaires à des paiements précédemment bloqués. Lorsque vous testez une règle, veillez à :
- Examiner le nombre de paiements précédemment bloqués qui auraient été autorisés. Les règles d’autorisation remplacent toutes les autres règles et l’évaluation des risques de Stripe. Lorsque vous testez une nouvelle règle d’autorisation, tous les paiements affichés auraient été autorisés si cette règle avait été active. Cela peut inclure des paiements qui ont été bloqués ou contestés, ce qui a un impact sur vos futurs taux de contestation.
- Continue to block any high-risk payments. You can do this by adding the following to any allow rule:
and :risk_level: !='highest' - Évaluer l’historique de transactions légitimes dans votre entreprise. Vous pouvez analyser les relations entre vos clients pour autoriser un plus grand volume de transactions sur la base d’un historique d’achats légitimes. Cela vous permet de bloquer moins de paiements provenant de clients justifiant d’un historique au sein de votre entreprise. Pour ce faire, consultez la liste des attributs et recherchez les attributs qui incluent le mot « client ».
Voici un exemple d’amélioration d’une règle d’autorisation pour une entreprise pour laquelle les paiements non frauduleux proviennent généralement (mais pas toujours) de clients du Royaume-Uni :
| Règle d’origine | Règle améliorée |
|---|---|
Allow if :ip_country: = | Allow if :ip_country: = |
| Trop large : certains paiements frauduleux sont autorisés | Plus restrictive : un plus petit nombre de paiements frauduleux sont autorisés |
Maintenance de vos règles
Au fur et à mesure que votre entreprise se développe, vous devez vous assurer que vos règles continuent de refléter les types de clients avec lesquels vous souhaitez faire des affaires. Voici quelques bonnes pratiques pour que les règles restent adaptées à l’évolution de votre entreprise.
Contrôle régulier des règles pour s’assurer qu’elles sont toujours efficaces
Mesures des règles
Étant donné que les mécanismes de fraude évoluent constamment, nous fournissons des mesures indiquant les performances de ces règles. Ces mesures varient selon le type de règle, car les règles exécutent des actions différentes en fonction de leur type.
Utilisez le graphique des performances de règle pour comprendre le comportement de vos règles Radar. Recherchez de fortes hausses ou baisses inattendues du nombre de paiements correspondant à vos règles (par exemple, un trop grand nombre de paiements acceptés par les règles d’autorisation ou refusés par les règles de blocage). De telles variations peuvent indiquer un changement dans les types de paiements que votre entreprise reçoit ou nécessiter des mises à jour des règles elles-mêmes. Ces mises à jour sont signalées par des triangles sur le graphique et vous permettent de comparer les situations avant et après le changement afin de déterminer son impact.
Les lignes à code couleur reflètent le nombre de paiements répondant aux critères des règles 3DS, des règles d’autorisation, des règles de blocage et des règles de vérification. Les symboles triangulaires sur ces lignes de graphique représentent les mises à jour apportées aux règles du type correspondant.
Vous pouvez obtenir des informations sur l’efficacité de vos règles et voir le nombre de paiements traités par chacune d’elles. Vous pouvez également afficher et télécharger une liste filtrée de tous les paiements auxquels une règle a été appliquée. Évaluez ces informations pour déterminer si certaines règles nécessitent des modifications ou doivent être entièrement supprimées.
Pour afficher les commandes supplémentaires, cliquez sur le menu déroulant). Les commandes supplémentaires sont les suivantes :Désactiver, Activer, Modifier ou Supprimer pour toutes les règles.
Vous pouvez également utiliser nos produits de reporting Sigma et Data Pipelines pour interroger les données sur les litiges et les fraudes, y compris les décisions relatives aux règles et les attributs de chaque paiement.
Évaluation de l’efficacité des règles
Vous pouvez obtenir des informations sur l’efficacité de vos règles et le nombre de paiements auxquels chacune d’entre elles a été appliquée. Vous pouvez également afficher et télécharger une liste filtrée de tous les paiements auxquels une règle a été appliquée. Répondez aux questions du tableau suivant pour déterminer si certaines règles nécessitent d’être modifiées voire entièrement supprimées.
| Type de règle | Évaluation | Actions à envisager |
|---|---|---|
| Générale | Cette règle ne s’applique-t-elle plus à aucun paiement ? | Supprimez la règle. |
| Cette règle présente-t-elle un comportement anormal, par exemple en autorisant davantage de paiements que sur les périodes précédentes ? | Vérifiez manuellement les paiements qui correspondent à cette règle pour déterminer si le comportement correspond à celui que vous souhaitez. | |
| 3DS | Le taux d’exécution des authentifications 3DS est-il élevé, tandis que le nombre de litiges/d’alertes de suspicion de fraude est faible ? | Supprimez la règle, car vous risquez de gêner les bons utilisateurs. |
| La fraude est-elle élevée pour les transactions qui réussissent l’authentification 3DS ? | Envisagez de modifier votre règle 3DS en une règle de blocage pour empêcher ces utilisateurs de transmettre un flux d’authentification simple (contrôlé par les émetteurs) ou de commettre une fraude directe. | |
| Le taux de conversion pour l’authentification 3DS est-il faible ? | Cette règle peut être pertinente, puisqu’elle bloque principalement les fraudeurs, mais envisagez d’examiner manuellement les paiements concernés pour vous assurer que vos utilisateurs légitimes n’abandonnent pas le processus de paiement en raison de difficultés supplémentaires. | |
| Autorisation | Le nombre de litiges, d’alertes de suspicion de fraude, de remboursements ou d’échecs de paiement est-il élevé ? | Supprimez la règle qui autorise les paiements non valides. |
| Blocage | Le nombre de blocages diminue, mais la fraude reste stable ou est en progression ? | Modifiez votre règle, car elle risque de ne plus être efficace. |
| Le nombre de blocages augmente, mais la fraude reste stable ou est en progression ? | Modifiez votre règle, car elle risque de bloquer les utilisateurs légitimes. | |
| Le nombre de blocages augmente-t-il alors que votre taux de fraude diminue ? | Ceci suggère que votre règle est efficace, mais veillez à vérifier manuellement quelques transactions pour vous assurer que vous ne bloquez pas trop d’utilisateurs légitimes. | |
| Vérification manuelle | Le pourcentage de paiements vérifiés est-il faible ? | Rendez la règle plus restrictive, car elle est susceptible d’être trop générale. |
| Le nombre de paiements réussis ou approuvés est-il élevé ? | Supprimez entièrement la règle de vérification manuelle ou définissez une règle d’autorisation pour cibler ces paiements. | |
| Le nombre de remboursements ou de litiges et d’alertes de suspicion de fraude est-il élevé ? | Convertissez la règle en règle de blocage. |
Règles de demande d’authentification 3DS
Pour les règles de demande d’authentification 3DS, nous affichons les informations suivantes :
- 3DS exigée : nombre de fois où une règle a déclenché une demande d’authentification 3DS.
Cliquez sur une règle 3DS pour afficher les mesures suivantes :
Règles d’autorisation
Pour les règles d’autorisation, les utilisateurs de Radar for Fraud Teams peuvent consulter les informations suivantes :
- Paiements autorisés : nombre total de paiements autorisés par vos règles.
- Volume des paiements autorisés : montant total des paiements autorisés par vos règles, libellé dans votre devise locale.
- Score de risque : résultats de risque correspondants attribués par les modèles d’apprentissage automatique de Stripe à l’ensemble des paiements autorisés par vos règles.
- Litiges sur les dérogations : nombre total de paiements ayant été contestés.
- Volume des litiges sur les dérogations : montant total des litiges liés aux paiements autorisés, libellé dans votre devise locale.
Cliquez sur une règle d’autorisation pour afficher les mesures suivantes :
Règles de blocage
Pour les règles de blocage, nous affichons les informations suivantes :
- Paiements bloqués : nombre total de paiements bloqués par vos règles.
- Volume des paiements bloqués : montant total des paiements bloqués par vos règles, , libellé dans votre devise locale.
Les utilisateurs de Radar for Fraud Teams peuvent également consulter les informations suivantes :
- Score de risque : résultats de risque correspondants attribués par les modèles d’apprentissage automatique de Stripe à l’ensemble des paiements autorisés par vos règles.
- Taux de faux positifs estimé : estimation du pourcentage de paiements non frauduleux bloqués de façon groupée par vos règles de blocage et individuellement par chacune de vos règles. (Pour effectuer ce calcul, Stripe utilise les taux de faux positifs estimés sur la base des scores de risque correspondants obtenus grâce à l’apprentissage automatique et calculés à partir de différentes estimations réalisées sur l’ensemble de son réseau.)
- Nombre estimé de paiements frauduleux évités : nombre estimé de paiements frauduleux que vos règles de blocage ont permis d’éviter. Stripe utilise des scores de risque d’apprentissage automatique, calculés en analysant des millions de transactions à travers le réseau Stripe, pour prédire les paiements ayant une forte probabilité d’être contestés ou refusés pour cause de fraude et estimer lesquels de ces paiements ont bien été bloqués par vos règles.
Cliquez sur une règle de blocage pour afficher les mesures suivantes :
Règles de vérification
Pour les règles de vérification, les utilisateurs de Radar for Fraud Teams peuvent consulter les informations suivantes :
- Paiements transférés pour vérification : nombre total de paiements soumis par vos règles en vue de leur vérification manuelle.
- Volume des vérifications approuvées : montant total des paiements approuvés lors de leur vérification, libellé dans votre devise locale.
- Taux de remboursement : pourcentage de vérifications ayant fait l’objet d’un remboursement.
- Litiges sur les vérifications approuvées : nombre total de paiements qui avaient été approuvés lors de votre vérification, mais qui ont finalement été contestés.
- Volume des litiges sur les vérifications approuvées : montant total des litiges liés aux paiements approuvés lors de leur vérification, libellé dans votre devise locale.
Cliquez sur une règle de vérification pour afficher les mesures suivantes :
Contrôle régulier de votre file d’attente de vérifications manuelles
Si votre file d’attente de vérification devient trop difficile à gérer, vérifiez que les règles appropriées ont été mises en place. Si la plupart des vérifications finissent par être remboursées parce qu’elles sont frauduleuses, envisagez de mettre en œuvre des règles supplémentaires destinées à bloquer les paiements. De même, si la plupart des paiements sont approuvés, envisagez de rendre vos règles de vérification plus spécifiques.
Analyse des paiements contestés et remboursés
Les litiges sont intrinsèquement liés à la fraude, c’est pourquoi plus vous tentez de réduire la fraude, plus votre taux de litiges sera faible. Vérifiez si les paiements contestés présentent des caractéristiques communes (par exemple, s’ils proviennent des mêmes emplacements ou si leur montant est similaire). Vous pouvez également répondre à ces questions en examinant les paiements qui ont été remboursés lors d’une vérification. Si vous constatez des tendances, vous pouvez tester et créer les règles appropriées. Si des paiements vous semblent frauduleux, remboursez-les et signalez-les comme tels afin d’éviter d’éventuels litiges.
Vous pouvez également utiliser nos produits de reporting Sigma et Data Pipelines pour interroger les données sur les litiges et les fraudes.
Vous pouvez répondre à tout litige entrant en utilisant le Dashboard ou l’API. Par ailleurs, notre documentation sur les litiges comprend plusieurs suggestions sur la façon de présenter un cas bien documenté.
Anticipation des changements importants au niveau de l’entreprise pouvant avoir un impact sur le taux de fraudes
Si vous prévoyez de lancer une version majeure d’un produit ou de modifier votre service (par exemple, de lancer un nouveau produit à forte valeur ajoutée ou d’étendre un service à de nouveaux pays), nous vous conseillons de surveiller ces paiements au départ. Pour ces types de changements, il est bon de mettre en place des règles de vérification afin de pouvoir examiner tous les nouveaux paiements. En effet, la vérification de ces paiements et l’identification de tendances pourront vous aider à mettre en place de nouvelles règles pour la protection de votre entreprise contre la fraude.