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. Le moteur continue de s'exécuter, de classer et d'enregistrer une décision, 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, Providers. Les deux côtés doivent être actifs : le prestataire lui-même et votre connexion. Le routeur retire une ligne inactive d'un côté ou de l'autre avant tout classement. 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 Routing configuration.

La priorité est absolue. Une connexion d'un palier inférieur n'est jamais essayée avant que toutes les connexions des paliers supérieurs aient échoué, quels que soient son coût et la règle qui lui correspond.

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.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
  -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.PVrU8x2k \
  -H "Authorization: sk.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "cm.mobile",
    "data": { "phone": "+237670000000" }
  }'

cm.mobile n'atteint jamais le routeur. resolveOperatorChannel() lit le numéro, détermine l'opérateur et transmet cm.mtn au routeur. Les candidats sont ensuite filtrés selon ce canal résolu. Une connexion qui déclare cm.orange, mais pas cm.mtn, est donc retirée avant le classement.

4. Lire la décision

Ouvrez le paiement dans le Dashboard. Sous la chronologie se trouve Routing decision, et « View routing details » ouvre la liste construite par le routeur, dans l'ordre de sa construction.

Les deux scores valent 0, ce qui est normal sur un nouveau compte. Le score additionne uniquement les bonus des règles, du coût le plus faible et de la télémétrie. Sans règle, sans tarif négocié et sans historique récent sur ce canal, rien ne peut être ajouté. La priorité fait 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 décision plutôt qu'une ligne par paiement. Cette page est réservée au mode live par le middleware de route, 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

PaymentResource n'expose 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.