Stripe Radar et les faux positifs : pourquoi vos paiements légitimes sont bloqués et comment y remédier

Certains liens de cet article sont des liens affiliés. Nous pouvons percevoir une commission si vous vous inscrivez à Whop via nos liens, sans frais supplémentaires pour vous. Lire notre déclaration d'affiliation.

Vous lancez une formation, organisez une vente flash ou ouvrez les inscriptions à un programme de coaching. Les paiements commencent à arriver. Puis vous consultez Stripe et remarquez quelque chose d'étrange : quelques acheteurs légitimes n'ont jamais réussi à finaliser leur achat. Stripe Radar a signalé leurs transactions comme frauduleuses et les a bloquées sans bruit. Le client a vu un message générique "carte refusée", a supposé que le problème venait de sa banque et est parti. Vous n'avez jamais su qu'il avait essayé de payer. C'est le problème des faux positifs, et pour les créateurs qui vendent des produits numériques, il est bien plus répandu qu'on ne le croit.

Stripe Radar est un système de prévention de la fraude basé sur l'apprentissage automatique qui analyse chaque transaction traitée via Stripe. Il est efficace pour détecter les fraudes réelles. Il est aussi, dans certains secteurs, trop agressif avec les transactions légitimes. Si vous vendez des formations, du coaching, des communautés payantes ou des infoproduits, vos habitudes d'achat paraissent suspectes à un algorithme entraîné principalement sur des données e-commerce classiques. Prix élevés, achats uniques de nouveaux clients, acheteurs internationaux avec des types de cartes peu courants : tout cela est normal pour votre activité, mais anormal pour le modèle de référence de Radar.

Ce guide explique comment diagnostiquer votre taux de faux positifs, comprendre pourquoi les créateurs sont touchés de façon disproportionnée et mettre en place des correctifs concrets pour cesser de perdre du chiffre d'affaires à cause de la prudence excessive de Radar.

Comment fonctionne Stripe Radar

Stripe Radar est une couche de détection de la fraude qui s'intercale entre l'action de paiement du client et le traitement effectif de la transaction. Chaque transaction passe par le modèle d'apprentissage automatique de Radar, qui lui attribue un score de risque compris entre 0 et 100. Plus le score est élevé, plus Radar considère la transaction comme frauduleuse.

Le modèle de Radar est entraîné sur les données de millions d'entreprises utilisant le réseau Stripe. Il évalue des signaux tels que :

• Empreinte de carte : cette carte a-t-elle été utilisée pour de la fraude chez d'autres marchands Stripe ?
• Géolocalisation IP : la localisation IP de l'acheteur correspond-elle au pays d'émission de la carte ?
• Empreinte d'appareil : l'acheteur utilise-t-il un appareil connu ou une configuration de navigateur suspecte ?
• Vélocité : combien de transactions cette carte ou cette adresse e-mail a-t-elle tentées sur une courte période ?
• Analyse de l'adresse e-mail : l'adresse e-mail est-elle jetable, récemment créée ou associée à des fraudes passées ?
• Signaux comportementaux : à quelle vitesse l'acheteur a-t-il finalisé le checkout ? A-t-il copié-collé le numéro de carte (fréquent avec les cartes volées) ?

Par défaut, Radar bloque les transactions dont le score de risque dépasse 75. Les transactions dont le score est compris entre environ 50 et 75 peuvent être placées dans une file de révision (si vous avez activé Radar for Fraud Teams) ou autorisées avec un marqueur d'avertissement. Les transactions en dessous de 50 passent normalement.

Le système fonctionne bien pour le e-commerce classique : biens physiques, prix modérés, clients récurrents, livraison domestique. Il fonctionne moins bien pour les habitudes d'achat propres aux activités de créateurs.

Pourquoi les créateurs génèrent plus de faux positifs que les vendeurs e-commerce

Les données d'entraînement de Stripe Radar sont orientées vers les schémas du e-commerce traditionnel. Lorsque votre activité s'écarte de ces schémas, le modèle interprète cet écart comme un signal de risque, même si la transaction est parfaitement légitime. Voici pourquoi les créateurs sont touchés de façon disproportionnée.

Prix élevés

Un programme de coaching à 2 000 € ou une formation à 997 € déclenche les signaux "montant inhabituellement élevé" de Radar. Pour un e-commerce classique, une transaction unique à 2 000 € est rare et suspecte. Pour un créateur qui vend un programme de coaching premium, c'est le tarif standard. Radar ne fait pas la différence à moins que vous ne le lui indiquiez.

