This is a build-to-order module, not an instant apps.odoo.com download. After purchase our team scopes your Adyen setup, then builds, tests against your merchant account and installs it — typically within a one working week lead time depending on the number of payment methods, multi-company scope and any recurring/tokenization requirements. You get a firm timeline in your kickoff, plus a test-environment build before go-live.

Every engagement includes a post-launch support window (its length is set in your quotation) covering bug fixes, configuration adjustments and help with reconciliation questions. Because the module is written to be upgrade-safe across Odoo 17, 18 and 19, we can also quote version-upgrade and enhancement work — for example new payment methods or added tokenization — after the initial window. You receive the full source, so your own developers can maintain it too.

Odoo 17, 18 and 19, on both Community and Enterprise. Adyen is registered as a standard payment.provider, so it works with website eCommerce, the customer portal, Sales/Invoicing Pay-Now links and subscription billing wherever those apps are installed. We confirm your exact edition and installed apps during scoping so dependencies in the __manifest__.py match your instance.

Cards plus 100+ Adyen local and alternative methods — iDEAL, Bancontact, SEPA, Klarna, PayPal, Apple Pay, Google Pay, Alipay, WeChat Pay and more — subject to what your Adyen contract enables. Using Adyen's Drop-in/Components, the available methods are surfaced dynamically by the shopper's country and currency, so you don't maintain per-method logic in Odoo. The module is multi-currency and multi-company aware.

Adyen sends asynchronous notification webhooks, and the module verifies the HMAC signature on every one before it changes a payment.transaction state — a forged callback can never mark an order paid. Webhook handling is idempotent and matched on the Adyen reference, so duplicate or out-of-order notifications don't double-post. Paid, authorized, refunded and voided states sync to the linked invoice and journal entries.

Yes. The full acquiring lifecycle is exposed on the Odoo transaction: authorize, immediate or delayed/manual capture, partial and full refunds, and void/cancel. This suits fulfilment-then-charge workflows where you authorize at checkout and capture on dispatch. Actions can be triggered from the transaction form and, if needed, exposed over XML-RPC/JSON-RPC for external systems.

No. API key, merchant account, client key and the HMAC webhook secret are stored as Odoo system parameters (with separate test and live environments), never committed to source. Access to payment configuration and transactions is governed by ir.model.access.csv and record rules so only authorized roles can view or act on them.