Connecteur · Paiement
Connecteur Odoo ↔ paiement
Un paiement encaissé n'est pas un versement reçu. Entre les deux : des commissions, un décalage de plusieurs jours et des remboursements — c'est là que la comptabilité décroche.
Le paiement est le flux où l’on croit avoir fini quand tout commence. Faire remonter « payé » dans Odoo prend une journée. Faire en sorte que la banque tombe juste à la fin du mois prend un projet — parce qu’entre le paiement du client et le virement reçu, il se passe beaucoup de choses.
Le décalage que tout le monde découvre
Un connecteur qui remonte seulement le statut « payé » vous laisse avec une comptabilité qui ne se rapproche jamais. Le travail réel consiste à ramener quatre objets et à les relier :
| Objet | Rôle |
|---|---|
| La transaction | Rattache le paiement à la commande |
| La commission | Charge réelle, à comptabiliser |
| Le remboursement | Avoir, à rattacher à la commande d’origine |
| Le versement | Ce qui tombe en banque, et qui doit se rapprocher |
Tant que ces quatre-là ne se rejoignent pas, le rapprochement bancaire reste manuel et l’écart s’accumule.
La sécurité : un périmètre à ne pas franchir
Aucune donnée de carte ne doit transiter par Odoo, ni y être stockée. Le paiement se fait chez le prestataire, qui porte la conformité qui va avec. Odoo ne manipule qu’un identifiant de transaction et un statut.
C’est une limite que nous ne négocions pas : une architecture qui ferait passer un numéro de carte par votre ERP vous ferait entrer dans un périmètre de conformité lourd, pour zéro bénéfice.
Les webhooks : vérifier la signature, toujours
Les prestataires notifient les changements d’état — autorisé, capturé, remboursé, contesté — et réessaient en cas d’échec, souvent longtemps. C’est plus robuste que la moyenne des webhooks e-commerce.
En revanche, la vérification de signature n’est pas optionnelle. C’est le point d’entrée le plus sensible de toute l’intégration : sans elle, n’importe qui connaissant l’URL peut déclarer une commande comme payée. Nous vérifions systématiquement, et nous rejetons ce qui ne l’est pas.
Comme ailleurs : webhook plus balayage de rattrapage. Une notification perdue ne doit pas laisser une commande payée en attente de règlement pendant trois semaines.
Les remboursements et les litiges
Ce sont les cas que les connecteurs traitent en dernier, quand ils les traitent.
Un remboursement partiel doit créer l’avoir correspondant dans Odoo, s’imputer sur la bonne commande, et se retrouver dans le versement. Un litige immobilise des fonds, parfois les retire, et se résout des semaines plus tard.
Ces flux ne sont pas des exceptions : sur une activité e-commerce normale, ils sont quotidiens. Ils se conçoivent dès le départ, sinon la période comptable est fausse et personne ne sait dire pourquoi.
Encaisser depuis Odoo
Le connecteur ne sert pas qu’à recevoir. Odoo peut aussi encaisser : acompte à la signature d’un devis, paiement d’une facture depuis le portail client, lien de paiement envoyé par mail.
C’est très sous-utilisé en B2B. Faire payer un acompte au moment où le client signe — plutôt que d’envoyer une facture à trente jours qu’on relancera à soixante — change la trésorerie sans rien changer au processus commercial.
Les limites, dites franchement
Les prestataires « high-risk » sont un sujet à part. Certains secteurs sont refusés par les prestataires classiques. Ce n’est pas un problème d’intégration : Odoo se branchera sur celui que vous aurez trouvé, il ne vous en procurera pas un.
Le rapprochement à 100 % n’existe pas. Il reste toujours un résiduel à traiter à la main. L’objectif est de le réduire à quelques lignes par mois, pas de le supprimer.
Les frais varient selon les moyens de paiement et les pays. Un modèle de commission unique donne une marge fausse : il faut ramener la commission réelle par transaction.
Pour la suite comptable du flux, voir comptabilité ; pour les commissions des places de marché, marketplaces.
Questions fréquentes
Les données de carte transitent-elles par Odoo ?
Non, et il ne faut surtout pas que ça arrive. Le paiement se fait chez le prestataire, qui porte la conformité. Odoo ne voit qu’un identifiant de transaction et un statut. Toute solution qui ferait transiter un numéro de carte par votre ERP vous ferait entrer dans un périmètre de conformité que vous ne voulez pas.
Pourquoi le montant reçu en banque ne correspond-il jamais aux commandes ?
Parce que le prestataire verse un solde : il agrège plusieurs transactions, retire ses commissions, déduit les remboursements et les litiges, et verse à échéance. Sans rapprochement entre paiements, commissions et versement, la banque ne tombe jamais juste — c’est la première source d’écart comptable en e-commerce.
Les webhooks de paiement sont-ils fiables ?
Ils sont mieux faits que la moyenne — les prestataires réessaient, souvent longtemps. Mais la signature doit être vérifiée systématiquement : sans elle, n’importe qui peut déclarer un paiement comme réussi. C’est le point d’entrée le plus sensible d’une intégration.
Comment gérer les remboursements partiels ?
En les traitant comme un flux à part entière, pas comme un cas particulier. Un remboursement partiel doit créer l’avoir correspondant dans Odoo, s’imputer sur la bonne commande et se retrouver dans le versement. C’est le cas que les connecteurs oublient, et qui fausse toute la période.
Peut-on encaisser depuis Odoo ?
Oui : acompte à la signature d’un devis, paiement d’une facture depuis le portail client, lien de paiement envoyé par mail. C’est très sous-utilisé en B2B, alors que faire payer un acompte à la signature change la trésorerie sans rien changer au processus commercial.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.