A build-to-order Odoo payment provider that wires Crédit Mutuel / CIC / OneyBank Monetico Paiement into your eCommerce checkout and invoicing, with HMAC-SHA1 sealed forms, signature-verified server-to-server returns, installments, deferred capture, and refunds. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17, 18, or 19. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo payment provider that wires Crédit Mutuel / CIC / OneyBank Monetico Paiement into your eCommerce checkout and invoicing, with HMAC-SHA1 sealed forms, signature-verified server-to-server returns, installments, deferred capture, and refunds. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17, 18, or 19.
Aucun paiement maintenant. Ceci envoie une demande de devis à notre équipe — nous vous recontacterons par e-mail avec les tarifs et les prochaines étapes.
Most French merchants running Odoo eCommerce already hold a Monetico Paiement contract with Crédit Mutuel, CIC, or OneyBank — but Odoo core ships no acquirer for it. Out of the box, payment and website_sale give you a generic payment.provider framework and adapters for a handful of international gateways, none of which speak the Monetico seal (MAC) protocol. Teams end up either redirecting customers off-site to a hosted page that never reconciles cleanly back to the sale order, or hand-patching a fragile bridge that trusts the browser return and silently double-confirms orders on a refresh. Neither is acceptable when the bank's server-to-server notification (the retour) is the only trustworthy source of payment truth.
Dedicated `payment.provider` record type carrying your Monetico `TPE` (terminal number), `société` code, and `MAC` HMAC key, with the key stored encrypted and never surfaced in views, exports, or logs
`HMAC-SHA1` sealed payment-form generation over the canonically-ordered field string, computed exactly per the published Monetico Paiement specification so the bank accepts requests on first submission
Server-to-server return (`retour`) controller that recomputes and verifies the `MAC` signature before any state change — the S2S notification, not the browser, is the source of payment truth
Idempotent browser-return handling: refresh, back-button, or duplicate callbacks resolve to the existing `payment.transaction` and can never double-confirm an order or emit a second invoice
`3-D Secure` pass-through so strong customer authentication is enforced on the bank's hosted page without custom PSD2 handling on your side
Installment / split payment (`paiement fractionné`) plan configuration modeled against the sale order, with scheduled amounts sealed and tracked per instalment
We build a dedicated Monetico acquirer as a proper Odoo module. It registers a new payment.provider record type carrying your TPE (terminal number), société code, and MAC HMAC key (the key is stored encrypted, never rendered in views or logs). At checkout, the provider generates the Monetico payment form with a HMAC-SHA1 seal computed over the canonically-ordered field string exactly per the Monetico Paiement specification, so the bank accepts the request first time. Amounts are formatted to EUR cents with strict validation — no floating-point drift, no locale ambiguity — before they enter the sealed string. The customer is redirected to the Monetico hosted payment page, completes 3-D Secure inline, and returns to your site.
The critical work is on the return path. A controller handles the server-to-server retour URL, recomputes the MAC over the received fields, and rejects any notification whose signature does not verify — this, not the browser redirect, is what moves the payment.transaction to done and confirms the sale order. Browser-return handling is fully idempotent: a refresh, a back-button, or a duplicate hit resolves to the existing transaction state and can never create a second confirmation or a double invoice. Every signed request and verified response is written to an audit log so disputed payments can be reconstructed field-by-field. On top of the base flow we build the revenue features Monetico offers: installment / split plans (paiement fractionné) configured against the order, deferred capture, and refunds issued straight from the order or invoice through the Monetico recredit (remboursement) API, with the credit reconciled back onto account.payment. A preproduction/production endpoint toggle lets you certify on the bank's test platform before going live.
Because this is made to order, delivery is not instant. After a short scoping call we confirm exactly which capabilities you need (single vs. multi-company, installment plans, deferred capture, marketplace splits), certify against your Monetico preproduction credentials, run UAT on a staging copy of your database, then deploy to production with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. The module targets Odoo 17.0, 18.0, and 19.0 and works on Community or Enterprise. Pricing starts from $249 (indicative, single-company base scope); multi-company acquirers, additional installment/marketplace plan logic, and deeper accounting-reconciliation or data-migration work increase the quoted scope, which we fix in a written quotation after the scoping call.
Runs an Odoo `website_sale` storefront and holds a Monetico Paiement contract with their bank. Needs card payments captured natively in Odoo with orders and invoices reconciling automatically, instead of redirecting shoppers to a disconnected hosted page.
Owns reconciliation and refunds. Wants confirmed payments to land on the right `sale.order` and `account.move` without manual matching, refunds issued from the invoice via the recredit API, and a signed audit trail for every disputed transaction.
Needs a clean-room, spec-compliant Monetico acquirer they can install and maintain, with source, git history, and documentation — rather than reverse-engineering a brittle bridge or trusting an unmaintained community add-on.
Sells higher-ticket goods and wants `paiement fractionné` installment plans and deferred capture wired into checkout, with each instalment sealed, tracked, and reconciled correctly against the order.
Achetez la licence sur ecosire.com et téléchargez le module ZIP Monetico Payment Provider for Odoo depuis le tableau de bord de votre compte.
Extrayez le ZIP dans votre dossier de modules complémentaires personnalisés Odoo sur le serveur (ou téléchargez-le via Applications > Installer à partir du fichier sur Odoo.sh / runbot).
Activez le mode développeur, ouvrez les applications, cliquez sur Mettre à jour la liste des applications, recherchez Monetico Payment Provider for Odoo et appuyez sur Installer.
Ouvrez le nouveau menu, collez votre clé de licence ECOSIRE, connectez toutes les informations d'identification externes (Shopify, Amazon, Stripe, etc.) et enregistrez.
Exécutez le test de connexion intégré, synchronisez vos 10 premiers enregistrements et planifiez le cron récurrent. Contactez le support si quelque chose échoue.
| Critère | ÉCOSIRE | Construction personnalisée | Concurrent | Odoo natif |
|---|---|---|---|---|
| Monetico seal (MAC) compliance | HMAC-SHA1 sealed forms built to the published Monetico Paiement spec, certified on preproduction | Depends entirely on your developer correctly implementing the seal by hand | Varies by add-on; often unmaintained against current spec revisions | |
| Server-to-server return verification | Signature-verified `retour` controller is the sole source of payment truth | Frequently skipped — browser return trusted, a common double-confirm bug | Sometimes implemented, quality inconsistent | |
| Duplicate / refresh safety | Idempotent handling — no double confirmation, order, or invoice | Must be engineered and tested deliberately; easily missed | Not guaranteed | |
| Installments & deferred capture | `paiement fractionné` plans and deferred capture wired to the order | Extra bespoke work on top of the base integration | Rarely covered by off-the-shelf modules | |
| Refunds | Issued from order/invoice via the recredit API, reconciled to `account.payment` | Additional development, often deferred and never finished | Frequently absent or manual-only | |
| Support & maintenance | Post-go-live support window plus optional upgrade retainer | Tied to the individual developer's availability | Community best-effort, no SLA | |
| Source & ownership | Full source and git repository handed over | You own it but carry all the build risk | Source available but you inherit its debt | |
| Odoo 17/18/19 coverage | Built and tested for your exact version, Community or Enterprise | One-off per version, re-work each upgrade | Version support often lags new releases |
No. This is a build-to-order module that ECOSIRE develops, certifies against your Monetico credentials, and installs for you. There is no instant download — we build your version against the published Monetico Paiement seal specification and hand over the source when it is delivered.
Typically 2–4 weeks from confirmed scope. After the scoping call we agree the exact capabilities, build the module, certify on the Monetico preproduction platform, run UAT on your staging database, then deploy to production. Multi-company setups or extra installment/marketplace logic can extend that timeline, which we state in the quotation.
Pricing starts from $249 (indicative, single-company base scope). The exact figure depends on drivers like multi-company acquirers, installment or marketplace split logic, deferred capture, and accounting-reconciliation depth. We hold a short scoping call, then send a written fixed quote — you approve that before we build.
Yes. Every build includes a post-go-live support window for defect fixes and configuration adjustments. Because you receive the full git repository and source, your team or another partner can also maintain it. We can additionally quote a longer support or version-upgrade retainer if you want us to keep it current across Odoo releases.
Both. The module builds on the standard `payment`, `account_payment`, `sale`, and `website_sale` layers, which exist in Community and Enterprise, and we target Odoo 17.0, 18.0, and 19.0. We confirm your exact version and edition during scoping.
Confirmation is driven only by the signature-verified server-to-server `retour` from Monetico, never by the browser redirect. Browser-return handling is idempotent — a refresh, back-button, or duplicate callback resolves to the existing `payment.transaction` state, so no second confirmation, order, or invoice can be created.
Yes. The `MAC` HMAC key is stored encrypted and is never rendered in views, exports, or logs. Access to the acquirer configuration and audit logs is restricted via `ir.model.access.csv` and record rules to authorized accounting and admin groups, and every sealed request and verified response is logged for audit without exposing the key itself.

A build-to-order 2Checkout (Verifone) payment integration for ERPNext, giving global digital-goods sellers card acceptance, 45+ local payment methods, multi-currency checkout, and reconciled invoices. ECOSIRE scopes, builds, installs, and supports it on your ERPNext v15/v16 instance.

A build-to-order 2Checkout / Verifone payment gateway for Magento 2 and Adobe Commerce: localized checkout in 12 languages, iDEAL, Giropay and regional methods, multi-currency global selling, subscription billing and tax/invoicing automation — engineered, installed and supported by ECOSIRE.

A build-to-order ERPNext application for anonymous 360-degree reviews — configurable peer, manager, report and self rater groups, weighted competency scoring, and aggregated gap-analysis and heatmap reports. ECOSIRE scopes, builds, installs and supports it on your Frappe/ERPNext v15/v16 instance.
A build-to-order Odoo payment provider that wires Crédit Mutuel / CIC / OneyBank Monetico Paiement into your eCommerce checkout and invoicing, with HMAC-SHA1 sealed forms, signature-verified server-to-server returns, installments, deferred capture, and refunds. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17, 18, or 19.