French SMBs on PayPlug hit a wall the moment they try to take payment inside Odoo. Odoo's out-of-the-box payment providers cover Stripe, PayPal, Adyen and a few others, but there is no maintained PayPlug provider — so merchants end up bouncing customers to an external PayPlug hosted page, reconciling transactions by hand, or gluing together a fragile redirect that breaks on the next Odoo point-release. That means broken order states, sale.order records stuck in "quotation sent", and no clean audit trail linking a PayPlug transaction back to an Odoo payment.transaction. For a French business that specifically needs Bancontact, Apple Pay and Oney installments (paiement en plusieurs fois), the native gap is a real revenue leak at checkout.

ECOSIRE builds you a first-class Odoo payment provider that speaks PayPlug's API natively. It ships as a proper payment_payplug provider module: a payment.provider record with your PayPlug API keys stored on the provider (test and live), a payment.transaction subclass that creates, captures and reads PayPlug payment intents, and an inbound webhook controller that PayPlug calls to confirm settlement. The checkout flow supports both hosted-payment-page redirect and, where your PayPlug contract allows, an inline card form — with 3-D Secure 2 / SCA handled by PayPlug so your business never touches raw PAN data and stays inside PSD2 requirements. Cards, Bancontact and Apple Pay are exposed as selectable methods on the checkout, and Oney installment plans are surfaced with the correct per-instalment schedule.

Technically, the module is structured the way an Odoo reviewer expects. __manifest__.py declares a dependency on payment (and website_sale/account where eCommerce and invoicing are in scope) and pins installable per Odoo series. Models extend payment.provider and payment.transaction with models.Model inheritance, fields for the PayPlug secret/public keys and installment settings, and @api.depends computes for display. Access is locked down through ir.model.access.csv plus record rules so API secrets are only readable by the payment/accounting groups. The webhook lives in a JSON controller that verifies the PayPlug signature before it mutates any transaction — no unauthenticated state change. Views are QWeb/OWL templates for the checkout method selection and the provider configuration form, and every EUR amount is formatted against the French locale (currency, decimal separator, VAT-inclusive display). Reconciliation writes back to account.payment so your accountant sees a matched entry, not an orphan.

Because it is a real Odoo module, everything is inspectable and extendable: you can trigger captures over the XML-RPC/JSON-RPC API from an external OMS, wire an automated action to email a receipt on state = done, or add a QWeb report for the installment schedule. We build against your target series — Odoo 17.0, 18.0 or 19.0, Community or Enterprise — and account for the differences (Enterprise's accounting reconciliation widgets vs Community's, and the payment-provider API changes Odoo made across those releases).

This is build-to-order, not an instant download. You request a quotation, we run a short scoping call to confirm your PayPlug contract options (which methods and installment plans you're entitled to), your Odoo version and edition, and whether eCommerce, POS or back-office invoicing is in scope. From confirmed scope, typical delivery is one working week. We develop on a staging copy of your database, run UAT with you against PayPlug's test environment, then install to production with a rollback plan and hand over the git repository and documentation. You own the code for your version.