Achats uniques de nouveaux clients

Les boutiques e-commerce constituent un historique d'acheteurs récurrents. Radar s'appuie sur cet historique pour établir la confiance. Quand un nouveau client achète une formation à 500 € chez vous, Radar n'a aucune donnée relationnelle antérieure sur laquelle s'appuyer. Chaque signal est évalué sans historique, ce qui pousse le score de risque à la hausse. Les créateurs qui lancent des offres (où la majorité des acheteurs sont nouveaux) subissent cet effet de manière amplifiée.

Acheteurs internationaux

Si vous commercialisez à l'international (et la plupart des créateurs de produits numériques le font), une part significative de vos acheteurs présentera des incohérences entre le pays d'émission de leur carte et leur localisation IP. Un acheteur en Thaïlande utilisant une carte émise aux États-Unis, ou un acheteur européen qui utilise un VPN, déclenche simultanément plusieurs signaux de risque. Pour une boutique e-commerce à livraison domestique, ce schéma serait inhabituel. Pour votre formation en ligne, c'est un mardi ordinaire.

Pics de volume lors des lancements

Stripe Radar prend en compte votre volume habituel de transactions. Si vous traitez normalement 20 transactions par semaine et que vous en traitez 200 en une seule journée lors d'un lancement, ce pic soudain devient lui-même un signal de risque. L'algorithme interprète les pics de volume comme d'éventuelles attaques de test de cartes, où des fraudeurs font passer des lots de cartes volées chez un marchand. Votre lancement ressemble exactement à une attaque de test de cartes pour un algorithme qui ne peut pas distinguer les intentions.

Le vrai coût des faux refus

Les faux positifs sont des pertes invisibles. Contrairement aux litiges (qui apparaissent dans votre tableau de bord avec des montants en euros), les faux refus surviennent en silence. Le client est repoussé. Vous ne voyez jamais la tentative de paiement. Aucune notification, aucune entrée de journal que vous consulteriez naturellement.

Les effets indirects s'accumulent au-delà de la vente immédiatement perdue :

• Frustration client : un acheteur légitime refusé retente rarement sa chance. Il suppose que le problème vient de sa carte ou de votre site, et passe à autre chose. Certains contactent le support, ce qui vous coûte du temps. La grande majorité part simplement.
• Abandon de panier : les faux refus pendant une fenêtre de lancement sont particulièrement dommageables, car l'intention d'achat de l'acheteur est limitée dans le temps. S'il ne peut pas payer maintenant, il ne reviendra pas deux jours plus tard quand la fenêtre sera fermée.
• Atteinte à la réputation : dans les petites communautés de créateurs, un acheteur refusé peut en parler publiquement. "J'ai essayé d'acheter mais le paiement ne passait pas" érode la confiance dans votre processus de paiement.
• Analytics faussées : si vous optimisez votre tunnel de vente sur la base des taux de conversion, les faux refus biaisent les données. Vous pourriez conclure que votre page de vente est sous-performante alors que le problème réel se situe au niveau du traitement des paiements.

La relation entre prévention de la fraude et faux refus fonctionne comme une balance. Des règles Radar plus strictes détectent davantage de fraudes, mais bloquent aussi plus de transactions légitimes. Des règles plus souples laissent passer davantage de fraudes. L'objectif est le calibrage, pas la maximisation d'un extrême ou de l'autre. Pour les créateurs, le calibrage par défaut est presque toujours trop agressif.

Comment vérifier votre taux de faux positifs Radar

Stripe n'identifie pas directement les faux positifs (cela nécessiterait de savoir quelles transactions bloquées étaient légitimes, ce que Stripe ne peut pas déterminer après coup). Mais vous pouvez approximer votre taux de faux positifs grâce au taux de blocage.

Dans votre tableau de bord Stripe :

1. Accédez à Paiements.
2. Cliquez sur Analytics (ou Radar dans les versions récentes du tableau de bord).
3. Consultez le taux de blocage : le pourcentage de transactions tentées que Radar a bloquées.
4. Filtrez les paiements bloqués par statut pour examiner les transactions individuelles bloquées, y compris le score de risque et la règle qui a déclenché le blocage.

