ASEAN enterprise merchants running Odoo hit a wall the moment they need to collect payment the way their customers actually pay. Odoo's stock payment providers cover Stripe, PayPal, Adyen, and a handful of global names, but they do not speak 2C2P — the acquirer of record for cards, TrueMoney, GrabPay, ShopeePay, and cash-based over-the-counter channels across Thailand, Singapore, Malaysia, the Philippines, Indonesia, and Vietnam. Without a native provider, finance teams end up reconciling 2C2P settlements by hand against Odoo sales orders and invoices, and eCommerce carts leak conversions because the local wallet or 7-Eleven counter option a buyer expects simply is not on the checkout page.

ECOSIRE builds a first-class Odoo payment provider (payment.provider / payment.transaction) that integrates 2C2P end to end. The module ships as a proper Odoo addon: a __manifest__.py declaring dependencies on payment, sale, and account; models that extend payment.provider with 2C2P credentials (merchant ID, secret key, environment toggle for sandbox vs production) and payment.transaction with the reference, invoice number, and settlement fields; plus ir.model.access.csv and record rules so only Accounting and Payment managers can view credentials or reconcile transactions. Checkout uses 2C2P's Hosted Payment Page — the customer is redirected to a PCI-scoped page hosted by 2C2P, chooses cards, a local wallet, or over-the-counter, and returns to Odoo with a signed result. No card data ever touches your Odoo server.

Technically, the flow is hardened for reconciliation, not just first payment. We generate the 2C2P payment request (JWT-signed payload per 2C2P's API), redirect via a QWeb-rendered form, and then treat the server-to-server webhook — not the browser return — as the source of truth. An inbound controller verifies the signature, maps the 2C2P transaction status to Odoo's pending / authorized / done / cancel / error states, and posts the payment against the linked invoice using Odoo's standard _set_done() / _set_pending() transaction lifecycle. Refunds are wired to Odoo's native refund action so a credit note or a partial refund in Accounting calls the 2C2P refund API and writes back the acquirer refund reference. Multi-currency ASEAN settlement is respected — THB, SGD, MYR, PHP, IDR, VND — with the transaction currency carried through to the journal entry. Automated actions (ir.cron / server actions) can retry unconfirmed webhooks and flag transactions that authorized but never settled.

Because this is build-to-order, nothing is a black box. After a short scoping call we confirm exactly which 2C2P products you use (payment methods, settlement currencies, whether you need the eCommerce Hosted Payment Page, the Point-of-Sale invoice link, or the XML-RPC/JSON-RPC path for a headless front end), then build against your specific Odoo edition. Community and Enterprise are both supported — the provider sits on the base payment framework present in both, and we adapt the accounting reconciliation to whichever you run. We deliver on Odoo 17.0, 18.0, or 19.0, test the full authorize-webhook-settle-refund cycle on your staging database, and only then cut over to production. Typical delivery is one working week from confirmed scope. You receive the complete, readable source — no obfuscation, no per-transaction license lock-in.