5732ce8dc6
PURPOSE Before this commit, the "payment from odoo" flow (direct) required tokenizing a payment method before processing a payment, rather than directly processing the payment, and eventually tokenizing the payment method later. In practice, this often meant that a 'validation' transaction had to be processed and immediately refunded in order to generate a temporary token. Then, a second "payment by token" flow had to be executed to process the intended payment. This implementation was too rigid for most modern payment providers' APIs. Indeed, they mostly expect single processing for a given payment and usually offer the possibility to tokenize the payment method after the payment, rarely before. Because of this, the implementation of many providers was either difficult, limited, or even impossible. Among the various incompatibilities, we find: support for direct payments but not tokenization, lack of support for authentication during tokenization, absence of hosted page dedicated to tokenization, etc. As another cascading consequence of this implementation choice, several providers could not be migrated to newer APIs after that the ones implemented in Odoo were deprecated. The goal here is thus to 'invert' the payment flow implemented in Odoo. As this means re-writing most of the payment module and of its provider implementations, the opportunity is taken to deeply clean and document the code of the impacted modules. SPECIFICATIONS - Lift the limitations listed above by inverting the generic direct payment flow to first create and process a transaction, then tokenize it if requested. - Remove the `payment_flow` field on `payment.acquirer` and let the acquirer choose the appropriate flow according to the use-case. - Filter acquirers offered to the customer based on the use-case. - Add overridable hooks at key steps of the payment flow to allow implementing new providers with minimal effort (both in Python and JavaScript). - Move all module-specific logic and fields to where they belong (e.g. let Subscriptions filter out acquirers based on their support for tokenization, move `qr_code` in `payment_transfer`, ...). - Homogenize the inheritance strategy of acquirer modules. - Standardize the implementation logic in other modules' controllers. - Improve the traceability of payments through stored fields and logs. - Remove the public read right on `payment.acquirer` and enforce the use of access tokens in all modules' flows. - Fix all bugs that were inherent to the old implementation. - Replace the previous testing suite (which was mostly commented-out for years) with a new one that allows testing of both routes and flows with different test configurations (user, transaction context, ...). LINKS Enterprise PR: https://github.com/odoo/enterprise/pull/12528 Upgrade PR: https://github.com/odoo/upgrade/pull/2291 task-2085989 closes odoo/odoo#56187 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com> Co-authored-by: Antoine Vandevenne <anv@odoo.com> Co-authored-by: Victor Feyens <vfe@odoo.com> Co-authored-by: Arnaud Joset <arj@odoo.com> Co-authored-by: Kevin Baptiste <kba@odoo.com> Co-authored-by: Barad Mahendrasinh <mba@odoo.com> Co-authored-by: Prakash Prajapati <ppr@odoo.com> Co-authored-by: Adrien Horgnies <aho@odoo.com>
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials