Who Should Build Your Odoo Payment Module?

We build and maintain Odoo payment modules for European banks and payment providers: Monetico, Axepta BNP Paribas, CAWL, Alma, Viva Wallet, HiPay, FLOA Pay. So we have a stake in the answer, and we would rather say it upfront. This guide is still meant to help if you never work with us: these are the questions we would ask any provider before trusting them with a shop's payments.

Do you really need custom development?

Before looking for a provider, three checks sometimes remove the need for any development.

• Is your provider already in Odoo? Odoo ships several payment providers out of the box, including Stripe, Adyen, Mollie and PayPal. If yours is one of them, it is a matter of configuration, not code. The list is in the payment providers menu of your database, and it changes from one version to the next.
• Does a module already exist? Search the Odoo Apps Store for your bank's name, filtered on your Odoo version. A maintained module almost always costs less than custom work.
• Does your hosting accept third-party modules? Odoo Online, Odoo's standard SaaS offer, does not accept custom Python modules. To install a payment module that Odoo does not provide, you need Odoo.sh or your own server.

French banks' payment solutions are the most common case where nothing exists in standard: Monetico for Crédit Mutuel and CIC, or Axepta for BNP Paribas, for example. That is where a module becomes necessary.

The options, and their limits

No option is wrong in itself. Each one has a weak spot that is worth knowing before you choose.

What a serious payment module must handle

A payment that works in a demo does not prove much. What sets a good module apart is how it behaves when something goes wrong. Here is what we check first when we are asked to audit or take over a module.

It is built on Odoo's payment framework

Odoo handles payments with shared models: payment.provider for the provider, payment.transaction for each payment, payment.token for saved cards. A module built on these models works at once everywhere Odoo takes payments: the online shop, payment links, the customer portal, subscriptions. A module that bypasses the framework has to be redone for every use. These models also change between versions (payment.acquirer became payment.provider in version 16, payment methods arrived in 17), so a module sold as compatible with every version deserves a question about how.

It does not rely on the customer coming back to the shop

After paying, many customers close the tab without returning to the site. If the order is only confirmed when the browser comes back, it stays a quotation while the money has been collected. A reliable module processes the notification the bank sends straight to the Odoo server, checks its signature, and does not record a second payment when the same notification arrives twice.

It covers the whole cycle, not just the payment

Depending on your business: deferred capture at shipping, full or partial refunds started from the Odoo credit note, saved cards for subscriptions, payment in instalments. Every missing feature turns into a manual step in the bank's back office, then into a difference to reconcile in accounting.

It leaves a readable trail

The day a customer says they paid, you need to find the transaction, its status at the bank and the reason for a refusal in a minute. Clear logs and understandable refusal messages save your customer service a lot of time.

Hosted or embedded payment page: the PCI DSS question

There are two main ways to take a card payment. With a hosted payment page, the customer enters their card on a page run by the bank, through a redirect or a frame embedded in your site. Card numbers never go through Odoo and your PCI DSS scope stays minimal, with the shortest self-assessment questionnaire (SAQ A). With a direct API integration, your site handles the card data itself, and your compliance obligations become much heavier.

Unless you have a very specific reason, the hosted page is the right choice for an Odoo shop. A serious provider raises this question in the first conversation. If they suggest sending cards through your server from the start, ask them why.

Maintenance, the real cost of a payment module

A payment module is never finished. Banks change their APIs and security rules: Monetico, for example, warned its merchants that it would add new parameters to its payment notifications, sometimes at short notice. A module that computes the security seal (MAC) the wrong way then starts rejecting valid payments, which led us to audit and update our Monetico module. BNP Paribas is moving its merchants from Axepta V1 to Axepta V2. On its side, Odoo releases a major version every year, and each upgrade means adapting the modules that Odoo does not provide.

A module nobody maintains ends up blocking the migration of your whole database. Before choosing, ask who will make these changes, how fast, and under what agreement. A support and maintenance contract, like the one we signed for the Alma module, puts those answers in writing.

Questions to ask before you sign

1. Which payment modules have you already put into production? Modules published on the Odoo Apps Store can be tried before you sign, and references can be checked.
2. Do you know this bank's API, and which version? Some banks run several platforms under the same brand name.
3. What happens if a notification is lost or arrives twice? The answer should be precise, not "that does not happen".
4. How do you test? On the bank's test environment, with the failure cases: declined card, abandoned 3D Secure, partial refund, a customer who never comes back to the shop.
5. Which Odoo versions do you cover, and what happens with the next one?
6. Under which licence is the code delivered, and can we change it or hand it to someone else? An Apps Store module is often under OPL-1 or LGPL-3; custom work should state who owns the code.
7. What support do you offer after go-live, and how fast do you answer? A blocked payment cannot wait for the next sprint.

A few signs should worry you: a quote that says nothing about maintenance, tests planned directly in production, no mention of server notifications, code sent by email rather than in a repository.

Our view

If your payment provider is built into Odoo, use Odoo's connector. If a maintained module exists for your bank and your version, buy it: it will be faster and cheaper than development. Custom work makes sense when nothing exists for your bank, or when your business needs a specific rule: capture at shipping, several shops on different contracts, subscriptions with their own schedule.

In that case, give the module to a team that already has payments in production and commits to maintaining it, and let your Odoo partner run the rest of the project. That is how we work most of the time: we start from the bank's test environment, we go through the list of failure cases before go-live, we build the module on Odoo's payment framework and we keep it up to date version after version, including as a subcontractor for other Odoo partners.

FAQ

How long does it take to build an Odoo payment module?

It mostly depends on the bank's API and the features you need. A redirect payment with server notifications is much faster to deliver than a module that also handles deferred capture, saved cards and subscriptions. The quality of the bank's test environment often weighs as much as the development itself.

Can a payment module be installed on Odoo Online?

Not a third-party one. Odoo Online only accepts apps provided by Odoo. You need Odoo.sh or your own hosting to install a payment module from another publisher.

Does the same module work for the Point of Sale?

Not necessarily. Online payment and the Point of Sale payment terminal are two separate integrations in Odoo. If you need both, say so from the start.

Who signs the contract with the bank?

You do. The e-commerce contract stays between you and your bank or payment provider; the module only connects Odoo to that contract.

What happens to the module if we change provider?

It depends on the licence and on what the contract says about code ownership. With the code in a repository you own and up-to-date documentation, another provider can take it over without starting from scratch.