Le paiement sur invite est le parcours que tout client de mobile money connaît par cœur sans jamais y penser. Un marchand demande de l'argent, une invite apparaît sur le téléphone du client, il saisit son code PIN, et c'est fait. C'est le mode de paiement le plus utilisé sur les marchés qui ont adopté le mobile money tôt, et il paraît sans effort. Cette facilité est le fruit d'une quantité surprenante d'ingénierie qui travaille dur pour rester invisible. Il suffit d'une erreur pour que la magie devienne un double débit, un paiement bloqué, ou un marchand qui a livré des marchandises contre de l'argent qui n'est jamais arrivé.
Voici ce qui se passe réellement derrière l'invite, et ce qu'il faut pour la rendre instantanée, sûre et à l'abri de tout double débit.
Deux façons dont l'invite arrive
Il existe deux mécanismes derrière « une invite apparaît », et ils comptent parce qu'ils n'ont ni la même portée ni les mêmes modes de défaillance.
Le mécanisme classique est le SIM Application Toolkit (STK) : du code qui s'exécute sur la carte SIM elle-même, ce qui explique qu'il puisse afficher une invite de code PIN sécurisée sur un simple téléphone basique sans application installée. C'est grâce au STK que les premiers systèmes de mobile money ont atteint tout le monde : le menu et la saisie du PIN sont pilotés depuis la SIM, via le réseau, sur un matériel qui n'a rien d'autre. Le mécanisme moderne est la notification d'application : une notification envoyée à une application pour smartphone qui ouvre un écran de confirmation. Les deux aboutissent au même point : le client autorise, et un débit suit son cycle de vie. Une plateforme digne de ce nom prend en charge les deux, car la clientèle utilise les deux.
Le débit est une machine à états
L'idée la plus importante du paiement sur invite est qu'un débit n'est pas un événement : c'est une machine à états avec un ensemble explicite et bien défini d'états et de transitions. Le traiter comme un appel « envoyer et oublier » est la source de la plupart des incidents en production. Les états sont à peu près les suivants :
- En attente : le marchand a demandé un débit ; l'invite a été envoyée ; le système attend le client.
- Autorisé : le client a saisi son PIN et confirmé ; le système a vérifié le solde et les plafonds et enregistre le mouvement.
- Terminé : le grand livre a passé des écritures équilibrées ; l'argent a bougé ; le marchand peut livrer.
- Refusé / Expiré / Échoué : le client a refusé, l'invite a expiré ou un contrôle a échoué ; aucun argent n'a bougé et le débit est clôturé proprement.
Chaque débit se trouve dans exactement un de ces états à tout instant, et ne peut évoluer que selon des transitions définies. Ce n'est pas de la bureaucratie : c'est ce qui rend le parcours raisonnable et récupérable. Quand quelque chose tourne mal, la question est toujours « dans quel état est ce débit, et quelle transition s'est bloquée ? », une question qui a une réponse, plutôt qu'un haussement d'épaules.
Comment le marchand apprend le résultat
Le système du marchand doit savoir si le débit a abouti : pour imprimer un reçu, remettre la marchandise, mettre à jour une commande. Il y a deux façons de le savoir, et la différence entre elles est celle qui sépare une intégration poussive d'une intégration nette.
- L'interrogation (polling). Le marchand interroge le point d'accès de statut, encore et encore : « c'est fait ? ». Cela fonctionne, mais c'est coûteux et lent : interroger trop souvent surcharge l'API ; trop rarement, et le client attend debout à la caisse.
- Les webhooks. La plateforme envoie au marchand un rappel signé dès que le débit change d'état. Le marchand l'apprend en quelques instants, sans appels inutiles, et reçoit un événement clair sur lequel agir. C'est la bonne brique de base, et une plateforme bien conçue en fait le comportement par défaut, avec l'interrogation en secours.
Ce qui le rend digne de confiance
Trois propriétés transforment une démonstration qui fonctionne en un système sur lequel un marchand peut bâtir son activité.
L'idempotence : l'arme contre le double débit
Les réseaux relancent les requêtes. Si la requête « créer un débit » d'un marchand expire et qu'il la renvoie, vous ne devez pas créer un second débit. Chaque requête de création porte une clé d'idempotence ; la plateforme l'enregistre, et une répétition avec la même clé renvoie le débit d'origine au lieu d'en créer un nouveau. La même discipline protège l'étape de confirmation. La garantie que ressent le client, « je n'ai été débité qu'une fois », c'est cette propriété, appliquée au moment où l'argent bouge, pas une vérification optimiste dans l'application.
Des webhooks signés
Un webhook est un appel HTTP non sollicité qui arrive sur le serveur du marchand en affirmant qu'un paiement a abouti. Pourquoi le croire ? Parce que chaque rappel est signé : une signature HMAC-SHA256 calculée sur le contenu avec un secret partagé que seuls la plateforme et le marchand connaissent. Le marchand recalcule la signature et rejette tout ce qui ne correspond pas, ce qui rend inutiles pour un attaquant les faux rappels « vous avez été payé ». Et comme les réseaux tombent en panne, les webhooks sont relancés avec un délai croissant jusqu'à accusé de réception, de sorte qu'une coupure momentanée chez le marchand ne fait pas perdre l'événement : il est renvoyé jusqu'à ce que son serveur réponde avec succès.
L'expiration
Un débit non confirmé ne peut pas traîner indéfiniment. Si le client s'en va sans saisir son PIN, le débit doit expirer proprement plutôt que rester un engagement ouvert qui pourrait mystérieusement aboutir une heure plus tard. Une fenêtre d'expiration bornée et prévisible est ce qui garde la vision du marchand cohérente avec celle du client.
Les cas limites qui distinguent les vrais systèmes des démonstrations
Le parcours heureux (envoi, confirmation, fin) représente le quart facile du travail. Les défaillances intéressantes se logent dans les interstices :
- Le client confirme, mais le réseau perd l'accusé de réception. Le débit est
completedsur la plateforme ; le marchand n'a rien reçu. La relance du webhook existe exactement pour cela. Le gestionnaire du marchand doit lui aussi être idempotent, pour qu'un événement « terminé » renvoyé ne fasse pas livrer la marchandise deux fois. - Deux confirmations arrivent en concurrence. Une confirmation relancée ne doit pas passer deux écritures. La clé d'idempotence et la machine à états garantissent ensemble que la seconde confirmation constate « déjà terminé » au lieu de déplacer l'argent à nouveau.
- Le débit expire au moment même où le client confirme. La machine à états doit désigner un seul gagnant : la transition est atomique, donc le débit est soit autorisé soit expiré, jamais les deux, et le client est clairement informé.
- Le rapprochement. En fin de journée, chaque débit
completeddoit correspondre à un ensemble équilibré d'écritures et à un enregistrement de règlement. Comme le cycle de vie du débit et le grand livre sont liés, l'achèvement est l'écriture, le rapprochement se fait par construction plutôt que par enquête.
Une chronologie détaillée
Voici ce qui se passe, seconde par seconde, quand un marchand débite un client de 1 250 pour des courses. Les durées sont typiques et non garanties.
| Temps | Ce qui se passe | État du débit |
|---|---|---|
| 0,0 s | Le caissier saisit le numéro du client et le montant ; la caisse envoie une requête de création de débit avec une clé d'idempotence | En attente |
| 0,3 s | La plateforme valide le marchand et le client et envoie l'invite | En attente |
| 2–20 s | Le client lit le nom du marchand et le montant et saisit son PIN | En attente |
| +0,2 s | Le cœur du système vérifie le PIN, le solde et les plafonds, et passe des écritures équilibrées | Terminé |
| +0,5 s | Un webhook signé parvient au marchand ; le client et le marchand reçoivent leurs confirmations | Terminé |
| Plus tard | Le solde du marchand est réglé vers la banque selon son calendrier | Terminé, réglé |
La lecture et la saisie du client dominent le temps. Tout ce que fait la plateforme prend bien moins d'une seconde, ce qui explique que l'expérience paraisse instantanée quand elle fonctionne, et que la rare étape lente se remarque immédiatement.
Bien construire le côté marchand
La moitié d'une intégration fiable de paiement sur invite se trouve dans le système du marchand. Un bon gestionnaire de webhooks :
- Vérifie la signature avant de faire confiance au moindre élément du contenu.
- Est idempotent : une seconde livraison du même événement ne change rien.
- Répond rapidement et fait le travail lourd ensuite, pour que la plateforme n'expire pas et ne relance pas inutilement.
- Apparie sur la référence du débit, jamais sur le seul montant et numéro de téléphone.
- Se rabat sur le point d'accès de statut si aucun événement n'arrive dans le délai attendu, plutôt que de conclure à un échec.
- Journalise chaque événement reçu, pour que les litiges trouvent leur réponse dans les enregistrements.
Choisir la fenêtre d'expiration
L'expiration est un compromis. Trop courte, et les clients qui cherchent leur téléphone voient le débit expirer avant de confirmer. Trop longue, et les marchands attendent avec la marchandise sur le comptoir, tandis que des invites périmées arrivent après le départ du client. La plupart des opérateurs retiennent une à deux minutes pour les paiements en personne, davantage pour les demandes à distance, comme une facture envoyée à un client chez lui. Quelle que soit la fenêtre, affichez-la : un caissier qui sait que l'invite dure une minute sait quand réessayer.
Les détails que les clients remarquent
De petits choix sur l'écran d'invite décident si les clients lui font confiance :
- Afficher le nom enregistré du marchand, pas un code interne, pour que le client sache qui demande.
- Afficher clairement le montant et la référence avant le champ du PIN.
- Proposer une option de refus claire, pour qu'un client qui n'attendait pas l'invite puisse la refuser plutôt que l'ignorer.
- Confirmer en toutes lettres et par message : un reçu avec le marchand, le montant et la référence, à l'écran et par SMS.
- Mettre en garde contre les invites inattendues. Des fraudeurs envoient des invites en espérant qu'un client approuve par réflexe ; une courte ligne comme « N'approuvez que si vous payez ce marchand » réduit ce risque.
Un seul cycle de vie, pour tous les canaux
Dernier élément pour bien faire : le paiement sur invite ne doit pas être un cas particulier câblé séparément dans l'application, la caisse et l'API. Ce doit être un cycle de vie de débit unique que tous les canaux pilotent : un client qui scanne le QR d'un marchand, un marchand qui envoie un débit depuis un terminal de vente et un partenaire qui appelle l'API développeur créent tous le même type de débit, passant par les mêmes états, écrivant dans le même grand livre, émettant les mêmes webhooks signés. Construisez-le une fois, correctement, et chaque canal hérite des garanties.
Paiement sur invite, QR ou numéro de caisse ?
Le paiement sur invite est l'un des trois moyens courants d'encaisser un client. Chacun convient à une situation différente :
| Méthode | Qui l'initie | Fonctionne sur téléphone basique | Idéal pour |
|---|---|---|---|
| Paiement sur invite | Le marchand | Oui, via des invites sur la SIM | Caisses et passages en caisse où le marchand connaît le montant |
| Code QR | Le client scanne | Non, il faut une application smartphone | Boutiques avec beaucoup de clients sur smartphone ; codes statiques pour les petits commerçants |
| Numéro de caisse ou de facturier | Le client le saisit | Oui, via USSD | Tout marchand ; la solution de repli universelle |
Les marchands s'en sortent le mieux quand ils peuvent accepter les trois, et que la plateforme les traite comme un même type de paiement arrivant par des chemins différents.
La fraude autour des invites
Parce qu'une invite demande au client d'approuver un paiement, elle attire l'ingénierie sociale. Le schéma courant : un fraudeur déclenche des invites puis appelle le client en se faisant passer pour le fournisseur, et le convainc d'approuver. Les défenses agissent à plusieurs niveaux : afficher en évidence le nom vérifié du marchand demandeur ; limiter le nombre d'invites qu'un marchand peut envoyer au même numéro en peu de temps ; surveiller les marchands dont les invites sont surtout refusées ou signalées ; et répéter aux clients que le fournisseur ne leur demandera jamais d'approuver un paiement par téléphone. L'intégration des marchands compte aussi, car un marchand vérifié à l'identité traçable est un mauvais outil de fraude.
Mesurer le paiement sur invite
| Indicateur | Pourquoi il compte |
|---|---|
| Taux d'approbation | La part des invites que les clients approuvent ; une chute soudaine signale des problèmes de livraison ou de la confusion |
| Délai d'approbation | Le temps que mettent les clients ; des délais longs suggèrent des écrans peu clairs ou une livraison lente |
| Taux d'expiration | Les invites qui expirent sans réponse ; ajuster la fenêtre d'expiration et les consignes aux caissiers |
| Succès des webhooks au premier essai | La fiabilité avec laquelle les marchands reçoivent les résultats sans relance |
| Invites inattendues signalées | Un signal précoce de tentatives de fraude |
Au-delà du comptoir : les demandes à distance
Le même mécanisme fonctionne quand le client n'est pas devant la caisse. Une école peut envoyer des demandes de frais aux parents, un service public peut demander le paiement d'une facture, un livreur peut demander le paiement à son arrivée. Les demandes à distance nécessitent quelques ajustements : une expiration plus longue, une description claire de ce qui est payé, le nom vérifié du demandeur, et une référence que le client reconnaît sur une facture ou un message. La machine à états, la signature et l'idempotence restent strictement identiques, c'est pourquoi un cycle de vie de débit unique sert aussi bien la caisse que la facture et l'API.
Tester une intégration de paiement sur invite
Avant qu'un marchand passe en production, exécutez ces cas dans l'environnement de test :
- approuver, refuser et laisser expirer une invite, et vérifier que le système du marchand affiche le bon résultat dans chaque cas ;
- envoyer deux fois la même requête de création avec la même clé d'idempotence et confirmer qu'un seul débit existe ;
- faire échouer le point d'accès webhook du marchand pendant quelques minutes et confirmer que les événements arrivent une fois le service rétabli ;
- envoyer un webhook avec une mauvaise signature et confirmer que le marchand le rejette ;
- tenter un débit au-dessus du plafond du client et confirmer qu'il est refusé proprement ;
- vérifier que les remboursements renvoient au débit d'origine.
Une intégration qui réussit ces tests se comportera bien lors de sa journée la plus chargée.
Questions fréquentes
Et si le client n'a pas de connexion de données ?
Les invites sur la SIM fonctionnent via le réseau mobile sans données. Pour les invites d'application, les clients sans données peuvent toujours payer en saisissant le numéro de caisse du marchand via USSD.
Un marchand peut-il débiter un client sans son accord ?
Non. Le débit n'aboutit que lorsque le client l'autorise avec son PIN. Un marchand peut demander ; seul le client peut approuver.
Comment sont traités les remboursements ?
Un remboursement est une nouvelle transaction du marchand vers le client, liée au débit d'origine. L'original reste dans l'historique, pour que les deux parties voient ce qui a été payé et ce qui a été rendu.
Que doit faire un caissier si le client dit avoir approuvé mais que la caisse n'affiche rien ?
Attendre le résultat plutôt qu'encaisser deux fois. La caisse doit interroger le statut du débit à l'aide de sa référence. Si le débit a abouti, le résultat s'affichera en quelques instants ; s'il a expiré, le caissier peut envoyer une nouvelle invite sans risque. N'acceptez jamais une capture d'écran de confirmation comme preuve de paiement.
Le paiement sur invite est-il sûr pour les gros montants ?
Les plafonds du niveau du client s'appliquent exactement comme pour tout autre paiement, et l'étape du PIN est la même. Pour les gros paiements entre entreprises, les marchands associent souvent une invite à une référence de facture, pour que les deux parties puissent rattacher le paiement à un document.
Fait ainsi, le paiement sur invite paraît instantané et rend tout double débit impossible, non pas parce que rien n'échoue jamais, mais parce que chaque défaillance a un état défini, une relance et un chemin de retour vers la cohérence. C'est ce que PesaBridge livre, dans les applications comme dans l'API développeur, sur un cycle de vie de débit unique.