Colombian merchants running Odoo hit a wall the moment they try to collect money the way their customers actually pay. Odoo core ships the payment provider framework for Stripe, PayPal, Adyen, and a handful of others, but there is no native Wompi acquirer — which means no PSE (débito bancario), no Nequi, and no local card acquiring priced in COP. Teams end up bolting on manual bank-transfer confirmation, reconciling by hand, and losing carts at checkout because the buyer's preferred rail simply isn't offered. That is where Odoo's out-of-the-box payment module runs out of road for Colombia.

ECOSIRE builds a first-class Wompi acquirer that plugs into Odoo's native payment.provider and payment.transaction framework. We add a new provider record (code = 'wompi') via models.Model subclasses with fields for your public/private keys and the events (integrity) secret, plus @api.depends-driven compute fields for environment (sandbox vs production) and enabled payment methods. The checkout controller redirects the buyer to Wompi's hosted Checkout — or renders the inline Widget — with a server-side reference and an integrity signature, so the amount, currency, and reference cannot be tampered with client-side.

On the return leg we handle both the redirect and the asynchronous webhook. Every event's checksum is recomputed from the documented concatenated property list plus your events secret (SHA-256) and compared in constant time before the payment.transaction state is moved — no forged APPROVED event can confirm an order. The transaction feedback path maps Wompi statuses (APPROVED, DECLINED, VOIDED, ERROR) onto Odoo's _set_done, _set_canceled, _set_error helpers, so sales orders, invoices, and the website checkout confirmation all react exactly as they do for a native provider. COP amounts are handled in cents as Wompi expects, and res.currency rounding is reconciled so the captured amount matches the SO to the peso.

Refunds are wired through the private API: an admin action on payment.transaction (and, where you want it, the linked invoice) posts a refund to Wompi, records the returned refund id, and reflects the outcome back on the Odoo record with proper ir.model.access.csv rights and a record rule so only accounting/payment managers can trigger it. The buyer sees their transaction and status in the website customer portal; your team sees a clean audit trail via mail.thread chatter on the transaction.

Because this is build-to-order, nothing ships as a blind download. We start from a short scoping call, confirm your Wompi account setup, target Odoo version (17.0, 18.0, or 19.0) and Community-vs-Enterprise edition, and which methods you need enabled (PSE, cards, Nequi, Bancolombia Transfer). We then build against your requirements, deliver on a staging instance for UAT, and only promote to production once you have signed off — typically 2–4 weeks from confirmed scope. You receive the full installable source, documentation, and a post-go-live support window.