Règles de protection contre la fraude

Fraud prevention rules allow you to take action whenever a payment matches certain criteria. Stripe Radar provides built-in rules to help detect and protect you against fraud risk on card, ACH, and SEPA Direct Debit payments.

Radar for Fraud Teams and Radar for Platforms let you use the Dashboard to create custom rules based on the business logic specific to your business. For example, you can:

• 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
• Review all payments greater than 1,000 USD that were made with a prepaid card
• Review and automatically pause payouts on accounts that have a high dispute rate (with Radar for Platforms)

Règles intégrées

The following rules are available by default, unless flagged as custom rules, which are only available if you use Radar for Fraud Teams or Radar for Platforms.

Vérifications des risques par l’IA

All Radar offerings provide a set of default rules based on the judgments of our AI models.

Radar for Platforms has additional account-level AI models that are incorporated through two default rules:

Vérification si :account_risk_level : = 'highest'

Vérification si :account_risk_level : = 'elevated'

We calculate account-level risk using KYC information, transactions, geographic signals, and behavior patterns.

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

3D Secure (3DS) prompts customers to complete an additional authentication step before they can complete the purchase flow. If 3DS authenticates a payment, the liability for any fraud-related disputes for that payment typically shifts from the seller to the issuer. This means that in most cases, the seller isn’t responsible for fraud costs on 3DS authenticated payments.

Stripe automatically handles soft decline codes indicating that 3DS is required by issuers. We also trigger 3DS when necessary, adhering to regulations, such as the Strong Customer Authentication (SCA) mandated by the PSD2. Disabling Radar doesn’t prevent 3DS from being triggered in cases where it’s necessary.

Stripe supports three legacy built-in rules to request 3DS when using Radar with Payment Intents or SetupIntents:

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.

Requesting 3DS doesn’t necessarily mean the issuer actually performs 3DS. Learn more about possible outcomes.

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 ou Radar pour les plateformes, vous pouvez évaluer le résultat dans les règles d’autorisation, de blocage et de vérification.

See below for the most important attributes for custom Radar rules.

For custom rules, we recommend keeping Request 3DS and Block rules aligned depending on your risk appetite. However, don’t block payments where 3DS isn’t supported, such as from some wallets.

See below for some examples that show how to achieve this for different use cases.

Exiger 3D Secure en fonction du niveau de risque Radar

You want to use Radar to request 3DS on all payments, based on the risk level and that are above a certain amount.

In this case, without a block rule, cards or wallets that don’t support 3DS aren’t blocked. 3DS attempts that failed authentication don’t continue to charge authorization.

Toujours exiger 3D Secure en fonction du niveau de risque Radar

You want to use Radar to request 3DS on all payments, based on an elevated or high risk level and that are above a certain amount. You don’t want to support cards that don’t support 3DS.

Only accept fully 3D Secure authenticated payments if 3D Secure is supported

You rely on Stripe activating 3DS when necessary in cases such as Strong Customer Authentication (SCA), but don’t want to accept edge cases, such as processing errors.

Request 3D Secure based on metadata

You want to use Radar to request 3DS on all payments with a custom metadata attribute.

In this case, without a block rule, we don’t block cards or wallets that don’t support 3DS. 3DS attempts that failed authentication don’t continue to charge authorization.

Always require 3D Secure based on metadata

You want to use Radar to request 3DS on all payments with a custom metadata attribute and block cards that don’t support it.

Exiger 3D Secure pour toutes les nouvelles cartes et vérifier si 3D Secure n’est pas pris en charge

You want to use Radar to request 3DS on all new cards and manually review payments from cards that don’t support 3DS.

In this case, without a block rule, we don’t block cards or wallets that don’t support 3DS. 3DS attempts that failed authentication don’t continue to charge authorization.

Toujours exiger 3D Secure pour les émetteurs de certains pays

You want to use Radar to request 3DS on all payments from card issuers originating from countries on a custom list and block the cards that don’t support it.

