# 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 de prendre des mesures chaque fois qu’un paiement répond à certains critères. Stripe Radar fournit des règles intégrées pour vous aider à détecter et à vous protéger contre le risque de fraude sur les paiements par carte bancaire, ACH et les prélèvements automatiques SEPA. Radar for Fraud Teams et [Radar pour les plateformes](https://docs.stripe.com/radar/radar-for-platforms.md) vous permettent d’utiliser le [Dashboard](https://dashboard.stripe.com/test/radar/rules) pour créer des règles personnalisées selon la logique propre à 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 - **Vérifier et suspendre automatiquement les virements** sur les comptes ayant un taux élevé de litiges (avec Radar pour les plateformes) > Les entreprises de l’UE pourraient être concernées par le [règlement sur le géoblocage](https://support.stripe.com/questions/eu-geo-blocking-regulation-changes) et ses interdictions de bloquer les paiements des clients établis dans les États membres de l’UE. ## Règles intégrées Les règles suivantes sont disponibles par défaut, sauf si elles sont considérées comme des règles personnalisées, disponibles uniquement si vous utilisez Radar for Fraud Teams ou Radar pour les plateformes. > #### Bloquer automatiquement la fraude > > Vous pouvez également utiliser les [contrôles de risque](https://docs.stripe.com/radar/risk-settings.md) Radar pour bloquer automatiquement la fraude. Les contrôles de risque utilisent des [alertes de suspicion de fraude](https://docs.stripe.com/radar/risk-settings.md#early-fraud-warning) pour évaluer et bloquer les paiements les plus risqués. ### Vérifications des risques par l’IA Toutes les offres Radar prévoient un ensemble de règles par défaut établies sur les jugements de nos modèles d’IA. | Règle Radar | Description | | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `if :risk_level: = ’highest’` (Deprecated) | Cette règle bloque les paiements présentant un risque très élevé de fraude et empêche leur traitement. Elle est activée par défaut pour tous les utilisateurs de Radar. | | `if :risk_level: = 'elevated'` | Le comportement par défaut de Radar for Fraud Teams et de Radar pour les plateformes consiste à placer sous examen les paiements soupçonnés de présenter un risque élevé de fraude. | Radar pour les plateformes propose des modèles d’IA supplémentaires au niveau du compte qui sont incorporés via deux règles par défaut : `si :account_risk_level : = 'highest'` `si :account_risk_level : = 'elevated'` Nous calculons le risque au niveau du compte à partir des informations KYC, des transactions, des signaux géographiques et des modèles de comportement. ### Vérifications traditionnelles de carte bancaire Un paiement peut aboutir même lorsque la vérification du *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number) ou de l’adresse (*AVS* (The address verification system (AVS) is used to pass billing address information to issuers to verify the data if available)) é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 relatives à la vérification CVC et AVS À compter du 17 décembre 2024, le Dashboard affichera ces règles aux nouveaux clients et aux clients existants qui n’ont pas utilisé les anciennes règles relatives à la vérification CVC ou AVS. | Règle Radar | Description | | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `if CVC verification fails based on risk score` | Activez cette règle pour bloquer les paiements qui échouent à la vérification du CVC effectuée par l’émetteur de la carte, à moins que Stripe estime qu’ils ne présentent qu’un risque faible. Cette règle ne bloque pas les paiements pour lesquels le client ne fournit pas le numéro CVC par exemple, parce qu’il utilise un *wallet* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase) ou pour lesquels l’émetteur de la carte ne prend pas en charge la vérification. | | `if Postal code verification fails based on risk score` | Activez cette règle pour bloquer les paiements qui échouent à la vérification du code postal effectuée par l’émetteur de la carte, à moins que Stripe estime qu’ils ne présentent qu’un risque faible. Cette règle ne bloque pas les paiements si le client ne renseigne pas son code postal ou si l’émetteur de sa carte ne prend pas en charge sa vérification. | #### Anciennes règles relatives à la vérification CVC et AVS À compter du 17 décembre 2024, le Dashboard affichera ces règles aux clients existants qui ont activé au moins une d’entre elles. | Règle Radar | Description | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `if CVC verification fails` | Activez cette règle pour bloquer les paiements qui échouent à la vérification du CVC effectuée par l’émetteur de la carte. Cette règle ne bloque pas les paiements pour lesquels le client ne fournit pas le numéro CVC par exemple, parce qu’il utilise un *wallet* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase) ou pour lesquels l’émetteur de la carte ne prend pas en charge la vérification. | | `if postal code verification fails` | Activez cette règle pour bloquer les paiements lorsqu’ils échouent à la vérification du code postal effectuée par l’émetteur de la carte. Cette règle ne bloque pas les paiements si le client ne renseigne pas son code postal ou si l’émetteur de sa carte ne prend pas en charge sa vérification. | ### Règles intégrées pour demander 3D Secure *3D Secure (3DS)* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments) invite les clients à s’authentifier une nouvelle fois pour finaliser leur achat. La [responsabilité](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments) de la fraude pour les paiements authentifiés par le 3DS passe généralement du commerçant à l’émetteur. Cela signifie que, dans la plupart des cas, le commerçant 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 le 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](https://stripe.com/guides/strong-customer-authentication) (SCA) imposée par la DSP2. La désactivation de Radar n’empêche pas le déclenchement du 3DS en cas de nécessité. Stripe prend en charge trois anciennes règles intégrées pour exiger une authentification 3DS lorsque vous utilisez Radar avec [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) ou [SetupIntents](https://docs.stripe.com/payments/save-and-reuse.md) : | Règle Radar | Description | | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `si 3D Secure est recommandé pour la carte` (Deprecated) | Activez cette règle pour inviter le client à une authentification 3DS en fonction du risque. | | `si 3D Secure est pris en charge pour la carte` (Deprecated) | Activez cette règle pour inviter le client à une authentification 3DS, tant que sa carte bancaire la prend en charge. | | `si 3D Secure est requis pour la carte` (Deprecated) | Activez cette règle pour inviter le client à une authentification 3DS, si la carte bancaire [nécessitait auparavant le 3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#three-ds-cards). Indépendamment de ces règles, Stripe déclenche automatiquement 3DS : - Si un code de refus temporaire indique que l’émetteur exige 3DS. - Conformément aux réglementations, telles que le mandat DSP2 relatif à l’[authentification forte du client](https://stripe.com/guides/strong-customer-authentication). | Dans la mesure où le système 3DS exige que le client passe par un niveau d’authentification supplémentaire, l’utilisation inconsidérée du système 3DS risque de faire baisser les taux de conversion. Une demande d’authentification 3DS ne signifie pas nécessairement que l’émetteur effectue réellement le 3DS. En savoir plus sur les [résultats possibles](https://docs.stripe.com/payments/3d-secure.md). ### 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](https://stripe.com/radar/fraud-teams) ou [Radar pour les plateformes](https://docs.stripe.com/radar/radar-for-platforms.md), vous pouvez évaluer le résultat dans les règles d’autorisation, de blocage et de vérification. Voir ci-dessous les attributs les plus importants pour les règles Radar personnalisées. | Attribut | Description | | ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `is_3d_secure` | Ceci est dé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 du client n’a pas échoué. Nous recommandons généralement de l’utiliser dans les règles de blocage. | | `is_3d_secure_authenticated` | Ceci est défini sur true en cas de tentative d’authentification 3DS par l’émetteur et de réussite de l’authentification du client. 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` | Ceci est défini sur true si Stripe prévoit un *transfert de responsabilité* (With some 3D Secure transactions, the liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer) pour couvrir le paiement. Cela peut ne pas toujours être le [3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments), mais ce peut être Apple Pay dans certaines régions, par exemple. | 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](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data). Cependant, ne bloquez pas les paiements pour lesquelles le 3DS n’est pas pris en charge, par exemple en cas d’utilisation de certains wallets. Voici ci-dessous 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 une authentification 3DS pour tous les paiements en fonction du niveau de risque et qui sont au-delà d’un certain montant. | Règle Radar | Description | | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | Cette règle vérifie le niveau de risque Radar, avant d’exiger le 3DS pour tous les paiements présentant un niveau de risque élevé ou très élevé dépassant un certain montant. | Dans ce cas, sans règle de blocage, les cartes ou wallets qui ne prennent pas en charge le 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 pour exiger une authentification 3DS sur tous les paiements, en cas de niveau de risque élevé ou très élevé qui dépassent un certain montant. Vous ne souhaitez pas prendre en charge des cartes qui ne prennent pas en charge le 3DS. | Règle Radar | Description | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Request 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | Cette règle vérifie le niveau de risque Radar, avant d’exiger le 3DS pour tous les paiements présentant un niveau de risque élevé ou très élevé dépassant un certain montant. | | `Block if not :is_3d_secure: and :risk_level: != 'normal' and :amount_in_usd: > 25 and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | 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. Cette règle 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_acknowledged`). Elle accepte les paiements hors session tels que les paiements d’abonnement récurrents et les wallets comme Apple Pay ou Google Pay. | #### Accepter uniquement les paiements authentifiés par 3D Secure si 3D Secure est pris en charge Vous comptez sur Stripe pour activer le 3DS lorsque cela est nécessaire dans des cas tels que l’[authentification forte du client](https://stripe.com/guides/strong-customer-authentication) (SCA), mais ne souhaitez pas accepter [de cas particuliers](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), tels que des 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 le 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 le 3DS, les exemptions de la SCA, les paiements hors session (tels que les paiements d’abonnements récurrents), et les wallets (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 une authentification 3DS pour tous les paiements avec un attribut de métadonnées personnalisé. | Règle Radar | Description | | -------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if ::foo:: = 'bar'` | Cette règle vérifie une condition de métadonnées, puis exige une authentification 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, nous ne bloquons pas les cartes ou wallets qui ne prennent pas en charge le 3DS. 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 une authentification 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:: = 'bar'` | Cette règle vérifie une condition de métadonnées, puis exige une authentification 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:: = 'bar' and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Cette règle bloque les paiements sans flux 3DS disposant d’un attribut de métadonnées personnalisé. Cette règle accepte les paiements 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_acknowledged`). Elle accepte les paiements hors session, tels que les paiements d’abonnement récurrents, et les wallets 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 une authentification 3DS sur toutes les nouvelles cartes et vérifier manuellement les paiements des cartes qui ne prennent pas en charge le 3DS. | Règle Radar | Description | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if is_missing(:seconds_since_card_first_seen:)` | Cette règle permet d’exiger une authentification 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 de façon à exiger une authentification 3DS uniquement si `:risk_level: != ’normal’`. | | `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 une authentification 3DS pour toutes les cartes qui n’ont pas encore été utilisées sur un objet [Customer](https://docs.stripe.com/api/customers.md) donné. Pour simplifier l’expérience utilisateur, vous pouvez ajouter une condition de façon à exiger une authentification 3DS uniquement si `:risk_level: != ’normal’`. | | `Review if not :is_3d_secure and not:is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | 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 wallets 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, nous ne bloquons pas les cartes ou wallets qui ne prennent pas en charge le 3DS. 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 d’exiger une authentification 3DS pour tous les paiements des émetteurs de cartes provenant de pays figurant sur une [liste personnalisée](https://docs.stripe.com/radar/lists.md) 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 vérifie l’existence d’une condition en fonction du pays d’origine de l’émetteur de la carte bancaire et la compare à une [liste personnalisée](https://docs.stripe.com/radar/lists.md). Si elle correspond, nous exigeons une authentification 3DS. | | `Block if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Cette règle bloque les paiements sans flux 3DS et qui proviennent de pays présents sur la liste personnalisée. Cette règle 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_acknowledged`). Elle accepte les paiements hors session tels que les paiements d’abonnement récurrents et les wallets 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 d’exiger une authentification 3DS pour tous les paiements selon le niveau de risque et bloquer les cartes qui ne prennent pas en charge le 3DS, tout en examinant manuellement les cas particuliers. | Règle Radar | Description | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :risk_level: != 'normal'` | Cette règle vérifie le niveau de risque Radar, avant d’exiger le 3DS pour tous les paiements présentant un niveau de risque élevé et dépassant un certain montant. | | `Block if not :is_3d_secure: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | 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. Cette règle accepte les paiements 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 wallets (comme Apple Pay ou Google Pay). | | `Review if not :is_3d_secure_authenticated: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Cette règle marque les paiements qui utilisaient le 3DS, mais qui n’ont pas abouti à un flux entièrement authentifié, pour les vérifier manuellement. Cette règle examine les [cas particuliers](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), tels que `attempt_acknowledged`, et marque également les paiements légitimes malgré les exemptions SCA. Les règles de vérification étant évaluées après les règles de blocage, nous bloquons les cartes qui ne prennent pas en charge le 3DS. | ## Créer des règles Seuls le propriétaire du compte, les administrateurs et les développeurs peuvent créer des règles. Si vous avez besoin que les [membres de l’équipe](https://support.stripe.com/questions/can-i-invite-other-team-members-or-my-developer-to-use-my-stripe-account) puissent créer des règles, vérifiez que ceux-ci disposent d’un accès administrateur dans vos [paramètres d’équipe](https://dashboard.stripe.com/settings/team). Les règles Stripe par défaut peuvent bloquer un nombre important de paiements frauduleux. Les entreprises qui ont besoin de plus de contrôle sur les paiements qu’elles souhaitent vérifier, autoriser ou bloquer peuvent écrire règles personnalisées via Radar for Fraud Teams. Les plateformes peuvent écrire des règles personnalisées via Radar pour les plateformes afin de calibrer le risque des paiements pour leur plateforme et leurs comptes associés, et appliquer des règles spécifiques à chaque compte. Tenez compte des questions suivantes lorsque vous décidez d’activer ou non les règles personnalisées : - Si vous considérez 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). - Si vous souhaitez mettre en place des règles basées sur le moyen de paiement (par exemple, bloquer automatiquement les paiement par prélèvement automatique SEPA qui dépassent un certain score de risque). - Si vous souhaitez 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). - Si vos paiements contestés et remboursés existants présentent des caractéristiques communes (par exemple, des montants, des types de cartes bancaires ou des pays similaires). - Si vous souhaitez migrer des règles existantes vers Stripe. Le modèle d’IA de Stripe peut déjà couvrir un grand nombre de ces règles, et vous pouvez évaluer les performances de notre système pour votre entreprise avant de le personnaliser. - Si vous souhaitez augmenter automatiquement les vérifications et éventuellement suspendre les virements sur les comptes. Cela concerne uniquement les plateformes. ### 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 à risque élevé ou très élevé ou bloquer un grand nombre de paiements légitimes si elle n’est pas configurée correctement. N’oubliez pas les éléments suivants lors de la configuration des règles : - Par défaut, les règles s’appliquent à tous les moyens de paiement pris en charge par Radar, sauf si vous définissez un moyen de paiement spécifique dans le prédicat de la règle à l’aide de l’attribut `payment_method_type`. - 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](https://docs.stripe.com/payments/checkout.md), [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md), ou [Setup Intents](https://docs.stripe.com/payments/save-and-reuse.md), 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 visant à bloquer tous les paiements ou de suspendre les virements pour les comptes qui répondent à ses critères, demandez-vous si vous préférez d’abord vérifier les paiements ou les comptes. - Toute règle d’autorisation ne doit être mise en œuvre que très rarement, car celles-ci 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 transaction et 100 règles de compte. ## Élaborer des règles de transaction Vous pouvez ajouter et gérer des règles depuis la [page Règles Radar](https://dashboard.stripe.com/test/radar/rules) du Dashboard. #### Pour ajouter une règle de transaction 1. Cliquez sur **+ Ajouter une règle**. 1. Sélectionnez le type de règle. 1. Dans l’éditeur de règles, créez une règle en utilisant la syntaxe `{action} if {attribute} {operator} {value}` selon laquelle : - `{action}`: représente 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}`: est l’élément du paiement à é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}`: représente comment comparer l’attribut à la valeur, par exemple `=`, `>`, `!=`, etc. - `{value}`: est la valeur de l’attribut à évaluer. 1. Cliquez sur **Tester la règle**. 1. Corrigez les erreurs de validation détectées, le cas échéant. 1. Sur la page **Vérifier une nouvelle règle**, vérifiez les performances de cette règle par rapport à vos paiements récents pour confirmer si vous souhaitez l’activer. Si la règle peut avoir un impact sur les paiements par plusieurs moyen de paiement, utilisez le filtre pour afficher les performances de la règle par moyen de paiement (par exemple, ACH ou Cards). 1. Cliquez sur **Ajouter une règle** pour appliquer cette règle à toutes les transactions futures. ### Utiliser l’assistant Radar L’éditeur de règles Stripe dispose d’un assistant LLM intégré qui construit une règle transaction Radar à partir d’une invite en langage naturel. En savoir plus sur les [services Stripe AI](https://support.stripe.com/questions/use-of-artificial-intelligence-(ai) dans les services Stripe). > #### Consentement à l’entraînement 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. #### Pour utiliser l’assistant Radar 1. Sur la [page Règles Radar](https://dashboard.stripe.com/test/radar/rules), cliquez sur **+ Ajouter une règle**. 1. Sélectionnez le type de règle. 1. Dans l’éditeur de règles, cliquez sur **Assistant Radar**. 1. Dans le champ message, saisissez votre exigence 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.* 1. 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. 1. Lorsque vous la règle vous convient, cliquez sur **Ajouter une règle** afin de l’activer pour toutes les transactions futures. > #### Faites-nous part de vos commentaires > > Aidez-nous à améliorer continuellement l’assistant Radar. Cliquez sur **Laisser un commentaire** et détaillez précisément votre expérience d’utilisation de l’assistant ainsi que les améliorations que nous pouvons y apporter. Tous les avis sont les bienvenus, qu’il s’agisse de la précision de la suggestion, de l’interface utilisateur ou de tout autre aspect de votre expérience. ### Règles de vérification Stripe traite toujours les paiements normalement lorsqu’ils correspondent aux critères d’une règle de vérification. Nous les ajoutons dans votre [file d’attente de vérification](https://dashboard.stripe.com/test/radar) afin que votre équipe puisse les vérifier 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 un paiement à risque élevé ou très élevé 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 | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | `if :card_funding: = 'prepaid'` | `if :is_disposable_email: and :card_funding: = 'prepaid'` | | Cette règle est trop générale et entraîne un trop grand nombre de vérifications. | Cette règle est plus spécifique et donne lieu à un nombre plus restreint 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 examiné 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 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 | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | `if :card_country: != 'US'` | `if :card_country: != 'US' and :risk_level: = 'elevated'` | | Cette règle est trop générale et bloque un nombre élevé de paiements légitimes. | Cette règle est plus spécifique et donne lieu à un nombre plus restreint de vérifications. | ### Règles d’autorisation Si vous souhaitez créer des règles d’autorisation, [contactez-nous](https://support.stripe.com/contact). 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 litiges. - **Continuer à bloquer tout paiement à haut risque**. Bloquez les paiements à risque élevé en ajoutant les éléments suivants à toutes vos règles d’autorisation : `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](https://docs.stripe.com/radar/rules/reference.md#supported-attributes) 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 légitimes proviennent généralement (mais pas toujours) de clients du Royaume-Uni : | Règle d’origine | Règle améliorée | | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- | | `if :ip_country: = 'GB'` | `if :ip_country: = 'GB' and :risk_level: != 'highest'` | | Cette règle est trop générale et autorise certains paiements frauduleux. | Cette règle est plus ciblée et permet d’autoriser un plus petit nombre de paiements frauduleux. | ## Effectuer la maintenance de vos règles Au fur et à mesure que votre entreprise se développe, assurez-vous 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](https://dashboard.stripe.com/settings/radar/rules) 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. ![](https://b.stripecdn.com/docs-statics-srv/assets/rule-performance.8d495f28c352641ff7b710df3c3df2ed.png) Il est possible que vous repériez une différence entre le nombre de paiements qui correspondaient à vos règles de vérification et le nombre de paiements envoyés à votre file de vérification à la même période. Puisque seuls les paiements *réussis* sont placés pour vérification, les paiements qui correspondent aux critères d’une règle de vérification mais qui sont refusés par l’émetteur par exemple, ne sont pas envoyés à votre file de vérification. 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. Les **lignes à code couleur** permettent de suivre le nombre de paiements qui correspondent aux règles [3DS](https://docs.stripe.com/issuing/3d-secure.md), les autorisent , les bloquent et les vérifient. Les règles mises à jour sont affichées sous forme de **symboles triangulaires** sur les lignes du graphique, et peuvent vous aider à comparer l’impact d’un changement avant et après l’avoir effectué. Cliquez sur le menu déroulant⋯ pour voir les commandes supplémentaires pour toute règle, notamment **Désactiver**, **Activer**, **Modifier** ou **Supprimer**. Vous pouvez également utiliser nos produits de reporting, Sigma et Data Pipelines, pour [interroger les données sur les litiges et les fraudes](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md), y compris les décisions relatives aux règles et les attributs de chaque paiement. #### Évaluation de l’efficacité des règles Vous pouvez trouver des informations sur l’efficacité de vos règles et voir combien de paiements chaque règle a affecté. Vous pouvez également afficher et télécharger une liste filtrée de chaque paiement auquel une règle a été appliquée. Vérifiez les exemples de questions du tableau suivant pour vous aider à décider si vous devez apporter des modifications à des règles ou les supprimer entièrement. | Type de règle | Évaluation | Actions à envisager | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Générale | Si cette règle ne s’applique 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 | Si le taux d’exécution des authentifications 3DS est élevé, tandis que le nombre de litiges ou d’alertes de suspicion de fraude est faible. | Supprimez la règle, car vous risquez de créer des frictions pour vos 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 efficace, puisqu’elle bloque principalement les fraudeurs. 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 | Si le nombre de litiges, d’alertes de suspicion de fraude, de remboursements ou de paiements échoués est élevé. | Supprimez la règle qui autorise les paiements non valides. | | Blocage | Si 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. | | | Si le nombre de blocages augmente alors que votre taux de fraude diminue. | Cette règle peut être efficace. Veillez à vérifier manuellement quelques transactions pour vous assurer de ne pas bloquer 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. | | | Si e nombre de remboursements ou de litiges et d’alertes de suspicion de fraude est élevé. | Convertissez la règle en règle de blocage. | #### Règles d’exigence d’authentification 3DS Pour les règles d’exigence d’authentification 3DS, nous affichons **3DS Requested**, c’est-à-dire le nombre de fois qu’une règle a déclenché une exigence d’authentification 3DS. Vous pouvez cliquer sur une règle 3DS pour voir les mesures suivantes. ![](https://b.stripecdn.com/docs-statics-srv/assets/request-credentials-rule-details.c22b65bc432aafec9e5bcb6079c53528.png) **Règles d’autorisation** Si vous utilisez Radar for Fraud Teams, vous pouvez consulter les règles d’autorisation 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](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) correspondants attribués par les modèles d’IA 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. > Si les indicateurs de litiges sont élevés, vous pouvez envisager d’écrire des règles d’autorisation plus ciblées, afin d’éviter de laisser passer des paiements qui seront finalement contestés. Sélectionnez une règle d’autorisation pour afficher les mesures suivantes : ![](https://b.stripecdn.com/docs-statics-srv/assets/allow-rule-details.e8da078613fdbca5592d2f9330c0f6d4.png) **Règles de blocage** Vous pouvez afficher les règles de blocage 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. Si vous utilisez Radar for Fraud Teams, vous pouvez également consulter les règles suivantes : - **Score de risque** : [résultats de risque](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) correspondants attribués par les modèles d’IA 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’IA 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 calculés par IA, 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. > Si le taux estimé de faux positifs est élevé, vous pouvez envisager d’écrire des règles de blocage plus ciblées ou de revoir les paiements auxquels s’appliquent vos règles, afin d’éviter qu’elles ne bloquent un aussi grand nombre de paiements non frauduleux. Sélectionnez une règle de blocage pour afficher les mesures suivantes : ![](https://b.stripecdn.com/docs-statics-srv/assets/block-rule-details.5df9a2e8652f228cf61b525a32ef56da.png) **Règles de vérification** Si vous utilisez Radar for Fraud Teams, vous pouvez consulter les règles de vérification 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 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. Sélectionnez une règle de vérification pour afficher les mesures suivantes : ![](https://b.stripecdn.com/docs-statics-srv/assets/review-rule-details.10851302ef65dee05ffce64f7989528f.png) #### Afficher l’historique des règles Vous pouvez consulter l’historique des modifications apportées à vos règles Radar. Cette piste d’audit vous aide à comprendre quand une règle a été créée, modifiée, activée ou désactivée, et par quel utilisateur de votre équipe. Pour voir l’activité d’une règle spécifique, accédez à l’onglet [Règles](https://dashboard.stripe.com/radar/rules) de la page Radar et cliquez sur le nom de la règle. Le log **Activité de la règle** fournit un aperçu de toutes les modifications. Cliquez sur un événement particulier pour accéder à davantage de détails, notamment le prédicat complet de la règle avant et après la mise à jour. Seules les modifications des 180 derniers jours sont consultables. Examiner régulièrement cette activité peut vous aider à établir une corrélation entre les modifications apportées aux règles et leur impact sur votre entreprise. ### Contrôle régulier de votre file d’attente de vérifications manuelles Si votre file de vérification est trop longue pour être gérée, assurez-vous d’avoir mis en place les bonnes règles. Si la plupart des vérifications aboutissent à un remboursement pour cause de fraude, envisagez des règles supplémentaire pour bloquer les paiements. Si la plupart des paiements sont approuvés, envisagez de mieux cibler vos règles de vérification. ### Analyse des paiements contestés et remboursés Les [litiges](https://docs.stripe.com/disputes.md) 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](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md). Vous pouvez répondre à tout litige entrant en utilisant le Dashboard ou l’API. Par ailleurs, notre [documentation sur les litiges](https://docs.stripe.com/disputes.md) 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 vous aider à protéger votre entreprise contre la fraude. ## Les règles prennent en charge plusieurs moyens de paiement (New) Par défaut, les règles Radar contrôlent les paiements pour les cartes, les paiements ACH et les prélèvements automatiques SEPA pour la plupart des utilisateurs. Nous supportons la règle du bloc à haut risque pour tous ces moyens de paiement. Si vous utilisez Radar for Fraud Teams ou Radar pour les plateformes, nous supportons également les règles personnalisées avec l’attribut `:payment_method_type:` afin d’écrire des règles qui ne s’appliquent qu’à des moyens de paiement spécifiques, par exemple : `if :payment_method_type: = ’us_bank_account’`. En savoir plus sur les [attributs pris en charge](https://docs.stripe.com/radar/rules/supported-attributes.md). ## Élaborer des règles de compte Avec Radar pour les plateformes, vous pouvez également ajouter et gérer des règles de compte depuis l’onglet **Règles** de la page Radar du Dashboard. #### Pour ajouter une règle de compte 1. Cliquez sur **+ Ajouter une règle**. 1. Sélectionnez le type de règle : **Vérifier** ou **Suspension des virements** (qui déclenche une vérification ET une suspension des virements). 1. Dans l’éditeur de règles, créez une règle en utilisant la syntaxe `{action} if {attribute} {operator} {value}` selon laquelle : - `{action}`: représente 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}`: est l’élément du paiement à évaluer, comme le montant ou le type de carte bancaire. Commencez par saisir `:` pour ouvrir une liste d’attributs valides. - `{operator}`: représente comment comparer l’attribut à la valeur, par exemple `=`, `>`, `!=`, etc. - `{value}`: est la valeur de l’attribut à évaluer. 1. Cliquez sur **Tester la règle**. 1. Corrigez les erreurs de validation détectées, le cas échéant. 1. Sur la page **Vérifier une nouvelle règle**, affichez les comptes qui correspondraient aujourd’hui à cette règle pour confirmer si vous souhaitez l’activer. 1. Cliquez sur **Activer la règle** pour appliquer cette règle à tous les comptes existants et futurs. Le test des règles au niveau des comptes prend plus de temps que le test des transactions, cependant nous vous recommandons de les tester pour éviter de soumettre involontairement des comptes à un contrôle ou de suspendre les virements automatiques. Tout d’abord, tentez de soumettre les comptes à un contrôle de comportement. Ensuite, testez la suspension des virements automatiques une fois que vous êtes certain que la règle affecte les comptes comme prévu. ## See also - [Exemples de règles 3DS](https://docs.stripe.com/radar/rules.md#request-3d-secure) - [Guide de gestion de la fraude continue](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) - [Interroger des données sur les litiges et la fraude](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md) - [Documentation sur les règles](https://docs.stripe.com/radar/rules/reference.md) - [Attributs pris en charge](https://docs.stripe.com/radar/rules/supported-attributes.md)