Étapes de détection de la fraude

Comprendre les étapes de détection de la fraude, un niveau de vérification supplémentaire pour les autorisations.

Activez les étapes de détection de la fraude pour :

Minimiser le blocage accidentel des transactions qui semblent frauduleuses, mais qui sont en fait légitimes
Effectuer des vérifications supplémentaires sur les autorisations que Stripe juge à haut risque
Effectuer des vérifications supplémentaires sur les autorisations que vous jugez nécessaires

Les étapes de détection de la fraude permettent aux titulaires de carte de relancer des transactions non frauduleuses qui, sans cette fonctionnalité, auraient été bloquées par des contrôles de fraude. Lorsque les étapes de détection de la fraude sont activées et qu’une transaction est refusée pour cause de fraude, Stripe envoie un SMS au titulaire de la carte. Celui-ci peut alors confirmer le caractère frauduleux ou légitime de la transaction en répondant au message. Tous les titulaires de carte ayant associé un numéro de téléphone peuvent utiliser les étapes de détection de la fraude.

Avant de commencer

Veillez à collecter les numéros de téléphone de vos titulaires de carte
Activez les étapes de détection de la fraude dans les paramètres d’émission de cartes

Transactions à haut risque

Stripe bloque les transactions à partir d’un certain niveau de risque. Le niveau de risque d’une transaction est déterminé par le réseau que vous utilisez. Les autorisations à haut risque sont identifiées par une valeur de suspected_fraud dans le champ request_history.reason, et ne déclencheront pas les webhooks issuing.authorization_request en cas de refus.

Flux des étapes de détection de la fraude

Stripe commence à envoyer des étapes de détection de la fraude sur les autorisations à risque élevé dès que vous activez la fonctionnalité dans les paramètres d’émission de cartes.

Consultez l’activité relative aux étapes de détection de la fraude à l’aide de l’API Authorizations. Les autorisations refusées en raison d’une étape de détection de la fraude présentent une valeur dans le champ fraud_challenges. Les autorisations suivantes, dont le titulaire de la carte vérifie la légitimité, présentent la valeur true dans le champ verified_by_fraud_challenge.

Voici un exemple d’autorisation bloquée et refusée pour cause de fraude :

{
  "id": "iauth_1CmMk2IyNTgGDVfzFKlCm0gU",
  "object": "issuing_authorization",
  "approved": false,
  ...
  "fraud_challenges": [{
    "channel": "sms",
    "status": "pending"
  }]
}

Cet exemple illustre une autorisation ultérieure qui a été vérifiée par le titulaire de la carte :

{
  "id": "iauth_1CmMk28Jx923VfJJwMCejmX",
  "object": "issuing_authorization",
  "approved": true,
  ...
  "verified_by_fraud_challenge": true
}

Remarque

Les autorisations légitimes et vérifiées déclenchent des webhooks issuing_authorization.request. Si vous utilisez une autorisation en temps réel, tenez compte du paramètre verified_by_fraud_challenge au moment d’approuver ou non une autorisation. Si le titulaire de carte a explicitement confirmé l’authenticité d’une transaction, nous vous recommandons de n’appliquer aucun de vos propres contrôles des risques.

Pour utiliser les étapes de détection de la fraude, assurez-vous que :

Le numéro de téléphone associé à votre titulaire de carte est valide et correct
La logique de refus de transaction existante dans tout gestionnaire de webhook issuing_authorization.request n’entre pas en conflit avec les étapes de détection de la fraude

Flux pour les titulaires de carte

Vos titulaires de carte peuvent recevoir une étape de détection de la fraude et contacter le service client de votre entreprise pour en savoir plus. Par conséquent, vos équipes internes doivent se tenir prêtes à répondre aux éventuelles questions de vos clients au sujet de ces étapes de détection.

Lorsqu’un titulaire de carte reçoit une étape de détection de la fraude, il peut annuler le rejet de la transaction en vérifiant que l’opération suspecte est légitime et qu’il en est l’auteur. Les étapes de détection de la fraude sont uniquement disponibles pour les titulaires de carte ayant associé un numéro de téléphone.

Le titulaire de la carte reçoit ce SMS l’invitant à confirmer l’annulation :

Avez-vous tenté d’effectuer une transaction de [montant] chez [marchand] ? Si oui, répondez « OUI », sinon répondez « NON ». Pour vous désinscrire, répondez « STOP ».

Si le titulaire de la carte répond « OUI », il reçoit le message suivant :

