Spanish merchants running on Odoo hit a wall the moment they try to accept payments the way their customers actually pay. Odoo core ships generic providers (Stripe, PayPal, wire transfer) but has no native integration for Redsys, the shared payment gateway used by virtually every Spanish acquiring bank (CaixaBank, BBVA, Santander, Sabadell and others), and no support at all for Bizum, the mobile pay-by-phone method a large share of Spanish shoppers now expect at checkout. Without them you either push customers to a bank-hosted TPV outside Odoo (breaking reconciliation and the eCommerce funnel) or pay higher fees to a third-party aggregator. This module makes Redsys and Bizum first-class payment.provider options inside Odoo.

We build a native payment acquirer that plugs into Odoo's standard payment framework. Technically, it registers a new provider by extending the payment.provider model with your Redsys merchant code, terminal number, SHA-256 secret key, and a test/production environment switch, and implements a payment.transaction subclass that constructs the Ds_MerchantParameters payload, Base64-encodes it, and computes the Ds_Signature using the 3DES key-derivation plus HMAC-SHA256 scheme Redsys requires. Customers are redirected to the Redsys hosted payment page, so PAN and CVV never touch your Odoo server and your PCI-DSS scope stays minimal (SAQ-A). A single provider record drives both flows: paymentMethods toggles between standard card acquiring and Bizum, which Redsys routes through the same signed request with the DS_MERCHANT_PAYMETHODS parameter set to z.

On the return trip we handle both the browser redirect (Ds_MerchantParameters on the merchant URL) and the asynchronous server-to-server notification (the Redsys online notification / notification URL), re-verifying the signature on every callback before we ever mark a transaction as done. That server notification is the source of truth: even if the buyer closes the tab after paying, the payment.transaction state transitions correctly and the linked sale order or invoice is confirmed. The integration is 3DS2 / SCA-ready by design, since the Redsys hosted page runs the PSD2 challenge flow, and it is EUR-localized to match l10n_es conventions (amounts sent to Redsys in cents, currency 978). Refunds are wired to Odoo's payment refund action, issuing a signed DS_MERCHANT_TRANSACTIONTYPE 3 (devolucion) request against the original order code so credit notes and reversals stay in sync.

Because this is a build-to-order engagement, nothing is a black box. After a short scoping call we confirm the exact Redsys terminal setup, which Odoo edition and apps you run (Website/eCommerce, Sales, Invoicing, POS), and whether you need Bizum, cards, or both. We then build against your target version (Odoo 17.0, 18.0, or 19.0), test end-to-end in the Redsys integration/test environment, and deliver installable source with documentation. Typical delivery is one working week from confirmed scope, and you receive the full Git repository so the code is yours to keep, audit, and extend.