Toujours exiger 3D Secure en fonction du niveau de risque Radar et passer en revue les cas particuliers

You want to use Radar to request 3DS on all payments based on the risk level, and block cards that don’t support 3DS, but manually review edge cases.

Create rules

The Stripe default rules can block a substantial number of fraudulent payments. Businesses that need more control over which payments they want to review, allow, or block can write custom rules through Radar for Fraud Teams. Platforms can write custom rules through Radar for Platforms to calibrate payments risk for their platform and connected accounts and apply account-specific rules.

Tenez compte des questions suivantes lorsque vous décidez d’activer ou non les règles personnalisées :

• If you see certain features or user behaviors as more risky (for example, using a disposable email).
• If you want to implement rules based on the payment method (for example, automatically blocking SEPA Direct Debit payments that exceed a certain risk score).
• If you want to implement rules based on payment amounts or perceived risk level (for example, automatically review if the payment is over 500 USD, automatically allow if the payment is under 5 USD).
• If your existing disputed and refunded payments share any common patterns (for example, similar amounts, card types, or countries).
• If you have existing rules you want to migrate to Stripe. The Stripe AI model might already cover many of these rules, and you can check how our system performs for your business before customizing it.
• If you want to automatically raise reviews and optionally pause payouts on accounts. This applies to platforms only.

Create effective rules

While rules can help you automate your existing workflows, they can also negatively affect your business if used incorrectly. For example, a rule can automatically allow a large number of elevated or high-risk payments or block a large number of legitimate payments, if it isn’t set up properly.

Remember the following when setting up rules:

• 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.
• Rules only apply to future payments and don’t apply to any that you already processed.
• 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.
• Before implementing any block rule to block all payments or pause payouts for accounts that meet its criteria, consider whether you’d rather review the payments or accounts first.
• Implement any allow rules minimally, because they override the Stripe default rules, along with any other custom rules that match the same criteria.
• Vous pouvez créer un maximum de 200 règles de transaction et 100 règles de compte.

Élaborer des règles de transaction

You can add and manage rules from the Radar Rules page in the Dashboard.

To add a transaction rule

1. Cliquez sur + Ajouter une règle.
2. Select the rule type.
3. Dans l’éditeur de règles, créez une règle en utilisant la syntaxe {action} if {attribute} {operator} {value} selon laquelle :
   • {action}: is how Radar responds when the rule criteria is met. This value is pre-populated based on the rule type you selected.
   • {attribute}: is the element of the payment to evaluate, such as the amount or card type. Begin typing with : to open a list of valid attributes. You can also evaluate your custom metadata by enclosing it in double colons, for example, ::product_sku::.
   • {operator}: is how to compare the attribute to the value, such as =, >, !=, and so on.
   • {value}: is the value of the attribute to evaluate.
4. Cliquez sur Tester la règle.
5. Corrigez les erreurs de validation détectées, le cas échéant.
6. On the Review new rule page, review how this rule performs against your recent payments to confirm whether you want to enable it. If the rule might impact payments from more than one payment method, use the filter to view rule performance by payment method (for example, ACH or Cards).
7. Click Add rule to apply this rule to all future transactions.

Utiliser l’assistant Radar

The Stripe rule editor has a built-in LLM assistant that constructs a Radar transaction rule from a natural language prompt. Learn more about Stripe AI services.

To use Radar Assistant

1. On the Radar Rules page, click + Add rule.
2. Select the rule type.
3. Dans l’éditeur de règles, cliquez sur Assistant Radar.
4. In the message field, enter your rule request. You might ask to:
   • 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.
5. When the Assistant returns its suggestion, you can either enter an additional command to make adjustments to the rule, or you can click Test rule to see how the rule performs against your recent transaction history.
6. When you’re satisfied with the rule, click Add rule to enable it for all future transactions.

Règles de vérification

Stripe still processes payments normally when they match a review rule’s criteria. We add these payments to your review queue so your team can review them more closely. Setting up a rule that’s too broad can result in too many payments placed in your review queue, slowing down your customers and burdening your review team.

