If you’ve ever tried to build a community Odoo app that accepts payments — a donation module, a membership system, an event ticketing app — you’ve probably run into the same wall. The payment module, which handles all payment processing through providers like Stripe, PayPal, and Adyen, depended on the account module. That meant your lightweight community app had to pull in the entire Invoicing application just to process a credit card transaction. For many use cases, that was a dealbreaker.
Odoo has now cleanly separated the two. The payment module operates as a standalone engine with no dependency on accounting, and a new bridge module called account_paymenthandles the integration when both are installed. It’s the kind of architectural change that doesn’t make headlines but quietly unlocks an entire category of applications that weren’t practical before.
Why the Old Architecture Was a Problem
The coupling between payment processing and accounting wasn’t just a dependency declaration in a manifest file. The logic itself was entangled in ways that made clean separation impossible.
Portal payment workflows — the flows where customers pay invoices or quotations from the customer portal — had their logic split across both modules. The main payment processing lived in account_payment, but critical parts of the flow leaked into the paymentmodule itself. Payment links, which let you generate a URL to send to a customer for direct payment, weren’t handled by account_paymentat all — they lived entirely in payment, which then needed accounting context to function.
The result was that the paymentmodule couldn’t function on its own. Even if you didn’t need invoices, journal entries, or any accounting feature, you were stuck with the full accounting stack just to let someone pay with a credit card.
How the Separation Works
Everything accounting-related has been moved to account_payment. The payment module retains its role as the core engine: it manages payment providers (the Stripe, PayPal, and Mollie configurations), processes transactions, handles tokenization for recurring payments, manages the portal payment experience, and generates payment links. None of that requires knowing what an invoice is or how a journal entry works.
When the Invoicing or Accounting app is installed alongside the payment module, account_payment automatically bridges the gap. It adds invoice payment capabilities, creates the appropriate journal entries when payments complete, and handles the reconciliation between payment transactions and accounting records. The bridge works through the same hooks that the Sales module already used to integrate with payments, so the pattern is consistent.
One practical improvement that came out of this refactor: payment method lines are now created automatically when a new payment provider module is installed. Previously, each provider module (like payment_stripe or payment_paypal) had to override multiple methods and load custom data files to register its payment method lines on accounting journals. That boilerplate is gone — the system handles it automatically through the bridge module when accounting is present, or skips it entirely when it’s not.
What This Opens Up for Community Developers
The immediate practical impact is for the community app ecosystem. A developer building, say, a volunteer management app with event registration fees can now depend on paymentdirectly. The app gets full payment provider support — Stripe checkout, card tokenization, payment status webhooks — without requiring the user to install and configure an accounting application they don’t need.
For smaller Odoo deployments that use the Community edition without accounting, this is especially relevant. The combination of a website, an e-commerce catalog, and payment processing no longer requires accounting infrastructure. The payment engine handles the transaction lifecycle independently, and the accounting layer can be added later if the business grows into needing it.
It also simplifies testing and development. Community modules that process payments no longer need accounting test fixtures, sample chart of accounts, or fiscal year configurations in their test suites. The payment module’s test infrastructure is self-contained.
The Broader Pattern
This decoupling follows a pattern that Odoo has been slowly pursuing across its module ecosystem — reducing the hard dependencies between functional areas so that each module can operate as independently as possible. The Sales module already used hooks in the payment system rather than hard dependencies. The Website module already separated its core from the e-commerce layer. Now payments follow the same philosophy.
For businesses running Odoo, the change is transparent. If you have both Invoicing and payment providers configured, everything works exactly as before — the bridge module loads automatically and handles all the accounting integration. The difference is purely architectural: the system is now correctly layered instead of entangled, and the community of developers building on top of it has one fewer arbitrary restriction to work around.
It’s not a feature that will appear in any sales presentation. But for the hundreds of community developers who have been forking and patching the payment module to work without accounting, it removes a friction point that has existed since the payment framework was first introduced. That kind of infrastructure work is what separates a platform from an application — and Odoo is clearly betting on being the former.