French and EU B2C retailers running Odoo Website checkout consistently lose orders at the payment step when the only options are card and bank transfer. Shoppers who want to split a 400 EUR cart into three payments abandon rather than pay in full up front. Odoo core ships payment, account_payment, sale, and website_sale, but out of the box it has no concept of a BNPL provider that quotes an installment plan per cart, exposes eligibility in real time, or reconciles multi-installment settlement back into your accounting. You can bolt on a generic redirect provider, but it will not show shoppers a p2x/p3x/p4x schedule on the product page, will not gate plans by amount or market, and will not confirm the sale order strictly on a validated callback — which is exactly where conversion and reconciliation both break down.

We build a dedicated payment.provider record for the BNPL service as a proper Odoo module. The provider model carries live and test API keys plus the merchant identifier, and a sandbox toggle that routes every call to the test endpoint with verbose transaction logging so your team can trace an order end to end before go-live. When a cart is priced, the module makes a real-time eligibility call to the provider's REST API and returns the plans available for that amount — pay-in-2x, 3x, 4x, and deferred options — which we render as an installment-schedule widget on both product and cart pages using QWeb/OWL templates, so the shopper sees the exact dates and amounts before committing. Plan availability is governed by per-plan minimum and maximum amount rules and by EUR / French-EU market gating, all editable from Odoo through fields on the provider and dedicated configuration models secured with ir.model.access.csv and record rules.

At checkout the customer is redirected to the provider's hosted payment page, and here we enforce the critical rule: the Odoo sale order is confirmed only after the provider validates the payment. A webhook/IPN controller handles every payment state the provider reports — in_progress, paid, refused, expired — updating the payment.transaction and driving the linked sale order accordingly, with idempotent handling so a retried callback never double-confirms. Because BNPL callbacks can be delayed, a status-reconciliation ir.cron job polls pending transactions and closes the loop when a webhook is late or lost. Refunds — full and partial — are issued through the provider's API from the Odoo backend and post the matching accounting entries, and merchant fees are surfaced on the transaction and booked so your finance team sees the true net. The module is built clean-room against the provider's public REST eligibility and hosted-page API, works across Odoo 17.0, 18.0, and 19.0, and runs on Community or Enterprise.

Because this is build-to-order, nothing is downloaded from an app store — we scope your exact requirements, build the module for your Odoo version and edition, test it on a staging instance against the provider sandbox, and hand over installable source and a git repository. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); multi-company checkout, additional localization depth, extra accounting or reconciliation integrations, and non-standard checkout customizations increase the quoted scope. You receive a fixed quote after the scoping call.