Most teams running Odoo hit the same wall the moment they need a payment provider that Odoo core does not ship a connector for. Out of the box, the payment framework covers a fixed set of acquirers; if your gateway is not one of them, you are left redirecting customers to a clunky external page, reconciling settlements by hand from a bank export, or bolting on a fragile module that breaks on the next point release. The result is abandoned checkouts, mismatched account.payment records, and finance chasing discrepancies at month-end. This is where a purpose-built acquirer integration earns its keep.

ECOSIRE builds a native Odoo payment provider that plugs directly into the standard payment.provider and payment.transaction models — the same objects the eCommerce checkout, the customer-portal invoice-pay button, and the Sales quotation online-payment flow already use. Technically we ship a proper addon: a __manifest__.py declaring the dependency on payment (plus website_sale and account where relevant), a provider record extending models.Model with gateway credentials stored as encrypted fields.Char, and controller routes that implement the redirect and/or inline server-to-server payment flow. We wire the gateway's API through a thin HTTPS client, map its transaction states onto Odoo's pending/authorized/done/cancel/error state machine, and post the resulting journal entries against the correct account.journal so reconciliation is automatic rather than manual.

The reliability of any acquirer lives in its webhook path, so we treat it as a first-class citizen. A dedicated public controller receives asynchronous gateway notifications, verifies the HMAC or signature header before trusting a single byte, and idempotently advances the matching payment.transaction — protecting you against duplicate callbacks, out-of-order events, and replayed requests. Saved-card tokenization is implemented against payment.token so returning buyers pay in one click, refunds and partial refunds are driven from the account.move / POS side back to the gateway, and every call is written to a structured log for auditability. Security is enforced with ir.model.access.csv plus record rules so provider secrets are visible only to accounting and system roles, and multi-company deployments get per-company provider records and journals. The connector is built and tested against Odoo 17.0, 18.0, and 19.0, and we account for Community vs Enterprise differences (for example, accounting-depth and POS payment-method wiring) during scoping.

Because this is build-to-order, delivery follows a clear path: a short scoping call to confirm your gateway's API capabilities, the flows you need (web checkout, portal, POS, subscriptions), your Odoo edition and version, and any localization or multi-company requirements; then a fixed written quote; then a typical one working week build from confirmed scope, delivered on a staging instance for UAT before we install to production and hand over the git repository. Pricing starts from $999 (indicative, single-company base scope for a standard redirect + webhook flow on one Odoo version); adding inline tokenized card capture, POS payment integration, multi-company provider/journal setup, extra target versions, or subscription/recurring billing increases the quoted scope. You always receive a firm fixed price after the scoping call — never a surprise.