Démarrage rapide

Vous n'avez rien à activer. L'orchestration classe vos connexions depuis votre premier paiement live, et aucun champ de requête ne la démarre ou ne l'arrête. Ce démarrage rapide n'ajoute donc aucun appel à votre intégration. Il rend le classement visible, puis le modifie une fois pour vous permettre d'observer le changement.

Cinq étapes, toutes en mode live. La première explique pourquoi.

1. Connecter un deuxième prestataire

Une seule connexion n'offre aucune solution de repli. Wajub enregistre toujours une décision de routage, mais la liste ne contient qu'une ligne et l'échec met fin au paiement.

Ajoutez un deuxième prestataire dans le Dashboard, sous Orchestration, Fournisseurs. Les deux côtés doivent être actifs : le prestataire lui-même et votre connexion. Un prestataire ou une connexion inactifs ne sont jamais essayés. Une connexion inachevée est donc invisible, pas simplement placée en dernier.

2. Définir leur ordre

Chaque connexion possède deux nombres, tous deux disponibles sur la page du prestataire sous Configuration du routage.

La priorité ordonne toutes les connexions qu'aucune règle de routage ne désigne, sur un canal sans politique de canal. Une connexion d'un palier inférieur n'est jamais essayée avant que toutes les connexions des paliers supérieurs aient échoué, quel que soit son coût. Une règle de routage correspondante et une politique de canal passent avant elle, c'est pourquoi ce guide de démarrage n'utilise ni l'une ni l'autre : Orchestration des paiements décrit l'ordre complet.

Définissez une connexion sur 10 et laissez l'autre sur 0. Vous obtenez deux paliers, la configuration minimale qui permet d'observer quelque chose dans les étapes suivantes.

3. Envoyer un paiement live

Un paiement nécessite deux appels. C'est le point sur lequel la plupart des intégrations se trompent : le premier appel n'effectue aucun routage. Il crée la transaction et n'accepte ni canal ni prestataire.

Envoyez un montant, une devise et l'un des moyens suivants pour identifier le payeur : email, phone, customer_id ou customer.

curl https://api.wajub.com/payments \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 500,
    "currency": "XAF",
    "phone": "+237670000000",
    "description": "Watching the router work"
  }'

Le deuxième appel effectue le routage. Il indique un canal et tout ce qui est décrit dans Orchestration des paiements se déroule pendant cet appel.

curl https://api.wajub.com/payments/trx_CSUGajfv9xh0XQ5wu2lx \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "cm.mobile",
    "data": { "phone": "+237670000000" }
  }'

Le routage utilise toujours le canal de l'opérateur. Wajub lit le numéro, reconnaît MTN et route le paiement comme cm.mtn. Une connexion qui déclare cm.orange, mais pas cm.mtn, est donc écartée.

4. Lire la décision

Ouvrez le paiement dans le Dashboard. Sous la chronologie se trouve Décision de routage, et « Voir les détails de routage » ouvre la liste classée, dans l'ordre où les connexions devaient être essayées.

Les deux connexions portent Coût le plus bas, ce qui est normal sur un nouveau compte : sans tarif négocié, elles coûtent la même chose pour le routage, et sans historique récent sur ce canal, aucune ne se distingue par sa réussite récente. Rien ne les départage, aucune règle ne correspond et le canal n'a pas de politique : la priorité fait donc tout le travail, exactement comme vous l'avez configurée à l'étape 2.

La même liste est disponible dans le journal de routage, avec une ligne par tentative de débit plutôt qu'une ligne par paiement. Cette page est réservée au mode live, pour la raison indiquée dans le premier encadré.

5. Déplacer une connexion et observer son changement

Inversez les deux priorités : la connexion qui était sur 0 passe à 10, tandis que l'autre passe à 0. Envoyez un deuxième paiement identique au premier.

La cascade apparaît dans le nouvel ordre. Votre code n'a pas changé, aucun déploiement n'a eu lieu et la requête de paiement est identique octet pour octet à celle envoyée cinq minutes plus tôt. C'est tout l'intérêt de cette fonctionnalité. Observez-la une fois vous-même avant de lui faire confiance en production.

Ce que l'API ne vous indique pas

L'objet paiement n'a aucun champ provider. GET /payments/{id} renvoie le channel débité, jamais la connexion qui l'a traité. Aucun endpoint marchand ne renvoie la priorité, le poids ou la liste des candidats. Le routage est visible dans le Dashboard et dans Konsole, nulle part ailleurs.