Philippine SMEs selling on Odoo eCommerce or taking payments at the POS lose orders every day because their customers reach for GCash or Maya and there is no native way to accept those wallets inside Odoo. Out of the box Odoo ships payment providers for cards, Stripe, PayPal, and a handful of global gateways, but none of them speak QR Ph or the GCash/Maya redirect flow, and none reconcile a wallet settlement back to the originating sale order or invoice. Teams end up screenshotting wallet transfers, manually matching references against bank statements, and re-keying amounts — a slow, error-prone process that breaks the moment volume grows or a refund is requested.

ECOSIRE builds a dedicated Odoo payment provider that plugs GCash and Maya directly into the standard checkout. Technically, we extend payment.provider and payment.transaction with a new provider code, so the wallet options appear natively on the website checkout, in the customer portal "Pay Now" flow, and — where your license permits — at the Point of Sale. The module presents a QR Ph code for scan-to-pay and a hosted-redirect path for in-app confirmation, then listens on a signed controller webhook (the merchant callback) to move the transaction through Odoo's canonical draft → pending → done/cancel/error state machine. On a confirmed settlement we call _set_done() (or _set_pending()/_set_error() as appropriate), which lets Odoo's own logic confirm the sale order, register the payment, and post the journal entry — so reconciliation is a first-class Odoo action, not a spreadsheet.

Under the hood the build includes proper __manifest__.py packaging with the right depends (payment, sale, website_sale, and point_of_sale when POS is in scope), models/ extending the payment ORM with @api.depends computed fields for fees and reference formatting, security/ir.model.access.csv plus record rules so only accounting/settlement roles see raw gateway payloads, and provider views authored in XML/OWL for the config screen and a QWeb-rendered payment status page. Amounts are handled in PHP with correct rounding and currency setup, gateway credentials are stored on the provider record (never hardcoded), and every webhook is signature-verified before it can flip a transaction. Refunds are wired through Odoo's _process_refund support where the wallet API allows it, with a clear manual-refund fallback and audit trail when it doesn't. Optional automated actions can flag stale pending transactions for follow-up, and the JSON-RPC/XML-RPC surface stays clean so your other systems can query transaction state.

Because this is build-to-order, you are not downloading a generic binary and hoping it fits. We start with a short scoping call to confirm your Odoo version (17.0, 18.0, or 19.0), Community vs Enterprise, which channels you need (website, portal, POS), your GCash/Maya merchant onboarding status, and your reconciliation and refund rules. ECOSIRE then develops the module against a staging copy of your database, runs UAT with you, and delivers installable source, documentation, and a training session. Typical delivery is one working week from confirmed scope, and every engagement includes a post-go-live support window plus the full git repository handover so the code is yours.