WeChat Pay et Alipay en caisse Odoo : une seule intégration, plusieurs passerelles
Pour un commerçant en Chine, la question du paiement ne se pose même plus. Les clients paient avec WeChat Pay ou Alipay, directement depuis leur application, en caisse. Le vrai défi, c’est ce qui se passe en coulisses : comment connecter ces solutions à Odoo de manière durable, capable de suivre l’ouverture d’un troisième magasin, le changement de prestataire de paiement ou la prochaine mise à jour d’Odoo ?
La plupart des premières tentatives ne tiennent pas la distance. Voici pourquoi, et à quoi ressemble une solution conçue pour durer.
La solution temporaire qui ne résiste pas
La première approche consiste souvent à créer un workflow low-code qui signe la requête et appelle la passerelle. Ça fonctionne… en démonstration. Mais cette solution se dégrade rapidement, et pas à cause des paiements eux-mêmes. Le problème vient d’un manque de rigueur technique. La clé de signature du commerçant se retrouve intégrée directement dans le workflow. Le runtime se met à jour sans versionnage, si bien qu’une modification externe peut casser la production. Les cas limites, comme un client qui saisit son code PIN, sont gérés avec des embranchements complexes, sans historique fiable. Les relances et le rapprochement deviennent difficiles à implémenter de manière robuste. Et chaque nouveau client impose de tout reconstruire à la main, sans tests unitaires ni état persistant.
Ce n’est pas un problème de paiement, mais un problème de "prototype transformé en produit". C’est précisément ce piège que Majorbird a voulu éviter.
Un contrat unique, plusieurs passerelles
Le principe est simple : le POS Odoo doit parler un langage neutre, quel que soit le prestataire en face. Côté point de vente, tout passe par un seul contrat HTTP, avec un vocabulaire restreint et fixe : paiement (référence de commande, montant, code scanné, passerelle cible), interrogation ou polling, remboursement, annulation, plus un proxy brut pour les cas particuliers.
Le statut des paiements est normalisé en un ensemble d’états communs à toutes les passerelles : créé, en cours de paiement, payé/échoué/annulé, puis remboursement en cours, remboursé ou partiellement remboursé. Les détails spécifiques à chaque prestataire, algorithme de signature, noms des champs, format des montants, endpoint à appeler, sont isolés dans un module dédié et masqués derrière un registre.
C’est ce qui rend concret le slogan "un module, plusieurs passerelles". La méthode de paiement Odoo ne stocke qu’un endpoint et le nom de la passerelle à utiliser. Ajouter un nouveau prestataire se résume à créer un module et à ajouter une ligne dans le registre. Le module POS, lui, reste inchangé. Pas de refonte, pas de copie forkée, pas de version spéciale par client.
Pourquoi les paiements en caisse en Chine posent un défi spécifique
Il faut le reconnaître : c’est objectivement plus complexe que d’intégrer une passerelle carte occidentale, et pour des raisons qui surprennent souvent.
Le flux est inversé. Au lieu que le client scanne un QR code marchand, c’est le caissier qui scanne le code affiché dans l’application du client. On parle ici de *micropaiement* ou de *code présenté par le client*.
La réponse n’est pas immédiate. Un paiement peut être validé instantanément… ou rester en attente pendant que le client saisit son code PIN, avec un statut du type "utilisateur en cours de paiement". Il n’y a pas de réponse synchrone. Il faut interroger la passerelle en continu jusqu’à obtenir une résolution. Autre point crucial : les réponses ambiguës comme "système occupé" ou "utilisateur en cours de paiement" ne doivent jamais être interprétées comme un échec. Relancer un paiement déjà validé, c’est risquer un double prélèvement. Un paiement bloqué en statut "en cours" au-delà d’un certain délai doit être automatiquement annulé pour éviter que l’argent ne reste bloqué.
Le rapprochement exige un suivi interne. Les passerelles ne fournissent que des réponses transaction par transaction ; impossible de s’appuyer sur un "récapitulatif des ventes du jour". Le système doit donc tenir son propre registre et s’y référer pour le rapprochement. Derrière le contrat unique, les deux prestataires sont radicalement différents : WeChat Pay v2 utilise du XML avec une signature MD5 et un certificat TLS client pour les remboursements, tandis qu’Alipay fonctionne en JSON avec RSA2. L’avantage du contrat neutre, c’est que ni le caissier ni le POS Odoo n’ont besoin d’en savoir quoi que ce soit.
D’une solution artisanale à un service industrialisé
Pour en faire une solution exploitable par plusieurs commerçants, il suffit d’appliquer les bonnes pratiques logicielles, point par point. La passerelle fonctionne comme un service versionné, avec des images immuables : ce qui est testé est ce qui est déployé. La configuration passe par le code : les identifiants et les passerelles sont injectés via l’environnement, rien de sensible n’est codé en dur, et les secrets sont récupérés depuis un coffre-fort au démarrage. La logique de signature est couverte par des tests unitaires. Un registre durable, un filet de sécurité de rapprochement en arrière-plan pour les paiements bloqués, un tableau de bord opérationnel et des sauvegardes auto-vérifiées complètent le dispositif. L’intégration d’un nouveau client devient une simple checklist, plus une reconstruction.
Ce que ça change en caisse
Pour le commerçant, le résultat est discret, et c’est bien l’objectif. WeChat Pay et Alipay sont acceptés directement en caisse Odoo, avec confirmation en temps réel et gestion des remboursements. Les paiements sont rapprochés automatiquement dans Odoo, sans qu’il faille recouper manuellement les totaux de l’application de paiement avec ceux des ventes en fin de journée. Ajouter un nouveau prestataire ne nécessite pas de développement spécifique. Le déploiement multi-magasins et multi-clients est plus rapide, la maintenance allégée, et l’historique des paiements est traçable de bout en bout.
Aujourd’hui, le module POS cible Odoo 18 Enterprise POS, tandis que le service de passerelle est indépendant de la version d’Odoo. Une adaptation pour Odoo 19 est prévue.
Notre analyse
Les rails de paiement chinois ne sont pas le vrai défi : presque tout le monde arrive à faire passer une transaction ponctuelle. Le vrai défi, c’est de le faire de manière uniforme pour tous les magasins, tous les prestataires et toutes les mises à jour, sans tout reconstruire à chaque fois et sans risquer de double prélèvement. C’est la différence entre une intégration qui marche en démonstration et une solution qui tient en production. C’est aussi la même rigueur que Majorbird applique à l’ensemble d’un projet Odoo : diagnostiquer avant de construire.
Si vous réfléchissez à intégrer WeChat Pay et Alipay à votre POS Odoo, ou si vous gérez déjà une solution artisanale qui commence à coûter cher, c’est le bon moment pour en parler, avant que le problème ne survienne au pire moment. Contactez l’équipe Majorbird à odoo@majorbird.com ou sur www.majorbird.com.