Each payment acquirer has its own implementation specificities: some
implement a 'payment with redirection' flow and others a 'direct payment
flow'; sometimes the 'payment with redirection' flow is even implemented
as a 'direct payment' flow through an iframe; one payment acquirer could
support webhooks while another does not and relies on another mechanism
to fetch payment status updates...
It can be tricky to guess where to look in the code to determine how a
payment acquirer is implemented.
On top of that, the online payments ecosystem evolves at a fast pace due
to competition, buyouts, and legislation enforcement. Acquirers are thus
frequently migrated to new APIs that might differ in implementation from
the previous API.
To help figure out the *which*, *why*, *how*, and *when* of payment API
implementations, a README.md file is added to the main directory of all
payment acquirer modules. They can be browsed in human-readable format
on GitHub.
task-2374916
closesodoo/odoo#156084
X-original-commit: 4c19f26df3d39394cce2f183d6df15c5b89c7d27
Related: odoo/enterprise#57921
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
For a first iteration, Russian translations were done using DeepL using
1 large .pot file of all the standard modules to translate (e.g. no
localizations, no test modules, etc). Unfortunately for some reason
doing a msgmerge with the existing ru.po files didn't seem to work, so
old "Translators" metadata at top of files were lost (maybe they will be
re-added during next Transifex sync?)
Part-of: odoo/odoo#152285
When user enables or tests payment provider it will automatically
enable most used payment method in that provider.
closesodoo/odoo#140907
Signed-off-by: anko-odoo <anko@odoo.com>
Before this commit, the payment providers (e.g., Stripe, Adyen...)
available for payment were displayed on the payment forms. The customer
had to select one to process their payment. After that, the customer had
to select their preferred payment method (e.g., Credit Card,
Bancontact...) from a list of payment methods supported by the selected
provider over which the website administrator had close to no control.
This was making the payment forms confusing because the payment methods
were displayed sometimes more than once, if at all, in a non-controlled
order, and behind the selection of a payment provider that customers
should not have to deal with.
As the payment method was selected in an iframe or directly on the
provider's website, the information on the selection payment method was
not available in Odoo. This posed many problems, among which were the
impossibility of assessing whether a specific feature (e.g.,
tokenization, refunds, manual capture...) was available, not being able
to easily identify payment tokens through the payment method logo,
listing available payment methods on the website, sorting and
fine-grained configuration of the available payment method, subpar
payment method-specific display on the payment form (e.g., PayPal that
requires displaying a "Pay with PayPal" button), etc.
In this commit, the payment providers are thus replaced by the payment
methods on the payment forms. All contextually available (depending on
the country, currency, requested feature...) payment methods are
displayed one after the other on a single-level list and in the order
configured by the website administrator. Each payment method is
"powered by" (i.e., linked) to a single payment provider: the first one,
by model order, to support it. This allows, for example, offering the
PayPal payment method through Mollie, which charges low processing fees,
while also offering Klarna through Stripe, which supports more payment
methods but charges higher processing fees.
While doing so, the two different payment forms, "Checkout" and
"Manage", are also merged together in a new, configurable case-by-case,
payment form that is entirely redesigned to offer a better user
experience.
After payment, the information on the selected payment method is saved
on the transaction and eventual payment record and updated with the
information received from the provider.
task-2882677
closesodoo/odoo#120446
Related: odoo/upgrade#5103
Related: odoo/documentation#5717
Related: odoo/enterprise#40666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Anita (anko) <anko@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Valeriya (vchu) <vchu@odoo.com>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
This is mostly a cleaning/refactoring change.
The current API for init hooks (pre, post, uninstall) is to pass
`cr, registry`.
But the first thing which was done by most
post init and uninstall hooks was to create an env using
the cr passed
e.g.
`env = api.Environment(cr, SUPERUSER_ID, {})`
and the `registry` argument was unused in all these hooks,
completely.
By changing the API of hooks to pass `env` instead
of `cr, registry`, we gain in average two lines in every
hooks:
- the line creating the env `env = api.Environment(cr, SUPERUSER_ID, {})`
- the line importing `api` and `SUPERUSER_ID`
Therefore removing ~250 lines of repeated code lines accross odoo/odoo and
odoo/enterprise.
In addition to these lines removed,
it also ease the API of init hooks for Odoo developers,
who are used to that `env` and not so much how to create an `env`
from a cursor.
Part-of: odoo/odoo#108254
Before this commit, the lists of supported currencies by payment
provider were hard-coded in the Python scripts, which made them
unavailable to the users.
With this commit, the implemented initial lists of supported currencies
are displayed on the form view and are editable, because Odoo lists may
not be up-to-date. Empty lists do not trigger any filtering on the
payment providers to access payment methods.
For Authorize.net and Asiapay payment providers, the specific
`(authorize,asiapay)_currency_id` are removed and the generic payment
provider field `available_currency_ids` is restricted to a single-item
list when one of those providers is enabled.
task-2926016
closesodoo/odoo#101018
Related: odoo/enterprise#34158
Related: odoo/documentation#2788
Related: odoo/upgrade#4069
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
auto_install is Falsy by default
author is Odoo SA by default
summary & description are empty strings by default
application is False by default
test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content.
closesodoo/odoo#106686
Related: odoo/enterprise#34462
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
We decided to make this list as feature and not application.
It allows any user in mode OneAppFree to use them without become an
Extra App.
List of apps impacted:
blog
forum
all payments acquirer
task-3062641
closesodoo/odoo#106487
X-original-commit: 8b1928b3ef0e098b193ac74084344eba5beac4db
Related: odoo/enterprise#34368
Signed-off-by: Thibault Francois <tfr@odoo.com>
Before this commit, most of these modules had a custom sequence
number intended to sort them in the Apps' kanban view. In reality, the
sort on the module name makes the custom sequence useless. This commit
thus sets all of these modules' sequences to `350`.
In an effort for uniformization, we also made names and summaries more
generic, and removed the descriptions which did not add any value.
Task - 2960976
closesodoo/odoo#103131
X-original-commit: 75397daa2fff1a027af7a3cb008e6cbc828645fc
Related: odoo/enterprise#32752
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When the payment views were updated with commit odoo/odoo@f7b8f075, a
hook was improperly renamed to `code`, which doesn't help to figure out
its purpose. This commit renames it to `provider_credentials` which
better fits its role.
While doing so, the view files are also renamed and/or split by model to
increase their readability.
closesodoo/odoo#102976
X-original-commit: 49d126d4fce18761d0261adac00e115b840b9b47
Related: odoo/enterprise#32662
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The present kanban view of acquirers is not the most appealing
one. It is full of useless information (e.g. "online payment") and the
combination of provider logos makes it look "old".
After this commit, the kanban view will hopefully have a "cool" and
concise look simular to the "Apps"'s kanban view.
Task - 284171
closesodoo/odoo#98345
Related: odoo/enterprise#30585
Related: odoo/upgrade#3803
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, tokens were prefixed with usually 12 X’s. To improve
readability, modernity and to shorten the length, this commit changes
token prefixes to a standard of •••• 1111.
task-2832669
closesodoo/odoo#94978
Related: odoo/upgrade#3738
Related: odoo/enterprise#29190
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Antoine Vandevenne (anv)