A build-to-order Odoo module that routes every payment to the cheapest or highest-performing gateway based on your rules, and automatically fails over when a provider declines or goes down. ECOSIRE builds, installs, and supports it for Odoo 17, 18, and 19. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $499.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo module that routes every payment to the cheapest or highest-performing gateway based on your rules, and automatically fails over when a provider declines or goes down. ECOSIRE builds, installs, and supports it for Odoo 17, 18, and 19.
现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。
If you sell across multiple regions, you almost certainly run more than one payment provider — a local acquirer for the GCC, Stripe or Adyen for cards abroad, maybe a wallet for a specific market. Odoo native handles this only at the crudest level: each payment.provider is either enabled or disabled, and the checkout simply lists whatever is active. There is no concept of "send USD cards over 500 to gateway A, everything from Egypt to gateway B, and if that provider times out, retry on C." Merchants end up either hard-limiting which methods show, or eating avoidable decline losses and paying higher-than-necessary MDR fees because every transaction goes down the same pipe regardless of cost or auth-rate performance.
`payment.routing.rule` model with ordered, first-match rule evaluation and an active/priority sequence you manage from the backend
Rule conditions on billing country, transaction currency, amount bands, and card BIN / IIN ranges
Least-cost routing mode that selects the provider with the lowest effective MDR for the qualifying transaction
Best-auth-rate routing mode that orders providers by observed authorization success rate
Automatic failover: on decline or provider timeout the transaction cascades to the next eligible gateway and logs each attempt on `payment.transaction`
Per-gateway `payment.gateway.stats` with `compute`/`@api.depends` success-rate, decline-reason breakdown, volume, and average-cost aggregation
ECOSIRE builds a routing layer that sits in front of Odoo's existing payment.provider records — it does not replace your acquirers, it orchestrates them. We add a payment.routing.rule model (models.Model) with ordered, condition-based rules keyed on billing country, currency, order/transaction amount bands, and card BIN ranges, plus a payment.gateway.stats model that rolls up authorization success rate and average cost per provider using compute fields with @api.depends on the underlying payment.transaction records. At checkout, a routing engine evaluates the rules in sequence (least-cost routing when you want to minimize fees, best-auth-rate ordering when you want to maximize conversion) and selects the target provider; the OWL/QWeb checkout is extended so the A/B-ordered method list reflects the decision. When a provider returns a decline or is unreachable, an ir.actions.server / automated-action-driven failover cascades the transaction to the next eligible gateway and records the attempt, so a single acquirer outage stops costing you completed orders.
Technically the build is a clean, upgrade-safe addon: its own __manifest__.py declaring dependencies on payment (and website_sale where you route storefront checkouts), models and fields following Odoo ORM conventions, access rules in ir.model.access.csv plus record rules so only Payments/Finance roles can edit routing logic, backend views and an OWL analytics dashboard, and a QWeb report for a per-gateway success-rate and cost summary. Everything is reachable over the standard XML-RPC / JSON-RPC API so your ops tooling or a treasury system can read stats and toggle rules programmatically. It respects the Community vs Enterprise split — we build against the payment framework available in your edition and flag anything (such as specific Enterprise-only provider connectors) that needs your license — and we target Odoo 17.0, 18.0, and 19.0 explicitly rather than assuming one version.
Because this is build-to-order, you are not downloading a generic app and hoping it fits. We start with a short scoping call, confirm exactly which providers, corridors, and cost/auth priorities you run, then build the module to that spec. Typical delivery is 2 to 4 weeks from confirmed scope. You get the installable source for your Odoo version, installation and configuration on your environment, UAT on a staging database with a rollback plan, a training session, and a post-go-live support window — plus the git repository so the code is yours to keep and extend.
Runs a local acquirer plus one or more international providers and wants each transaction routed to the best-fit gateway by country, currency, and amount instead of a single static provider list.
Loses completed orders to avoidable soft declines and provider outages, and needs rule-based failover plus per-gateway success-rate visibility to prove and improve authorization performance.
Pays inconsistent MDR across providers and corridors and wants least-cost routing to push each transaction down the cheapest eligible rail, with a QWeb cost report to justify the savings.
Needs a clean, upgrade-safe addon that extends the standard `payment` framework, respects `ir.model.access.csv` and record rules, and exposes routing data over JSON-RPC to existing ops tooling.
在 ecosire.com 上购买许可证并从您的帐户仪表板下载 Smart Multi-Gateway Payment Router for Odoo 模块 ZIP。
将 ZIP 解压到服务器上的 Odoo 自定义插件文件夹中(或通过“应用程序”>“从 Odoo.sh / runbot 上的文件安装”上传)。
激活开发者模式,打开应用程序,单击更新应用程序列表,搜索 Smart Multi-Gateway Payment Router for Odoo,然后按安装。
打开新菜单,粘贴您的 ECOSIRE 许可证密钥,连接任何外部凭据(Shopify、Amazon、Stripe 等),然后保存。
运行内置连接测试,同步前 10 条记录,并安排定期 cron。如果出现任何问题,请联系支持人员。
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| Transaction routing | Rule-based on country, currency, amount, and BIN with least-cost and best-auth modes | Whatever you build; needs deep payment-framework knowledge | Usually static per-provider enable/disable or basic country filter | |
| Failover on decline/outage | Automatic cascade to next eligible gateway with logged attempts and retry caps | Possible but must be designed and tested from scratch | Rarely offered; often manual re-attempt only | |
| Per-gateway analytics | OWL dashboard plus QWeb report for success rate, decline reasons, volume, and cost | Build your own reports and compute fields | Basic or absent; limited to that provider's own numbers | |
| Fit to your corridors | Built to your exact providers and priorities during scoping | Fully bespoke but you own all specification and risk | Generic; you adapt your process to its assumptions | |
| Security model | `ir.model.access.csv` + record rules restricting rule edits to Finance roles, with audit trail | Depends on your implementation discipline | Varies; often coarse access control | |
| Odoo version support | Built and tested for 17.0, 18.0, 19.0, Community or Enterprise | Whatever you target and maintain | Often one or two versions; upgrade timing not guaranteed | |
| External integration | Rules and stats exposed over XML-RPC / JSON-RPC for BI and treasury | You expose whatever endpoints you build | Limited or no documented API for routing data | |
| Ownership & support | Git repo handover, UAT + rollback, training, and a post-go-live support window | You own it and carry all maintenance | Vendor-locked; support quality and roadmap vary |
This is a build-to-order module, not an instant download. After a short scoping call to confirm your providers, corridors, and cost/auth priorities, typical delivery is 2 to 4 weeks from confirmed scope. Larger rule sets or additional provider connectors can extend that, and we give you a firm estimate before work starts.
We build and test against Odoo 17.0, 18.0, and 19.0, in either Community or Enterprise. Because it extends the standard `payment` framework, we confirm at scoping which provider connectors your edition includes and flag anything Enterprise-only that depends on your license.
No. The module orchestrates your existing `payment.provider` records — it decides which of your already-configured acquirers a given transaction should use and handles failover between them. Your connectors, credentials, and settlement relationships stay exactly as they are.
No. Routing decisions use non-sensitive attributes such as country, currency, amount, and BIN range (the leading digits, not the full card number). Actual card capture and processing stay inside your PCI-compliant gateway connectors, exactly as in native Odoo.
When the selected gateway returns a decline or is unreachable, the routing engine cascades the `payment.transaction` to the next eligible provider per your rules and records each attempt. You control the cascade order and can cap retries so a single acquirer outage stops silently costing you orders.
Every build includes a post-go-live support window for bug fixes and configuration tweaks. We hand over the git repository so your team owns the code, and we offer ongoing support or version-upgrade engagements (for example moving the module to a newer Odoo release) as a separate arrangement.
Yes. Routing rules and per-gateway stats are exposed over Odoo's standard XML-RPC / JSON-RPC API, so your BI, treasury, or ops tooling can read success-rate and cost metrics and toggle rules programmatically, subject to the same access rights and record rules that protect the backend.
A build-to-order Odoo module that routes every payment to the cheapest or highest-performing gateway based on your rules, and automatically fails over when a provider declines or goes down. ECOSIRE builds, installs, and supports it for Odoo 17, 18, and 19.