Merci, veuillez patienter quelques instants et réessayer.

Pour finaliser l’achat, le titulaire de la carte doit retenter la transaction. Une fois l’opération réalisée, il ne recevra pas d’invitation par SMS, et Stripe ne bloquera pas la transaction pour risque élevé. En revanche, si le titulaire de la carte répond « NON », il reçoit le message suivant :

Cette transaction a été refusée. Nous vous recommandons d’annuler votre carte et d’en demander une nouvelle. Vérifiez que votre compte ne fait pas l’objet d’autres transactions suspectes.

Les titulaires de cartes peuvent répondre « STOP » pour se désinscrire des étapes de détection de la fraude et « START » pour s’y réinscrire.

Les étapes de détection de la fraude pour les plateformes Connect

Si vous utilisez Connect avec Stripe Issuing, et que vous activez les étapes de détection de la fraude, elles seront activées pour tous les titulaires de cartes sur tous les comptes connectés.

Disponibilité

Les étapes de détection de la fraude sont uniquement disponibles pour les titulaires de carte dont le numéro de téléphone correspond aux pays suivants. Les demandes de vérification envoyées à d’autres numéros de téléphone, ou à des titulaires de carte se trouvant en dehors de ces pays, n’aboutiront pas.

Royaume-Uni (+44)
États-Unis (+1)

Les étapes de détection de la fraude qui ne peuvent être envoyées en raison d’un code de pays non pris en charge ont un statut undeliverable.

Tests

Stripe n’envoie pas de questions de détection de la fraude aux titulaires de cartes en mode test. Pour vous aider à intégrer les étapes de détection de la fraude, nous fournissons des API de support, qui simulent un flux de détection de la fraude, notamment l’envoi d’une question et de sa réponse.

Détecter la fraude sur une autorisation à haut risque dans le mode test

Utilisez les API d’assistance pour créer une autorisation en mode test. Le niveau de risque de l’autorisation que vous créez est contrôlable : vous pouvez créer une autorisation à haut risque en remplaçant l’évaluation du risque par défaut par un niveau de risque de fraude élevé.

Cette autorisation serait refusée, avec le motif (reason) suspected_fraud dans son attribut request_history. Si les étapes de détection de la fraude sont activées, un flux de détection de la fraude est créé pour cette autorisation à haut risque en mode test. Reportez-vous à la section Avant de commencer pour découvrir comment activer le flux de détection de la fraude.

Vous pouvez également tester le flux de détection de la fraude en émettant une étape de détection. Pour générer une étape de détection de la fraude en mode test, créez une autorisation test sans contourner l’évaluation des risques, puis répondez à un webhook issuing_authorization.request. Cette méthode fonctionne même si le flux de détection de la fraude n’est pas activé dans vos paramètres Issuing. Découvrez comment déclencher des étapes de détection de la fraude dans les réponses de webhook.

Simuler une réponse au flux de détection de la fraude

Après avoir provoqué une étape de détection de la fraude en mode test, vous pouvez simuler la réponse d’un titulaire de carte à l’aide d’une autre API de support. Appelez la méthode de réponse à une étape de détection de la fraude en mode test en lui transmettant l’ID de l’autorisation que vous avez créée à l’étape 1, ainsi qu’un paramètre confirmed.

Utilisez le paramétrage confirmed=true pour simuler une réponse du titulaire de carte du type « oui, j’ai effectué cette transaction et elle n’est pas frauduleuse ». Paramétrez confirmed=false pour simuler une réponse du type « non, je n’ai pas effectué cette transaction, elle est frauduleuse ».

Réessayer l'autorisation à haut risque

Si vous avez simulé une réponse du type « oui, j’ai effectué cette transaction » (confirmed=true), vous pouvez alors réessayer l’autorisation à haut risque en mode test. Cette fois-ci, l’autorisation ne sera pas refusée, car vous avez simulé un scénario dans lequel le titulaire de la carte indique que la transaction initialement refusée est en fait légitime.

Cette nouvelle autorisation ne sera pas refusée pour suspected_fraud. Elle pourra soit être approuvée, soit être refusée pour un autre motif (comme un solde insuffisant en mode test). Consultez l’objet request_history de l’autorisation pour en savoir plus.

En outre, le champ verified_by_fraud_challenge de cette nouvelle autorisation sera true. Cela indique que le titulaire de la carte a déjà effectué une étape de détection de fraude pour une autorisation similaire (comme simulé à l’étape 2).