ITSkillsCenter
Blog

Mobile money en backend 2026 — Wave, Orange Money, PayDunya, CinetPay

24 min de lecture

Sommaire

Introduction

En 2026, accepter un paiement mobile money depuis une application web est devenu un prérequis d’entrée pour toute solution SaaS, e-commerce ou marketplace qui sert le marché francophone d’Afrique. Le terrain est dominé par trois familles d’acteurs : les opérateurs télécoms qui exposent leur propre API (Wave, Orange Money), les portefeuilles d’opérateurs qui passent par les agrégateurs (Mixx by Yas au Sénégal), et les agrégateurs paneuropéens-africains qui unifient l’ensemble derrière une API unique (PayDunya, CinetPay).

Le choix d’architecture n’est pas anodin. Une intégration directe Wave et Orange Money optimise les coûts de transaction et raccourcit la chaîne de panne, mais multiplie le code à maintenir et impose deux contrats webhook à fiabiliser. Une intégration agrégateur unique simplifie le code mais introduit une marge supplémentaire, un point de défaillance unique et parfois des limitations sur les retraits B2B. Beaucoup de produits matures en 2026 finissent en hybride : Wave et Orange Money en direct pour le gros du flux, agrégateur en filet de sécurité ou pour les méthodes secondaires.

Cette ressource expose les concepts, le vocabulaire, les contrats d’API et l’architecture cible que les articles techniques de la série déclinent ensuite en pas-à-pas Laravel, Next.js et Django.

Le paysage des paiements en 2026

Au Sénégal, le volume du mobile money a atteint environ 15 300 milliards de FCFA en 2025, soit plus de 27 milliards de dollars de transactions, selon les chiffres publiés par la Banque centrale des États de l’Afrique de l’Ouest en mars 2026 — faisant du Sénégal le leader régional avec 24 % des parts UEMOA. La bascule structurelle initiée par Wave a poussé les concurrents historiques à aligner leurs tarifs et à ouvrir leurs API. En Côte d’Ivoire, Wave et Orange Money se partagent l’essentiel du marché grand public, MTN MoMo joue un rôle significatif mais hors Sénégal, et Moov Money complète le tableau. Au Bénin, au Togo, au Burkina Faso et au Mali, l’opérateur dominant varie : Mixx by Yas Togo (ex-T-Money), Moov Africa, Telecel, Orange ou Sotelma-Mali se partagent les utilisateurs.

Pour un développeur, deux conséquences pratiques :

  • Aucune solution unique ne couvre tous les pays sans approximation. Un produit qui vend dans cinq pays a presque toujours besoin d’un mix : passerelle native dans le pays principal, agrégateur ailleurs.
  • Le ticket moyen, la part B2B et la fréquence des retraits dictent le choix. Une plateforme freelance qui reverse des commissions chaque semaine n’a pas les mêmes besoins qu’un site e-commerce qui encaisse des paniers à 25 000 XOF. La première a besoin d’une API de payout robuste (Wave Payout, PayDunya disbursement). La seconde a besoin d’une API de checkout rapide à intégrer (Wave Checkout, Orange Money Web Payment, CinetPay).

Le glossaire utile à fixer avant d’aller plus loin : la collecte (cash-in, encaissement) est l’argent qui rentre depuis le portefeuille du client vers le marchand. Le versement (cash-out, payout, disbursement) est l’inverse, du compte marchand vers un portefeuille. Le wallet désigne le compte mobile money. La session de checkout est l’objet créé côté API qui matérialise une intention de paiement et porte un identifiant unique réutilisable côté client comme côté webhook.

Passerelle directe ou agrégateur ?

La décision tient en quatre critères.

Le coût de transaction d’abord : Wave affiche typiquement des frais inférieurs aux agrégateurs sur la collecte au Sénégal, mais l’écart se réduit dès qu’on intègre via un agrégateur qui négocie au volume. Sur le payout, Wave Payout reste imbattable pour les petits montants haute fréquence — les agrégateurs prélèvent souvent un pourcentage minimum par transaction qui pénalise les versements de moins de 5 000 XOF.

Le temps de mise en marché ensuite. Une intégration directe Wave Checkout demande typiquement deux à cinq jours de développement plus deux semaines d’aller-retour KYC pour les clés de production. Un agrégateur comme PayDunya ou CinetPay permet d’aller plus vite si vous n’avez besoin que de la collecte multi-méthodes — l’inscription business reste obligatoire mais la couverture est immédiate.

