La fraude au paiement désigne les tactiques trompeuses ou non autorisées utilisées pour voler des biens ou des services pendant le processus de transaction. La détection doit se produire avant la confirmation de la commande, ce qui signifie qu'il faut évaluer le risque en temps réel avec des données incomplètes.

Les pertes mondiales liées à la fraude à la carte bancaire se sont élevées à 33,41 milliards de dollars en 2024, ce qui montre la nécessité de systèmes de prévention de la fraude. Vous trouverez ci-dessous comment fonctionne la fraude au paiement, comment les systèmes d'évaluation de la fraude évaluent le risque au point de paiement et comment intégrer la détection dans votre tunnel de paiement sans réduire le taux de conversion.

L’essentiel à retenir

• La fraude au paiement cible spécifiquement le moment de la transaction. L'évaluation du score de risque en temps réel avant l'autorisation est une ligne de défense efficace.

• Les moteurs de règles et les modèles de machine learning fonctionnent mieux de manière combinée : les règles détectent les mécanismes de fraude connus et les modèles identifient les nouveaux.

• La calibration des frictions (l'application des étapes de vérification uniquement lorsque les signaux de risque le justifient) est un élément important de la prévention de la fraude.

Qu'est-ce que la fraude au paiement ?

La fraude au paiement est l'utilisation non autorisée ou abusive d'un tunnel de paiement pour effectuer des transactions que le titulaire du compte ou le titulaire de la carte n'a jamais approuvées. Elle se produit au moment où les données de carte bancaire volées, les scripts de test automatisés et les comptes compromis convergent dans le tunnel de paiement.

Quels sont les scénarios courants de fraude au paiement ?

La fraude au paiement se concentre sur quelques schémas bien définis. Chacun a une signature comportementale distincte dans les données de transaction.

Vulnérabilités des paiements en tant qu'invité

Le paiement en tant qu'invité supprime la couche de compte de la transaction. Il n'y a pas d'historique d'achat, pas d'adresse enregistrée et pas de référence comportementale, ce qui le rend attrayant pour les fraudeurs.

Les paiements légitimes en tant qu'invité ont toujours tendance à paraître normaux au niveau de la session : les clients naviguent, ajoutent des éléments et passent un temps raisonnable sur la page. Ce n'est souvent pas le cas des transactions frauduleuses effectuées en tant qu'invité : la durée de la session est courte et la navigation est minimale. Ces signaux ne sont pas déterminants en soi, mais combinés, ils font rapidement augmenter le score de risque.

Test de cartes bancaires lors du paiement

Le test de cartes bancaires est une question de volume. Les criminels qui acquièrent des données de cartes bancaires volées en masse doivent savoir quelles cartes bancaires sont encore actives avant de pouvoir les monétiser. Les tunnels de paiement (en particulier ceux avec des éléments de faible valeur ou des biens numériques) constituent des terrains d'essai pratiques.

La signature comportementale est difficile à manquer : des tentatives de transaction séquentielles rapides, des montants faibles ou ronds, des taux élevés de refus de paiement et une vélocité de session qu'aucun être humain ne pourrait reproduire. Les scripts de test modernes sont devenus plus sophistiqués en effectuant une rotation des adresses IP et en espaçant les tentatives sur des fenêtres plus longues pour rester sous de simples seuils de vélocité, c'est pourquoi une détection multicouche est importante.

Piratage de compte à l'étape du paiement

La fraude par piratage de compte ne fait pas toujours surface lors de la connexion. Elle apparaît souvent au moment du paiement, lorsqu'un criminel déjà dans un compte légitime apporte des modifications qui ne correspondent pas à son historique : une nouvelle adresse de livraison ajoutée et utilisée immédiatement, un numéro de carte bancaire saisi à partir d'un appareil qui n'a jamais touché à ce compte, un changement d'adresse de facturation associé à une expédition accélérée. Pris individuellement, l'un ou l'autre de ces éléments peut être légitime. Ensemble, au sein d'une même session, ils constituent un signal fort indiquant que la personne à l'origine du paiement n'est pas le titulaire du compte.

Comment fonctionne l'attribution d'un score de risque dans le tunnel de paiement ?

Lorsqu'un client effectue un paiement, un système d'évaluation des fraudes extrait les signaux disponibles et génère un score de risque.

Les éléments suivants sont généralement inclus :

• Signaux au niveau de la carte bancaire : Numéro d'identification bancaire (BIN), pays, type de carte bancaire, si la carte bancaire a déjà été utilisée, et si l'adresse de facturation correspond à celle enregistrée auprès de la banque émettrice via un service de vérification d'adresse (AVS).

• Signaux de l'appareil et de la session : Empreinte d'identification de l'appareil, caractéristiques du navigateur, géolocalisation de l'IP et association de l'IP à un proxy connu ou à un réseau privé virtuel (VPN).

• Caractéristiques de la commande : Type d'élément (les biens numériques ont tendance à présenter des taux de fraude plus élevés que les biens physiques), valeur de la commande par rapport à l'historique du compte et correspondance de l'adresse de livraison à la facturation.

• Signaux comportementaux : Temps passé sur la page, parcours de navigation et rapidité avec laquelle le client est passé de la page de destination au paiement.

Comment fonctionne la détection de la fraude au paiement en temps réel ?

La détection en temps réel combine des moteurs de règles et des modèles comportementaux pour évaluer le risque au moment de la transaction. Ces deux approches présentent des avantages différents.

Moteurs de règles

Les règles gèrent une logique déterministe : si une transaction correspond à un mécanisme de fraude connu, elle est bloquée. Elles sont rapides et transparentes, et permettent de voir exactement pourquoi une transaction a été bloquée (ce qui est important pour la résolution de litiges et l'investigation des faux positifs). L'inconvénient est leur manque de flexibilité. Une règle créée pour détecter un mécanisme de fraude spécifique ne détectera probablement pas une variante sans la création d'une autre règle. Les règles nécessitent donc une maintenance continue, car les schémas d'attaque évoluent.

Modèles de machine learning

Les modèles de machine learning gèrent l'évaluation probabiliste. Ils évaluent les combinaisons de signaux par rapport aux modèles appris à partir de millions de transactions antérieures et attribuent un score de probabilité plutôt qu'un indicateur binaire. Ils se généralisent bien aux nouveaux mécanismes de fraude sans nécessiter de définir manuellement chaque scénario de risque. L'inconvénient est l'opacité : un résultat de modèle tel que « 94 % de probabilité de fraude » nécessite une interprétation, contrairement à un blocage basé sur des règles.

Analyse comportementale

Les signaux comportementaux ajoutent une couche généralement plus difficile à usurper que les points de données statiques. Les événements de copier-coller dans les champs de paiement signalent une saisie automatisée ou un bourrage d'identifiants (lorsque des attaquants utilisent des identifiants de connexion volés lors de violations de données non liées pour pirater des comptes). Le remplissage inhabituellement rapide d'un formulaire, les mouvements de souris erratiques et le changement d'onglet pendant le paiement contribuent tous à l'évaluation du score de risque d'une manière qui nécessiterait d'imiter l'interaction humaine en temps réel pour être contournée.

Ensemble, ces systèmes produisent des scores de risque avec une résolution suffisante pour prendre des décisions nuancées. Les transactions à la limite doivent être acheminées vers une vérification plutôt que rejetées d'emblée.

Comment intégrer l'attribution d'un score de fraude à votre processus de paiement ?

L'intégration s'effectue au niveau de l'interface de programmation d'application (API), entre la soumission du paiement et l'autorisation. Votre page de paiement collecte les détails du paiement, votre back-end les envoie à votre système d'évaluation des fraudes avec les données de session et de commande, le système d'évaluation renvoie un score de risque et une action recommandée, et votre logique de paiement achemine la transaction en conséquence.

Voici comment fonctionne chaque étape :

• Transmettez les bonnes données : Les systèmes d'évaluation des fraudes ne valent que par les signaux qu'ils reçoivent. Si vous ne transmettez pas les données d'empreinte d'identification de l'appareil, l'adresse IP et les métadonnées de session avec les détails de paiement, vous laissez vos données à signal le plus élevé inutilisées. De nombreuses API d'évaluation incluent une bibliothèque client JavaScript qui collecte automatiquement les données d'appareil et de session.

• Configurez délibérément les seuils de risque : Les seuils par défaut ne sont généralement pas calibrés pour votre entreprise. Un seuil approprié pour une marketplace à volume élevé et à faible marge diffère d'un seuil adapté à un paiement B2B à faible volume et à valeur élevée. Définissez des seuils en fonction de vos objectifs de taux de fraude et de votre tolérance aux faux positifs, puis affinez-les avec des données de transaction réelles.

• Créez une file de vérification plutôt qu'une liste de blocage : Les transactions dont le score est supérieur à votre seuil de blocage sont automatiquement bloquées, mais celles qui se situent dans la moyenne (suspectes mais non concluantes) doivent être acheminées vers une file de vérification par des humains. Le blocage automatique des transactions à la limite augmente les taux de faux positifs et entraîne l'abandon ; les approuver automatiquement augmente les pertes liées à la fraude.

• Surveillez le taux de conversion lors du paiement en plus des résultats de la fraude : Si votre taux de blocage grimpe mais que les pertes liées à la fraude ne diminuent pas proportionnellement, vos règles génèrent probablement des faux positifs. Si les pertes liées à la fraude augmentent malgré des taux de blocage élevés, vos seuils peuvent être mal configurés ou les fraudeurs ont appris à rester en dessous.

Quelles sont les bonnes pratiques pour la prévention de la fraude au paiement ?

Quelques pratiques de maintenance peuvent vous aider à assurer le bon fonctionnement de votre système de prévention de la fraude sans bloquer de transactions légitimes :

• Conservez vos règles à jour : Les mécanismes de fraude évoluent et une règle adaptée au comportement de test de cartes bancaires du trimestre précédent peut manquer la variante de ce trimestre. Vérifiez régulièrement vos taux de blocage et de vérification. Mettez à jour les règles lorsque vous constatez de nouveaux modèles dans les refus de paiement ou les transactions contestées.

• Superposez les vérifications de vélocité sur plusieurs identifiants : Les règles de vélocité qui vérifient uniquement les adresses IP sont faciles à contourner. Superposez-les sur l'empreinte d'identification de l'appareil, l'adresse e-mail et le BIN de la carte bancaire, car un fraudeur qui effectue une rotation des adresses IP déclenchera tout de même une règle de vélocité par appareil ou par e-mail.

• Intégrez les signaux post-transaction à l'évaluation : Les schémas de rétrofacturation, les abus de remboursement et les taux d'exceptions de livraison révèlent tous la fraude passée entre les mailles du filet au moment du paiement. Utilisez-les pour mettre à jour vos règles et votre configuration d'évaluation, car l'évaluation de la fraude s'améliore avec les boucles de rétroaction.

• Segmentez les seuils par type de commande : Les biens numériques, les cartes cadeaux et les commandes avec expédition accélérée ont tendance à présenter des taux de fraude plus élevés. Appliquez des seuils plus stricts à ces types de commandes plutôt qu'une évaluation uniforme sur l'ensemble de votre catalogue.

Comment Stripe Radar peut vous aider

Stripe Radar s’appuie sur des modèles d’IA entraînés à partir des données issues du réseau mondial de Stripe pour détecter et prévenir la fraude. Ces modèles sont continuellement mis à jour pour tenir compte des nouvelles tendances, ce qui permet de protéger votre entreprise face à l’évolution des risques.

Stripe propose également Radar for Fraud Teams, qui permet aux utilisateurs d’ajouter des règles personnalisées adaptées à des scénarios spécifiques et d’accéder à des analyses avancées sur la fraude.
Radar peut aider votre entreprise à :

• Prévenir les pertes dues à la fraude : Stripe traite plus de 1 000 milliards de dollars de paiements chaque année. À cette échelle, Radar peut détecter et prévenir la fraude avec une précision inégalée, ce qui vous permet de limiter les pertes financières.

• Augmenter les revenus : les modèles d’IA de Radar sont notamment entraînés avec des données réelles, provenant de litiges, d’informations clients ou encore de la navigation. Ils permettent à Radar d’identifier les transactions à risque tout en réduisant le nombre de faux positifs, ce qui contribue à augmenter vos revenus.

• Gagner du temps : Radar est intégré à Stripe et ne nécessite aucune ligne de code pour être configuré. Vous pouvez suivre vos performances en matière de fraude, définir des règles et accéder aux analyses depuis une plateforme unique, pour plus d’efficacité.

En savoir plus sur Stripe Radar, ou démarrez dès aujourd’hui.