If you collect mobile-money payments today, the reconciliation gap is where the pain lives. A customer pays on their phone, a confirmation arrives in a separate portal or by SMS, and someone re-keys the amount and reference into Odoo by hand — or worse, marks a sales order paid on trust and chases the mismatch at month-end. Odoo core ships a generic payment provider framework and a pos.payment.method, but neither speaks the STK Push (prompt-on-phone) flow natively: there is no built-in provider that initiates a push request, waits on an asynchronous result callback, verifies the operator reference, and posts the payment against the right sale.order, pos.order, or account.move automatically. That last-mile automation is exactly what teams end up doing by hand, and it is what this base module removes.

We build a proper Odoo payment provider that extends the standard payment.provider and payment.transaction models so M-PESA Express behaves like any other acquirer in your database — configurable per company, per currency, in test or live mode, with credentials stored on the provider record (encrypted) rather than hard-coded. On the e-commerce and invoice-portal side, checkout triggers an STK Push to the shopper's number; the module opens a payment.transaction in pending, and a secured controller endpoint receives the operator's asynchronous result callback, validates it (amount, currency, reference and a shared-secret/signature check), then transitions the transaction to done or error and lets Odoo's native flow confirm the order and post the journal entry. On the POS side we register a custom pos.payment.method with an OWL-based payment line UI so a cashier can send the prompt, see live push/poll status at the terminal, and cancel or retry — the session closes cleanly because the payment is a real pos.payment tied to a verified transaction, not a manual note.

Under the hood the integration is built to hold up in production. Outbound calls (access-token retrieval, STK push initiate, status query) run through a small service layer with timeout, retry and idempotency handling so a dropped network response never double-charges or double-posts; every request and callback is written to a dedicated log model for audit and dispute resolution. Access is governed by ir.model.access.csv plus record rules so only Payment/POS managers see credentials and transaction internals, and the callback controller is CSRF-exempt but signature-gated. The provider is delivered against your target Odoo line — 17.0, 18.0 or 19.0 — and respects the Community vs Enterprise split (works on Community point_of_sale and website_sale; Enterprise-only touchpoints are only wired if your edition has them). Because it is a base module, it exposes clean extension hooks (overridable methods on the transaction and provider, plus the JSON/XML-RPC surface) so future add-ons — bill/paybill vs buy-goods flows, reversals, C2B/B2C, scheduled reconciliation via an ir.cron automated action — layer on without a rewrite.

Delivery is build-to-order: nothing is pre-downloaded. After a short scoping call we confirm your Odoo version and edition, sandbox vs production credentials, the currencies and companies in scope, and whether you need POS, e-commerce, or both. We build against a staging copy of your database, run UAT with you (test-mode STK pushes end to end), then install to production with a rollback plan and hand over the git repository. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope covering one Odoo edition and the sandbox integration); multi-company or multi-currency setups, additional flows (buy-goods vs paybill, refunds/reversals, B2C payouts), deeper localization, and historical payment data migration increase the quoted scope.