La profondeur d’intégration est le troisième critère. L’API directe expose les statuts intermédiaires (processing, succeeded, failed, reversed chez Wave Payout) et les messages d’erreur précis (insufficient-funds, payer-mobile-mismatch). Un agrégateur normalise ces statuts et perd parfois le détail. Si votre produit a besoin de réagir finement à un échec — relance, message client localisé, choix automatique d’une méthode alternative — le direct paye à terme.

La réversibilité enfin. Wave Checkout expose POST /v1/checkout/sessions/:id/refund qui permet de rembourser un paiement complété. PayDunya pousse les remboursements via un workflow administratif sur leur back-office. CinetPay implémente le remboursement avec des contraintes opérationnelles. Si votre flux métier exige des annulations programmatiques fréquentes — marketplaces avec litiges, e-commerce avec retours — vérifiez la primitive de remboursement avant de figer le choix.

La règle de pouce qui ressort sur le terrain en 2026 : direct sur Wave et Orange Money pour la collecte si > 70 % du flux, agrégateur (PayDunya ou CinetPay) pour le reste, Wave Payout en direct pour les versements.

Wave : Checkout et Payout

Wave expose deux API distinctes qui partagent l’authentification mais répondent à des besoins opposés. La Wave Checkout API sert à encaisser un paiement depuis le portefeuille d’un client. La Wave Payout API sert à verser un paiement depuis le portefeuille du marchand vers un destinataire identifié par numéro de téléphone.

Les deux utilisent la même URL de base — https://api.wave.com — et le même mode d’authentification : un header Authorization: Bearer <api_key> avec une clé créée depuis le Wave Business Portal. Les clés peuvent être restreintes par scope (Checkout seul, Payout seul, ou les deux) et la rotation se fait depuis la même interface.

Le checkout démarre avec un POST sur /v1/checkout/sessions qui retourne un objet contenant un identifiant de session, une URL wave_launch_url à ouvrir dans le navigateur du client, et un couple checkout_status (open, complete, expired) plus payment_status (processing, cancelled, succeeded). Le client confirme la transaction depuis son application Wave après redirection. Une session non confirmée expire automatiquement, et l’événement checkout.session.completed est émis sur le webhook configuré une fois le paiement validé. La signature HMAC-SHA256 est portée dans le header Wave-Signature: t=<timestamp>,v1=<hash> que tout backend doit vérifier avant de considérer le paiement comme acquis.

Le payout démarre avec un POST sur /v1/payout qui exige seulement trois champs (currency, receive_amount, mobile au format E.164) et accepte des champs optionnels qui aident à la traçabilité (name, national_id, client_reference, payment_reason). La réponse arrive de manière synchrone avec un statut initial processing, et les transitions vers succeeded, failed ou reversed sont notifiées par webhook.

Trois pièges à connaître sur Wave en 2026. Le premier : wave_launch_url doit être ouvert dans le navigateur du client, pas dans une webview embarquée — la redirection vers l’application Wave échoue sinon. Le second : la vérification d’un destinataire avant un payout est limitée à 30 vérifications du même numéro sur une fenêtre glissante de 5 minutes. Le troisième : les montants sont passés en chaînes de caractères sans séparateur décimal pour éviter les erreurs de précision flottante.

Le pas-à-pas du payout B2B en Laravel est traité dans le tutoriel Wave Payout API en Laravel : verser un paiement mobile pas-à-pas.

Orange Money Web Payment via Sonatel

Orange Money expose son API via deux portails. Le portail global developer.orange.com/apis/om-webpay couvre le Mali, le Cameroun, la Côte d’Ivoire, le Sénégal, Madagascar, le Botswana, la Guinée Conakry, la Guinée-Bissau, la Sierra Leone, la République Démocratique du Congo et la République Centrafricaine. Le portail spécifique au Sénégal developer.orange-sonatel.com propose en plus des produits locaux — paiement par QR code, cash-in, notifications transactionnelles — accompagnés d’un environnement de test gratuit.

Le flux Web Payment fonctionne en redirection : votre backend appelle l’API Orange Money pour créer une intention de paiement, récupère un pay_token et une payment_url, redirige le navigateur du client vers cette URL, le client confirme par OTP via USSD, et Orange notifie votre backend par callback. C’est conceptuellement le même schéma que Wave Checkout, à ceci près que la confirmation OTP côté client passe par un menu USSD plutôt qu’une application mobile dédiée — ce qui change la latence perçue mais pas la logique côté serveur.

