Odoo + Payment Hub, one unified payment layer to replace 170+ scattered native payment provider modules

Why Odoo customers add Payment Hub, and what changes when they do

Odoo is the open-core business platform from Belgium, originally TinyERP in 2005, then OpenERP, then rebranded as Odoo in 2014. The platform's strength is its modularity: a few core apps (Sales, Accounting, Inventory) become a manufacturing ERP when you add MRP, a retail platform when you add POS, an eCommerce stack when you add Website + eCommerce, a subscription business when you add Subscriptions, a field-service company when you add Field Service. Customer base spans every vertical, manufacturing, wholesale distribution, retail, eCommerce, services, healthcare, education, hospitality, construction, non-profit, and Odoo customers and partners specialize accordingly. Open-source Community edition (free, self-hosted) and feature-extended Enterprise (paid, includes Studio low-code and advanced apps) cover both the cost-sensitive and feature-hungry ends of the market. Deploy self-hosted, on Odoo Online (SaaS), or on Odoo.sh (PaaS).

The gap, and it's a different kind of gap from what we see on most enterprise ERPs, is that Odoo's payment story is fragmented rather than missing. The Odoo App Store has 170+ separate payment provider modules: payment_stripe, payment_adyen, payment_authorize, payment_paypal, payment_mollie, payment_razorpay, payment_buckaroo, payment_worldline, payment_sips, plus regional acquirers and dozens of community-maintained ones. Each module is built differently. Some support manual capture (Stripe, Adyen), others don't. Some support refunds from the Odoo UI (Stripe, Adyen), others don't. Stored-credential handling is clean in a few modules and absent in most. Surcharging is hacked into some and missing from the rest. The capability matrix is uneven. Switching gateways means installing a different module and reconfiguring everything, and serving new markets means installing yet another. None of them ship Level III interchange enrichment, a unified customer portal, real-time line-level cash application across multi-invoice batches, or multi-MID routing per scenario. The native architecture is optimized for breadth rather than depth.

Payment Hub fills this gap with a different shape: one Odoo module (clarity_payment_hub) connecting to 19+ gateways behind a single, consistent API surface. The module installs through Odoo's standard module install / upgrade lifecycle. Integration to Odoo's data model uses the standard XML-RPC / JSON-RPC API, no monkey-patching, no source modifications, no PostgreSQL triggers. Studio customizations, App Store community modules, custom Python modules, automated actions, and computed fields all coexist. Switch between gateways without changing modules. Add Level III enrichment, surcharging, multi-MID routing, dunning automation, customer portal payment surface, and real-time cash application, capabilities none of the 170+ native modules deliver. Works across Community, Enterprise, Online, and Odoo.sh.

170+ scattered payment provider modules → one unified Payment Hub layer

Visit the Odoo App Store under "Payment Acquirers" / "Payment Providers" and you'll see what every Odoo customer eventually grapples with: a sprawl of separate modules, each implementing payment a different way, each with a different capability matrix. Payment Hub is the consolidation layer.

The 170+ figure isn't an exaggeration, Odoo lists payment provider modules numbering well into that range when you include community-maintained ones in the App Store. The fragmentation isn't Odoo's design failure. It's an inherent property of the open-platform-plus-community-modules model. Payment Hub takes the opposite approach: one module, one consistent surface, one set of capabilities, one place to maintain.

All four Odoo flavors supported, Community, Enterprise, Online, Odoo.sh

Odoo ships in four flavors that map to different deployment, license, and feature trade-offs. Payment Hub installs cleanly on all four. The integration code is identical. What differs is the deployment process, module-install on self-hosted, App marketplace on Online, branch-deploy on Odoo.sh.

The integration surface is identical across all four flavors, Payment Hub uses Odoo's standard XML-RPC / JSON-RPC API and the standard module install lifecycle. What changes is the deployment process. Self-hosted Community and Enterprise: drop the module into addons-path, restart, install. Odoo Online: install from the Apps marketplace. Odoo.sh: include in your repo's addons folder, push to staging, validate, push to production. For Odoo customers running multiple instances of multiple flavors (Online for sales / Community for back office, common in larger organizations), Payment Hub deploys once per instance with shared back-end configuration.

Industry specializations supported, 12+ Odoo verticals, all served

Odoo's specialization-driven approach means one customer's "Odoo" is fundamentally different from another customer's "Odoo." A manufacturer runs MRP + Inventory + Quality. A retailer runs POS + Inventory + Studio. A SaaS business runs Subscriptions + CRM + Project. Each specialization has different payment cadences and patterns. Payment Hub adapts to all 12+.

