Cascade et repli

La cascade parcourt une seule fois la liste classée des candidats pendant l'appel POST /payments/{id}, alors que votre requête est encore ouverte. Ce n'est ni une politique de nouvelle tentative ni une tâche en arrière-plan. Lorsqu'elle se termine, la réponse HTTP est déjà en route vers vous.

Vous ne pouvez configurer aucune chaîne de repli. Cette chaîne correspond à la liste de candidats construite par Orchestration des paiements. Cette page explique jusqu'où Wajub la parcourt avant d'abandonner.

Ce qui fait avancer la cascade

Une seule situation la fait avancer : la tentative a échoué d'une manière qui ne dit rien sur le payeur.

Chacun de ces cas marque la tentative comme échouée, pèse sur l'état de cette connexion sur ce canal et descend d'une ligne. Le payeur n'est informé de rien, car rien ne s'est encore passé de son côté.

Ce qui arrête la cascade

Outre la requête restée sans réponse décrite plus haut, quatre situations l'arrêtent. Une seule représente une bonne nouvelle.

Un prestataire a accepté. Cela comprend une acceptation avec pending ou requires_action. Le prestataire prend en charge le paiement dès cet instant et aucune autre connexion n'est essayée.

Un prestataire a refusé pour un motif qui se reproduirait. Un portefeuille vide, un numéro non enregistré, un plafond de l'opérateur, une carte refusée ou une demande laissée expirer par le payeur. Wajub renvoie immédiatement 402 sans consulter le candidat suivant, car un deuxième prestataire poserait la même question à la même personne. Une carte refusée chez Stripe l'est définitivement, et error_code contient le code de refus propre à Stripe.

Une de vos connexions est mal configurée d'une manière que le prestataire ne présente pas comme un refus de vos identifiants. Un champ obligatoire absent pour ce canal, par exemple. Cela arrête la cascade au lieu de passer à la connexion suivante. Une seule connexion défectueuse au début de votre liste peut donc vous faire perdre tous les paiements qui lui sont routés. Les identifiants font exception : manquants, rien n'est envoyé, et refusés, c'est un échec du chemin. Dans les deux cas la connexion suivante est essayée, et la connexion est signalée, comme décrit plus bas.

Trois prestataires ont été essayés. Wajub essaie au plus trois prestataires par appel POST /payments/{id}, sur tous les comptes. Même une liste de dix candidats est parcourue sur trois lignes au maximum. La requête se termine avec 402, alors que des connexions admissibles n'ont pas été essayées. Une connexion ignorée faute d'identifiants compte parmi les trois.

Combien de temps l'appel peut durer

Un prestataire qui ne répond pas à temps correspond à la requête restée sans réponse décrite plus haut : le paiement reste pending et rien d'autre n'est essayé. Avec trois prestataires essayés, POST /payments/{id} peut rester ouvert près d'une minute. Donnez à votre propre client HTTP au moins 90 secondes sur cet appel, pour qu'il n'abandonne pas un paiement que Wajub est encore en train de placer.

Une carte reste chez son prestataire

Une carte que le payeur a saisie dans les champs propres à un prestataire ne peut être débitée que par ce prestataire : un moyen de paiement Stripe.js, une autorisation Paystack enregistrée. Un autre prestataire ne peut pas la lire, et le premier a peut-être déjà débité la carte.

Cette connexion est donc la seule essayée, quelle que soit la connexion que le classement place en premier, et un échec ne bascule jamais vers une autre connexion. Si cette connexion ne peut pas être essayée du tout, parce qu'elle est en pause sur ce canal ou qu'elle n'est plus active, le paiement reçoit la même réponse 422 qu'une liste vide, plutôt que d'aller chez un prestataire incapable de débiter la carte.

Une étape ouverte par un prestataire reste chez lui

Deux sortes d'appels vont au prestataire qui les a ouverts, et ne basculent jamais :

• La fenêtre de paiement propre au prestataire (client_session, la page hébergée ou la feuille SDK du prestataire que le payeur remplit) : elle s'ouvre chez le premier prestataire du classement, et si celui-ci ne peut pas l'ouvrir, l'appel échoue plutôt que d'essayer la connexion suivante.
• Une confirmation (un code, un PIN, un numéro de téléphone, une date de naissance ou une adresse que le payeur envoie après le début du débit) : elle va au prestataire qui l'a demandée et qui détient le débit en attente. Un autre prestataire ne connaît pas ce débit.

Une connexion que le prestataire refuse

Lorsqu'une connexion n'a pas d'identifiants pour le canal, ou que le prestataire refuse la clé qu'elle contient, Wajub l'enregistre sur la connexion.

Le signalement disparaît lorsque vous enregistrez des identifiants différents, lorsqu'un test de connexion réussit, ou au prochain paiement que la connexion prend en charge. Un paiement qui n'a trouvé que des connexions sans identifiants n'est pas imputé au payeur comme un refus : la configuration était en cause, pas lui.

Chaque tentative laisse une ligne

Chaque tentative est listée sur le paiement avec le prestataire essayé, sa réponse, la latence et son rang dans la décision. Un paiement qui est passé deux fois à la connexion suivante en affiche trois, dans l'ordre.

