Saudi merchants running Odoo eCommerce or the POS frequently hit a wall at the payment step: local buyers expect to pay with STC Pay or their mada card, but Odoo core ships only with generic providers (Stripe, PayPal, wire transfer, and the payment_custom manual flow). There is no native payment.provider record that speaks to STC Pay's wallet API or routes mada correctly through a local acquirer, so merchants either lose the sale to an off-platform payment link or reconcile transactions by hand. Enterprise adds more first-party acquirers, but STC Pay and true mada-first routing are still not among them — the road runs out exactly where the Saudi conversion happens.

We build a dedicated payment provider module that plugs into Odoo's standard payment framework. It ships a new payment.provider type with its own settings view (merchant credentials, environment toggle, supported currencies restricted to SAR), a payment.transaction extension implementing _get_specific_rendering_values, _send_payment_request, and _process_notification_data, and a set of controller routes for the redirect/return and the asynchronous webhook. The STC Pay flow presents the wallet QR and OTP confirmation step; mada card payments and Apple Pay are routed through your acquirer's hosted fields or redirect, with the card scheme detected so mada BINs settle on the domestic rails. Every state transition is driven by the acquirer's signed callback, not by the browser return, so a dropped connection never leaves a paid order stuck in draft.

Technically, the module is a clean, PEP8/OCA-styled addon: __manifest__.py declaring the dependency on payment (and website_sale/point_of_sale where in scope), models in models/ with @api.depends computes for any derived fields, access control via ir.model.access.csv plus record rules so a portal user can only see their own transactions, QWeb/OWL templates for the checkout widget, and a payment-status page. Webhook reconciliation verifies the HMAC signature on every notification, matches it to the pending payment.transaction by provider reference, is idempotent against duplicate deliveries, and posts the payment against the sale order and invoice. Refunds are supported through the standard action_refund path so a credit note or a POS return triggers a real refund call to the acquirer and writes back the refund reference. Everything is auditable via ir.logging and exposed to the XML-RPC/JSON-RPC API like any other Odoo model, so your existing integrations keep working.

Because this is a build-to-order engagement, we start from your exact scope — which STC Pay/mada acquirer contract you hold, whether you need web checkout, POS, or both, and your Odoo edition and version (17.0, 18.0, or 19.0; Community or Enterprise). We confirm the specification, build against a staging copy of your database, run UAT with real sandbox credentials, and hand over installable source plus a git repository. Typical delivery is one working week from confirmed scope. There is no instant download — this is a real module, built, installed, and supported for your environment by ECOSIRE.