Merchants across Africa lose sales at checkout because Odoo core ships no DPO Group integration. Out of the box, payment only wires the generic providers (Stripe, PayPal, Adyen, wire transfer, demo), none of which cover the DPO reality of pan-African cards plus mobile money (M-Pesa, MTN MoMo, Airtel Money, Tigo Pesa) settled in KES, TZS, UGX, ZMW, GHS, RWF, ZAR and more. Teams end up reconciling DPO settlements by hand against Odoo invoices, or bolting a half-finished script onto sale/account that breaks on the next upgrade. The gap is not a config toggle — it is a real payment.provider implementation Odoo does not include.

ECOSIRE builds a proper DPO provider as a first-class Odoo module. We add a payment.provider record with code='dpo', its own __manifest__.py declaring the payment (and payment_custom) dependencies, and a models.Model layer that extends payment.transaction to speak DPO's XML/Direct API — createToken to open a transaction, the hosted payURL redirect for the customer, and verifyToken to confirm the final state. Provider credentials (Company Token, service IDs, endpoint, currency map) live on the provider form as encrypted fields, split cleanly between test and live so you can validate on staging before go-live. Card, mobile-money and bank rails are all routed through the same transaction, with a per-currency service-type map so each country charges the right way.

Technically, the money path is event-driven, not screen-scraped. A controller route receives DPO's redirect and back-channel notification, we re-verify server-side with verifyToken (never trusting the browser round-trip), and the transaction is moved through _set_pending, _set_done or _set_canceled so Odoo's own state machine posts the payment, confirms the sale order and validates the invoice via account.move. Idempotency is enforced on the DPO transaction reference so a retried webhook cannot double-post. For subscriptions, we store the DPO token against the customer and drive tokenized recurring charges from a scheduled ir.cron automated action, so sale.subscription/recurring invoices settle without re-prompting the cardholder. Access is locked down with ir.model.access.csv plus record rules on the provider and transaction data, and every state change is written to the chatter and to download/audit logs for reconciliation. Where you need branded proof of payment, we ship a QWeb report and expose the transaction over the standard XML-RPC/JSON-RPC API for your finance tooling.

Because this is build-to-order, you are not downloading a frozen zip and hoping it fits. We start from a short scoping call to confirm your DPO service configuration, the exact countries and currencies, whether you need mobile money and/or recurring, and which Odoo edition and version you run — the module is delivered targeting your Odoo 17.0, 18.0 or 19.0 database and works on both Community and Enterprise (Enterprise adds the accounting-automation and subscription niceties; on Community we wire the equivalents against account and cron). Typical delivery is one working week from confirmed scope. You receive installable source, a staging UAT with a rollback plan, documentation, a training session and a post-go-live support window — and the full git repository, so the code is yours.