Italian and Nordic merchants running Odoo eCommerce, subscriptions, or portal invoice payment consistently hit the same wall: Odoo core ships Stripe, Adyen, PayPal, and a handful of others, but there is no native payment.provider for Nexi XPay or Nets Easy. That means the acquirer your bank actually settles with — the one giving you Italian domestic card rates or Nordic methods like Dankort, MobilePay redirection, or Vipps-adjacent flows — cannot take money on your Odoo checkout. Merchants end up bouncing customers to an off-platform hosted page with no reconciliation back into Odoo, or manually reconciling settlements against account.move by hand. Both leak revenue and both break the audit trail.

ECOSIRE builds a first-class Odoo payment provider that inherits payment.provider and payment.transaction and speaks natively to the Nexi XPay / Nets Easy hosted checkout APIs. The __manifest__.py declares a clean dependency on payment (and website_sale where eCommerce is in scope), registers the provider in payment_provider_data.xml, and adds provider-specific credential fields (merchant/terminal id, secret/API key, environment toggle) on the provider model with values encrypted at rest and gated by ir.model.access.csv plus record rules so only Payment Administrators can read them. At checkout the module creates a payment intent/order against the gateway, redirects the shopper to the hosted, PCI-scope-reducing payment page, and returns them to Odoo's controller. 3DS2 / SCA is handled by the acquirer's hosted flow so you stay out of card-data scope; the module simply carries the authentication result back. An inbound webhook controller (CSRF-exempt, signature-verified against the shared secret) reconciles the asynchronous notification: it looks up the payment.transaction by the gateway reference, verifies amount and currency, and transitions the transaction state (_set_done, _set_pending, _set_canceled, _set_error) idempotently so a retried webhook never double-posts. Confirmed transactions flow through Odoo's standard pipeline to confirm the sale order and post the invoice, and refunds are issued from the invoice/transaction using the provider's refund support so a credit note in Odoo triggers the real acquirer refund and writes back the state.

Everything is built to Odoo conventions so it survives upgrades and audits: compute fields use @api.depends, states use standard selection values, the gateway dialogue is logged for traceability, and admin-facing configuration lives in proper XML/OWL settings views rather than hardcoded config. We support Community and Enterprise — the provider works on Community website_sale, and where Enterprise-only flows (e.g. subscription tokenization) are in scope we build against them explicitly. The same provider is available for Odoo 17.0, 18.0, and 19.0, matched to your exact running version.

Because this is build-to-order, we start from your acquirer contract and settlement setup, not a generic template. After a short scoping call we confirm which product (Nexi XPay vs Nets Easy), which methods (cards plus the specific Nordic/Italian local methods you are enabled for), currencies, and whether tokenized/recurring payments are needed. We then build against your sandbox credentials, run the full flow — authorize, capture, 3DS2 challenge, webhook reconciliation, partial and full refund — on a staging database, and hand over installable source, a git repo, docs, and a training session. Typical delivery is one working week from confirmed scope, followed by a post-go-live support window while you take real transactions.