Vous les consultez dans le Dashboard, sous la chronologie du paiement, et dans Konsole à côté de la décision qui les a produits. L'historique des tentatives n'existe qu'à ces endroits. L'objet paiement renvoyé par l'API n'en contient aucune trace.

Un paiement, deux prestataires

1. tentative 1status: failed

   12:31:40

   Rang 1 de la décision, placée là par une règle de routage. Le prestataire a répondu que l'opérateur avait dépassé son délai. L'échec a donc été comptabilisé pour cette connexion sur ce canal, et la connexion suivante a été essayée.

   provider

   cinetpay

   response

   timeout

   latency

   8.0 s

2. tentative 2status: processing

   12:31:49

   Rang 2, la première connexion qu'aucune règle ne désigne. L'opérateur a accepté d'envoyer une demande au payeur. Il s'agit d'une acceptation, la cascade s'est donc arrêtée ici.

   provider

   flutterwave

   response

   pending

   latency

   0.9 s

La deuxième ligne explique la majeure partie de la confusion autour de la cascade.

Les échecs qui pèsent sur une connexion

Les échecs qui viennent du payeur ne pèsent jamais sur une connexion : un portefeuille vide, un numéro erroné ou non enregistré, un plafond de l'opérateur, une carte refusée par sa banque ou par le filtre antifraude du prestataire, une demande que le payeur n'a pas confirmée. Un autre prestataire obtiendrait la même réponse, et les prendre en compte éloignerait progressivement votre trafic d'une connexion en parfait état.

Les échecs du côté du prestataire ou de l'opérateur, eux, comptent. Ils font baisser le taux de réussite récent de la connexion sur ce canal, et une connexion qui échoue de façon répétée est mise en pause, comme décrit ci-dessous.

Le coupe-circuit

Lorsqu'une connexion échoue de façon répétée sur un canal, Wajub la met en pause sur ce canal pendant quelques minutes, avant qu'elle ne vous fasse perdre davantage de paiements, et la remet automatiquement en service dès qu'elle fonctionne de nouveau. Seuls votre compte et ce canal sont concernés : une connexion défaillante sur cm.mtn continue de traiter cm.orange, sans affecter les autres marchands. Les paiements et les payouts partagent l'état d'une connexion sur un canal.

Une connexion en pause n'est pas essayée. Une connexion que vous pensiez voir essayée peut donc être entièrement absente du classement. Elle n'est pas écartée silencieusement : Konsole l'affiche comme Ignoré (circuit ouvert), et la page Matrice montre le circuit sur la cellule de cette connexion.

Décision de routage · cm.mtn · 25 000 XAF

Une connexion en pause, deux connexions classées et la première a traité le paiement.

1. 1
   flutterwave

   accepté0.9 s

   priority 100
2. 2
   pawapay

   jamais appelée

   priority 100
3. cinetpay

   Ignorée (circuit ouvert). La connexion a été mise en pause sur ce canal après des échecs répétés.

Si cette connexion était votre connexion préférée, l'effet est visible et difficile à comprendre sans cette page : une règle qui cible CinetPay semble ignorée pendant quelques minutes. Elle ne l'est pas : la connexion était en pause et ne pouvait pas être placée. Si la règle désigne un prestataire de secours, celui-ci prend la place de CinetPay tant que dure la pause.

Deux prestataires ne peuvent jamais débiter en même temps

Au cours d'un appel, Wajub s'arrête à la première acceptation. Une seule tentative peut donc réussir. Vous devez surtout faire attention à la répétition de l'appel lui-même.

Envoyez un en-tête Idempotency-Key avec POST /payments/{id} : répéter le même appel dans les 24 heures renvoie la même réponse sans exécuter une deuxième cascade. Sans cet en-tête, aucune protection de ce type n'existe. Un client qui répète une requête dont il n'a jamais reçu la réponse peut lancer une deuxième cascade sur un paiement déjà réussi.

Lorsque la liste était vide dès le départ

Une réponse 422 sur la clé channel signifie qu'aucun candidat n'a passé les filtres. Rien n'a donc été essayé et aucune nouvelle tentative ailleurs n'est possible. Il s'agit d'un problème de configuration du compte, pas du payeur : le canal, la devise, un prestataire par lequel Wajub ne peut pas encore débiter ou des connexions en pause sur ce canal n'ont rien laissé à essayer. Une carte détenue par un prestataire dont la connexion ne peut pas être essayée aboutit aussi ici.

Réponse · 422 Unprocessable Content

{

"code": 422,

"status": "Unprocessable Content",

"message": "No eligible payment provider found for this transaction.",

"errors": {

"channel": [

"No eligible payment provider found for this transaction."

]

}

}

La correction ne se trouve jamais dans votre requête. Le journal de routage montre les connexions ignorées parce qu'elles étaient en pause sur le canal. Pour les autres motifs, passez le même canal, la même devise et le même montant dans le simulateur de routage, disponible à partir du plan Growth, qui indique pourquoi chaque connexion a été écartée. Une connexion que vous avez vous-même suspendue, ou un prestataire inactif, n'y apparaît pas du tout.