Règles de routage

Une règle de routage désigne l'une de vos connexions pour les paiements qui présentent certaines caractéristiques. Lorsqu'un paiement correspond, cette connexion est essayée en premier, avant toutes les connexions qu'aucune règle ne désigne et quelle que soit la priority des unes et des autres, avec le prestataire de secours de la règle juste derrière. La politique du canal ou la priorité des connexions ordonne ensuite le reste, comme le décrit Orchestration des paiements.

Une règle n'est pas une liste ordonnée de prestataires. Elle place une connexion, deux avec son secours, en tête de la liste de candidats classés. Tout ce qui suit est la liste que Wajub aurait construite de toute façon.

Ce à quoi une règle peut correspondre

Une règle possède des conditions, une cible, un secours facultatif et deux nombres qui lui sont propres. Toutes les conditions sont facultatives, et une règle ne correspond qu'à un paiement qui remplit chacune des conditions qu'elle définit. Les noms ci-dessous sont ceux des champs du formulaire de règle dans le Dashboard.

Conditions avancées

La section Conditions avancées du formulaire en ajoute quatre. Chacune, lorsqu'elle est définie, doit aussi être remplie.

Les étiquettes d'un client sont les tags du client, définis par l'API ou dans le Dashboard. Les filtres de métadonnées comparent eq et in sur le texte de la valeur : 100 saisi dans le formulaire correspond à 100 envoyé comme nombre ou comme chaîne, et true au booléen. in prend plusieurs valeurs séparées par des virgules, comme web, app, et correspond quand la métadonnée est égale à l'une d'elles. contains cherche le texte dans une chaîne, et gt, gte, lt et lte comparent des nombres. Une liste ou un objet dans vos métadonnées ne correspond qu'à une valeur identique. Le formulaire affiche ces opérateurs sous la forme =, « dans », « contient », >, ≥, < et ≤.

Plafonds de fréquence

Un plafond empêche la règle de correspondre dès qu'elle a compté assez de paiements dans sa fenêtre. La règle correspond de nouveau lorsque la fenêtre suivante commence.

Un paiement compte lorsqu'un prestataire l'a pris en charge : réussi, en attente, ou en attente d'une action du payeur. Un paiement refusé en chemin ne compte pas.

Quelle règle l'emporte

Toutes vos règles actives sont évaluées pour chaque paiement live, et chaque règle qui correspond place sa cible. Elles sont prises dans cet ordre.

1. La Priorité de règle la plus élevée d'abord.
2. À priorité égale, la règle la plus précise.
3. Les règles encore à égalité se partagent le trafic selon leur Poids, à chaque paiement. Avec des poids de 70 et 30, la cible de la première règle passe en premier sur environ sept paiements sur dix.

Chaque règle place sa cible, puis son secours, puis la règle suivante fait de même.

Prenons un compte connecté à CinetPay et à Flutterwave. Les deux connexions ont une priorité de 0, peuvent traiter cm.mtn en XAF, et une règle associe cm.mtn et XAF à CinetPay. CinetPay est placé en premier par la règle. Flutterwave vient après, ordonné avec toutes les connexions qu'aucune règle ne désigne, et le fait qu'il soit moins cher avec un meilleur taux de réussite récent n'y change rien.

C'est tout l'intérêt. Lorsqu'une règle correspond, rien d'autre ne l'emporte : ni la priorité de vos connexions, ni leur coût, ni leur taux de réussite en direct. Écrivez des règles pour les cas où vous connaissez une meilleure réponse que les chiffres. Laissez les chiffres décider dans les autres cas.

Répartir le trafic

Par montant. Une règle par tranche, chacune avec sa plage de montants et sa connexion. Un paiement tombe dans une seule tranche : une seule règle correspond.

Par proportion. Deux règles avec les mêmes conditions et la même priorité, chacune ciblant une connexion différente, avec des poids de 70 et 30. La page Règles de routage signale les règles dont les conditions se chevauchent, sauf deux règles de même priorité qui ont toutes deux un poids inférieur à 100 et des cibles différentes : elle y voit une répartition voulue.

Le prestataire de secours

Une règle peut désigner une seconde connexion, celle que vous voulez voir essayée quand sa cible échoue. Quand la règle correspond à un paiement, le secours est placé de l'une de deux façons.