The Stripe rule testing interface runs a simulation on the last 6 months of charges to determine how many legitimate, fraudulent, and blocked payments would have been affected by the rule, had it been implemented. While testing a rule and examining the last 6 months, make sure that:

• Overall volume of payments is low. Reviewing these payments shouldn’t create a burden for your team.
• Human reviewers add value. A human reviewer can generally identify an elevated or high-risk payment with greater confidence than the automated system.
• The rule results in a mix of successful and refunded or disputed payments. This means that additional inspection on these types of payments can help separate legitimate payments from fraudulent payments.

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ègles de blocage

You can use block rules to block payments that you’re confident are fraudulent, or based on any restrictions your business has in place (such as blocking payments from prepaid cards). If you’re not sure how to apply block rules, we recommend using a review rule to place payments in review. After reviewing these payments for potential false positives, you can confirm whether you want to create a block rule instead.

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.
• Minimize unnecessary rules. If your rule appears to perform well but is already covered by an existing rule, your newer rule might not be necessary. Similarly, if the results during testing appear to be mixed, consider setting up a review rule instead so you can gather more information about those types of payments.

The following is an example of how to improve a block rule created by a business that has a high level fraud from payments outside the US.

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 à :

• Examine the number of previously blocked payments that would have been allowed. Allow rules override all other rules and Stripe’s risk assessment. When testing a new allow rule, all payments shown would have been allowed if this rule were active. This can include payments that had been blocked or disputed, impacting your future dispute rates.
• Continue to block any high-risk payments. Block high-risk payments 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 ».

The following is an example of how to improve an allow rule for a business that generally (but not always) sees legitimate payments coming from customers in the UK:

Maintain your rules

As your business continues to grow, make sure your rules continue to reflect the types of customers that you want to do business with. The following are some best practices to keep rules current for the state of your business.

Regularly monitor rules to make sure they’re still effective

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.

Use the rule performance chart to understand the behavior of your Radar rules. Look for unexpected spikes or declines in the number of payments matching your rules, such as allow rules letting through too many payments or block rules blocking too many. These spikes might indicate a change in the types of payments your business receives or that might necessitate updates to the rules.

Color-coded lines track the number of payments that match 3DS rules, allow rules, block rules, and review rules. Updated rules are displayed as triangular symbols on the graph lines, and can help you compare the impact of a change before and after you make it.

Click the overflow menu () to view additional commands for any rule, including Disable, Enable, Edit or Delete.

You can also use our reporting products, Sigma and Data Pipelines, to query disputes and fraud data, including rule decisions and attributes for each individual payment.

Évaluation de l’efficacité des règles

You can find information about the effectiveness of your rules and see how many payments each rule has affected. You can also view and download a filtered list of every payment that a rule has been applied to.

Review the sample questions in the following table to help you decide if you need to make changes to any rules or remove them entirely.

Request 3DS rules

For request 3DS rules, we display 3DS Requested, which is the number of times a rule triggered a 3DS request. You can click a 3DS rule to see the following metrics.

Règles d’autorisation

If you use Radar for Fraud Teams, you can view the following allow rules:

• Allowed payments: The total number of payments allowed by your rules.
• Volume, allowed payments: The total amount, in your local currency, associated with payments allowed by your rules.
• Risk score: The corresponding risk outcomes assigned by our AI models to the set of payments allowed by your rules.
• Disputes from overrides: The total number of allowed payments that were disputed.
• Volume, disputes from overrides: The total amount, in your local currency, associated with disputes from allowed payments.

Select an allow rule to see the following metrics:

Règles de blocage

You can view the following block rules:

• Blocked payments: The total number of payments blocked by your rules.
• Volume, blocked payments: The total amount, in your local currency, associated with payments blocked by your rules.

If you use Radar for Fraud Teams, you can also view the following:

