Démarrage rapide

Shield évalue déjà vos paiements live avec les seuils de la plateforme. Son activation vous permet de les remplacer par vos propres seuils et de débloquer toutes les fonctionnalités qui agissent sur un score au lieu de simplement le signaler.

Cinq étapes, toutes en mode live.

1. Activer Shield

Dans le Dashboard, Shield affiche un écran d'activation jusqu'à ce que vous l'activiez. Cette opération ne définit rien d'autre. Vous commencez avec les seuils de la plateforme qui s'appliquaient déjà, et GET /shield/settings les renvoie.

Un seul appel suffit depuis l'API.

curl -X PUT https://api.wajub.com/shield/settings \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…" \
  -H "Content-Type: application/json" \
  -d '{ "enabled": true }'

La réponse contient les paramètres désormais appliqués, dont un indicateur advanced qui vous indique si les règles, les listes et l'activation automatique de 3D Secure sont disponibles.

2. Définir des seuils réellement acceptés

Les deux seuils sont limités. Une valeur située hors de leurs limites est refusée ou discrètement ramenée dans l'intervalle. Ce comportement surprend souvent.

Une requête qui demande un seuil de blocage supérieur à celui de la plateforme réussit donc, mais vous laisse sur celui de la plateforme. Relisez les paramètres après leur écriture au lieu de supposer que la valeur envoyée est celle appliquée.

curl -X PUT https://api.wajub.com/shield/settings \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…" \
  -H "Content-Type: application/json" \
  -d '{
    "enabled": true,
    "block_threshold": 70,
    "review_threshold": 45,
    "auto_3ds_enabled": true,
    "blocklist_enabled": true
  }'

auto_3ds_enabled et blocklist_enabled sont enregistrés avec tous les plans, mais produisent un effet uniquement avec Shield Advanced. Une valeur true enregistrée sur un plan qui ne possède pas cette option est renvoyée comme false.

3. Lire la décision prise

Cette information ne vient pas de l'API. La réponse du paiement ne contient aucun score et aucun webhook n'est émis lors d'une décision de Shield. Tout se trouve dans le Dashboard.

Les compteurs de la page overview peuvent mettre quelques minutes à se mettre à jour. La file est toujours à jour.

4. Traiter la file d'examen

La file contient tous les paiements signalés des 90 derniers jours que vous n'avez pas encore clôturés. Elle affiche les plus récents en premier, vingt par page. Chaque ligne contient le score, les codes de signalement, le client et le montant que renverrait un remboursement total.

Elle contient aussi les tentatives que Shield a bloquées. Rien n'a été encaissé pour celles-ci, il n'y a donc rien à rembourser. Vous pouvez en revanche laisser passer le client la prochaine fois.

Vous pouvez clôturer une ligne avec l'une des quatre décisions suivantes.

Approve et allow this customer sont disponibles avec tous les plans. Si Shield a refusé un client de confiance, l'autoriser est la façon de le libérer : sa prochaine tentative passe, et Shield, lists affiche les clients autorisés et permet de revenir en arrière. Les deux décisions qui bloquent nécessitent Shield Advanced, car elles écrivent dans la liste de blocage.

5. Reconnaître un blocage

Un paiement bloqué n'atteint jamais un prestataire. L'appel renvoie immédiatement une réponse, la transaction reste à pending et votre intégration reçoit un message avec une référence.

Comme la transaction n'est pas modifiée, vous pouvez proposer au payeur une autre tentative sur le même paiement. Une nouvelle tentative est évaluée à nouveau, et elle est généralement bloquée à nouveau si rien n'a changé chez le payeur.

Si vous utilisez votre propre checkout

Les pages hébergées de Wajub et Wajub Components débitent depuis le navigateur du payeur, et envoient un petit bloc de données du navigateur avec chaque débit. Si vous avez développé votre propre page de paiement et que vous débitez depuis votre serveur avec une clé secrète, la requête vient de votre serveur, pas du payeur, et Shield ne voit pas le navigateur du payeur.

Pour rendre le payeur à Shield, appelez Wajub.signals() dans le navigateur du payeur, envoyez le résultat à votre serveur, et transmettez-le tel quel dans data._client du débit. Vos entrées de liste de blocage ip et country en ont aussi besoin.

const signals = await Wajub.signals();

// Envoyez-le à votre serveur avec la commande, puis dans data._client du débit.
await fetch('/checkout', { method: 'POST', body: JSON.stringify({ order, signals }) });

token atteste l'adresse IP du payeur. Sa durée de validité est courte : obtenez-le pendant que le payeur se trouve sur votre page de paiement. Avec lui, Shield voit le payeur comme sur une page hébergée. Wajub.signals() ne rejette jamais, il ne peut donc pas bloquer votre checkout.

Si vous ne pouvez pas exécuter Wajub.js sur la page, vous pouvez envoyer vous-même l'adresse du payeur dans _client.ip. Une adresse déclarée est une preuve plus faible qu'un jeton, et vos entrées de liste de blocage ip et country ainsi que vos règles sur le pays de l'IP sont comparées au jeton. Envoyez le jeton avec chaque débit.

Les autres champs décrivent le navigateur et l'appareil du payeur. Transmettez-les tels que Wajub.signals() les renvoie.