Spanish merchants running Odoo hit a wall the moment they need to take card and mobile payments through the domestic banking network that their acquiring bank actually uses. Odoo core ships generic international acquirers, but it has no native support for the redirect-and-notification protocol used by Spanish bank gateways, and none at all for the instant account-to-account mobile scheme that Spanish shoppers now expect at checkout. The result is either lost conversions, manual reconciliation of bank statements against Odoo orders, or an expensive detour through a third-party processor that charges more and hides the transaction detail your finance team needs.

ECOSIRE builds a dedicated payment provider module that plugs into Odoo's standard acquirer framework so both flows behave like any first-class payment method. On the technical side we implement a payment.provider record (a model inheriting payment.provider in models/, declared in __manifest__.py with depends on payment and account) plus a payment.transaction subtype that builds the signed redirect form, computes the request signature with your merchant secret, and handles the asynchronous server-to-server notification callback. The controller route validates the returned signature before it ever touches a transaction state, so a spoofed or replayed callback cannot mark an order paid. Card and the instant mobile scheme are exposed as two selectable methods on the same provider, each with its own code, terminal number, and currency handling. QWeb templates render the checkout button and the redirect form; ir.model.access.csv and record rules keep credentials and transaction logs scoped to the right users, and configuration lives on the provider form in test/enabled/disabled states exactly like a native acquirer.

Because it uses the real acquirer plumbing, everything downstream just works: successful payments confirm the sales order, post to the correct journal in Invoicing, and reconcile automatically; refunds are initiated from Odoo and pushed to the gateway; and every request/response pair is logged for audit. We wire the eCommerce checkout, the customer portal "pay now" links on invoices, and — where you need it — the point-of-sale or subscription renewal path. Configuration values (merchant code, terminal, secret key, environment URLs) are stored per company so a multi-company or multi-brand group can route each entity to its own bank contract. The build targets your exact Odoo version (17.0, 18.0, or 19.0) and respects Community vs Enterprise differences in the accounting and POS layers.

Delivery is build-to-order. After a short scoping call we confirm the flows you need (eCommerce, portal invoices, POS, subscriptions), your bank's specific gateway variant, currencies, and reconciliation rules, then send a fixed quotation and a written scope. You get the work on a staging clone first for UAT against your bank's test terminal, with a rollback plan, before we install on production and hand over the git repository. Typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); additional companies or bank contracts, POS and subscription integration, multi-currency handling, and migrating historical transaction data increase the quoted scope.