Merchants selling in Thailand and wider Southeast Asia lose orders at checkout when their only options are foreign card rails. Local buyers expect PromptPay QR, the TrueMoney wallet, and THB internet banking — the exact tender types Opn Payments (formerly Omise) settles natively. Odoo core ships a payment framework with a handful of providers, but there is no first-party Opn provider, and Odoo does not model asynchronous QR/wallet confirmations, source-based flows, or Opn's webhook event shapes out of the box. The result is manual bank-statement matching, orders stuck in a pending state, and reconciliation gaps between what Opn settled and what Odoo believes it collected.

We build a dedicated Odoo payment provider that extends the native payment.provider and payment.transaction models rather than bolting on a parallel system, so it inherits Odoo's checkout, invoicing, and accounting hooks. A new provider record (code = 'opn') carries your public and secret API keys plus the webhook signing secret, stored on encrypted fields and gated by ir.model.access.csv and record rules so only Accounting/Settings managers can read them. At checkout the OWL/QWeb payment form renders the enabled Opn methods; the server creates an Opn charge or source via the REST API over requests, and for PromptPay it returns the QR payload to a QWeb-rendered template the customer scans. Card flows carry the 3-D Secure redirect through Odoo's standard return controller.

Because PromptPay, TrueMoney, and internet-banking payments confirm asynchronously, the module exposes a signed webhook controller that verifies each Opn event, maps charge.complete, charge.failed, and refund events onto the transaction state machine (_set_done, _set_pending, _set_canceled), and is idempotent against Opn's event id so retried deliveries never double-post. A scheduled action (ir.cron) polls any transaction still pending past a threshold and reconciles it against the Opn charge, closing the gap when a webhook is missed. Refunds initiated from the Odoo credit-note flow call the Opn refund API and write the returned refund id back to the transaction for audit. THB is the primary currency, with SGD and JPY handled per Opn's supported set, and amounts are converted to the correct minor-unit (satang) representation Opn expects.

This is a build-to-order engagement, not an instant apps.odoo.com download. After a short scoping call we confirm which methods you need (cards, PromptPay, internet banking, TrueMoney), your Odoo edition and version (17.0/18.0/19.0, Community or Enterprise), and your accounting/journal setup. We then build against your exact configuration, run UAT on a staging database with Opn test keys, and hand over installable source, a git repository, and documentation. Typical delivery is one working week from confirmed scope, and every path is tested end-to-end with live-mode keys before go-live.