Pour la plupart des entreprises e-commerce, un taux de blocage entre 0,5 % et 2 % est normal. Pour les activités de créateurs, des taux entre 3 % et 8 % sont courants en raison des facteurs décrits ci-dessus. Si votre taux de blocage dépasse 5 %, examinez manuellement les transactions bloquées. Vous y trouverez très probablement un nombre significatif d'acheteurs légitimes.

Consultez également votre file de révision si vous utilisez Radar for Fraud Teams. Les transactions en attente de révision que vous approuvez systématiquement sont un autre indicateur que les seuils de Radar sont trop restrictifs pour votre modèle d'activité. Si vous approuvez plus de 80 % des transactions en file de révision, vos règles de révision se déclenchent trop largement.

Si vous constatez que les faux refus coïncident avec des problèmes plus larges sur votre compte (retenues, réserves ou contrôles de conformité), notre guide sur la classification des activités à haut risque chez Stripe explique comment Stripe catégorise les entreprises et ce qui déclenche un examen approfondi.

Comprendre les règles Radar : défauts vs. personnalisées

Stripe Radar fonctionne sur deux niveaux de règles : les règles par défaut que Stripe applique automatiquement, et les règles personnalisées que vous rédigez vous-même.

Règles par défaut

Les règles par défaut de Stripe ne sont pas documentées dans leur intégralité, mais la principale est la suivante : bloquer les transactions dont le score de risque Radar dépasse 75. Ce seuil s'applique à tous les comptes Stripe sauf si vous le remplacez. Les comportements par défaut supplémentaires comprennent le blocage des cartes signalées pour fraude sur le réseau Stripe et le blocage des transactions en provenance de pays sous sanctions.

Règles personnalisées

Les règles personnalisées vous permettent de remplacer, compléter ou affiner les valeurs par défaut de Radar. Vous rédigez des règles en utilisant la syntaxe de règles Stripe, qui évalue les attributs de la transaction. Les règles peuvent produire trois actions : Bloquer (refuser la transaction), Réviser (mettre en attente pour validation manuelle) ou Autoriser (contourner entièrement le score de risque).

Exemples de règles personnalisées utiles pour les créateurs :

• :risk_score: < 65 AND :card_country: = 'US' avec action Autoriser : laisse passer les transactions domestiques à risque modéré sans les bloquer.
• :is_recurring: avec action Autoriser : autorise les prélèvements d'abonnement récurrents de clients précédemment approuvés, en contournant les vérifications de risque lors des renouvellements.
• :risk_score: > 50 AND :risk_score: < 75 avec action Réviser : envoie les transactions limites dans votre file de révision plutôt que de les bloquer, vous donnant la possibilité d'approuver manuellement les paiements légitimes.

Les règles personnalisées nécessitent Radar for Fraud Teams (0,07 $ par transaction analysée) pour bénéficier de toutes les fonctionnalités. La formule Radar gratuite prend en charge des règles personnalisées basiques, mais n'inclut pas les files de révision ni les attributs avancés.

5 étapes concrètes pour réduire les faux positifs

1. Créez des listes d'autorisation pour vos acheteurs réguliers

Dans les paramètres Radar, vous pouvez ajouter des adresses e-mail, des empreintes de carte ou des adresses IP à une liste d'autorisation. Les clients figurant sur la liste d'autorisation contournent entièrement le score de risque de Radar lors de leurs futurs achats. Pour les créateurs ayant un modèle d'abonnement ou de communauté, c'est le changement à l'impact le plus élevé : vos membres existants ne devraient jamais être bloqués lors d'un renouvellement ou d'un achat complémentaire.

Si vous utilisez Radar for Fraud Teams, vous pouvez automatiser cela avec une règle : :customer_purchases: > 1 avec action Autoriser. Cela fait automatiquement confiance à tout client de retour.

2. Ajustez votre seuil de blocage par défaut

Radar bloque par défaut à un score de risque de 75. Pour les activités de créateurs, relever ce seuil à 80 ou 85 (via une règle personnalisée qui autorise les transactions dont le score est inférieur à votre nouveau seuil) réduit significativement les faux positifs. Vous acceptez un risque légèrement plus élevé, mais pour la plupart des activités de produits numériques, la fraude supplémentaire est bien inférieure au chiffre d'affaires légitime récupéré.

Alternativement, remplacez l'action par défaut de Bloquer par Réviser pour les scores compris entre 65 et 85. Cela maintient le filet de sécurité (vous voyez toujours les transactions signalées) tout en offrant aux acheteurs légitimes une possibilité de finaliser leur achat via une validation manuelle.

