Payments and refunds from Mollie reach Odoo carrying the state each one is actually in, so nobody releases goods against money that has not arrived and on some methods may never arrive.
Mollie carries a lot of payment methods and they do not behave alike. A card authorises in seconds. A bank transfer can take days and might simply not happen. A few can be reversed afterwards. If Odoo treats all of them as paid the moment an order appears, the warehouse ships against money that has not landed, and somebody in finance finds out weeks later. The Odoo to Mollie integration carries the real state of each payment across, so releasing an order becomes a decision the business made once rather than a guess repeated with every order that comes through the shop.

Odoo sees the real state of each Mollie payment, so an order is released for picking when the money has genuinely cleared rather than when a customer reached the confirmation page.
A refund issued through Mollie updates the Odoo order it belongs to, so the books and the customer's balance agree without anybody recording the same thing in two separate places.
Payment methods that take days are treated differently from the ones that clear instantly, so offering them does not quietly mean carrying a risk the business never agreed to take.
Payments arrive against the orders they actually paid for, so the monthly comparison between what the bank received and what the shop sold stops being an exercise somebody dreads.
A customer pays through Mollie and the payment state reaches Odoo, so an order is only released for picking once the method they used has genuinely cleared, rather than at the moment they happened to see a confirmation page.
A refund processed in Mollie updates the matching Odoo order and its accounting, so the customer's record and the business's own figures both reflect the money going back without anybody having to enter it twice in two places.
A bank transfer that will take three days leaves its order waiting rather than picked, so the warehouse is not holding stock against a payment that could still, several days from now, fail to arrive at all in the end.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
A fraud screening service is the usual addition, and it belongs beside this one rather than after it, because deciding to release an order is the same decision either way. It works from the same payment and order data, so a flagged transaction and a slow payment are handled by one process rather than two that disagree.
Yes, and the decision to make first is which payment states count as paid for your business. Instant methods and slow ones are not the same thing, and treating them alike is what causes goods to ship against money that never lands. Alumio carries the real state of each payment, so Odoo acts on the one you chose.
No, and it is worth asking who will own it in a year. Which payment states release an order is exactly the rule finance wants to change after a bad month, and if that means a development request it will not get changed. Held in a form, it belongs to the people who care about the answer and can change it themselves.
When the payment behind it has actually cleared, which is not the same moment for every method. A card authorisation is close to instant. A bank transfer may take days and can simply not arrive. Deciding which states you are willing to pick against, method by method, is the whole question, and it is a commercial decision rather than a technical one.
You find out from the alert, not from the warehouse. Alumio watches each payment update as it happens, keeps a log of the payment and the order it referred to, and raises an alert with the reason the moment Odoo will not take it. Retries run where configured. The version of this that costs money is goods leaving against a payment that never cleared, and nothing is released quietly on one.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.