Solutions par activité

L'API est la même pour tout le monde. Ce qui change d'une activité à l'autre, ce sont les produits que vous assemblez et l'ordre dans lequel vous les construisez. Une boutique a besoin d'un checkout et d'un webhook. Une marketplace a besoin que l'argent arrive à quelqu'un d'autre qu'elle. Une plateforme de paie n'encaisse presque rien.

Chaque parcours ci-dessous liste ses produits dans l'ordre de construction et dit clairement ce qu'il exige : le plan à partir duquel il est disponible, et si vous pouvez le construire en sandbox ou uniquement en production.

Quel est votre parcours

Répondez à une seule question : où finit l'argent ?

Les parcours se recoupent, et c'est normal. Une marketplace vend et rembourse aussi : elle suit donc d'abord le parcours e-commerce et ajoute les sous-comptes par-dessus.

Le socle de tous les parcours

Les paiements, la page de checkout hébergée, les remboursements, les clients, les webhooks et les événements forment le cœur. Aucun plan ne les restreint, et ils se comportent de la même façon en sandbox et en production. Quoi que vous construisiez, c'est la base sur laquelle vous vous appuyez, et c'est ce qu'il faut faire fonctionner avant tout le reste.

E-commerce et vente en ligne

Vous vendez des produits ou des services, et chaque client paie une fois.

Avant d'écrire la moindre ligne de code, vérifiez sur quoi tourne déjà votre boutique. Si c'est WordPress, le plugin officiel couvre WooCommerce, GiveWP, Easy Digital Downloads, Tutor LMS, MemberPress et Gravity Forms, avec un shortcode [wajub_pay] pour tout le reste. Vous collez vos clés et c'est terminé, il n'y a aucune intégration à maintenir.

Si vous construisez la boutique vous-même, trois étapes suffisent. Vous créez le paiement quand le panier est validé, vous envoyez le client vers l'authorization_url renvoyée, et vous livrez la commande quand le webhook payment.succeeded arrive. Ne livrez jamais sur la seule redirection : un client qui ferme l'onglet paie quand même.

Les remboursements arrivent en dernier, et c'est voulu. Il vous faut des commandes avant d'avoir quoi que ce soit à rembourser, et l'endpoint de remboursement a besoin d'un identifiant de paiement que vous n'aurez qu'une fois la première étape fonctionnelle.

Tout ceci fonctionne avec Pay as you go, en sandbox comme en production. Seule exception : les liens de paiement, disponibles uniquement en production et limités à 25 liens sur le plan gratuit, avant de devenir illimités avec Growth.

Marketplace et plateforme

Vous mettez en relation des vendeurs et des acheteurs, et l'argent doit arriver au vendeur au lieu de s'arrêter chez vous.

C'est le rôle de Sync. Chaque vendeur devient un sous-compte avec ses propres capacités, sa propre tarification et son propre historique de transactions. Vous agissez ensuite pour le compte d'un vendeur en ajoutant un en-tête à un appel que vous savez déjà faire, X-Sync: acc_…, sans deuxième API à apprendre. Inscrivez les vendeurs avant de faire passer le moindre paiement par eux, car un sous-compte doit être accepté et actif avant de pouvoir effectuer des transactions.

Les payouts bouclent la boucle. Les bénéficiaires vous permettent d'enregistrer une fois le portefeuille d'un vendeur, au lieu de renvoyer le numéro et l'opérateur à chaque transfert.

Sync nécessite le plan Scale. Il fonctionne en sandbox, mais un sous-compte appartient à un seul environnement : appeler un sous-compte sandbox avec une clé de production, ou l'inverse, renvoie une 403 qui indique la clé attendue. Les transferts et les bénéficiaires sont disponibles sur tous les plans.

Payouts en masse et économie à la tâche

Vous distribuez des fonds : salaires, gains de chauffeurs, commissions, primes.

Il n'y a pas d'endpoint de lot. Vous appelez POST /transfers une fois par destinataire, dans une boucle. C'est plus simple qu'il n'y paraît, à condition de cadencer la boucle selon la limite de requêtes de votre plan et de traiter chaque transfert comme une unité idempotente. Un lot à moitié échoué n'est alors qu'une liste de transferts à relancer un par un.

Enregistrer d'abord vos destinataires comme bénéficiaires est ce qui raccourcit cette boucle. Vous passez un identifiant ben_… au lieu de répéter le numéro de téléphone, l'opérateur et le pays à chaque appel, et une paie devient une boucle sur des identifiants que vous avez déjà.

Surveillez le solde, pas la réponse de l'API. Un transfert est refusé quand le solde disponible est insuffisant : une série de payouts doit donc lire le solde avant de démarrer, au lieu de découvrir le problème au quarantième destinataire.

Les transferts, les bénéficiaires et le solde sont disponibles sur tous les plans et fonctionnent en sandbox via l'API. Dans le Dashboard, le bouton qui crée un transfert à la main est réservé à la production.

Abonnements et facturation récurrente

Vous facturez le même client à chaque cycle.

Sur Wajub, la facturation récurrente repose sur des factures, pas sur un mandat enregistré. Le Mobile Money ne permet pas de débiter un portefeuille plus tard sans que le client s'en aperçoive : chaque cycle produit donc une nouvelle facture avec son propre lien de paiement, et le client l'approuve. Vous créez la première facture avec is_recurring activé et une recurring_frequency parmi daily, weekly, monthly, quarterly ou yearly, et Wajub émet les suivantes selon le calendrier. Changer le montant ou le cycle revient à mettre à jour cette facture, et l'annuler arrête la facturation.

Ce sont les relances qui font vraiment encaisser ce modèle. Comme chaque cycle demande une approbation humaine, une facture impayée le reste tant que personne n'est relancé : considérez le calendrier de relances comme une partie de l'intégration, pas comme un bonus.

Il n'existe pas de ressource produits, prix ou coupons pour modéliser votre catalogue. Si vous avez besoin de plans par paliers, de prorata ou de facturation à l'usage, vous construisez cette logique de votre côté au-dessus de l'API Payments, et le guide de facturation récurrente vous accompagne.

La facturation est disponible sur tous les plans, limitée à 10 factures avec Pay as you go et illimitée à partir de Growth. La génération récurrente elle-même nécessite Growth ou plus, et elle échoue sans bruit si vous repassez en dessous : la facture parente est conservée, mais aucun nouveau cycle n'est émis tant que le plan n'est pas rétabli. Les factures sont réservées à la production : construisez et testez d'abord la gestion des paiements et des webhooks en sandbox, puis changez de clé avant de toucher à la facturation.