Évaluation du risque

Shield combine de nombreux signaux sur le payeur, l'appareil, la carte et l'historique de chaque identifiant pour produire un score de 0 à 100. Wajub ajuste ces signaux en permanence, au gré de la fraude : un même paiement peut donc obtenir un score différent d'un mois à l'autre. L'historique compte aussi : une nouvelle tentative sur le même paiement est évaluée à nouveau, en tenant compte de ce qui s'est passé avant.

Chaque paiement enregistre les signaux déclenchés, et le Dashboard les affiche sur le paiement. Cette page décrit ce que ces signaux examinent et ce que vous contrôlez.

Les niveaux et ce qu'ils ne sont pas

Ces libellés facilitent la lecture rapide d'une liste. La décision dépend de vos seuils, pas du niveau. Un paiement avec un score de 62 reste donc high, que votre seuil de blocage soit de 70 ou de 60. Seul l'un de ces seuils refuse le paiement.

Ce qui compte sans Shield Advanced

Chaque famille décrite sur cette page est examinée sur chaque paiement live. Shield Advanced évalue avec l'ensemble complet des signaux de Wajub ; les autres plans évaluent avec un sous-ensemble essentiel de ces signaux. Shield compare les plans.

Origine du payeur

Shield vérifie que le réseau, la localisation, les réglages du navigateur et le téléphone du payeur concordent. Un payeur dont tous les éléments désignent le même endroit ne ressemble pas à celui dont l'adresse IP, le téléphone et le navigateur racontent chacun une autre histoire.

Shield les lit dans le navigateur du payeur. Le checkout hébergé, les liens de paiement, les factures et Wajub Components envoient ces données pour vous. Si vous débitez depuis votre propre serveur avec une clé secrète, appelez Wajub.signals() dans le navigateur du payeur et transmettez le résultat tel quel dans data._client : Si vous utilisez votre propre checkout montre comment.

Vérifier si la requête vient réellement d'un navigateur

Shield reconnaît les navigateurs automatisés et sans interface graphique. Envoyez les données du navigateur du payeur avec chaque débit, comme ci-dessus.

Vitesse d'utilisation du même identifiant

Shield surveille la vitesse à laquelle une même adresse IP, une même plage de cartes, un même appareil, une même adresse e-mail et un même téléphone sont utilisés, et reconnaît les schémas de test de cartes.

Ce que la plateforme retient sur ce payeur

Shield retient le comportement d'une adresse e-mail, d'un numéro de téléphone ou d'un appareil sur toute la plateforme, issue des litiges comprise, et remarque un numéro de téléphone qui apparaît sur un nouvel appareil (changement de carte SIM). Cet historique s'estompe avec le temps : personne ne reste marqué à cause d'un seul mauvais mois.

Un litige que vous concédez, avec accept ou close ou depuis le Dashboard, finit lost comme un litige tranché contre vous, mais il en dit peu sur le payeur et pèse moins contre lui. Un tel litige porte metadata.resolution à accepted.

Forme des identifiants eux-mêmes

Shield examine aussi l'adresse e-mail et le numéro de téléphone eux-mêmes : domaines d'adresses jetables, identifiants jamais vus, répétitions inhabituelles. C'est pourquoi le paiement d'un client que personne n'a encore rencontré obtient rarement un score de zéro.

Caractéristiques de la carte

Shield compare le lieu et le mode d'émission de la carte avec la localisation et le téléphone du payeur, et tient compte des refus récents.

Seuls les huit premiers chiffres d'un numéro de carte parviennent au moteur de risque. Rien de plus long n'est enregistré.

Ce que vous et votre historique indiquez

Shield prend en compte les litiges du client avec vous, la façon dont le paiement se compare à l'activité habituelle de votre compte, et l'ancienneté de votre compte.

Vous pouvez aussi alimenter le score vous-même. Définissez risk_flag sur high ou medium dans les metadata du paiement pour augmenter le risque que Shield attribue à ce paiement. La même clé dans les metadata du client s'applique à tous ses paiements. Seule la valeur high y est lue.

Les deux scores qui ne sont pas calculés

Deux éléments ne dépendent d'aucun signal. Ils fixent le score à 100, ce qui refuse le paiement avec tous les seuils configurables.

Une correspondance avec votre liste de blocage, lorsqu'elle est activée.

Une correspondance avec les sanctions, selon la liste de surveillance de la plateforme, avec tous les plans et même sans configuration de Shield. Le contrôle des sanctions n'est pas une fonctionnalité payante.

Cette liste est constituée à partir des listes publiques officielles, la liste SDN de l'OFAC et la liste consolidée de l'ONU, augmentées des ajouts propres à Wajub, et elle est rafraîchie régulièrement. Un payeur qui y correspond est refusé.

Pour une correspondance possible, un nom qui ressemble à un nom listé, c'est vous qui décidez, dans Shield, Risk controls ou avec sanctions_near_match_action sur PUT /shield/settings, sur tous les plans et que vos propres réglages Shield soient activés ou non.

La revue est le choix par défaut parce que ces listes contiennent des milliers de noms translittérés : un payeur dont l'orthographe croise celle d'une personne listée ne doit pas être refusé pour cela seul, et vous n'auriez pas de quoi l'expliquer à votre client. Une revue ne retient jamais les fonds : le paiement est encaissé, et la décision vous revient ensuite.

Ce que présente la page Rules

La page Shield, Rules répertorie les signaux avec un nom, une description et un niveau de gravité. Cette liste décrit ce qui vous protège. Ce n'est pas un ensemble d'interrupteurs : vous ne pouvez ni désactiver un signal, ni modifier son poids, ni en ajouter un. Wajub ajuste les signaux pour toute la plateforme.

Les niveaux de gravité de cette page et du détail des signalements d'un paiement facilitent la lecture. Vos leviers sont vos seuils, vos règles et listes, et le risk_flag que vous définissez.