L’authentification utilise OAuth2 avec un endpoint de récupération de token séparé de l’endpoint de paiement. Vous échangez vos credentials contre un access_token à durée limitée, puis présentez ce token dans le header Authorization: Bearer des appels suivants. La durée de vie typique est de 1 heure ; un mécanisme de refresh ou de regénération automatique côté serveur est obligatoire pour éviter qu’une transaction lancée à minuit moins une ne tombe sur un token expiré.

Le déclenchement d’une intégration en production passe par un dossier KYC auprès d’Orange Sonatel — preuves d’activité, numéro NINEA, statut juridique, RIB du compte de versement. Ce processus prend typiquement une à quatre semaines selon la qualité du dossier. Tant que les credentials de production ne sont pas délivrés, vous travaillez dans le sandbox documenté sur le portail développeur.

L’intégration Next.js avec App Router, server actions et signed callbacks est traitée dans Orange Money Web Payment en Next.js : encaisser un paiement web pas-à-pas.

Mixx by Yas — où en est l’API ?

Mixx by Yas, anciennement Free Money, est le portefeuille mobile money de Yas au Sénégal. La marque a été repositionnée le 26 novembre 2024 par le groupe Axian, qui a unifié ses opérations fintech au Sénégal, au Togo et en Tanzanie sous l’identité « Mixx by Yas ». La filiale sénégalaise faisait déjà partie du périmètre Axian depuis l’acquisition progressive entamée en 2018 et finalisée à 80 % en 2023. L’application est interopérable avec les autres comptes mobile money et bancaires du marché. La carte prépayée Mixx Mastercard adossée au compte a été lancée le 19 juin 2025 en partenariat avec Mastercard et Ecobank Sénégal.

Du côté développeur, le tableau est moins fourni que pour Wave et Orange Money. Yas n’expose pas, à la date de mai 2026, une API publique de paiement web directement utilisable par les développeurs externes. Les marchands qui veulent encaisser sur Mixx by Yas passent typiquement par les agrégateurs PayDunya ou CinetPay, qui exposent le wallet Mixx by Yas comme l’une des méthodes de paiement de leur multi-canal — l’utilisateur final saisit son numéro Yas, reçoit une demande de validation OTP, et l’agrégateur abstrait la communication avec l’opérateur.

Ce détour par un agrégateur n’est pas une régression. Pour un produit qui sert tous les wallets sénégalais (Wave, Orange Money, Mixx by Yas) sans surcoût d’intégration, l’agrégateur reste la voie la plus efficace. Ce qui change si Mixx by Yas ouvre une API directe à l’avenir, c’est l’opportunité d’optimiser les frais sur ce flux particulier — exactement comme cela s’est produit pour Wave en 2022 quand l’opérateur a publié son API publique.

PayDunya, l’agrégateur historique

PayDunya est l’agrégateur de paiement basé à Dakar le plus ancien du marché, fondé en 2015. Sa documentation à l’adresse developers.paydunya.com est en français et en anglais et couvre quatre familles d’API : DMP (Demande de Paiement) pour la collecte par redirection, SOFTPAY pour le paiement carte (réservé aux marchands certifiés PCI-DSS), CRM pour la facturation et la gestion clients, et PER (Paiement Express) pour le disbursement.

L’authentification PayDunya repose sur trois clés portées en headers HTTP — PAYDUNYA-MASTER-KEY, PAYDUNYA-PRIVATE-KEY, PAYDUNYA-TOKEN — récupérées depuis le tableau de bord PayDunya après création d’une application. Une quatrième clé PAYDUNYA-MODE distingue sandbox et production. Cette pluralité de clés est inhabituelle et justifie une encapsulation propre dans votre code (variables d’environnement séparées, ne jamais committer en clair).

Le flux DMP standard crée une facture par POST sur /v1/checkout-invoice/create, récupère un token et une URL de redirection, ouvre cette URL dans le navigateur du client, et reçoit la confirmation par notification IPN une fois le paiement validé. Le payload minimal est extrêmement compact :

{
  "invoice": {"total_amount": 5000, "description": "Commande #1247"},
  "store": {"name": "Boutique Bamba"}
}

La réponse retourne un response_code à "00" en cas de succès et une URL de checkout à utiliser pour la redirection. Cette URL embarque déjà le sélecteur de méthode (Wave, Orange Money, Mixx by Yas, carte) — c’est PayDunya qui gère l’écran de choix côté utilisateur.