La cible peut être essayée. Le secours vient juste derrière elle : c'est la connexion essayée ensuite si la cible échoue du côté du prestataire.

La cible ne peut pas être essayée du tout. Elle est en pause sur ce canal après des échecs répétés, elle ne prend pas en charge le canal ou la devise, ou la connexion n'est plus active. Le secours prend alors la place de la cible, comme si la règle l'avait désigné.

Le secours est une connexion comme les autres. S'il ne peut pas non plus traiter le paiement, la règle ne place rien. Dans le journal de routage, une connexion placée ainsi affiche un badge Repli.

Situations où une règle ne peut pas aider

Quatre situations rendent une règle inopérante. Vérifiez-les avant de conclure que la règle a été ignorée.

La cible doit être une de vos connexions. Le formulaire permet uniquement de choisir parmi les prestataires déjà connectés à votre compte, actifs et en mode live. La suspension ultérieure d'une connexion désactive également ses règles, sauf une règle qui a un secours : le secours prend alors sa place.

Le canal doit être un canal d'opérateur. Le routage utilise toujours le canal de l'opérateur : cm.mobile avec un numéro MTN est routé comme cm.mtn, écrivez donc la règle sur cm.mtn. Une règle basée sur un terme de produit comme mobile_money, bank_transfer ou mobile ne correspond à rien, car aucun paiement n'est routé sur ces chaînes.

Une règle plafonnée attend la fin de sa fenêtre. Une fois un plafond de fréquence atteint, la règle ne correspond plus, et les paiements qu'elle aurait placés suivent l'ordre général.

Une carte reste chez le prestataire qui la détient. Une carte saisie dans les champs propres à un prestataire ne peut être débitée que par lui : une règle qui vise une autre connexion ne la déplace pas. Voir Cascade et repli.

Une règle qui produit un effet

Le modèle à reproduire utilise un canal précis, indique explicitement la devise et cible la connexion que vous voulez pour ce cas.

Supposons que MTN Cameroon soit votre principal réseau. Trois connexions peuvent le traiter et l'une d'elles offre le meilleur taux d'acceptation pour les montants inférieurs à 100 000 XAF. Créez une règle.

Sous 100 000 XAF, cette connexion est essayée en premier, quelle que soit sa priorité. Au-dessus, la règle ne correspond plus et les trois connexions sont ordonnées par la politique du canal, ou par leur priorité, leur coût et leur réussite récente. C'est généralement le comportement souhaité pour les montants les plus importants.

Les bornes de montant utilisent les unités principales, comme le paiement. 100000 représente 100 000 XAF, pas 1 000 XAF.

Le simulateur de la page Règles de routage

Le Simulateur de routage de la page Règles de routage prend une décision de routage sans rien débiter. Donnez-lui un canal, une devise et un montant : il répond avec l'ordre dans lequel vos connexions seraient essayées, la raison de chaque place (une règle, le secours d'une règle, la politique du canal ou la priorité de la connexion), tout garde-fou qui a reculé une connexion, et les connexions écartées, avec leur motif. Rien n'est débité et rien n'est enregistré.

Une connexion est écartée pour l'un de ces motifs :

Il n'envoie ni client ni métadonnées : une règle avec un segment client ou un filtre de métadonnées n'y correspond donc jamais. Il n'envoie pas non plus de pays : le pays ne vient que d'un slug de canal qui commence par un pays, si bien que sur card une règle avec un Pays n'y correspond jamais, alors qu'elle peut correspondre à un vrai paiement. Les fenêtres horaires sont lues à l'heure actuelle et les plafonds de fréquence à leurs compteurs actuels. Là où le poids répartit le trafic, deux simulations peuvent différer. Comme les règles elles-mêmes, le simulateur demande un plan Growth ou supérieur.

Le formulaire d'une règle affiche aussi son impact avant l'enregistrement. Il compte vos paiements live des 7 derniers jours qui correspondent au canal, à la devise, au pays (lu dans le canal sur lequel le paiement a été débité) et à la plage de montants de la règle, et liste les connexions qui les ont traités et qui les perdraient au profit de celle que vise la règle. Il ignore les conditions avancées et suppose que la règle l'emporte à chaque fois : c'est le maximum de ce qu'elle peut déplacer, pas une prévision.