Each specialization has a different typical Payment Hub fit. Manufacturing shops get deposits on production orders, milestone billing on configured-to-order work, partial-shipment captures via stock.picking events. Wholesale distribution gets the customer-portal payment surface with multi-invoice batch pay and ACH for recurring buyers. Retail / POS gets P2PE-validated card-present captures via the POS module. eCommerce gets hosted checkout with stored credentials, 3DS2 / SCA where required, refund automation. Services / consulting gets milestone-based and timesheet-based billing through the Project module. Subscription / SaaS gets full recurring billing with the Subscriptions module, schedules, retries, dunning, mid-cycle changes. Field service gets per-ticket invoicing with stored credentials. Healthcare gets patient payment plans and HSA / FSA card handling. Education gets tuition payment plans and donation processing. Hospitality gets restaurant POS and reservation deposits. Construction gets progress billing and retainage. Non-profit gets donation forms with recurring options and member dues.

Payment Hub vs native Odoo payment modules, honest side-by-side

Odoo's 170+ native payment provider modules each implement payment differently. Capability matrix is uneven. Here's how Payment Hub compares, measured against the best-of-breed native modules (Stripe and Adyen, generally the most feature-complete).

How the integration works, XML-RPC + JSON-RPC + standard module install

Payment Hub plugs into Odoo through Odoo's standard external API (XML-RPC and JSON-RPC) and installs as a single Odoo module (clarity_payment_hub). Same install / upgrade lifecycle as any other module. Eight features that come online when Odoo gets Payment Hub:

The integration workflow, a multi-channel Odoo customer's order-to-cash, end to end

Walk through one realistic Odoo scenario. Northstar Industrial Supply, a $40M Toronto-headquartered wholesale distributor running Odoo Enterprise 17 across two companies (Northstar Canada Inc. and Northstar US LLC), three warehouses, B2B customer portal, B2C eCommerce site, and a parts-counter POS shop. Before Payment Hub, they had four separate native payment modules installed: payment_stripe for B2C eCommerce, payment_authorize for B2B portal payments, payment_adyen for European parts orders, and payment_paypal for the long-tail. Eight steps: how a $42K B2B contractor order flows through a single unified Payment Hub layer instead.

Use cases that light up on Odoo

All eleven Payment Hub use cases run on Odoo. These are the patterns where the Odoo integration shines, and where Odoo customers across the 12+ specializations get the highest use.

Technical details, for the Odoo developers and partners

For Odoo developers, Odoo partners, and Odoo administrators: the connection model, data model touchpoints, security posture, and deployment options.

Integration surface

XML-RPC for synchronous calls, token, authorize, capture, refund, void, account.payment / account.move creation. Standard Odoo external API. JSON-RPC for richer payload scenarios. Authentication via session-based or API-key. Module installs as clarity_payment_hub through Odoo's standard module install lifecycle.

Odoo data models consumed and posted

• res.partner: read/write. Stored credentials linked back via custom field.
• res.company: read for multi-company routing rule lookup.
• sale.order / sale.order.line: read for order details and L3 enrichment.
• account.move / account.move.line: read for invoice payment. Cash receipts post back via account.payment.
• account.payment: written on every capture. Reconciled against the originating account.move.
• account.payment.method: the integration registers as a payment method.
• payment.transaction: written for full transaction history. Supports refunds and disputes.
• pos.payment.method / pos.session: for POS module integration.
• mrp.production / stock.picking: subscribed for manufacturing trigger events.
• sale.subscription (Enterprise), subscribed for recurring schedule events.

Studio &, community module compatibility

• Studio (Enterprise) custom fields visible to Payment Hub via XML-RPC introspection.
• Studio Automated Actions / Server Actions fire on Payment Hub-driven postings.
• Studio-built custom forms continue to render and validate through standard Odoo form flow.
• Existing App Store community modules coexist, no module-conflict.
• Custom Python modules (in your addons-path) coexist. Their _override / _inherit logic fires as designed.

Security and compliance

• Standard HTTPS over Odoo's web tier. Session-based or API-key authentication.
• PCI DSS Level 1 service provider, with PCI scope minimized via tokenization at gateway.
• Card data never lands in Odoo's PostgreSQL. Tokens stored in res.partner custom field.
• P2PE-validated terminals available for card-present (POS module integration).
• SOC 2 Type II (Clarity).
• 3DS2 / SCA support natively across all gateways for European compliance.
• GDPR-aware data residency where required.

Deployment options across Odoo flavors

• Odoo Community (self-hosted): drop module into addons-path, restart, install. XML-RPC integration.
• Odoo Enterprise (self-hosted): same as Community plus Studio / Subscriptions / Field Service / Marketing Automation hooks.
• Odoo Online: install through the Apps marketplace. Module activates against the platform's external API.
• Odoo.sh: include in the addons folder of your repo, push to staging, validate, push to production.
• Multi-instance customers: install per instance, back-end Payment Hub configuration shared across.

Version compatibility

Payment Hub supports the currently-supported Odoo major versions: Odoo 16 (LTS), Odoo 17, Odoo 18, and the current latest release. Each new Odoo major version is supported within 60 days of release. The module's code paths use Odoo's stable APIs (sale.order, account.move, account.payment, payment.transaction, payment.provider) which Odoo maintains across versions. Upgrading Odoo doesn't require Payment Hub re-integration.

Related, explore other Payment Hub topics