L’avantage net de PayDunya : un seul code, toutes les méthodes du marché francophone d’un coup, en moins de 200 lignes Python ou PHP. L’inconvénient : les frais marchand sont supérieurs à une intégration directe Wave, et la latence ajoute un saut réseau.

L’intégration Django avec vue par class-based, IPN sécurisé et mise à jour atomique de la commande est traitée dans PayDunya en Django : encaisser via tous les wallets pas-à-pas.

CinetPay, multi-canal et carte bancaire

CinetPay est l’agrégateur basé à Abidjan dont la couverture régionale est la plus large : Côte d’Ivoire, Sénégal, Burkina Faso, Mali, Cameroun, Togo, Bénin, Guinée Conakry, République Démocratique du Congo. La documentation à docs.cinetpay.com est en français et en anglais et expose une API checkout unifiée et un SDK seamless pour intégration sans redirection.

Le flux standard initialise un paiement par POST sur https://api-checkout.cinetpay.com/v2/payment avec un payload qui inclut l’apikey, le site_id, un transaction_id unique côté marchand, le montant (multiple de 5 sauf en USD), la devise (XOF, XAF, CDF, GNF ou USD), une description, l’URL de notification webhook, l’URL de retour client, et un sélecteur de canaux (ALL, MOBILE_MONEY, CREDIT_CARD, WALLET). La réponse retourne un payment_token et une payment_url à servir au client.

La vérification de transaction passe par un POST sur https://api-checkout.cinetpay.com/v2/payment/check avec le même transaction_id. Cette API de vérification est essentielle : la notification webhook peut arriver en retard ou être manquée, et un appel de check côté serveur lors du retour client garantit l’atomicité de la mise à jour de la commande.

CinetPay se distingue par deux points pratiques. Le premier : le canal CREDIT_CARD exige des champs customer_* complets (id, name, surname, email, phone, address, city, country en code ISO, state, zip_code) — sans ces champs le paiement carte échoue silencieusement. Le second : la fonctionnalité lock_phone_number couplée à customer_phone_number empêche l’utilisateur de saisir un numéro autre que celui passé dans le payload, ce qui sécurise les flux où le numéro est connu d’avance (compte client connecté).

L’intégration Laravel avec Service Provider, Job de retry et webhook signé est traitée dans CinetPay multi-canal en Laravel : encaisser sur tous les wallets pas-à-pas.

Comparatif synthèse

Acteur Type Cas d’usage idéal Pays Sénégal Devises Auth
Wave Checkout Direct opérateur Encaissement haute volumétrie, faibles frais ✅ XOF Bearer + HMAC option
Wave Payout Direct opérateur Reversement B2B, gig économie ✅ XOF Bearer + HMAC option
Orange Money Web Payment Direct opérateur Encaissement, public Orange ✅ XOF (et autres pays) OAuth2
Mixx by Yas Wallet opérateur Via agrégateur uniquement ✅ XOF Indirect
PayDunya Agrégateur Multi-méthodes simples, time-to-market ✅ XOF 3 clés en headers
CinetPay Agrégateur Multi-pays, mobile money + carte ✅ XOF/XAF/CDF/GNF/USD apikey + site_id

Trois lectures rapides du tableau. Pour un produit B2C focalisé Sénégal qui cherche à minimiser les frais : Wave + Orange Money en direct, fallback PayDunya pour Mixx by Yas. Pour un produit multi-pays qui sert la zone Franc CFA : CinetPay en couverture principale, Wave en direct là où le volume justifie l’effort. Pour une marketplace qui doit verser des commissions : Wave Payout en direct, complété par PayDunya PER pour les méthodes hors Wave.

Architecture backend de référence

Une architecture saine pour intégrer ces APIs en 2026 sépare clairement quatre responsabilités.

La première est la création d’intention de paiement. Côté backend, vous exposez une route applicative — par exemple POST /api/payments/initiate — qui prend en entrée le panier ou la facture, calcule le montant, choisit la passerelle selon la méthode demandée, appelle l’API de la passerelle, persiste l’objet PaymentIntent en base avec son identifiant externe et son statut initial (pending), et retourne au client l’URL de redirection ou le payload SDK. Cette persistance avant redirection est non-négociable : sans cela, vous ne pouvez pas réconcilier un webhook reçu plus tard.

