Le paiement en ligne : ce qui se passe entre le clic du client et l'argent sur votre compte

Un client appuie sur Payer sur votre page de commande et voit une coche verte. Derrière cette coche, quatre ou cinq choses devaient réussir, et l’une d’elles décide si vous avez réellement l’argent ou seulement la permission de le prendre. La plupart des litiges avec un prestataire commencent parce qu’un restaurant a cru que c’était la même chose.

La passerelle prend d’abord le consentement, ensuite l’argent

Tout réseau de cartes découpe un paiement en deux moments :

1. L’autorisation — la banque émettrice confirme que l’argent existe et le réserve.
2. La capture — le commerçant dit « prenez-le maintenant », et l’argent bouge.

Certaines passerelles fusionnent les deux étapes pour vous. D’autres non, et vous remettent une commande approuvée, financée, et entièrement non encaissée tant que vous ne la réclamez pas. PayPal fonctionne de la seconde façon : un client qui approuve sur la page PayPal a consenti à vous payer, et rien n’a quitté son compte avant la capture. Stripe Checkout, configuré normalement, fait les deux pour vous.

Cela compte pour une raison très concrète. Si votre système marque une commande payée dès le retour du client, vous servirez tôt ou tard des plats contre des autorisations jamais capturées — et vous l’apprendrez en fin de mois, par votre banque, pas par votre caisse.

La règle est donc simple et mérite d’être imposée à tout fournisseur : une vente est payée quand l’argent a bougé, pas quand le client est revenu.

Quatre réseaux, et à quoi chacun sert honnêtement

Fawry est l’exception utile : il n’accepte aucune carte. Il émet un code, le client le paie dans un kiosque ou une pharmacie, et la confirmation vous parvient ensuite. Sur un marché où une large part de la population ne détient pas de carte, ce n’est pas une solution de repli — c’est la voie principale.

Les espèces et le terminal de votre comptoir restent deux autres réseaux, sans passerelle du tout. Ils sont enregistrés en caisse et rapprochés du tiroir en fin de service.

C’est votre devise qui choisit la passerelle

C’est la partie qui surprend, alors disons-le franchement : un prestataire règle dans une liste fixe de devises, et si la vôtre n’y figure pas, aucune configuration n’y changera rien.

Paymob et Fawry règlent en livres égyptiennes. Ils sont la bonne réponse au Caire et sans objet à Madrid. Stripe couvre presque partout. PayPal couvre une grande partie du monde mais n’accepte pas du tout la livre égyptienne, ni le riyal, ni le dirham — un restaurant égyptien dont la carte est en EGP ne peut donc pas mettre PayPal derrière son paiement, quelle que soit son envie.

Un bon système vous le dit à la configuration, pas à la première commande ratée. Un restaurant facturant en euros ne devrait tout simplement pas se voir proposer les réseaux égyptiens ; un autre facturant en livres ne devrait pas être discrètement autorisé à configurer un prestataire qui refusera sa première transaction.

Si vous opérez dans plusieurs pays, facturez chaque établissement dans sa devise et laissez chacun porter son prestataire. Ce qui mène à l’erreur suivante.

Les clés d’une succursale ne sont pas celles du siège

Les identifiants d’un prestataire appartiennent à un compte marchand, et un compte marchand règle sur un compte bancaire, dans une devise.

Quand un groupe possède une succursale dans un autre pays, celle-ci ne peut pas hériter des identifiants du siège — ce n’est pas une décision de politique interne mais d’arithmétique. Ces clés dirigeraient ses clients vers un processeur incapable d’encaisser son argent.

L’organisation saine : une succursale facturant dans la même devise hérite des réglages et ne demande aucune configuration séparée. Une succursale facturant dans une autre garde ses propres identifiants, sa propre adresse de rappel et son propre règlement. Demandez à tout fournisseur comment il gère cela avant d’ouvrir le deuxième pays, pas après.

Le webhook est la confirmation

Quand un client finit de payer, deux choses arrivent indépendamment :

• son navigateur est redirigé vers votre page, et
• le prestataire envoie à votre serveur une notification signée décrivant ce qui s’est passé.

Seule la seconde est fiable. Une redirection peut être interrompue par une connexion perdue, un onglet fermé, une batterie vide ou un client qui a simplement fait « retour » — et dans chacun de ces cas l’argent a très bien pu bouger. Pire : une redirection est une URL, et une URL peut se taper à la main.

La notification signée — le webhook — c’est le prestataire qui dit à votre serveur, de serveur à serveur, avec une signature que vous vérifiez, que le paiement a abouti. C’est cet événement qui doit marquer la commande payée, libérer le ticket en cuisine et apparaître dans la recette du jour.

Deux conséquences pratiques :

• Votre adresse de rappel doit être joignable depuis Internet. Un webhook est une requête entrante. Il ne fonctionne pas vers un portable sur le WiFi d’un café, et c’est pourquoi un test concluant chez un développeur peut échouer en production.
• Le prestataire enverra le même événement deux fois. Les réseaux perdent des accusés de réception, et tout prestataire sérieux réessaie. Y prêter attention est ce qui évite qu’une commande soit enregistrée comme deux paiements.

Les remboursements remontent le même réseau

Un remboursement n’est pas un virement en sens inverse — c’est l’instruction donnée au réseau d’origine d’annuler une opération précise. Vous ne pouvez donc rembourser que via le prestataire qui a encaissé, et il vous faut en général la référence de la capture elle-même, pas celle de la commande.

Deux conséquences. D’abord, un remboursement en espèces et un remboursement par passerelle sont deux opérations distinctes et doivent apparaître distinctement dans vos rapports, car l’une vide un tiroir et l’autre ajuste un règlement bancaire. Ensuite, un remboursement partiel doit être rattaché à l’opération qu’il annule, sans quoi votre rapprochement ne se bouclera jamais.

Ce qui fait vraiment perdre la commande

En pratique, le paiement en ligne échoue pour des raisons ennuyeuses, pas exotiques :

• Le montant est bon, la devise ne l’est pas. Le prestataire refuse et le client voit une erreur incompréhensible.
• L’URL de retour est un lien d’application, pas une adresse web. Certains prestataires n’acceptent que des adresses https ordinaires et rejettent le reste — la commande n’est même jamais créée.
• Personne n’a configuré le webhook. Les paiements passent, les clients sont débités, et rien dans le restaurant ne le sait. C’est la panne la plus fréquente, et elle est silencieuse.
• Les clés de test n’ont jamais été remplacées. Tout fonctionne à merveille et aucun argent n’arrive.

Aucun de ces problèmes n’est subtil. Ce sont des problèmes de liste de contrôle, et c’est précisément pour cela qu’ils devraient y figurer — et pourquoi un test de connexion qui appelle réellement le prestataire, au lieu de se contenter d’enregistrer vos clés, mérite sa place dans l’écran de réglages.

En bref

Proposez les réseaux que vos clients utilisent vraiment, facturez chaque établissement dans la devise où il est réglé, laissez le webhook — pas la redirection — décider qu’une commande est payée, et testez avec les clés de production avant d’annoncer l’ouverture de la page. Le reste n’est que configuration.