Illustrative previewBuild-to-order Mollie payment provider for Odoo
— iDEAL, Bancontact, cards, Apple Pay, Klarna with webhook reconciliation and refunds.
What is Mollie Payment Gateway for Odoo?
Build-to-order Mollie payment provider for Odoo — iDEAL, Bancontact, cards, Apple Pay, Klarna with webhook reconciliation and refunds. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.
Key Features
Built to order, done for you
No DIY setup — a working app, built, installed and supported by ECOSIRE.
- 1
You order
Start with a one-time build price. We scope it with you at kickoff.
- 2
We build & install
ECOSIRE builds, configures and installs it on your Odoo.
- 3
Go live + support
You go live in about one working week, with two weeks of go-live support. Defects in the code we deliver are fixed free of charge.
Technical Specifications
- Odoo Compatibility
- Odoo 17, Odoo 18, Odoo 19
- Editions
- Enterprise & Community
- License
- Licence confirmation required
- Python Requirement
- Python 3.10+
- Database
- PostgreSQL 12+
About this Product
Give your European customers the checkout they already trust. This is a build-to-order Mollie payment provider that ECOSIRE designs, builds, installs, and supports for your Odoo 17, 18, or 19 instance — it is not an instant apps.odoo.com download. After purchase we scope your exact method mix and go live in roughly one working week.
Under the hood it is a proper Odoo payment provider. We register a new payment.provider record and a dedicated payment.mollie extension of payment.transaction, so Mollie behaves like any native provider across the Website eCommerce checkout, Sales quotation online payment links, Invoicing customer portal, and Subscriptions. One Mollie API key unlocks the full European method set — iDEAL, Bancontact, credit/debit cards, Apple Pay, Klarna Pay Later/Slice It, SEPA, and more — instead of stitching together several single-method connectors.
The connector is reconciliation-first. Every checkout creates a Mollie order/payment, and Mollie's asynchronous webhook is received on a public controller route that verifies the payment status server-side (never trusting the redirect alone), then moves the linked payment.transaction to done, cancel, or error and confirms the sale order or posts the invoice. Statuses are polled as a fallback via Mollie's API so a missed webhook never leaves a transaction stuck in pending. Refunds and partial refunds are issued straight from the Odoo transaction form, writing back to Mollie and reflecting in accounting.
We build it clean and upgrade-safe: a documented __manifest__.py, models with computed fields declaring @api.depends, access rights in ir.model.access.csv plus record rules so only Payment and Accounting managers touch provider config, OWL/XML backend views, and a QWeb payment-status snippet for the portal. EUR localization, multi-currency, and per-method availability rules are configured to your countries. Works on Community and Enterprise. You get the full source, so nothing is a black box.
What you get
- Complete, commented Odoo module source (models, controllers, views, security, data) delivered as a versioned repo for Odoo 17, 18, or 19
- A configured, live Mollie payment provider on your instance with test-mode validation followed by live go-live
- Method and country availability configured to your target markets (iDEAL, Bancontact, cards, Apple Pay, Klarna, SEPA)
- Webhook and return-URL setup verified end-to-end against your domain, including reconciliation and refund test transactions
- Admin runbook: how to add/rotate API keys, enable methods, issue refunds, and read the transaction state trail
- A live training/handover session for your finance and store-admin team, with recording
- Security configuration: ir.model.access.csv access rights and record rules restricting provider config to authorized roles
- A defined post-go-live support window covering bug fixes and minor Odoo point-release compatibility
Who this is for
EU merchant standardizing on Mollie
Runs an Odoo Website store and wants iDEAL, Bancontact, cards, Apple Pay, and Klarna from a single Mollie account instead of juggling several single-method connectors and dashboards.
Finance / accounting manager
Needs every online payment to reconcile cleanly against invoices in Odoo, with partial refunds handled inside Odoo and an auditable transaction trail — not manual matching against the Mollie dashboard.
Store operations / e-commerce admin
Wants checkout to show only the payment methods relevant to each customer's country and to trust that a successful payment reliably confirms the order without stuck-pending tickets.
How Mollie Payment Gateway for Odoo Compares
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Mollie support in Odoo (iDEAL, Bancontact, Klarna, Apple Pay) | Full method set from one connector, built and configured for you | Possible but you build every method and edge case yourself | Varies — some list Mollie but coverage/quality differs per module | Not included |
| Server-verified webhook reconciliation with polling fallback | Built in and tested end-to-end | You must design and test the whole flow | Partial support | Not included |
| Full + partial refunds from inside Odoo | Yes, from the transaction form, written back to Mollie | Only if you build it | Partial support | Not included |
| Installed, configured, and validated on your instance | Yes — test-mode sign-off then live go-live | You do the setup | You install and configure yourself | Included |
| Full source code you own and can extend | Yes — complete commented module delivered | Yes, it's your code | Partial support | Not included |
| Fixes, Odoo point-release compatibility, and handover training | Defined support window + live training + runbook | Your team owns all maintenance | Depends on vendor SLA | Not included |
| Per-country method availability rules | Configured to your target markets | Build it yourself | Partial support | Not included |
Frequently Asked Questions about Mollie Payment Gateway
This says build-to-order — do I get an instant download?
No. This is not an existing apps.odoo.com download. ECOSIRE scopes, builds, installs, and configures the Mollie provider for your specific Odoo instance and method mix. Typical delivery is one working week from when we confirm requirements and receive access — faster for a standard EUR setup, longer if you need custom subscription tokenization or multi-company routing.
What's the lead time and what happens after I purchase?
After purchase we run a short scoping call to confirm your Odoo version (17/18/19), Community vs Enterprise, target countries, and desired methods. We then build in a staging environment, validate every method in Mollie test mode, and schedule go-live. Most projects complete in one working week; you approve at test-mode sign-off before we switch to live keys.
How do support and updates work after go-live?
You receive a defined post-go-live support window covering bug fixes and configuration help, plus minor-version compatibility as Odoo ships point releases on your major version. Because you get the full source, your own team can extend it too. Extended support and upgrades to a future major Odoo version (e.g. moving from 18 to 19) are available as a separate engagement.
Which Odoo versions and editions are supported?
Odoo 17, 18, and 19, on both Community and Enterprise. It registers as a standard payment.provider, so it integrates with Website eCommerce, Sales online payment links, and the Invoicing customer portal. We target the exact minor version your instance runs.
How does reconciliation work if a webhook is missed?
Payment status is always verified server-side via Mollie's webhook — we never confirm an order from the browser redirect alone. If a webhook is delayed or lost, a fallback poll queries Mollie's API for the payment status so the payment.transaction resolves to done, cancelled, or error and the sale order/invoice updates accordingly. Refunds and partial refunds are issued from the Odoo transaction and written back to Mollie.
Can it handle refunds, partial refunds, and multi-currency?
Yes. Full and partial refunds are triggered directly from the Odoo payment transaction and reflected in both Mollie and your accounting. It handles EUR localization and multi-currency with correct amount formatting and rounding, and you can restrict methods per country so customers only see relevant options at checkout.
Related Modules
Midtrans Payment Gateway for Odoo (Indonesia)
Indonesian cards, e-wallets, and VA bank transfer via Midtrans Snap on Odoo — built, installed and supported by ECOSIRE.
Mobile Messaging Integration - Base Framework for Odoo Discuss
A build-to-order foundation module that extends Odoo Discuss with the core plumbing to send and receive mobile messages through a provider gateway. ECOSIRE scopes, builds, installs and supports it — this is a made-to-order engagement, not an off-the-shelf download.
Moyasar Payment Gateway for Odoo
A build-to-order Odoo payment provider that connects your Saudi checkout to Moyasar — accepting mada, Apple Pay, STC Pay, and cards in SAR with webhook-based reconciliation. ECOSIRE builds, installs, and supports it after a scoping call.
M-PESA Express Payment Base for Odoo
A build-to-order base module that wires M-PESA Express (STK Push) into Odoo as a first-class payment provider for both e-commerce checkout and Point of Sale. ECOSIRE scopes, builds, installs, and supports it — this is not an off-the-shelf download.
Mollie Payment Gateway
Build-to-order Mollie payment provider for Odoo — iDEAL, Bancontact, cards, Apple Pay, Klarna with webhook reconciliation and refunds.
- Single Mollie connector exposing iDEAL, Bancontact, credit/debit cards, Apple Pay, Klarna Pay Later & Slice It, and SEPA from one API key
- Registered as a native Odoo payment.provider with a dedicated payment.mollie transaction model — works in Website checkout, Sales payment links, Invoicing portal, and Subscriptions
- Server-verified webhook controller: Mollie's async notification confirms payment status server-side before the payment.transaction is set to done
- API status polling fallback so a dropped or delayed webhook never strands a transaction in pending