La deuxième est la réception et la vérification du webhook. Chaque passerelle pointe sur une route dédiée — POST /api/webhooks/wave, POST /api/webhooks/cinetpay, etc. — qui doit en moins de 200 ms vérifier la signature HMAC ou recalculer le hash de validation, retrouver l’intention de paiement par son identifiant externe, transitionner son statut vers succeeded ou failed, déclencher les effets métier (validation de commande, envoi de SMS, déblocage de cours), et retourner 200 à la passerelle pour acquitter l’événement. L’idempotence est obligatoire — le même événement peut arriver deux fois pour cause de retry — et passe typiquement par un index unique sur l’identifiant d’événement.

La troisième est le fallback de réconciliation. Aucun webhook n’est garanti. Si un client revient sur l’URL de retour avec un identifiant de session mais que le webhook n’a pas encore été reçu, votre handler de retour doit appeler l’API de check de la passerelle (GET /v1/checkout/sessions/:id chez Wave, POST /v2/payment/check chez CinetPay) pour récupérer l’état réel et synchroniser la base. Ce double mécanisme — webhook + pull à l’arrivée client — évite les écarts entre l’argent reçu et la commande validée.

La quatrième est l’audit et le monitoring. Toute requête sortante vers une passerelle, tout webhook reçu, toute transition de statut doit être loguée dans une table d’audit horodatée et consultable. En 2026, la conformité opérationnelle des marchands africains est suivie de près par les régulateurs locaux, et un défaut de traçabilité se paye en gel de compte marchand le jour où un litige client remonte.

Sécurité : signatures, idempotence, conformité

La signature HMAC est la barrière de premier rang contre la falsification des webhooks. Wave utilise Wave-Signature: t=<timestamp>,v1=<hash> avec HMAC-SHA256 sur la concaténation du timestamp et du corps brut de la requête. CinetPay utilise un header x-token calculé en HMAC-SHA256 sur les paramètres de la transaction. PayDunya utilise un mécanisme de notification IPN où votre serveur reçoit le payload et doit appeler l’API PayDunya en retour pour vérifier l’intégrité.

Le piège classique : la signature se calcule sur le corps brut de la requête, pas sur le JSON parsé puis re-sérialisé. La sérialisation JSON n’est pas déterministe (ordre des clés, espaces) et un middleware qui re-sérialise avant signature casse silencieusement la vérification. Tout framework — Laravel, Express, Django — doit exposer le raw body au handler de webhook avant tout parsing.

Le second pilier est l’idempotence côté webhook. Une fois la signature validée, ne traitez pas l’événement deux fois. Stockez l’identifiant d’événement émetteur (champ id chez Wave, transaction_id chez CinetPay, token chez PayDunya) dans une table webhook_events avec index unique, et inscrivez-y l’événement avant tout traitement métier. Si l’insertion échoue pour cause de duplicat, retournez 200 sans rien faire — l’événement a déjà été traité.

Le troisième pilier est la conformité réglementaire. Les passerelles vous demandent un dossier KYC à l’inscription marchand : statut juridique, NINEA pour le Sénégal ou son équivalent ailleurs, justificatif de compte bancaire, parfois preuves d’activité. Ce dossier conditionne l’octroi des clés de production. Côté backend applicatif, vous devez de votre côté collecter et stocker l’identifiant de transaction passerelle pour chaque commande, conserver les logs au moins 5 ans pour les besoins comptables et fiscaux locaux, et chiffrer en base toute donnée sensible — numéros de téléphone des clients, références de compte mobile money — selon les recommandations de l’autorité de protection des données du pays concerné (CDP au Sénégal, ARTCI en Côte d’Ivoire).

Le quatrième pilier, souvent oublié, est la rotation des clés. Toute clé d’API doit pouvoir être tournée en moins d’une heure si elle est compromise. Cela impose deux choses : ne jamais committer une clé en dur dans le code, et concevoir le mécanisme de chargement de clé pour accepter une nouvelle valeur sans redémarrer toute l’application — typiquement via un secret manager (HashiCorp Vault, AWS Secrets Manager, ou même un fichier .env rechargeable par signal Unix).

Tutoriels de la série

Quatre tutoriels pas-à-pas creusent chacun une intégration en code testé sur les principaux frameworks du marché :

Erreurs fréquentes