3. Routez les transactions à risque moyen vers le 3D Secure

Plutôt que de bloquer les transactions avec des scores de risque modérés, routez-les vers l'authentification 3D Secure (3DS). Créez une règle Radar : si le score de risque est compris entre 40 et 65, demandez le 3D Secure. Le client bénéficie d'une étape de vérification (généralement une confirmation via l'application bancaire ou un code SMS) plutôt qu'un refus. S'il s'authentifie avec succès, la transaction est traitée et vous bénéficiez d'un transfert de responsabilité de la banque émettrice.

Cette approche est particulièrement efficace pour les achats haut de gamme de nouveaux clients internationaux, exactement le scénario où les faux positifs de Radar sont les plus fréquents pour les créateurs. Le client peut prouver son identité sans être repoussé. Pour en savoir plus sur l'utilisation stratégique du 3DS en parallèle avec la prévention des litiges, consultez notre guide sur la prévention des chargebacks.

4. Enrichissez les métadonnées des transactions

La précision de Radar s'améliore quand il dispose de davantage d'informations sur la transaction. Transmettez des métadonnées supplémentaires avec chaque intention de paiement :

• Nom et adresse e-mail du client (via l'objet Customer, pas uniquement le paiement)
• Type de produit (formation, coaching, communauté) via les champs de métadonnées
• Ancienneté du compte client sur votre plateforme
• Historique d'achats précédents si vous le suivez

Quand Radar peut voir qu'un acheteur possède un compte sur votre plateforme créé il y a 30 jours et s'est connecté 12 fois, le score de risque baisse par rapport à une transaction par carte anonyme, sans aucun contexte rattaché. Utilisez le champ payment_intent.metadata pour transmettre ces informations.

5. Examinez les paiements bloqués chaque semaine

Programmez un rappel dans votre calendrier pour examiner les transactions bloquées chaque semaine. Dans le tableau de bord Stripe, filtrez les paiements par statut "Bloqué" et examinez chacun. Cherchez des récurrences :

• Les blocages sont-ils concentrés sur des pays spécifiques vers lesquels vous vendez régulièrement ?
• Les blocages touchent-ils un produit ou un niveau de prix particulier ?
• Les blocages s'intensifient-ils pendant les lancements ?

Chaque récurrence identifiée est une règle personnalisée en attente d'être rédigée. Si vous constatez 15 transactions bloquées depuis le Royaume-Uni en une semaine et que vous vendez régulièrement à des clients britanniques, c'est un signal clair pour créer une règle d'autorisation pour les cartes britanniques en dessous d'un certain seuil de risque.

Quand passer à Radar for Fraud Teams

Radar for Fraud Teams coûte 0,07 $ par transaction analysée. Pour 1 000 transactions par mois, cela représente 70 $. Pour 10 000 transactions, 700 $. La question est de savoir si les fonctionnalités supplémentaires justifient ce coût.

Radar for Fraud Teams ajoute :

• Files de révision manuelle : les transactions signalées sont envoyées dans une file où vous (ou votre équipe) les approuvez ou les refusez individuellement. Sans Fraud Teams, les seules options sont Bloquer ou Autoriser. Avec Fraud Teams, vous disposez d'une troisième option : Réviser.
• Attributs de règles avancés : accès à la valeur vie client, au nombre total d'achats, au temps depuis le premier achat et à d'autres attributs comportementaux dans vos règles personnalisées.
• Listes d'autorisation et de blocage : listes granulaires pour les e-mails, empreintes de carte, adresses IP et BIN de carte.
• Analyses de risque : détail précis des raisons pour lesquelles une transaction spécifique a reçu son score de risque.

Pour les créateurs traitant moins de 500 transactions par mois avec un taux de blocage inférieur à 3 %, la formule Radar gratuite est généralement suffisante. Dès que vous dépassez 500 transactions mensuelles ou que votre taux de blocage franchit les 5 %, la file de révision manuelle à elle seule vaut les 0,07 $ par transaction. Pouvoir réviser et approuver les transactions limites plutôt que de les bloquer automatiquement récupère un chiffre d'affaires qui couvre largement ce coût.

Quand Radar ne suffit pas : l'approche plateforme

Ajuster les règles Radar, maintenir les listes d'autorisation, examiner les paiements bloqués chaque semaine, enrichir les métadonnées et surveiller votre taux de blocage : tout cela représente un travail opérationnel continu. Pour les créateurs solo ou les petites équipes, cette maintenance entre directement en concurrence avec le temps consacré au développement produit, au marketing et au support client.

Les plateformes Merchant of Record (vendeur officiel, MoR) adoptent une approche fondamentalement différente. Au lieu de vous fournir une boîte à outils de prévention de la fraude en vous demandant de la configurer, elles gèrent le filtrage anti-fraude au niveau de la plateforme. Vous vendez via leur infrastructure, et la prévention de la fraude est leur problème, pas le vôtre.

Whop opère en tant que Merchant of Record pour les produits numériques, formations, communautés et programmes de coaching. Le filtrage anti-fraude se fait automatiquement au niveau de la plateforme, ce qui signifie que vous ne gérez pas vous-même les règles Radar, les files de révision ou les journaux de paiements bloqués. Le modèle de la plateforme est entraîné spécifiquement sur les transactions de l'économie des créateurs (et non sur le e-commerce général), de sorte que le taux de faux positifs pour le coaching, les formations et les communautés est structurellement plus bas que ce que vous obtiendriez en ajustant vous-même Stripe Radar.

• Seulement 2,7 % + 0,30 $ par transaction. Sans abonnement. Sans frais cachés.
• Whop gère et conteste automatiquement les litiges à votre place.
• Whop aide à se protéger des retenues et fermetures de compte, car les contrôles de conformité se déclenchent à des paliers de revenus prévisibles.
• Iman Gadzhi a réalisé plus de 25 M$ sur Whop. TJR génère 1 M$/mois. Airrack atteint 250 K$/mois.

La décision n'est pas de savoir si Stripe Radar est mauvais (il ne l'est pas ; c'est un solide système de prévention de la fraude). La décision porte sur la question de savoir si le réglage manuel d'un modèle anti-fraude généraliste est la meilleure utilisation de votre temps par rapport à l'utilisation d'une plateforme conçue spécifiquement pour votre type d'activité. Si vous avez subi des sanctions sur votre compte en parallèle de problèmes de faux positifs, notre guide sur les fermetures de compte Stripe explique ce qui se passe quand les signaux Radar s'accumulent jusqu'à devenir un risque global pour le compte.

Ce qu'il faut retenir

Les faux positifs de Stripe Radar ne sont pas un bug. Ils sont le résultat de l'application d'un modèle anti-fraude généraliste à des habitudes d'achat non standards. Les activités de créateurs (formations, coaching, communautés payantes, infoproduits) génèrent plus de faux positifs parce que leurs transactions paraissent suspectes à un algorithme calibré sur des données e-commerce : prix élevés, nouveaux clients, acheteurs internationaux, pics de volume lors des lancements.

La solution est le calibrage, pas l'abandon. Commencez par vérifier votre taux de blocage dans le tableau de bord Stripe. Examinez les paiements bloqués pour identifier des récurrences. Créez des listes d'autorisation pour vos clients réguliers. Relevez votre seuil de blocage. Routez les transactions à risque moyen vers le 3D Secure plutôt que de les bloquer. Enrichissez vos métadonnées de paiement. Examinez les paiements bloqués chaque semaine.

Si la charge opérationnelle liée à la maintenance de ces ajustements dépasse la valeur de votre temps, envisagez une plateforme Merchant of Record comme Whop qui gère la prévention de la fraude au niveau de la plateforme. Les deux options fonctionnent. Le mauvais choix est d'ignorer le problème entièrement et de perdre 5 à 10 % de votre chiffre d'affaires à cause d'un algorithme qui ne comprend pas votre activité.

Questions fréquentes

Quel est un bon taux de faux positifs pour Stripe Radar ?

La plupart des processeurs de paiement considèrent qu'un taux de faux positifs inférieur à 2 % est acceptable pour le e-commerce en général. Pour les créateurs de produits numériques (formations, coaching, communautés), des taux entre 3 et 8 % sont courants, car les habitudes d'achat déclenchent naturellement des signaux de fraude. Si votre taux de blocage dépasse 5 %, vous perdez très probablement du chiffre d'affaires légitime et devriez revoir vos règles Radar. Consultez votre taux de blocage dans le tableau de bord Stripe, sous Paiements puis Analytics.

Stripe me rembourse-t-il pour les transactions incorrectement bloquées par Radar ?

Non. Stripe ne vous facture pas les transactions bloquées, mais ne vous indemnise pas non plus pour le manque à gagner. Une transaction bloquée n'est jamais traitée : il n'y a donc ni frais ni remboursement. Le coût est entièrement constitué de ventes perdues que vous ne voyez jamais. C'est pourquoi surveiller votre taux de blocage est essentiel : vous ne pouvez pas récupérer le chiffre d'affaires des clients qui ont été refusés au checkout et ne sont jamais revenus.

Quelle est la différence entre Stripe Radar et Radar for Fraud Teams ?

Stripe Radar (gratuit) est inclus avec chaque compte Stripe et fournit un score de fraude basique par apprentissage automatique, ainsi qu'un ensemble limité de règles par défaut. Radar for Fraud Teams coûte 0,07 $ par transaction analysée et ajoute des files d'attente de révision manuelle, des règles personnalisées avancées (utilisant des attributs comme la valeur vie client et la vélocité d'achat), ainsi que des listes d'autorisation et de blocage. Pour la plupart des créateurs traitant moins de 500 transactions par mois, la formule gratuite est suffisante. Au-delà, les 0,07 $ par transaction se justifient par le contrôle supplémentaire offert.

Puis-je récupérer une vente après que Stripe Radar l'a bloquée ?

Pas directement. Dès que Radar bloque une tentative de paiement, le client voit un message de refus générique. Vous pouvez limiter l'impact en configurant les transactions limites en mode "révision" plutôt qu'en "blocage", ce qui met le paiement en attente pour votre validation manuelle au lieu de le refuser d'emblée. Si vous connaissez personnellement un client bloqué, vous pouvez lui demander de réessayer (idéalement depuis le même appareil et la même adresse IP) après avoir ajouté son adresse e-mail ou l'empreinte de sa carte à votre liste d'autorisation.

Le 3D Secure réduit-il les faux positifs ?

Oui, mais avec un compromis. Lorsque vous redirigez une transaction signalée vers le 3D Secure plutôt que de la bloquer, le client a la possibilité de s'authentifier et de finaliser son achat. S'il passe l'authentification, la transaction est traitée et vous bénéficiez d'un transfert de responsabilité en cas de fraude de la part de la banque émettrice. Le compromis est la friction de conversion : le 3D Secure ajoute une étape au checkout, et environ 10 à 15 % des clients abandonnent à l'écran d'authentification. Utilisez le 3DS de manière sélective pour les transactions à risque moyen, plutôt que de l'appliquer à l'ensemble de vos paiements.

Pourquoi les transactions internationales déclenchent-elles plus souvent Stripe Radar ?

Stripe Radar évalue plusieurs signaux que les transactions internationales déclenchent fréquemment : décalage entre le pays d'émission de la carte et le pays de l'adresse IP, utilisation d'un VPN (courant dans les pays soumis à des restrictions internet), plages BIN peu connues (numéros d'identification bancaire) et incohérences entre adresses de livraison et de facturation. Pour les créateurs vendant à l'international, ces signaux génèrent un nombre disproportionné de faux positifs. La solution consiste à créer des règles personnalisées qui réduisent la pondération du risque pour vos pays acheteurs les plus courants, plutôt que de s'appuyer sur les paramètres par défaut de Radar.

Dois-je continuer avec Stripe Radar ou passer à une plateforme qui gère la prévention de la fraude pour moi ?

Cela dépend de votre volume et de votre aisance technique. Si vous traitez moins de 200 transactions par mois et vendez principalement à des clients domestiques, Radar avec un réglage de base est généralement suffisant. Si vous vendez des produits numériques haut de gamme à une clientèle internationale, le travail continu de maintenance des règles personnalisées, de révision des paiements signalés et de surveillance de votre taux de blocage représente un coût en temps significatif. Les plateformes Merchant of Record (vendeur officiel) comme Whop gèrent le filtrage anti-fraude au niveau de la plateforme, ce qui signifie que vous ne gérez pas vous-même les règles Radar, les files de révision ou les listes d'autorisation.

Dernière révision : 2026-05-22. Les fonctionnalités et tarifs de Stripe Radar sont à jour au 2026. Radar for Fraud Teams coûte 0,07 $ par transaction analysée selon la tarification publiée par Stripe. Les estimations d'impact sur le chiffre d'affaires liées aux faux refus sont basées sur des études sectorielles publiées, et non sur des communications de Stripe. Rien dans cet article ne constitue un conseil juridique ou financier. WhatPayment peut percevoir une commission sur certains liens. Lire notre déclaration d'affiliation.