A custom Odoo payment provider that accepts STC Pay and mada directly at checkout, with SAR localization, webhook reconciliation, and refund support. ECOSIRE builds, installs, and supports it for your Saudi Odoo instance. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $199.00 USD; request a quote for a scoped proposal.

A custom Odoo payment provider that accepts STC Pay and mada directly at checkout, with SAR localization, webhook reconciliation, and refund support. ECOSIRE builds, installs, and supports it for your Saudi Odoo instance.
现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。
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.
New `payment.provider` type registered in Odoo's payment framework with a dedicated settings form (credentials, sandbox/production toggle, currency locked to SAR)
STC Pay wallet flow with QR presentment and OTP confirmation handled in the checkout widget
mada card acceptance with BIN/scheme detection so domestic cards settle on mada rails rather than a cross-border scheme
Apple Pay routing through the acquirer's hosted payment session for supported Safari/iOS buyers
`payment.transaction` model extended with `_get_specific_rendering_values`, `_send_payment_request`, and `_process_notification_data` per the standard provider contract
Asynchronous webhook controller with HMAC signature verification and idempotent handling of duplicate deliveries
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 2 to 4 weeks from confirmed scope. There is no instant download — this is a real module, built, installed, and supported for your environment by ECOSIRE.
Runs `website_sale` and is losing conversions because local buyers can't pay with STC Pay or their mada card at checkout. Needs a native in-checkout provider, not an off-platform payment link, and wants SAR amounts and Arabic labels to look right.
Wants one payment provider that works both in-store (Point of Sale) and online, so STC Pay and mada reconcile the same way across channels and refunds flow through credit notes and POS returns.
Cares about clean reconciliation: every wallet and card payment matched to the right invoice and sale order, idempotent webhooks, a full audit trail, and refunds that write back a real acquirer reference for the books.
Owns the instance and wants a maintainable addon: standard `payment.provider` contract, proper `ir.model.access.csv` and record rules, XML-RPC/JSON-RPC compatibility, and a git handover they can upgrade across 17.0/18.0/19.0.
在 ecosire.com 上购买许可证并从您的帐户仪表板下载 STC Pay & mada Wallet Checkout for Odoo 模块 ZIP。
将 ZIP 解压到服务器上的 Odoo 自定义插件文件夹中(或通过“应用程序”>“从 Odoo.sh / runbot 上的文件安装”上传)。
激活开发者模式,打开应用程序,单击更新应用程序列表,搜索 STC Pay & mada Wallet Checkout for Odoo,然后按安装。
打开新菜单,粘贴您的 ECOSIRE 许可证密钥,连接任何外部凭据(Shopify、Amazon、Stripe 等),然后保存。
运行内置连接测试,同步前 10 条记录,并安排定期 cron。如果出现任何问题,请联系支持人员。
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| STC Pay & mada support | Built directly into checkout for STC Pay wallet and mada rails | Possible but you build the whole provider yourself | Often generic card only; STC Pay/mada rarely first-class | |
| Webhook reconciliation | Signed, idempotent, matched to invoice and sale order | Depends entirely on in-house engineering effort | Varies; signature/idempotency handling often thin | |
| Refund support | Real acquirer refund via `action_refund` with reference write-back | Must be designed and tested from scratch | Sometimes present, sometimes manual-only | |
| POS + web coverage | One provider across Point of Sale and Website in scope | Two separate builds to reconcile yourself | Usually web-only or POS-only | |
| Odoo version fit | Built and tested for your 17.0/18.0/19.0, Community or Enterprise | You own compatibility across versions | May lag new Odoo releases | |
| Ownership & maintainability | Full source + git repo handover, standard framework code | You own it, but also all the maintenance burden | Usually closed/obfuscated, vendor lock-in | |
| Support & fixes | Post-go-live support window + optional SLA | Whatever your team can staff | Ticket queue, variable response | |
| Time to live | 2-4 weeks from confirmed scope, UAT on staging first | Often months of internal effort | Install fast, but integration gaps surface later |
This is a build-to-order module, so we build it for your specific scope rather than shipping a stock download. Typical delivery is 2 to 4 weeks from confirmed scope — the exact timeline depends on whether you need web checkout, POS, or both, your Odoo version/edition, and how quickly your acquirer provides sandbox credentials. You get a firm estimate after the scoping call.
Both patterns are possible. STC Pay is integrated via its wallet API (QR + OTP flow), and mada is routed through your acquiring bank or a local aggregator with mada BIN detection so domestic cards settle on mada rails. During scoping we confirm exactly which contracts and credentials you hold and build the provider to match — we don't invent an acquirer relationship you don't have.
Yes. We build and test against Odoo 17.0, 18.0, or 19.0, on Community or Enterprise. The module uses the standard `payment.provider` / `payment.transaction` framework that exists in both editions, so it does not require Enterprise-only apps unless your scope (for example a specific POS feature) does.
Refunds run through Odoo's standard `action_refund` path — a credit note or a POS return triggers a real refund call to the acquirer and writes the refund reference back to the transaction. Reconciliation is driven by signed webhooks: each notification is signature-verified, matched to the pending transaction by provider reference, handled idempotently against duplicate deliveries, and posted against the invoice and sale order.
Every engagement includes a post-go-live support window for defect fixes and configuration tweaks. Because you receive the full source and a git repository, you or we can maintain and upgrade the module across future Odoo versions. Extended support, SLAs, and version-migration work can be arranged as a separate agreement.
Card data is handled through the acquirer's hosted fields or redirect, so sensitive PAN data does not transit your Odoo server. Webhooks are HMAC signature-verified, provider secrets live in the provider settings record (not in code), portal access is scoped by `ir.model.access.csv` and record rules, and every transaction is logged via `ir.logging` for audit.
Yes. The module's models behave like any other Odoo model, so they're reachable over the XML-RPC/JSON-RPC API and visible to your existing automations, reports, and integrations. If you need custom automated actions or exports tied to payment events, we can include those in scope.
A custom Odoo payment provider that accepts STC Pay and mada directly at checkout, with SAR localization, webhook reconciliation, and refund support. ECOSIRE builds, installs, and supports it for your Saudi Odoo instance.