Erreur Cause Solution
Webhook reçu mais commande pas mise à jour Le webhook arrive avant que la transaction soit committée en base par le handler d’init Persister l’intention avant l’appel API, pas après
Signature HMAC invalide alors que la clé est bonne Le middleware re-sérialise le JSON avant le handler webhook Récupérer le raw body brut, désactiver le parsing JSON sur la route webhook uniquement
Doublon de paiement appliqué deux fois Pas d’idempotence sur l’identifiant d’événement Index unique sur webhook_events.event_id + insert-or-skip avant traitement métier
Client redirigé sur URL d’erreur alors qu’il a payé Latence du webhook, retour client traité avant le webhook Pull en complément : appeler l’API de check sur la session/transaction au retour client
wave_launch_url ne redirige pas vers l’app Wave URL ouverte dans une webview embarquée et non dans un navigateur système Forcer l’ouverture dans le navigateur (window.open côté web, Intent.ACTION_VIEW côté Android natif)
401 Unauthorized sur Orange Money après quelques heures Token OAuth2 expiré et non rafraîchi Cron de refresh ou refresh à la demande avec mémoïsation TTL
Paiement carte CinetPay refusé sans erreur claire Champs customer_* incomplets sur le canal CREDIT_CARD Valider la complétude des champs avant POST, journaliser le payload
PayDunya retourne response_code ≠ 00 Sandbox vs production confondus, PAYDUNYA-MODE pas en cohérence avec les clés Synchroniser le mode et les clés via des variables d’environnement séparées par environnement

FAQ

Faut-il intégrer Wave et Orange Money en direct ou passer par un agrégateur ?

Pour un produit qui sert plus de 70 % de son flux au Sénégal et où chaque centime de marge compte, l’intégration directe Wave + Orange Money est gagnante sur 12 mois. Pour un produit multi-pays ou pour un MVP qui doit se mettre en marché en moins de deux semaines, l’agrégateur (PayDunya ou CinetPay) est plus rationnel.

Quelle différence concrète entre Wave Checkout et Wave Payout ?

Wave Checkout sert à encaisser un paiement entrant — un client paie votre marchand. Wave Payout sert à verser un paiement sortant — votre marchand paie un destinataire. Les deux APIs partagent l’authentification mais ont des contrats de payload, des webhooks et des cas d’usage métier complètement distincts.

Mixx by Yas a-t-il une API publique en 2026 ?

À la date de mai 2026, Yas n’expose pas d’API publique de paiement web directement utilisable par les développeurs externes. Les marchands qui veulent encaisser sur Mixx by Yas passent par les agrégateurs PayDunya ou CinetPay qui exposent ce wallet comme l’une de leurs méthodes.

Combien de temps pour obtenir des clés de production ?

Wave : typiquement deux semaines après dépôt de dossier marchand complet. Orange Money via Sonatel : deux à quatre semaines. PayDunya : quelques jours après validation du compte business. CinetPay : quelques jours également. Le sandbox de chaque passerelle est accessible immédiatement après inscription.

Comment sécuriser un webhook contre les rejeux ?

Trois couches : vérifier la signature HMAC sur le corps brut, vérifier que le timestamp embarqué dans le header n’est pas vieux de plus de 5 minutes, indexer uniquement les identifiants d’événements déjà traités pour ne jamais traiter deux fois le même.

Quelle architecture de retry pour les payouts ?

Un job différé qui consulte l’API de la passerelle pour récupérer le statut courant en cas d’absence de webhook après 60 secondes, puis re-tente jusqu’à un seuil (5 essais espacés exponentiellement) avant de basculer la transaction en failed_to_confirm pour revue manuelle. Ne jamais re-soumettre la même transaction sans avoir confirmé qu’elle n’est pas déjà passée — risque de double paiement.

Le webhook de Wave est-il garanti ?

Comme tous les webhooks, il peut être manqué. Wave réessaie en exponential backoff sur 24 heures, mais une coupure réseau côté marchand qui dépasse cette fenêtre laisse l’événement perdu. La parade est le pull au retour client et un cron de réconciliation périodique sur les sessions en processing depuis plus de 10 minutes.

Peut-on tester en local avec un tunnel HTTPS ?

Oui. Tunnels recommandés en 2026 : Cloudflare Tunnel (gratuit, stable), ngrok (limites en gratuit), localtunnel (open source). Le tunnel HTTPS expose votre serveur de dev sur une URL publique que vous renseignez dans la configuration du sandbox de la passerelle.

Pour aller plus loin

#cluster-paiements-afrique #cluster-pillar #paiements
Sponsoriser ce contenu

Cet emplacement est à vous

Position premium en fin d'article — c'est l'instant où les lecteurs sont le plus engagés. Réservez cet espace pour votre marque, votre formation ou votre offre.

Recevoir nos tarifs
Publicité

Articles Similaires