Comment accepter le mobile money sur un site e-commerce
Mis à jour le 2026-09-23
Ajouter le mobile money à une boutique ne consiste pas seulement à placer un logo d’opérateur près du bouton payer. La boutique doit connaître les moyens réellement activés, guider l’acheteur et décider à quel moment livrer sans risque de doublon. Voici un parcours de la commande au paiement qui ne suppose pas que chaque rail soit disponible pour chaque marchand.
Choisissez le parcours adapté à votre boutique
Un lien de paiement convient à une facture, une vente assistée ou un petit catalogue lorsque vous créez un paiement du bon montant et partagez sa page hébergée. Un checkout hébergé permet de diriger l’acheteur du panier vers une page de paiement. Une API de paiement sert un back-end personnalisé qui doit créer et suivre les paiements avec ses propres commandes.
Ces parcours ne garantissent pas qu’un opérateur mobile money précis soit actif. Terminez l’onboarding entreprise et vérifiez les méthodes activées pour votre compte, marché, devise et opération avant de les annoncer. ZyndPay ne promeut actuellement aucun plugin public WooCommerce ou WordPress maintenu : basez l’intégration sur les liens, le checkout ou l’API vérifiés.
Créez la commande avant d’ouvrir le checkout
Votre boutique reste responsable du total panier, de la devise, des taxes, de la livraison et d’une référence de commande unique. Créez le paiement avec cette référence et conservez l’identifiant de paiement renvoyé. Le support doit pouvoir retrouver la tentative depuis la commande sans recherche par nom du client ni capture d’écran.
Gardez montant et référence stables pour cette tentative. Si le panier change, créez une nouvelle tentative appropriée selon la politique de votre boutique plutôt que de réutiliser discrètement un paiement d’un autre montant. Affichez le montant et le moyen sélectionnés dans le checkout réel, pas une liste d’opérateurs codée en dur depuis une page marketing.
Prévoyez un résultat mobile money en attente
Un paiement mobile money peut demander une autorisation du client puis produire un résultat asynchrone. La spécification GSMA sur les paiements marchands décrit des demandes en attente qui se terminent ensuite par un succès, un échec ou une expiration. C’est une référence sectorielle, pas une affirmation que ZyndPay implémente cette spécification ni une promesse sur un opérateur particulier.
Indiquez à l’acheteur quand la tentative reste en attente. Ne marquez pas une commande payée parce qu’une demande a été acceptée, que le navigateur est revenu ou que le client a partagé un message de confirmation. Si le client ferme la page, conservez la référence afin de consulter l’état de paiement faisant autorité et de proposer la suite adaptée.
Livrez une seule fois après confirmation côté serveur
Utilisez l’état de paiement authentifié et les événements webhook signés proposés à votre intégration. Vérifiez chaque événement selon la documentation, puis rendez la mise à jour de la commande idempotente : une livraison répétée ne doit provoquer ni second envoi, ni second droit d’accès, ni second crédit. Séparez les tentatives en attente, échouées, expirées et confirmées.
Une page de retour rassure l’acheteur, mais ne remplace pas cette décision côté serveur. Si un webhook tarde, rapprochez paiement et commande par leurs références au lieu de supposer que l’absence d’événement signifie un échec. Le guide sur les webhooks détaille les principes de vérification et de relance.
Rapprochez les exceptions avant de clore la commande
Conservez référence commande, identifiant paiement, moyen choisi, montant et états successifs pour que support et finance puissent expliquer une tentative. Un remboursement, un litige ou un règlement reste lié au paiement initial sans être le même événement. Comparez les enregistrements avant de changer une commande ou d’annoncer au client que les fonds sont revenus.
Avant le live, testez la finalisation ordinaire, un acheteur qui quitte le checkout, une autorisation en attente, une tentative échouée ou expirée, un webhook répété et un endpoint de réception indisponible. Utilisez uniquement les parcours de test proposés à votre compte : réussir en sandbox ne prouve pas qu’un rail ou un marché live est approuvé.
Sources primaires
FAQ
- Puis-je accepter le mobile money sans installer de plugin e-commerce ?
- Lorsque le mobile money est activé pour votre compte approuvé, un lien de paiement ou un checkout hébergé peut convenir sans plugin. Une boutique personnalisée peut utiliser l’API prise en charge. ZyndPay ne promeut actuellement aucun plugin public WooCommerce ou WordPress maintenu.
- Quels opérateurs mobile money apparaîtront au checkout ?
- Le checkout live ou la réponse API affiche les méthodes disponibles pour le compte et l’opération. La disponibilité varie selon marché, devise, contexte client et état du rail ; une liste générique par pays ou opérateur ne fait pas autorité.
- Quand ma boutique doit-elle marquer la commande comme payée ?
- Appliquez votre politique de livraison après vérification de l’état de paiement confirmé côté serveur et traitement sûr des événements signés. Une demande acceptée, un retour navigateur ou une capture client ne suffisent pas.
- Que faire si l’acheteur ferme la page de paiement ?
- Conservez les références de commande et de paiement, affichez un état en attente si nécessaire, puis rapprochez avec l’état authentifié. Ne créez pas un second encaissement au seul motif que la page s’est fermée.