Qui choisir pour créer votre module de paiement Odoo ?

Nous développons et maintenons des modules de paiement Odoo pour des banques et des prestataires de paiement européens : Monetico, Axepta BNP Paribas, CAWL, Alma, Viva Wallet, HiPay, FLOA Pay. Nous sommes donc juge et partie, autant le dire tout de suite. Ce guide se veut utile même si vous ne travaillez pas avec nous : ce sont les questions que nous poserions à n'importe quel prestataire avant de lui confier l'encaissement d'une boutique.

Avez-vous vraiment besoin d'un développement ?

Avant de chercher un prestataire, trois vérifications évitent parfois tout développement.

• Votre prestataire est-il déjà dans Odoo ? Odoo intègre en standard plusieurs fournisseurs de paiement, dont Stripe, Adyen, Mollie et PayPal. Si le vôtre en fait partie, c'est une affaire de configuration, pas de code. La liste se trouve dans le menu des fournisseurs de paiement de votre base, et elle varie selon la version.
• Un module existe-t-il déjà ? Cherchez le nom de votre banque sur l'Odoo Apps Store, en filtrant sur votre version d'Odoo. Un module maintenu coûte presque toujours moins cher qu'un développement sur mesure.
• Votre hébergement accepte-t-il un module tiers ? Odoo Online, l'offre SaaS standard d'Odoo, n'accepte pas de module Python personnalisé. Pour installer un module de paiement qui n'est pas fourni par Odoo, il faut Odoo.sh ou un hébergement sur votre propre serveur.

Les solutions des banques françaises sont le cas le plus fréquent où rien n'existe en standard : Monetico pour le Crédit Mutuel et le CIC, Axepta pour BNP Paribas, par exemple. C'est là qu'un module devient nécessaire.

Les options possibles, et leurs limites

Aucune option n'est mauvaise par principe. Chacune a un point faible qu'il vaut mieux connaître avant de choisir.

Ce qu'un module de paiement sérieux doit gérer

Un paiement qui fonctionne en démonstration ne prouve pas grand-chose. Ce qui distingue un bon module, c'est son comportement quand quelque chose se passe mal. Voici ce que nous vérifions en premier quand on nous demande d'auditer ou de reprendre un module.

Il s'appuie sur le framework de paiement d'Odoo

Odoo gère les paiements avec des modèles communs : payment.provider pour le fournisseur, payment.transaction pour chaque paiement, payment.token pour les cartes enregistrées. Un module construit sur ces modèles fonctionne d'un coup partout où Odoo encaisse : la boutique en ligne, les liens de paiement, le portail client, les abonnements. Un module qui contourne ce framework devra être refait pour chaque usage. Ces modèles évoluent d'ailleurs d'une version à l'autre (payment.acquirer est devenu payment.provider en version 16, les moyens de paiement sont arrivés en 17) : un module annoncé compatible avec toutes les versions mérite qu'on demande comment.

Il ne dépend pas du retour du client sur la boutique

Après le paiement, beaucoup de clients ferment l'onglet sans revenir sur le site. Si la commande n'est confirmée qu'au retour du navigateur, elle reste en devis alors que l'argent est encaissé. Un module fiable traite la notification que la banque envoie directement au serveur Odoo, vérifie sa signature, et ne crée pas un second paiement quand la même notification arrive deux fois.

Il couvre tout le cycle, pas seulement l'encaissement

Selon votre activité : capture différée à l'expédition, remboursement total ou partiel lancé depuis l'avoir Odoo, cartes enregistrées pour les abonnements, paiement en plusieurs fois. Chaque fonction absente se traduit par une manipulation dans l'interface de la banque, puis par un écart à rapprocher en comptabilité.

Il laisse une trace lisible

Le jour où un client affirme avoir payé, il faut retrouver en une minute la transaction, son statut chez la banque, la raison d'un refus. Des journaux clairs et des messages de refus compréhensibles font gagner un temps considérable au service client.

Page de paiement hébergée ou intégrée : la question PCI DSS

Il existe deux grandes façons d'encaisser une carte. Avec une page de paiement hébergée, le client saisit sa carte sur une page de la banque, par redirection ou dans un cadre intégré au site. Les numéros de carte ne passent jamais par Odoo et votre périmètre PCI DSS reste minimal, avec le questionnaire d'auto-évaluation le plus court (SAQ A). Avec une intégration directe par API, votre site manipule lui-même les données de carte, et vos obligations de conformité deviennent bien plus lourdes.

Sauf raison très précise, la page hébergée est le bon choix pour une boutique Odoo. Un prestataire sérieux pose cette question dès le premier échange. S'il propose d'emblée de faire transiter les cartes par votre serveur, demandez-lui pourquoi.

