Introduction

Wajub est une plateforme d'orchestration de paiement pensée pour l'Afrique. Au lieu d'intégrer séparément chaque opérateur Mobile Money, chaque banque ou chaque agrégateur, vous intégrez une seule API. Wajub route ensuite chaque transaction vers le meilleur prestataire disponible, gère les échecs et expose des webhooks standardisés.

Avant de commencer

Pour suivre les exemples de ce site, il vous faut trois choses.

1. Un compte Wajub. Créez-en un gratuitement sur dashboard.wajub.com.
2. Vos API keys. Une fois connecté, ouvrez Settings → Developer → API Keys.
3. Un client HTTP, curl, ou un SDK serveur (Node.js, Python, PHP, Go, Ruby, Java, C#).

Chaque compte possède quatre clés, deux par environnement :

Consultez Configurer votre compte pour une visite guidée du Dashboard, étape par étape.

Ce que vous pouvez construire

• Encaissez des paiements par Mobile Money (MTN MoMo, Orange Money, Wave, Airtel), carte et virement bancaire.
• Versez des fonds sur des portefeuilles Mobile Money via l'API des transferts ou gérez vos bénéficiaires.
• Intégrez le checkout directement dans votre application avec Wajub Components, en React, Vue, Svelte ou JS natif.
• Orchestrez intelligemment vos prestataires grâce au routage et au repli (Orchestration).

Comment fonctionne l'API

L'API Wajub suit les principes REST. Elle utilise des URLs prévisibles, accepte des corps de requête encodés en JSON, renvoie des réponses JSON et s'appuie sur les codes HTTP standard.

Toutes les requêtes passent par une seule URL de base :

https://api.wajub.com

Votre premier appel

Un paiement commence par une requête. Vous envoyez le montant, la devise, la personne qui paie et la page vers laquelle la renvoyer une fois qu'elle a terminé. Wajub crée le paiement, le garde en pending et répond avec une page hébergée où le client choisit son opérateur et confirme. Personne n'est débité à ce stade, et aucun opérateur n'a encore été contacté.

Décrivez le payeur dans l'objet customer plutôt qu'à la racine de la requête. L'API accepte aussi un email au premier niveau, et les deux aboutissent sur la même fiche client, mais l'objet est la structure qui évolue avec vous : il porte aussi name, phone, address et metadata, et ses valeurs priment sur leurs équivalents à la racine. Le callback est l'adresse où Wajub renvoie le client une fois qu'il a terminé sur la page de paiement.

Lancez cet appel depuis votre serveur ou votre terminal avec votre clé privée sandbox (sk_test.…). Ne mettez jamais cette clé dans un navigateur ou une application mobile. Wajub fournit aussi une clé publique (pk_test.…) pour la seule opération sans risque côté client : initialiser un paiement depuis le navigateur. Consultez Concepts clés → API keys pour le détail complet.

curl https://api.wajub.com/payments \
  -H "Authorization: sk_test.kZ3qP8mWvL2xR7tB5nY4hC6dF9jS1aG0eU3i…" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 25000,
    "currency": "XAF",
    "customer": { "email": "amina@example.com" },
    "description": "Order #4172",
    "callback": "https://shop.example.com/order/complete"
  }'

Wajub répond 201 Created. Le paiement existe désormais sur votre compte, il porte un id que vous utiliserez partout ailleurs, et il contient les deux valeurs qui pilotent le reste de votre intégration :

Trois champs de cette réponse comptent dès maintenant :

• authorization_url est la page de paiement hébergée de ce paiement, et de rien d'autre. Redirigez votre client vers elle. C'est la façon la plus simple d'intégrer Wajub, et celle que nous recommandons.
• authorization_token est le jeton de session contenu dans cette URL. Il ne vaut que pour ce paiement et peut être transmis sans risque à un navigateur : c'est ce qu'utilisent les Components quand vous préférez garder le client sur votre propre page.
• transaction.status démarre à pending. Il ne passe à succeeded qu'une fois que le client a confirmé sur son téléphone, ce qui arrive bien après le retour de cet appel.

« Paiement » ou « transaction »

Vous venez de voir les deux mots dans la même réponse, et ils désignent le même objet. « Paiement » est le concept métier, d'où l'endpoint POST /payments. « Transaction » est ce que l'API sérialise, d'où une réponse qui l'imbrique sous "transaction" et préfixe l'id par trx_. Les deux termes sont interchangeables dans toute cette documentation. L'explication complète se trouve dans Concepts clés.

Ce qui se passe ensuite

En ouvrant authorization_url dans votre navigateur, vous arrivez sur la page de paiement, où des numéros de téléphone sandbox permettent de simuler un succès, un refus ou un délai dépassé. Votre serveur confirme ensuite le résultat avec GET /payments/{id} avant de livrer quoi que ce soit, car le seul retour du navigateur peut être falsifié, ou ne jamais se produire. Le Démarrage rapide détaille ces deux étapes avec les numéros de test.

Et maintenant ?

Pour débuter

• Démarrage rapide : traitez un premier paiement en 5 minutes.
• Démarrage rapide des SDKs : installez le SDK de votre langage (Node.js, Python, PHP, Go).
• Concepts clés : cycle de vie d'un paiement, sandbox ou live, jetons de session.
• Environnements et API keys : test ou production.

Prêt à intégrer

• Guides et tutoriels : des intégrations pas à pas pour chaque cas d'usage.
• Moyens de paiement et canaux : couverture complète pays × opérateur.
• Référence API : chaque endpoint, avec des exemples de requête et de réponse.

Pour aller plus loin

• Bonnes pratiques : idempotence, gestion des erreurs, sécurité.
• Passer en live : checklist de production et KYC.
• Tous les SDKs et bibliothèques : Node.js, Python, PHP, Go, SDKs mobiles et navigateur.