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>
This reverts commit 5fd345e.
The duplicate option was removed but it should be available.
closesodoo/odoo#136014
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
before this commit, the create/new button is shown in
the payment provider form, where us it is removed in
the kanban and tree
after this commit, the create/new button will be removed
from the form and users can use duplicate option to create
new provider
closesodoo/odoo#134779
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In V14, the cardholder name is send, but not in V16.
closesodoo/odoo#130545
X-original-commit: b8d7d1a619c76e3ce0a50e9fc9251a33fc8ca52b
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@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
Prior to this commit, the generation of token aliases in Ogone relied
on the util function `singularize_reference_prefix`, which is intended
to make transaction references (and not token aliases!) more
distinguishable by suffixing a timestamp accurate to the second. That
util function does not guarantee the uniqueness of generated reference
prefixes, which is okay because the final reference is further suffixed
if the prefix happens to collide with an existing reference.
Using the util to generate Ogone's token aliases, however, poses a
problem because aliases *must* be unique. Otherwise, a customer saving a
payment token at the same second as another customer would end up
linking their payment method to the other customer's payment token.
This commit drops the use of the util method and replaces it with a UUID.
closesodoo/odoo#115580
X-original-commit: 61d833ffcd1562950126d3c87c92569fe35a8b08
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
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
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>
Skip the payment_asiapay test verifying the reference computation
with an invoice when account_payment is not installed.
Also add a dedicated helper, using the variable in payment already storing
whether the account_payment module is installed.
closesodoo/odoo#103449
X-original-commit: f1fd1c9e484025782079fc18c152269aa1723ed5
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@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 four payment acquirers implemented with these modules all present
a subset of the following issues:
- The user experience for the payment step is really bad: All of them.
- The API is poorly documented, breaks often, or is badly designed and
hard to work with: All of them.
- It is no longer possible to open a new account: PayULatam, PayU money.
- The countries/payment methods/currencies coverage is limited: Alipay,
PayU money.
- It is not possible to implement additional features such as
tokenization, manual capture, or refunds: Alipay, PayULatam,
PayU money.
- They have a better replacement already available in Odoo: All of them.
This commit thus deprecates the above-mentioned payment acquirers. This
means that their module can no longer be installed on new databases and
alternatives are suggested. Existing databases in which the modules were
already installed will keep working.
task-2806832
closesodoo/odoo#99025
Related: odoo/upgrade#3848
Related: odoo/documentation#2686
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>
Before this commit, zombie payment tokens (= tokens linked to disabled
acquirers) could still
1) be used by internal users and
2) reactivated when the acquirer’s state changed to ‘test’ or ‘enabled’.
This is not desirable because zombie tokens should neither be used,
nor reactivated.
After this commit, all tokens related to an acquirer are unassigned
from linked documents and archived as soon as the acquirer’s state is
changed to ‘disabled’. Creating a payment with an archived token is
prohibited. In addition, archived tokens cannot be un-archived anymore.
task-2649806
closesodoo/odoo#93774
Related: odoo/enterprise#28661
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Computing the fields instead of storing them allows to implement the
feature for each provider more easily, without needing a migration
script.
task-2841744
closesodoo/odoo#91961
Related: odoo/enterprise#27618
Related: odoo/upgrade#3535
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Since odoo/odoo#85759 we are allowed to use other hashing algorithm
with OGONE's payment acquierer.
The V15 fw-port of this PR missed to unlock the max key size.
The goal of this PR is to fix the issue where 32+ length key
were not accepted in V15 and later.
opw-2766648
closesodoo/odoo#90895
X-original-commit: 534d16a6000c603025897bae225e0955317f411f
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When setting up an acquirer there is sensible information to
be supplied.
There was inconsistency on what was obfuscated and what not.
Now sensible information as passwords and keys is obfuscated
and public information as names and addresses is visible.
Task - 2694139
closesodoo/odoo#81211
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, most acquirers needed to run several successive
searches for the transaction whose reference was received by a
controller in notification data. This is because the security checks
run on the notification data require access to the acquirer through the
transaction record which was immediately discarded.
Starting with this commit, all `*_feedback_data` method are no longer
decorated with `api.model` and can use the transaction record they're
called on if provided. They are also renamed to `*_notification_data`.
task-2737144
closesodoo/odoo#83850
Related: odoo/enterprise#23938
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
An overridable model method was added in a previous commit in order to
neutralize a database.
This commit introduce the implementation of this method for the payment
modules.
Also, a `_neutralize_fields` helper method is added on the
PaymentAcquirer model to simplify the neutralization of the various
payment modules.
Part-of: odoo/odoo#67825
Notification handling in some acquirers presents a subset of the
following issues:
1. The signature of synchronous notifications (redirect payloads) is not
checked. (Alipay, Authorize, Buckaroo, Mollie, PayU money, PayULatam)
2. When the signature check fails, we raise a ValidationError which
counts as an HTTP 200 for some providers (it's not the case if they
expect a specific string). (Adyen, Paypal, Sips, Stripe)
3. If a ValidationError is raised when processing the feedback data, it
is allowed to bubble up to the provider. (Alipay, Ogone)
The issues are respectively addressed as follows:
1. If the acquirer implements payments with redirection, make sure that
if either makes a request to the provider to validate the data or
that it verifies the signature. Verifying the origin of the request
is not enough: the payload must be checked too.
2. Instead of raising ValidationError's, raise an HTTP 403 FORBIDDEN
error if the signature check fails.
3. Wrap the call to `_handle_feedback_data` of the webhook method inside
a try/except clause to catch any ValidationError, log a warning, and
acknowledge the notification to avoid having the provider disable the
webhook because of too many failures.
task-2688139
task-2693293
closesodoo/odoo#81607
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Lucie Van Nieuwenhuyze <luvn@odoo.com>
Before this revision, when a payment was declined,
for instance because the authorization is declined by the bank,
or the credit card amount limit is exceeded,
the error was marked as
"Received data with invalid payment status: 2"
which is not very meaningful for the users.
This revision aims to set the reason why the payment
was declined with the meaningful error from ogone.
closesodoo/odoo#80742
X-original-commit: 758f94a173379ba7bd22813b2050e3a6f98210a9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The logs for payments contain the transaction reference whenever possible.
Before logs for transactions contained the reference or the id of the
transaction in an inconsitent way. No transactions are identified by
reference whenever possible.
The logs for payments for the same function on different acquirers should
have the same format. Same flow step for different acquirers had
information passed in different formats. Now at each step of a transaction
flow log messages have the same format regardless of the acquirer.
Overall the payment logs should have an uniform format. Hopefully
understanding log messages related to transactions should be easier, as
now log format is independent of the acquirer and transaction are easily
identified by reference.
Task - 2545450
closesodoo/odoo#79547
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, it was not possible to refund a payment from Odoo.
Users had to go through the payment acquirer's backend and update the
payment accordingly in Odoo.
With this commit, refunds are made available in Odoo directly from the
payment form, for acquirers that support them. Acquirer can either only
support full refunds or also support partial refunds.
As of now, the only acquirer allowing refunds is Adyen, with partial
refund support.
task-2527891
closesodoo/odoo#70881
Related: odoo/upgrade#2689
Related: odoo/enterprise#19829
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Fix two issues:
The search of suitable payment token was searching on the journal_id
field of the payment acquirer that is no longer stored.
Change it to now search on the acquirer_id directly, since we have
this information.
The _inverse_journal_id method on payment acquirers would create
new payment line with the manual payment method when no provider
are given to an acquirer, or no payment method is existing for
a given provider. This would cause issues with the creation of
multiple line with the same name on a same journal, which would
trigger the constrains blocking that.
closesodoo/odoo#74990
X-original-commit: a3a2fcb0b299fafbf359ec9015da5c85cdb57b3a
Related: odoo/enterprise#20193
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Commit 3d90d02 removed the integration with the Flexcheckout API but the
dedicated views were left behind, as it was not possible to remove them
in stable version.
This commit removes the unused views in master.
task-2494916
closesodoo/odoo#74505
Related: odoo/upgrade#2699
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, the FlexCheckout API was used to process validation
operations only. It proved itself to be:
- unusable without making small payments with immediate refunds
- badly suited to PSD2 due to its Merchant Initiated Transactions (MIT)
- not worth the maintenance cost tied to its complexity given the simple
flow that it implements
- inconvenient to integrate to standard payment flows
- poorly customizable in regard to the hosted tokenization page
This commit thus removes it entirely and drops Ogone's support for
validation operations with it.
task-2494916
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
With commit 139dd9d, the Hosted Payment Page API of Ogone was entirely
replaced by the FlexCheckout API. This new API allows customers to
tokenize a payment method for a later use without the need of making a
purchase. However, it proved itself to be less convenient for regular
purchases as it offers less payment options than the HPP, and payments
are no longer cardholder-initiated transactions but merchant-initiated
transactions which have a higher chance of triggering an authentication
check. Furthermore, the payment flow itself is more complicated than
before.
This commit brings back the Hosted Payment Page API to work in parallel
with the FlexCheckout API and the other APIs that were left untouched.
It will be exclusively used for making online payments with a new card.
The validation flow is managed by the FlexCheckout API while the
DirectLink API manages the payment by token and offline payment flows.
task-2494916
closesodoo/odoo#72991
X-original-commit: 4fa7b772c71979f61eb098ff8d005deba834527c
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
As it is possible to hard-code the DirectLink URLs used by Odoo in the
backend of Ogone, some users might encounter payment issues after
migrating to 14.3+ if they did not replace those URLs by the new ones.
This commit adds back the URLs that were used by DirectLink prior to
14.3 and allows requests to target both the new and the old URLs.
task-2494916
closesodoo/odoo#72566
X-original-commit: 16ee2651ba7f537e3644da2fd80595896e3421fc
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Co-authored-by: Toufik Ben Jaa <tbe@odoo.com>
Before this commit, the implementation of Ogone and PayU Latam's
requirements regarding the transaction reference was preventing the
computation of the reference prefix from being based on the related
document (invoice, SO).
This commit attempts to compute the reference based on the document if
no reference prefix is provided, before applying the said requirements.
task-2494916
closesodoo/odoo#72291
X-original-commit: f18a1d67b769ea69a07fb3c0343e092038df5c93
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- Re-introduce the changes added by commit 783a8e22a9
- It seems like Ogone has a bug on their side. Even when configuring
the encoding to UTF-8 on their back office, when signing a request
containing non ISO characters the signature we send do not match
the one computed by Ogone.
By calling the URLs suffixed with `_utf8` the issue is fixed.
closesodoo/odoo#71672
X-original-commit: f435ad2d69c7910139cd3ea6a47576399fb4d882
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