• Risk score: The corresponding risk outcomes assigned by our AI models to the set of payments allowed by your rules.
• Est. false positive rate: The estimated percentage of non-fraudulent payments that were blocked for both your block rules as a set and by individual rules. These estimates are made using the estimated false positive rates of the corresponding AI risk scores, which we calculate with experiments across the Stripe network.
• Est. fraudulent payments prevented: The estimated number of fraudulent payments that your block rules prevented. Stripe uses AI risk scores, calculated by analyzing millions of transactions across the Stripe network, to predict payments with a high probability of being disputed or declined because of fraud, and estimate which of those payments were successfully blocked by your rules.

Select a block rule to see the following metrics:

Règles de vérification

If you use Radar for Fraud Teams, you can view the following review rules:

• Payments sent to review: The total number of payments sent to manual review by your rules.
• Volume, approved reviews: The total amount, in your local currency, associated with approved payment reviews.
• Refund rate: The percentage of reviews that were refunded.
• Disputes from approved reviews: The total number of payments approved in your review, but were ultimately disputed.
• Volume, disputes from approved reviews: The total amount, in your local currency, associated with disputes from approved payment reviews.

Select a review rule to see the following metrics:

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.

To see the activity for a specific rule, go to the Rules tab on the Radar page and click the name of the rule.

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.

Regularly monitor your manual review queue

If your review queue is too large to manage, make sure you have the correct rules in place. If most reviews result in a refund because of fraud, consider additional rules to block payments. If most payments are approved, consider making your review rules more focused.

Analyse des paiements contestés et remboursés

Disputes are inherently linked to fraud, so the more you do to reduce fraud, the lower your dispute rate. Check to see if disputed payments share any similar characteristics (for example, from the same locations or of similar amounts). You can also perform this type of investigation by looking at payments that were refunded during a review. If you see trends, you can test and create the appropriate rules. If any payments appear to be fraudulent, refund and report them as fraud to avoid potential disputes.

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

Anticipate large changes to your business that might impact your fraud rate

If you’re planning any major product releases or changes to your service (for example, a new, high-value product or expanding your service into new countries), you might want to monitor these payments in the beginning. For these kinds of changes, it’s a good practice to set up some review rules so you can examine any new payments. Reviewing these payments and identifying patterns can help you set up new rules to help protect your business from fraud.

Les règles prennent en charge plusieurs moyens de paiement New

By default, Radar rules screen payments for cards, ACH, and SEPA Direct Debits for most users. We support the high risk block rule for all of these payment methods. If you use Radar for Fraud Teams or Radar for Platforms, we also support custom rules using the :payment_method_type: attribute to write rules that apply only to specific payment methods, for example: Block if :payment_method_type: = 'us_bank_account'. Learn more about supported attributes.

Élaborer des règles de compte

With Radar for Platforms, you can also add and manage account rules from the Rules tab on the Radar page in the Dashboard.

To add an account rule

1. Cliquez sur + Ajouter une règle.
2. Select the rule type: Review or Payout pause (which raises a review AND payout pause).
3. Dans l’éditeur de règles, créez une règle en utilisant la syntaxe {action} if {attribute} {operator} {value} selon laquelle :
   • {action}: is how Radar responds when the rule criteria is met. This value is pre-populated based on the rule type you selected.
   • {attribute}: is the element of the payment to evaluate, such as the amount or card type. Begin typing with : to open a list of valid attributes.
   • {operator}: is how to compare the attribute to the value, such as =, >, !=, and so on.
   • {value}: is the value of the attribute to evaluate.
4. Cliquez sur Tester la règle.
5. Corrigez les erreurs de validation détectées, le cas échéant.
6. On the Review new rule page, view the accounts that would match this rule today to confirm whether you want to enable it.
7. Click Activate rule to apply this rule to all existing and future accounts.

Testing account-level rules takes longer than transaction testing, however we recommend testing to avoid unintentionally raising accounts for review or pausing automatic payouts. First, test raising accounts for review behavior. Then, test automatic payout pauses after you’re confident the rule impacts accounts as expected.