La maintenance, le vrai coût d'un module de paiement

Un module de paiement n'est jamais terminé. Les banques font évoluer leurs API et leurs règles de sécurité : Monetico a par exemple prévenu ses marchands qu'il ajouterait de nouveaux paramètres à ses notifications de paiement, parfois avec un court préavis. Un module qui calcule mal le sceau de sécurité (MAC) se met alors à rejeter des paiements valides, ce qui nous a conduits à auditer et mettre à jour notre module Monetico. BNP Paribas fait passer ses marchands d'Axepta V1 à Axepta V2. De son côté, Odoo sort une version majeure par an, et chaque montée de version demande d'adapter les modules qui ne sont pas fournis par Odoo.

Un module que personne ne maintient finit par bloquer la migration de toute votre base. Avant de choisir, demandez qui fera ces adaptations, dans quel délai et dans quel cadre. Un contrat de support et de maintenance, comme celui que nous avons signé pour le module Alma, met ces réponses par écrit.

Les questions à poser avant de signer

1. Quels modules de paiement avez-vous déjà mis en production ? Des modules publiés sur l'Odoo Apps Store se testent avant de signer, des références se vérifient.
2. Connaissez-vous l'API de cette banque, et dans quelle version ? Certaines banques ont plusieurs plateformes sous le même nom commercial.
3. Que se passe-t-il si une notification se perd ou arrive deux fois ? La réponse doit être précise, pas « ça n'arrive pas ».
4. Comment testez-vous ? Sur l'environnement de test de la banque, avec les cas d'échec : carte refusée, 3D Secure abandonné, remboursement partiel, client qui ne revient pas sur la boutique.
5. Quelles versions d'Odoo couvrez-vous, et que se passe-t-il à la prochaine ?
6. Sous quelle licence le code est-il livré, et pouvons-nous le modifier ou le confier à quelqu'un d'autre ? Un module de l'Apps Store est souvent sous licence OPL-1 ou LGPL-3, un développement sur mesure doit préciser à qui appartient le code.
7. Quel support après la mise en production, et avec quel délai de réponse ? Un paiement bloqué ne peut pas attendre le prochain sprint.

Quelques signaux doivent vous alerter : un devis qui ne dit rien de la maintenance, des tests prévus directement en production, aucune mention des notifications serveur, du code livré par e-mail plutôt que dans un dépôt.

Notre avis

Si votre prestataire de paiement est intégré en standard dans Odoo, utilisez le connecteur d'Odoo. Si un module maintenu existe pour votre banque et votre version, achetez-le : ce sera plus rapide et moins cher qu'un développement. Le sur-mesure se justifie quand rien n'existe pour votre banque, ou quand votre activité demande une règle particulière : capture à l'expédition, plusieurs boutiques sur des contrats différents, abonnements avec un calendrier propre.

Dans ce cas, confiez le module à une équipe qui a déjà des paiements en production et qui s'engage sur la maintenance, et laissez votre intégrateur piloter le reste du projet. C'est la façon dont nous travaillons le plus souvent : nous partons de l'environnement de test de la banque, nous déroulons la liste des cas d'échec avant la mise en production, nous construisons le module sur le framework de paiement d'Odoo et nous le suivons version après version, y compris en sous-traitance pour d'autres intégrateurs.

Questions fréquentes

Combien de temps faut-il pour développer un module de paiement Odoo ?

Cela dépend surtout de l'API de la banque et des fonctions attendues. Un paiement par redirection avec notification serveur est bien plus rapide à livrer qu'un module qui gère aussi la capture différée, les cartes enregistrées et les abonnements. La qualité de l'environnement de test de la banque pèse souvent autant que le développement lui-même.

Peut-on installer un module de paiement sur Odoo Online ?

Non, pas un module tiers. Odoo Online n'accepte que les applications fournies par Odoo. Il faut passer sur Odoo.sh ou sur un hébergement propre pour installer un module de paiement développé par un autre éditeur.

Le même module sert-il au point de vente ?

Pas forcément. Le paiement en ligne et le terminal de paiement du point de vente sont deux intégrations distinctes dans Odoo. Si vous avez besoin des deux, dites-le dès le départ.

Qui signe le contrat avec la banque ?

Vous. Le contrat de vente à distance reste entre vous et votre banque ou votre prestataire de paiement ; le module relie seulement Odoo à ce contrat.

Que devient le module si nous changeons de prestataire ?

Tout dépend de la licence et de ce que dit le contrat sur la propriété du code. Avec le code dans un dépôt à votre nom et une documentation à jour, un autre prestataire peut le reprendre sans repartir de zéro.