Encaisser des paiements
Les quatre façons d'encaisser un paiement, ce que chacune vous coûte en code, et la suite.
Encaisser un paiement avec Wajub repose toujours sur la même transaction. Ce qui change entre les quatre modes d'intégration, c'est qui affiche l'écran où le client confirme, et donc la part de l'expérience de paiement que vous possédez et devez maintenir.
Choisissez sur ce seul critère. Tout le reste, les opérateurs que vous atteignez, les webhooks que vous recevez, les remboursements que vous pouvez émettre, est identique pour les quatre.
Quatre points d'entrée
Chaque mode produit un écran différent pour votre client, et c'est toute la différence. Voici à quoi ressemble concrètement chacun une fois en ligne.
Recommandé
Checkout hébergé
Créez le paiement, redirigez vers l'authorization_url, traitez le webhook. Wajub affiche le choix de l'opérateur, la demande de confirmation et le résultat.
Dans votre page
Composants intégrés
Le même checkout, monté dans votre propre mise en page avec le jeton de session. React, Vue, Svelte ou JavaScript vanilla.
Sans code
Liens de paiement
Une URL à partager ou un QR code, sans aucune intégration. Production uniquement, et 25 liens sur l'offre gratuite.
Contrôle total
API directe
Vous collectez le numéro et appelez POST /payments/{id} vous-même. La demande de confirmation arrive sur le téléphone, vous affichez tout le reste.
Vous hésitez ? Choisir une intégration compare les quatre sur le code, la personnalisation et les cas d'usage. Si vous préférez en voir un fonctionner avant de choisir, le Démarrage rapide mène un paiement sandbox de zéro jusqu'à un webhook vérifié.
Moyens de paiement
Le Mobile Money est la colonne vertébrale : MTN, Orange, Wave, Airtel, Moov et M-Pesa, dans une
douzaine de pays. Les cartes et les virements bancaires domestiques sont disponibles là où l'opérateur
les prend en charge. Les canaux sont nommés country.operator : cm.mtn est MTN Mobile Money au
Cameroun et sn.wave est Wave au Sénégal.
La matrice complète des pays et des opérateurs se trouve dans Moyens de paiement et canaux, et les formats de numéro acceptés par chaque opérateur dans Formats de numéros de téléphone. Un mauvais format de numéro fait échouer le paiement avant même que le client voie une demande de confirmation : cette deuxième page mérite d'être lue une fois.
Les deux appels
Créer un paiement ne débite jamais personne. POST /payments enregistre l'intention, la garde en
pending, et vous renvoie l'URL d'une page hébergée et un jeton de session utilisable dans le
navigateur. Rien n'a encore atteint un opérateur.
C'est le second appel qui débite, et trois des quatre modes le font pour vous. Le Checkout hébergé le
fait quand le client appuie sur confirmer sur la page Wajub, les Composants intégrés le font depuis
votre page, et un lien de paiement le fait sur sa propre page hébergée. Seule l'API directe vous le
laisse : vous collectez vous-même le numéro de téléphone ou la carte, puis vous envoyez
POST /payments/{id} avec un channel et les détails du paiement, et la demande de confirmation part
vers le téléphone du client.
Une clé privée dans un navigateur est refusée
sk.… envoyée depuis une requête portant un en-tête Origin ou Referer est rejetée avec un
403, et le propriétaire de la clé reçoit un e-mail. L'API directe a donc sa place sur votre
serveur. Le code front-end utilise la clé publique, ou le jeton de session que renvoie la réponse
de création.
Ressources de l'API
Les paiements partagent une seule API avec tous les autres produits. Voici les ressources qu'ils appellent ; les paramètres et les réponses complets se trouvent dans la Référence API.
| Endpoint | Méthodes | Utilisé pour |
|---|---|---|
/payments | GET POST DELETE | Créer, lister, récupérer et annuler un paiement |
/payments/{id} | POST | Le débiter sur un canal, et ses /splits pour les échéances |
/refunds | GET POST | Émettre un remboursement et le suivre |
/customers | GET POST PUT DELETE | Clients récurrents, plus blocage et désactivation |
/disputes | GET POST | Preuves, acceptation, clôture et messages |
/links | GET POST PUT DELETE | Liens de paiement. Production uniquement |
Les appels de paiement standard n'ont besoin d'aucun en-tête propre au produit. Une marketplace qui
attribue le paiement à l'un de ses sous-comptes ajoute X-Sync: acc_… au même appel, comme décrit
dans Sync → Ressources de l'API.
Après le paiement
| Besoin | Où |
|---|---|
| Connaître le résultat au moment où il arrive | Webhooks |
| Comprendre chaque état et ses transitions | Cycle de vie d'un paiement |
| Rembourser un paiement | Remboursements |
| Traiter un litige ou une rétrofacturation | Litiges |
| Reconnaître un client récurrent | Clients |
| Choisir entre webhooks et polling | Webhooks ou polling |
Pages associées
- Démarrage rapide PaiementsUn paiement sandbox, de zéro jusqu'à un webhook vérifié.
- Choisir une intégrationLes quatre modes comparés sur le code, le contrôle et les cas d'usage.
- Moyens de paiement et canauxLa couverture par pays et par opérateur, canal par canal.
- Accepter un paiementLe parcours de bout en bout : créer, rediriger, vérifier, livrer.