Prestataires et canaux

Un canal désigne un opérateur dans un pays : cm.mtn correspond à MTN Cameroun et sn.wave à Wave Sénégal. C'est le champ qui indique où l'argent est réellement envoyé. Il appartient au bénéficiaire, et non au payout, et reste donc fixé dès la création de la destination.

Nommer un canal ne garantit pas que vous puissiez y envoyer un payout. La liste ci-dessous indique ce que l'API accepte. L'exécution réelle dépend de votre compte.

Conditions à remplir

Un payout passe quatre contrôles distincts avant même d'atteindre un opérateur. Chacun renvoie son propre message.

Les trois derniers contrôles renvoient volontairement la même erreur : un marchand n'a pas à savoir quel circuit de Wajub est en panne. En pratique, un canal peut figurer dans le tableau ci-dessous, être accepté à la création, puis n'avoir aucun circuit disponible.

Canaux acceptés par l'API

L'API accepte cinquante canaux Mobile Money dans vingt-deux pays. Chacun constitue une valeur valide pour beneficiary.channel.

cd.vodacom et mz.mpesa désignent tous deux M-Pesa, tandis que cm.eu désigne Express Union. Le slug suit l'opérateur utilisé par Wajub pour le routage, pas la marque affichée sur le téléphone du client.

Trois autres canaux sont valides pour un bénéficiaire sans être du Mobile Money : ci.djamo et sn.djamo, des portefeuilles Djamo payés par numéro de téléphone, et wajub, un autre compte Wajub payé par son numéro de compte, qui ne quitte jamais Wajub et n'entraîne aucuns frais.

Canal générique

Un payout désigne son canal : le slug de l'opérateur dans ce tableau, comme ke.mpesa ou eg.vodafone. Il n'y a qu'une exception, le Cameroun : cm.mobile détermine à partir du numéro s'il s'agit de cm.mtn ou de cm.orange. La page Bénéficiaires explique le fonctionnement de cette résolution et ses cas d'échec.

Aucun autre pays n'a de canal générique. ke.mobile, eg.mobile ou tout autre {country}.mobile est refusé comme un canal inconnu, avec 422 et The selected channel is invalid.. Même au Cameroun, indiquez l'opérateur dès que vous le connaissez : un échec de résolution produit une erreur 422, alors qu'un slug explicite serait passé directement.

Couverture propre à votre compte

Le circuit propre à Wajub effectue des payouts sur cm.mtn, cm.orange et cm.eu. Tous les autres canaux du tableau ci-dessus nécessitent un prestataire de payout connecté à votre compte et approuvé par Wajub pour les payouts live, et GET /providers liste ce que possède votre compte. Encaisser sur un canal ne signifie jamais que vous pouvez aussi y effectuer un décaissement, et connecter un prestataire pour les encaissements n'active pas son côté payout.

Ce que la devise détermine ou non

Aucune règle ne lie une devise au pays du canal. Le payout est contrôlé par rapport aux plafonds configurés pour sa devise, à la liste des devises actives et aux devises prises en charge par vos prestataires. Rien ne compare la devise aux deux lettres du slug.

En pratique, vous enverrez des XAF sur cm.* et des XOF sur ci.*, car ce sont les devises de règlement des opérateurs. Une incohérence ne produit cependant pas d'erreur dédiée. Elle renvoie le même message No payout provider is available for this channel and currency. que tout autre manque de couverture.

Canaux existants qui ne sont pas des canaux de payout

Le catalogue Wajub marque quelques destinations supplémentaires comme compatibles avec les payouts. L'API les refuse toutes pour un bénéficiaire créé par votre intégration.

Envoyer l'une de ces valeurs comme beneficiary.channel renvoie 422 The selected beneficiary.channel is invalid.. Des destinations bancaires existent, sous forme de comptes de versement que vous créez dans le Dashboard sur le canal wire.

Prestataire chargé du payout

Vous ne le choisissez jamais. Un transfert ne possède aucun champ provider ni aucune surcharge par appel. Vous indiquez un canal, puis Wajub choisit parmi les circuits capables de le traiter.

L'ordre est déterministe, et non équilibré, car les mouvements d'argent privilégient la prévisibilité à la répartition de charge. Les candidats sont triés selon la priorité définie pour chaque prestataire, de la plus haute à la plus basse. Un échec fait passer au suivant. Un circuit dont les échecs récents ont déclenché le coupe-circuit est ignoré jusqu'à son rétablissement. La page Orchestration explique comment définir cette priorité et comment fonctionne le repli.

Le transfert indique ensuite dans provider le prestataire qui l'a exécuté. L'identifiant propre à l'opérateur apparaît dans provider_reference une fois que le payout l'a atteint.