UX was lacking comparing to other payment providers,
important fields were not always shown or were checkboxes
when they should be automatically true.
In order to make payment flow easier and more intitive, unnecessary fields
were removed, email is automatically filled. Now when user cancels transaction
on paypal before paying, it automatically cancels transaction on Odoo. Additionaly, quick
onboarding is only available if user already has paypal account and Stripe
no longer installs ond configures paypal if Stripe's onboarding get canceled.
task-2854184
closesodoo/odoo#104974
Related: odoo/upgrade#4025
Related: odoo/documentation#3063
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
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>
With commit 7b165cd5, it was incorrectly assumed that PDT notifications
sent by PayPal could not be verified with the suggested method
(dedicated to PDT notifications) because they were missing some required
parameters. The code was thus adapted to have their verification done
with the method already in place for IPN notifications, as it seemed to
do the job. It turns out that the PayPal sandbox account that was used
at that time was not properly configured, and that PayPal was then
sending IPN-like notifications instead of actual PDT notifications,
which is the reason why the swap of methods worked.
Actually, once the account is properly configured, PayPal sends
correctly populated PDT notifications that must be verified with the
method dedicated to PDT notifications, as the one dedicated to IPN
notifications stops working in that case.
With this commit, the method used to verify the origin and integrity of
PDT notifications is replaced by the one that was previously removed.
The method is however implemented in a more defensive manner to:
1. accept and process the notification without verification if the
account is not properly configured on PayPal.
2. silently discard the notification if the acquirer is not properly
configured on Odoo. We then rely on the IPN (webhook) to confirm the
transaction.
task-2744043
closesodoo/odoo#83659
X-original-commit: 7367f543498810bbdb018aa3566c7afed5684436
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
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 commit, users returning from PayPal to Odoo after payment
could see their session renewed, depending on their browser's
implementation of the `SameSite` cookie attribute. This prevented Odoo
from retrieving the transaction from the users' session.
This commit flags the return route of PayPal with `save_session=False`,
hence allowing all users to immediately post-process their transactions
when they return to Odoo.
closesodoo/odoo#83327
X-original-commit: 33ae5e491609c580a3aeb83568c74cd1acaae336
Signed-off-by: Victor Feyens (vfe) <vfe@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>
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>
- fix missing access rights when handling feedback data
- redirect customers to the payment confirmation page when notification
data are not acknowledged by PayPal, rather than displaying an
internal server error
task-2494916
closesodoo/odoo#70885
X-original-commit: 948c22243c88dd905f1a7838f6fba75f44f06b2a
Related: odoo/enterprise#18349
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
account_payment:
- Processing fees computation was done based on the wrong country.
payment:
- The acquirer's cancel message was missing from the
/payment/confirmation page.
- `redirect_form_view_id` field was declared with attribute 'name'
instead of 'string'.
- Uninstalling a payment acquirer would fail with a traceback.
- The first acquirer was not automatically selected if it was the only
selectable payment option of a 'manage' payment form.
- Specifying a preferred acquirer to the /payment/pay page would show
not acquirer at all if the preferred option was incompatible with
the constraints, rather than falling back on showing all acquirers.
payment_adyen:
- When the value of the API URL fields is malformed (e.g., missing the
"https://"), clicking on the confirm button raised a traceback.
payment_ogone:
- There was a typo in the return route.
payment_paypal:
- PayPal acquirers were not filtered out if the currency was not not
supported.
- Returning to the webshop without paying would raise a traceback.
task-2494916
closesodoo/odoo#69996
X-original-commit: 4f7e463fb8b13506caa8aff0beeef5eb0720bf00
Related: odoo/enterprise#17997
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
If a Paypal account is configured to send IPN notifications to Odoo at
the account level (as we officially advise in our doc) and is used in
another system than Odoo, transactions from that other system will
trigger notifications that gets sent to Odoo with references that are
unknown.
This tends to generate 500 errors, but Paypal will keep trying to send
the same notification over and over; this will cause a lot of errors in
logs and could also could Paypal to contact the account owner regarding
repeated failure on the IPN endpoints, which is somewhat scary for
lambda users.
This commit simply ensures that any such payment will not trigger a
faulty response (Paypal only accept 200 OK responses), but still keep a
trace of it in the logs as a warning.
Note that enabling IPN at the account level is not strictly necessary,
as transactions sent by Odoo force this behaviour regardless of the
setting with the 'notify_url' param.
closesodoo/odoo#56323
X-original-commit: e4e4b51e0d97c5dd6afe332bf7c70d8321469a52
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
The paypal payment flow was crashing because no transaction was found
when the client wasn't connected.
closesodoo/odoo#40966
X-original-commit: 48f02f32fc3c32812a391d1fa37d561a8ae55e74
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Issue was blocking the system to confirm a SO/Invoice after redirection
from paypal.
In V13 is getting the value of the paypal_urls using
paypal_get_form_action_url() returning the correct string, not a dict
anymore.
Closing
opw-2119027
opw-2122833
closesodoo/odoo#40471
X-original-commit: b7f32e6451da75a9583d28686641fc328ab661da
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Log an error only if a transaction exists.
opw-2071862
closesodoo/odoo#36946
X-original-commit: 903bd53d5f11dc9a9cfea246e6c5c0a088ad02ba
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Replace website_published and environment by a generic state on
payment.acquirer
Payment acquirers aren't enabled by default. When setting their state to 'enabled' or 'test', it is verified the required fields for the provider are set.
The following trick used to work, because `sudo()` was actually making
an environment for the superuser to operate upon:
request.env[...].sudo().method(...)
It no longer works in general, since `sudo()` now makes an environment
in superuser mode but with `uid=None`! It may still work by accident
for operations that never use `env.uid`, but is broken in general.
Using `auth='public'` fixes the problem by using the public user when no
user is available.
closesodoo/odoo#34297
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This commit aims to improve the user experience when using payment acquirers. There currently are no error feedback with some acquirers, which leaves the user wondering what is going on and what is the real status of its payment.
In some cases, the user is currently being redirected to the home page even though the payment has failed. We want to make it more obvious to the user that something unexpected has happened by redirecting to an intermediate page that will provide good feedback on payments status.
Another goal of this commit is to order acquirers by sequence instead of by flow and to select the first acquirer by default. This feature was already implmented in commit fe294fd43e521bd2d339e962f43acf46c3d4cb97, some UI adaptations were needed though.
Related to task #36680Closes#26958
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
In case of error, paypal return some lines where error message and not a
string with 'key=value'.
This commit fix traceback:
ValueError: dictionary update sequence element #0 has length 1; 2 is required
When you enable the IPN notifications in your Paypal account configuration,
the default IPN URL is mandatory.
You are therefore obliged to put the IPN feedback URL of Odoo
in this default URL, even if this is not used because
each transaction done by Odoo specifies the URL to which the IPN
notifications must be sent.
Because of this, if you use your Paypal account
for something else, e.g. Ebay, you receive
notifications of payments for these other transactions,
that have nothing to do with Odoo.
In such a case, Odoo returned an HTTP error status code (e.g. 500),
because Odoo couldn't find the given transactions, and
then Paypal sent emails to the Paypal owner
to tell the IPN feedback was failing. Eventually, after
several fails, Paypal automatically disabled the IPN
notifications of the given account.
With this revision, we now avoid to raise the Validation errors
in the case of the IPN feedback, and just logs it,
to avoid Paypal to sent emails to
the owner and to automatically disable the IPN notifications
if it receives transactions from other services than Odoo.
opw-702403
This reverts commit 8b64bf7682.
This should have been fixed in 8.0, a moment of distraction made me
push it in 10.0.
This is not the branch you are looking for, carry on.
When `paypal_validate_data` is called without any reference, `tx` is None.
Before the migration, it was catched by a `tx and tx.acquired_id` but it is no
longer the case.
Introduced at f1ac1b12Fixes#13834
It seems Paypal does not always send the same responses on auto-return
even when PDT is off. Although not reproducible on a Paypal sandbox,
sometimes the system auto-return to /payment/paypal/dpn without any
meaningful POST data. This seems to only happen with new accounts
that use the 'Hermes' web application of Paypal.
The correct thing to do would be to add a new field on the paypal
payment provider for PDT token and make the PDT flow available
to users; but this is a stable branch and this fix is already
sufficiently delicate. This shall be done in master though.
From this revision on, users can then activate PDT on their paypal
account, set the PDT token as an ir.config_parameter value (WITH
GROUP RESTRICTION SET TO ADMIN/SETTINGS GROUP!!!) and the system
will process these requests correctly.
Although we have been reluctant to perform this change, a specific
use case can cause customers to be redirect to the Odoo DPN url
with a GET request.
This happens when a Paypal Merchant account has the feature Guest
Checkout active; in that case, a customer can pay without having
a Paypal account (using only his credit card) and will *not* be
subjected to auto-return; as detailed here:
https://www.sandbox.paypal.com/be/cgi-bin/webscr?cmd=p/pop/help-account-optional
Request coming from that payment flow will always trigger a GET
request, causing the customer to be welcomed by a
405 - Method Not allowed
error on the Odoo server. The payment is normally correctly processed
through IPN, so this does not normally causes loss of data; however
this is not a nice way to welcome back your customer right after
they pay you.
The stdlib version of the json library is more recent than the 3.5.3
version we are pinning in `requirements.txt`
There is no reason to use it.
Closes#6940
with post.pop('custom', '{}'), if the key 'custom' is not there, it will return '{}', but if the key is there, but the value is equivalent to False, the json decode will fail.
Anita (anko)
