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 et s'exécutent uniquement lorsque votre propre configuration de Shield est 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, bank, crypto. 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 dont le driver peut transmettre cette demande. 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. 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.

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.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
  -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

Il n'existe aucune table de liste d'autorisation. Un client autorisé correspond à une règle classique avec l'action allow. Le Dashboard en écrit une lorsque vous clôturez un examen avec allow this customer : une règle par identifiant, à la priorité 0 pour passer avant toutes les autres, et une correspondance exacte avec l'adresse e-mail ou avec les chiffres du téléphone.

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 x-attacker@mail.com en même temps que attacker@mail.com.

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.