Règles Shield

Le score décide seul la plupart du temps. Trois dérogations déterministes s'appliquent ensuite aux cas où vous possédez une information invisible dans les signaux : un client fiable, un numéro déjà utilisé pour vous frauder ou une tranche de paiements que vous souhaitez contrôler quel que soit son score.

Toutes les trois nécessitent Shield Advanced, à une exception près : un client que vous avez autorisé depuis la file d'examen reste autorisé avec tous les plans. Rien de tout cela ne s'exécute tant que votre propre configuration de Shield n'est pas active.

Ordre de résolution d'une décision

Rien ici ne remplace le score. Tous ces éléments s'appliquent après son calcul. Cette séquence explique tous les résultats présentés sur cette page.

La règle de la première correspondance s'applique uniquement à l'étape 4. L'étape 2 explique pourquoi une règle d'autorisation ne peut pas sauver un client présent dans la liste de blocage.

Composition d'une règle

Chaque règle contient également un compteur de correspondances et l'heure de sa dernière correspondance. Ces deux valeurs sont mises à jour pour tous les paiements concernés, y compris pour les règles test. Ce compteur mesure réellement si une règle produit un effet.

Les huit champs

Le générateur repose sur un catalogue fermé. Il ne possède aucun langage d'expression et ne peut accéder à aucun élément absent de cette liste, y compris le score de risque lui-même.

Vous devez connaître plusieurs comportements avant d'écrire une règle.

Le montant utilise les unités principales, comme le paiement. 50000 représente donc cinquante mille XAF.

Le moyen de paiement correspond au type du canal, pas à son slug : card, mobile_money, wallet, crypto, ussd, voucher, bnpl, redirect, et trois types bancaires, bank.transfer, bank.debit et bank.redirect. Il n'existe pas de type bank seul : une règle sur les paiements bancaires liste les types bancaires qu'elle vise. C'est le seul endroit du produit où un terme de niveau produit est la bonne valeur.

Les numéros de téléphone sont comparés uniquement selon leurs chiffres. +237 6 70 00 00 00 et 237670000000 représentent donc la même valeur. La comparaison des adresses e-mail ne tient pas compte de la casse, tout comme matches, dont * est le seul caractère générique et qui est ancré aux deux extrémités.

Première transaction signifie que ce client n'a encore jamais réussi un paiement live avec vous. Un paiement sans client associé compte comme une première transaction.

Les quatre actions

L'effet d'une action dépend de la décision déjà prise par le score. Ce comportement surprend souvent.

challenge_3ds atteint l'émetteur uniquement par les prestataires qui le prennent en charge. Ailleurs, le prestataire applique sa propre politique 3D Secure et la règle ne change rien.

Mode test

Une règle en mode test est évaluée sur chaque paiement live, y compris ceux qu'une règle live a déjà tranchés. Elle comptabilise ses correspondances et est enregistrée comme correspondante sur le paiement, sans jamais prendre de décision. C'est ce qui se rapproche le plus d'une simulation dans Shield, et la seule disponible. Il n'existe toujours aucune sandbox pour Shield.

Pour l'utiliser, écrivez la règle envisagée en mode test, laissez-la fonctionner pendant une semaine, puis consultez son compteur de correspondances. Vous devez savoir qu'une règle aurait bloqué quatre cents paiements avant de la passer en live.

La liste de blocage

Une entrée dans la liste de blocage fixe le score à 100. Elle entraîne donc un refus avec tous les seuils que vous pourriez configurer. C'est l'outil le plus direct de Shield et le seul qui ne nécessite aucune règle.

Une entrée country est comparée au pays de l'adresse IP du payeur, pas à son numéro de téléphone ni à sa devise. Bloquer NG arrête tous les paiements effectués depuis une adresse IP nigériane, y compris ceux de vos propres clients nigérians qui se trouvent dans le pays.

Les entrées ip et country sont comparées à l'adresse du payeur lui-même. Si vous débitez depuis votre serveur avec une clé secrète, envoyez le jeton Wajub.signals() du payeur avec chaque débit.

Une entrée card_bin correspond à toutes les cartes dont le numéro commence par ces chiffres. Une correspondance est refusée, ou part dans votre file d'examen, où vous pouvez rembourser le paiement et bloquer le payeur.

La liste de blocage est la seule partie de cette page qui possède une API.

Le type et la valeur sont obligatoires. Vous pouvez renseigner le motif, qui sera enregistré dans la décision lorsque l'entrée correspond.

curl https://api.wajub.com/shield/blocklist \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "phone",
    "value": "+237690000000",
    "reason": "confirmed fraud, chargeback March"
  }'

La liste complète est renvoyée après chaque écriture. Vous n'avez donc pas besoin d'un second appel pour consulter le résultat.

La liste d'autorisation

Autoriser un client crée une règle d'autorisation qui s'exécute avant vos autres règles. Le Dashboard en écrit une lorsque vous clôturez un examen avec allow this customer : une règle par identifiant, avec une correspondance exacte sur l'adresse e-mail ou sur les chiffres du téléphone.

Cette règle est la seule partie de cette page qui fonctionne avec tous les plans. Sans Shield Advanced, elle reste lue à chaque paiement alors que toutes les autres règles sont en sommeil, et Shield, lists affiche les clients que vous avez autorisés et en retire un en un clic. C'est ainsi que vous libérez un payeur que Shield a refusé par erreur.

Ce qui compte est volontairement étroit : une règle allow en mode live avec une seule condition, l'adresse e-mail avec eq ou le téléphone avec in. Avec Shield Advanced, vous pouvez créer la même règle manuellement. Gardez-la tout aussi précise. Une règle allow avec contains au lieu de eq autoriserait [email protected] en même temps que [email protected], et c'est une règle personnalisée comme les autres : elle cesse d'être lue si vous quittez Shield Advanced.

Ce qu'une règle ne peut pas faire

Elle ne peut pas consulter le score. Le catalogue ne contient aucun champ de score de risque. Vous ne pouvez donc pas écrire « bloquer les premières transactions dont le score dépasse 60 ». Les seuils sont le seul moyen d'agir sur le score.

Elle ne peut pas combiner les conditions avec OR. Toutes les conditions d'une règle doivent être remplies. Deux possibilités nécessitent deux règles.

Elle ne peut pas lire vos métadonnées. Aucun élément envoyé avec le paiement n'est visible dans une règle, à l'exception du montant, de la devise, du canal, de l'adresse e-mail et du téléphone du client.

Elle ne peut pas sortir un paiement de la liste de blocage. Cette décision correspond à l'étape 2 ci-dessus et est prise avant même la lecture des règles.