Malaysian SMEs selling on Odoo eCommerce, the customer portal, or via sales-order payment links keep losing checkouts because Odoo core ships no FPX option — the online banking rail that most Malaysian buyers actually trust. The stock payment module only carries generic providers (Stripe, PayPal, wire transfer, and a demo acquirer), none of which speak to Maybank2u, CIMB Clicks, or the other ~40 FPX participating banks. Buyers bounce at the last step, and finance ends up chasing manual bank-in slips and matching them against sales orders by hand. This is exactly where native Odoo runs out of road: there is no payment.provider record type for FPX, no state machine that understands Billplz bill callbacks or ToyyibPay category/bill flows, and no MYR-aware reconciliation.

We build a proper Odoo payment provider add-on that plugs into the standard payment framework so it behaves like a first-class acquirer everywhere Odoo already renders a pay button — website checkout, /my portal invoices, subscription renewals, and sales-order payment links. Technically, the module defines a new provider in payment.provider (code = 'billplz_toyyibpay'), extends payment.transaction with the compute/state logic for both gateways, and stores API keys, collection/category IDs, and the sandbox/production toggle as encrypted provider fields. On checkout it creates a Billplz bill (or ToyyibPay bill under a configured category) via the gateway REST API, redirects the buyer to the hosted FPX bank-selection page, and then reconciles the result through two independent paths: the server-to-server signed webhook (X-Signature / HMAC verification against your secret) and the browser redirect return. Both funnel into one idempotent _handle_notification handler so a transaction is never double-confirmed and a dropped redirect still settles from the webhook. Access is locked down with ir.model.access.csv plus record rules, provider secrets never render in QWeb, and every gateway call is logged for audit.

Beyond the happy path, we build the parts that make it production-grade in Malaysia: MYR currency and 2-decimal amount handling (gateways transact in sen, so amounts are converted and validated to avoid rounding drift), FPX-specific failure/pending states mapped to Odoo's pending/done/cancel/error transaction states, and refund support wired to the provider's refund endpoint from the invoice/transaction so accounting stays consistent. We add configuration views (OWL/XML) for keys and environment, an automated action or scheduled ir.cron to re-poll any transaction left pending past a threshold (FPX can settle asynchronously), and clean confirmation email/receipt behavior. Where you need it, transactions and provider status are reachable over the XML-RPC/JSON-RPC API so an external storefront or middleware can drive Odoo as the system of record. It targets Odoo Community and Enterprise on 17.0, 18.0, and 19.0 — the payment framework differs across those majors, so we pin and test against your exact version.

Because this is build-to-order, nothing is a black-box download. We start with a short scoping call to confirm which gateway(s) you use (Billplz, ToyyibPay, or both), your Odoo version and edition, sandbox credentials, and which sales flows must accept FPX. We then build against your requirements, deliver on a staging database for UAT, and go live only after you sign off — typical delivery is one working week from confirmed scope. You receive the full installable source, a git repository handover, and a post-go-live support window so the reconciliation keeps working after real money starts flowing.