Skip to main content
Un paiement naît de l’une de deux façons : via le flux de checkout (votre serveur crée une session, le client paie sur la page hébergée), ou directement par POST /api/v1/payments. Peu importe lequel, le calcul des frais et la confirmation par webhook se comportent exactement pareil ensuite. Seule la façon de démarrer diffère.

POST /api/v1/payments

Encaisse un paiement mobile money sans jamais passer par une session de checkout ni une page hébergée : votre serveur collecte le numéro et l’opérateur du client dans sa propre interface et appelle directement cet endpoint, en sandbox comme en live. Pour l’instant, seul le mobile money est pris en charge ici. La carte demande une étape de tokenisation côté client que cet endpoint ne gère pas encore.

En-têtes

Corps

Réponse 201

Le statut reste pending jusqu’à ce que le webhook payment.succeeded ou payment.failed tranche, exactement comme pour un paiement né d’une session de checkout. Voir Gérer les webhooks.
Un opérateur mobile money ne déplace que sa propre devise nationale. Si currency ne correspond pas à la devise du pays choisi (country), le montant est converti automatiquement avant l’encaissement. La réponse reflète alors le montant réellement prélevé, dans la devise de l’opérateur, pas celle envoyée dans la requête. Par exemple, une requête avec "amount": 1000, "currency": "XAF", "country": "RWA", "provider": "MTN_MOMO_RWA" encaisse réellement en RWF : la réponse renvoie "currency": "RWF" et gross_amount dans cette devise. Si aucun taux n’est disponible pour la devise de l’opérateur, la requête échoue en 422.

Erreurs

GET /api/v1/payments

Liste vos paiements, du plus récent au plus ancien.

GET /api/v1/payments/

Renvoie un paiement, qu’il vienne d’une session de checkout ou d’une charge directe.

Réponse

Voir Paiements pour les statuts.

Erreurs