A build-to-order Odoo payment provider that adds Malaysian FPX online-banking and card checkout through Billplz and ToyyibPay, with signed webhook plus redirect reconciliation, MYR localization, and refund support. ECOSIRE scopes, builds, installs, and supports it for you. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $199.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo payment provider that adds Malaysian FPX online-banking and card checkout through Billplz and ToyyibPay, with signed webhook plus redirect reconciliation, MYR localization, and refund support. ECOSIRE scopes, builds, installs, and supports it for you.
अभी कोई भुगतान नहीं। यह हमारी टीम को एक कोटेशन अनुरोध भेजता है — हम कीमत और अगले चरणों के साथ ईमेल द्वारा संपर्क करेंगे।
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.
New `payment.provider` record with `code='billplz_toyyibpay'` so FPX appears natively in website checkout, `/my` portal, and sales-order payment links
Dual-gateway support — Billplz (bill API) and ToyyibPay (category/bill API) selectable per provider record, or run both side by side
Extends `payment.transaction` with a gateway-specific state machine mapping FPX outcomes to Odoo `draft`/`pending`/`done`/`cancel`/`error` states
Signed server-to-server webhook: HMAC/X-Signature verification against your gateway secret before any transaction state change
Idempotent `_handle_notification` reconciliation so webhook and browser redirect can't double-confirm a transaction
Scheduled `ir.cron` re-poll of transactions stuck `pending` past a threshold (FPX settles asynchronously)
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 2-4 weeks 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.
Runs an Odoo website store and is losing checkouts because buyers can't pay by FPX online banking. Needs Maybank2u/CIMB Clicks-grade coverage at checkout without switching platforms.
Tired of matching manual bank-in slips to sales orders. Wants FPX payments auto-reconciled into Odoo, refunds handled in-system, and a clean audit trail per transaction.
Owns the Odoo instance and needs a provider that installs cleanly, respects access rules, survives version upgrades, and exposes transactions over the JSON-RPC/XML-RPC API for their stack.
Bills recurring MYR invoices through the customer portal and needs FPX (plus cards) accepted on portal invoice payment links with reliable webhook settlement.
Buy the license on ecosire.com and download the Billplz & ToyyibPay FPX Gateway for Odoo (Malaysia) module ZIP from your account dashboard.
Extract the ZIP into your Odoo custom addons folder on the server (or upload via Apps > Install from file on Odoo.sh / runbot).
Activate Developer Mode, open Apps, click Update Apps List, search for Billplz & ToyyibPay FPX Gateway for Odoo (Malaysia), and press Install.
Open the new menu, paste your ECOSIRE license key, connect any external credentials (Shopify, Amazon, Stripe, etc.), and save.
Run the built-in connection test, sync your first 10 records, and schedule the recurring cron. Contact support if anything fails.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| FPX online banking support | Native FPX via Billplz/ToyyibPay across all Odoo pay flows | Possible but you design the whole provider from scratch | Varies; often single-gateway and version-locked | |
| Webhook + redirect reconciliation | Idempotent dual-path handler + cron re-poll for pending | You must build and test the state machine yourself | Usually redirect-only; async settlement often unhandled | |
| Odoo version fit (17/18/19) | Built and tested against your exact version + edition | Depends on your team's Odoo depth | Often lags a major version; upgrade gaps common | |
| MYR / sen handling | Sen conversion + 2-decimal validation, rounding-safe | Must implement and verify amount math | Inconsistent; rounding bugs reported | |
| Refund support | Provider refund endpoint wired to account.move | Extra scope to build and reconcile | Often manual or absent | |
| Fit to your process | Scoped to your flows, delivered on staging with UAT | Fully bespoke but slower and higher risk | Generic; you adapt to the module | |
| Support & handover | Post-go-live window + git repo + docs + training | Whatever your contractor agrees to | Ticket queue; response varies | |
| Time to live | 2-4 weeks from confirmed scope, build-to-order | Often months for a robust provider | Instant install but integration/debug time after |
This is build-to-order, not an instant download. After a scoping call to confirm your gateway(s), Odoo version, and sales flows, typical delivery is 2-4 weeks from confirmed scope. We build against your requirements, deliver on a staging database for UAT, and go live only after you sign off.
Both. You can enable Billplz, ToyyibPay, or both as separate `payment.provider` records. Billplz uses its bill/collection API and ToyyibPay uses its category/bill API; the module normalizes both into Odoo's standard payment transaction flow.
Odoo 17.0, 18.0, and 19.0, on Community or Enterprise. The `payment` framework changes between majors, so we pin and test against your exact version and edition rather than shipping a one-size build.
The transaction still settles. We reconcile from two independent paths — the signed server-to-server webhook and the browser redirect — into one idempotent handler, plus a scheduled `ir.cron` re-polls any transaction left pending. A dropped redirect does not lose the payment.
Yes. Refunds are wired to the gateway's refund endpoint and triggered from the invoice/transaction in Odoo, so the refund is reflected in your `account.move` records and the audit log stays consistent.
You get a post-go-live support window for defect fixes and reconciliation issues once real transactions start, plus a full git repository handover so you own the source. Version upgrades or new features beyond the delivered scope are quoted separately.
No. FPX bank selection and any card entry happen on the gateway's hosted page. Your Odoo server only exchanges API calls and verified webhooks, so no raw card data touches your infrastructure.
A build-to-order Odoo payment provider that adds Malaysian FPX online-banking and card checkout through Billplz and ToyyibPay, with signed webhook plus redirect reconciliation, MYR localization, and refund support. ECOSIRE scopes, builds, installs, and supports it for you.