Skip to main content

Vue d’ensemble

Les paiements en application utilisent le type redirect qui permet de contrôler l’expérience utilisateur dans votre application tout en redirigeant le client vers son application de paiement mobile pour finaliser le paiement. Pour plus de détails : /api-reference/demandes-de-paiement/créer-une-demande-de-paiement

Caractéristiques

  • Contrôle de l’expérience : Vous contrôlez le flux dans votre application
  • Redirection vers l’app : Le client est redirigé vers son application de paiement mobile (Wave, Orange Money, Djamo, etc.)
  • Callbacks personnalisés : Vous définissez les URLs de succès et d’erreur
  • Retour automatique : Le client est automatiquement redirigé vers votre application après le paiement

Cas d’usage

  • Applications mobiles natives
  • Applications web avec intégration personnalisée
  • Expériences de paiement contrôlées par le développeur
  • Intégrations nécessitant un contrôle total du flux

Créer une demande de paiement redirect

Pour créer une demande de paiement redirect, utilisez l’endpoint /partner_api/payment_requests avec le type redirect.

Paramètres requis

  • storeId : Identifiant du magasin
  • amountCents : Montant en centimes (minimum 100 centimes)
  • currency : Code devise (ISO 4217), généralement “XOF”
  • reference : Référence unique du paiement (1-100 caractères)
  • paymentDetails.type : "redirect"
  • paymentDetails.data.paymentMethod : Méthode de paiement (wave, orange, mtn, moov, djamo)
  • paymentDetails.data.successUrl : URL de redirection en cas de succès (requis)
  • paymentDetails.data.errorUrl : URL de redirection en cas d’erreur (requis)

Contourner le checkout Jeko (optionnel — encaissement direct fournisseur)

Par défaut, une demande redirect renvoie une URL de paiement hébergée pour guider le payeur jusqu’à son opérateur.
Ce flux est recommandé car il gère pour vous les cas limites propres à chaque opérateur (redirections, contraintes d’interface, variations de parcours).
Si vous connaissez déjà le numéro du payeur et la méthode (paymentMethod), vous pouvez activer le mode direct pour envoyer le payeur vers son fournisseur de paiement sans étape intermédiaire.
Ce mode est surtout adapté si vous voulez construire votre propre expérience de checkout et gérer vous-même les cas limites propres à chaque opérateur.
  • paymentDetails.data.forceProviderDirect : true pour activer ce mode ; sinon omis ou false (flux standard).
  • paymentDetails.data.payerPhone : numéro mobile du payeur (MSISDN, en pratique souvent au format international, ex. +2250765432108) ; obligatoire lorsque forceProviderDirect est true.

Exemple de requête

Réponse réussie

Important : Le champ redirectUrl contient l’URL vers laquelle vous devez rediriger le client. Cette URL redirigera ensuite le client vers son application de paiement mobile.

Flux de paiement

  1. Créer la demande : Créez une demande de paiement redirect avec vos URLs de callback
  2. Rediriger le client : Redirigez le client vers redirectUrl
  3. Redirection automatique : JEKO redirige le client vers son application de paiement mobile
  4. Paiement client : Le client complète le paiement dans son application
  5. Retour automatique : Le client est redirigé vers votre successUrl ou errorUrl
  6. Notification : Vous recevez également une notification via webhook

Intégration dans votre application

Exemple : Application web

Exemple : Application mobile (React Native)

Gérer les callbacks

Page de succès

Page d’erreur

Vérifier le statut

Pour vérifier le statut d’une demande de paiement :
Réponse avec transaction réussie :

Méthodes de paiement supportées

  • "wave" : Wave Mobile Money
  • "orange" : Orange Money
  • "mtn" : MTN Mobile Money
  • "moov" : Moov Money
  • "djamo" : DJAMO

URLs de callback

Format des URLs

Les URLs de succès et d’erreur doivent être des URLs HTTPS valides. Vous pouvez inclure des paramètres de requête pour identifier la transaction :
Pour les applications mobiles, vous pouvez utiliser des deep links :
Important : Assurez-vous que votre application est configurée pour gérer ces deep links.

Bonnes pratiques

  1. URLs sécurisées : Utilisez toujours HTTPS pour les URLs de callback
  2. Paramètres de requête : Incluez des paramètres pour identifier la transaction (référence, orderId, etc.)
  3. Vérification du statut : Toujours vérifier le statut du paiement via l’API après le callback
  4. Gestion des erreurs : Implémentez une gestion d’erreurs robuste pour les cas d’échec
  5. Webhooks : Utilisez les webhooks comme source de vérité principale, les callbacks comme fallback
  6. Expérience utilisateur : Affichez des messages clairs sur les pages de succès et d’erreur
  7. Timeouts : Gérez les cas où le client ne revient pas de l’application de paiement

Cas d’usage avancés

Sélection dynamique de la méthode de paiement

Permettez à l’utilisateur de choisir sa méthode de paiement avant de créer la demande :

Gestion des timeouts

Si le client ne revient pas après un certain temps, vérifiez le statut :