Daily updates from Odoo
Tuesday, March 30, 2021
1 change · master
Code cleanup and technical improvements
Odoo’s online payment process has been redesigned so payments can be processed first and saved for future use afterward, matching how modern payment providers work. This improves compatibility with providers, reduces unnecessary validation/refund steps, and simplifies future payment integrations, including SEPA direct debit updates.
Original PR description
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…
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 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>