Commit 4d1a1f1c introduced a systematic check on the kwargs passed to
transaction routes of modules integrating with online payments, but
failed to check the access token of documents whose ID is passed to
payment routes. This allowed retrieving the access token of such
documents by visiting a route that did not check the document access
(e.g., /my/payment_method) and passing an arbitrary document ID
(e.g, sale_order_id=123). The route's controller would reroute the
payment flow to the document's portal page and render the landing route
of the flow on the payment form, with the access token included.
This commit makes sure that we always check the access token of a
document before reading rerouting a payment flow.
closesodoo/odoo#138238
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit changes the way transactions linked to a document (sales
order, invoice...) are created in a payment flow. Rather than receiving
and trusting the transaction values from the controller, they are now
read from the linked document, and the payment flow is rerouted to use
the document's module's controllers instead of that of `payment`.
This ensures that no unexpected value can be passed to the `create`
method of a transaction, and simplifies the implementation of the
payment flows of linked documents.
task-3136240
closesodoo/odoo#126425
Related: odoo/enterprise#43212
Related: odoo/upgrade#5124
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
Instead of monitoring a list of transactions to post-process in the
session, we now track only the last processed transaction, thus allowing
to drop the 10 min delay of the post-processing cron.
task-3125913
Part-of: odoo/odoo#119473
Co-authored-by: mano-odoo <mano@odoo.com>
The "fees" or "extra fees" or "customer fees" feature was meant to make
customers pay for the processing fee charged by the payment provider
they choose to make their payment. The fee was also displayed on the
payment form to deter customers and encourage them to choose another,
cheaper, payment provider.
In practice, it didn't hold up because:
1. the provider's API must allow sending the fee as a separate amount,
and PayPal was the only supported provider to do it;
2. charging extra fees is highly discouraged by providers, and forbidden
in Europe;
3. the final fee amount depends on the customer, country, payment
method, risk profile... rendering charging the actual fees amount
infeasible;
4. most of the time, only one payment provider is enabled at a time,
thus alienating customers who would have no other choice than paying
the fee;
task-3358581
closesodoo/odoo#132104
Related: odoo/documentation#5517
Related: odoo/upgrade#5053
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit the public user did not have access to tokens or the
possibility of saving payment methods.
When receiving a link to pay the customer (even if not logged in) should
be able to use tokens saved by the parter of the document and also save
new payment methods. This is intuitively correct: as the possesor of the
link, the customer have rights to pay with tokens linked to the partner.
After this commit tokens linked to the partner of the document will be
visible to the public user and also the possibily to save payment
methods.
Task - 2799296
closesodoo/odoo#104472
Related: odoo/enterprise#34792
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Until this point the access to tokens was somehow arbitrary and
illogical.
After this commit we will uniformize the tokens access rule where by
default an user can only access its own tokens by default and in
function of the use case then relax the rules.
Task - 2832561
closesodoo/odoo#104808
Related: odoo/enterprise#33541
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The payment values in the Qweb context of sale, sale_subscription and
website_sale were computed separately, although there is a large common
basis. This split made it hard to communicate between modules and
generated a lot of duplicates. The new function `_get_payment_values`
in sales is now used as a common basis method for all sale_* modules to
get the common payment values.
closesodoo/odoo#107788
Related: odoo/enterprise#34922
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Rather than hiding all payment providers and payment tokens from the
payment form, a warning is now shown to the user if their company is
not the same as that of the document (SO, invoice, ...) they're paying
for.
task-2983985
closesodoo/odoo#100375
Related: odoo/enterprise#31424
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit removes unused imports and renames some confusing variable
names and helper texts that were changed with commit f7b8f075 when
renaming the term "acquirer" to "provider".
closesodoo/odoo#100348
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>
The alert block content and style for the transaction status after
payment were computed in two different places: In the dedicated
`payment.transaction_status` QWeb template, and in the
/payment/confirmation` route's controller which, for some reason, was
re-inventing the wheel instead of relying on the dedicated template.
This commit combines the slightly different behaviors in the template
and gets rid of the duplicated logic in the controller to:
- Handle the states 'draft' and 'error'.
- Always show the transaction's state message, and not only when the
transaction was in a state for which there exists no pre-defined
message (`draft` and `error`).
task-2924873
closesodoo/odoo#96348
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>
When a customers paid a transaction through the `/payment/pay` route and
the transaction was authorized, the message for confirmed transactions
would be shown on the `/payment/confirmation` route instead of the one
specific to authorized transactions.
task-2527323
closesodoo/odoo#78843
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Due to an oversight, the "Save my payment details" checkbox was shown on
the inline payment form of SEPA Direct Debit acquirers, which should
never happen because the transaction is *always* tokenized with those.
With this commit, the `_is_tokenization_required` method is slightly
refactored to read the provider from the current `payment.acquirer`
record rather than from the kwargs. This conveniently fixes the issue
and prevents it from happening again elsewhere.
closesodoo/odoo#95519
X-original-commit: ebeebd87ed6d687b96dda3006b81356dfa76d0a0
Related: odoo/enterprise#29237
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the reference of a validation transaction followed
this format: “validation-20220222072710”, which did not match the
standard format for refund transactions (”R-S000001”). Moreover, some
providers limit the length of transaction references which forced us to
truncate the quite long reference.
With this commit, future validation transactions will have a reference of
the format: “V-20220222072710”.
task-2830826
closesodoo/odoo#94921
Related: odoo/enterprise#29076
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, sales orders/invoices that had been canceled could
still be paid from a payment link. Now, when trying to pay for a
canceled sales order/invoice, the amount to pay is set to zero.
Task - 2735019
closesodoo/odoo#85728
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: account_payment, sale, website_sale
Users should not be able to discard the tokenization of their payment if
they pay for a subscription.
This commit introduces a new helper method to better predict when the
tokenization checkbox should be shown or hidden. This also ensures that
the behavior will be the same across all modules.
task-2695201
closesodoo/odoo#91860
X-original-commit: 1d8dc53f8ed2a967b35213bc913cdfbc42ff15bc
Related: odoo/enterprise#27568
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: account_payment, sale
This doesn't change anything from a technical point of view, but it
helps to consistently assess whether a method is attached to a route or
not, only by looking at the class' skeleton.
closesodoo/odoo#91359
X-original-commit: 93de42458ed0a7df20a7bc2f2c2b106386293c78
Related: odoo/enterprise#27330
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In a multi-company environment, a partner of company A should not be able
to make payments for company B. With this commit, if we detect a
mismatch between the companies, a UserError is raised.
Task - 2627751
closesodoo/odoo#91189
X-original-commit: 6064cf2e98f16b42f516dcd1b0793a62436bab33
Related: odoo/enterprise#27245
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Before this commit, the public user would be prevented from creating,
reading, or using payment tokens entirely. This was put in place in an
effort to homogenize the way each application interacts with tokens,
and because it was considered more logical to only create tokens when
you can see actually them afterward. This however led to an undesirable
side effect in Subscriptions where customers would pay while being
logged out, thus preventing the token from being saved and failing the
automatic renewal of the subscription.
With this commit, we enable the public user to create tokens from any
payment flow. This also means that when a token is created, its owner
will not see it until they log in. This commit also reverts 2a084c48
which was intended to hide payments acquirers from the public user if
their payment would end up being tokenized.
opw-2789340
closesodoo/odoo#90061
X-original-commit: 4e03d4b6106f10522dd5f1839a0f941ca6b202fa
Related: odoo/enterprise#26741
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the /payment/pay page would not filter out acquirers
configured to allow tokenization when it was although required for the
payment. For example, for sales order with a subscription product (which
requires tokenization), acquirers that don't allow tokenization would be
shown to the customer if they pay from the /payment/pay page, but not if
they pay from the portal view of the SO.
This commit makes sure the sales order id is correctly propagated to the
Subscription app which then flags the payment as requiring tokenization.
closesodoo/odoo#86202
X-original-commit: 9ab7b2447f2ece46f1a25335ab76f06323f03d22
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
Current behavior :
In a multi-company environnement if you generate a payment link and access it from incognito page the company was always the logo of the first company.
Steps to reproduce :
- Get in a multicompany environnement
- Create a invoice in company B
- Generate the payment link in the action menu
- Access the link in incognito mode
- The company logo is always the logo from company A
opw-2756438
closesodoo/odoo#85000
X-original-commit: 0e2e79d055e8565e2913b30477fcfdb71e99bdae
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Expected behavior :
User should be able to archive the tokens he sees
Current behavior :
User sees his tokens but cannot archive a token from another company
Steps to reproduce :
- Install Sales & Contacts
- Create a 2nd Company
- Enable `Online Payments`
- Setup a Payment Acquirer (Test Mode for current company) *Be sure to have `Allow Saving Payment Methods` checked*
- Create a new contact and grant him portal access
*With new contact*
- Get the link and set a password
- Create a new payment method in `Manage payment methods`
*With admin again*
- Replace `Allowed Companies` and `Default Company` for the new contact by the company created before
*With new contact*
- Go back in `Manage payment methods` and try to delete the token
Reason :
Before, the `write` method from the model was called but returned an AccessError because the token was linked to another company.
Now a custom route is called, it checks if the token is linked to the user and archives it with the necessary rights
OPW-2660186
closesodoo/odoo#82405
X-original-commit: 19f8c4e26291740edecd0c101c3d331deef2758d
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
... even if they are in a company in which he has no access rights.
Finetuning of #79253 to keep previous multi-company behavior.
We didn't consider the fact that the previous behavior was fully managed
in sudo (through request.env.user.partner, which gives a sudoed record)
and changed the behavior by using an unsudoed search.
closesodoo/odoo#80694
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Saved payments methods for disabled acquirers are no longer visible on the customer
portal. It was fustrating for the customer to see saved payment methods that he was
no longer able to use as they are disabled.
Now the use should only be able to see payment methods that he can indeed use.
Task - 2679695
closesodoo/odoo#79253
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When a payment is made, add required parameters to the landing route.
This issue was introduced with 7fccbac
task-2645216
X-original-commit: cfcf4c64caac951783a1b39b63c024028b07b434
Part-of: odoo/odoo#77874
Co-authored-by: Victor Feyens<vfe@odoo.com>
This commit adds /donation/* routes to perform the donation:
- /pay: shows the form with the contact details and donation details
- /transaction: creates the partner_id if missing and executes the
transaction
- /confirm: displays the payment success page
PR-63133
task-2398403
Part-of: odoo/odoo#63133
Before this commit, the validation flow with verification (payment of a
small amount with immediate refund) was performed with the use of
validation routes: after payment, the customer was redirected to the
validation route stored on the transaction to trigger the refund. This
implementation had an issue: if the customer never reached the
validation route, they were not refunded their validation amount. This
could happen if the customer closed the tab after paying with an
acquirer offering payments with redirection, or if the validation
payment was asynchronously confirmed through a webhook notification.
This commit gets rid of validation routes and requires acquirers to
immediately refund the validation amount when the payment is confirmed.
This way, a payment confirmation coming from a webhook can trigger the
refund too.
As the only acquirer that implements the validation with verification
flow, Authorize.net now voids validation transactions as soon as they
are authorized.
While we're at it, the logging of processing values is adapted to only
log specific rendering values if a redirect form is rendered.
task-2612977
closesodoo/odoo#74707
Related: odoo/enterprise#20060
Related: odoo/upgrade#2710
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Before this commit, it was not possible for an acquirer to support
tokenization while not supporting validation because the acquirer would
be thought to be compatible with either flow based on the
`support_tokenization` field. This was a false assumption because some
acquirers, such as Ogone, can offer to tokenize a payment method in
payment with redirection flow while not allowing tokenizing a payment
method for future usage, without payment.
Note that this was not an issue for acquirers supporting the direct
payment flow because they could either support validation natively, or
seamlessly charge a small amount and refund it immediately to tokenize a
payment method.
This commit makes it possible for a module implementing the validation
operation to filter acquirers based on whether they support it,
regardless of their support for tokenization.
task-2494916
This commit brings back the possibility to pass invoice ids in payment
links, a feature that was lost with commit 573ed74c. If such an id is
present in the payment link URL, the transaction that is created must
have a reference starting with the name of the invoice, and must be
linked to it.
task-2494916
closesodoo/odoo#72992
X-original-commit: 6c13a361400332955cdf5ac5a14bd1970b4f66ef
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.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>
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
Steps:
- Install account,payment
- Go to Invoicing
- Create an invoice
- Click Actions > Generate a Payment Link
- Follow the generated link
- Pay
Bug:
The transaction is not linked to the sale order in the link table
`account_invoice_transaction_rel`
Explanation:
This fix is broadly mimicking the behavior of the sales module regarding
the link of an order to a transaction, adding `invoice_id`s where they
are needed throughout the payment process in order to link the
transaction to the invoice.
opw:2451534
closesodoo/odoo#67296
X-original-commit: 7c6d06fa5858f79f3b22cdeaf74cdc26a642742f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Select a sales order.
Go to action > generate payment link.
Open private browser, reach the link.
User will receive error message because of access denied to the
res.partner data.
opw-2287534
closesodoo/odoo#54808
X-original-commit: 3b4f3a8ad2880721cf6de9fb08387412df85d356
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install 3 payment providers:
P1: no countries set
P2: country set to USA
P3: country set to Canada
- Activate online payment of invoices
- Create an invoice for portal user A (country of user is USA)
- Login with A
- Pay the invoice
All 3 providers are available, while only 1 & 2 should be available.
The providers are filtered in the sale module, but not in the account
module:
https://github.com/odoo/odoo/blob/586ee04a6296c13868011b3afaca61be5c6ff3c6/addons/sale/controllers/portal.py#L190-L193
The same issue occurs with the direct link `/website_payment/pay`.
We apply the same filtering in all modules.
opw-2279710
closesodoo/odoo#53483
X-original-commit: aaac93b551e2a5f331dd14ee5aefbe4ced173691
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When generating a payment link through the payment link wizard, the
company was previously not included. This could cause accounting issues
if the acquirer displayed to the customer were not part of the same
company as the underlying document that generated the link.
This commit add a new computed field 'company_id' on the wizard model
that gets computed based on the underlying model; this field will be
included in links generated by the wizard to limit the acquirers
displayed to those of the that company, preventing extra acocunting
steps (interco reconciliation).
opw-2254011
closesodoo/odoo#51441
X-original-commit: a6fcd7e0cfec8d4c62620a53b5fa806561e239af
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce:
- install sales, ecommerce and payment_authorize
- setup authorize.net (test mode)
- go to sales and select the quotation S00007 (demo data) or create a quotation
with multiple items that add up to a float
- select action > generate a payment link > go to the link > select pay with authorize
- you are redirected to authorize.net use 4111 1111 1111 1111 as card number and 1223
as expiration date > pay
- you are redirected to the odoo payment process page
- wait for the result
Previous behavior:
the user is returned to a 404 error page but the payment went trough
Current behavior:
access_token generation is consistent and will not fail because of
float representation
the user is returned to the "payment confirmed" page
WARNINGS:
- watching the values in vscode prevents bug reproduction
- when setting up authorize.net, do not forget to add your test url to
the account's allowed return urls
- use https for authorize.net connection
opw-2223135
closesodoo/odoo#50633
X-original-commit: 0fe7fa0f95b7393d8829ba4b216d6c41d0c0dc3d
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
- The payment link generated by using the wizard
`payment.link.wizard` are overriden to generate
URL linked to sale orders.
If so, we want the payment acquirer displayed to
be in the same company as the sale order.
closesodoo/odoo#49018
X-original-commit: 8c299efb6cb4355cec39cdedd8d7c3134f53d199
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
The access right on payment_token is based on the partner_id
linked with the user
If there is token link with the public user,
they are shown for every request were the partner_id is not defined
If you are logged with an internal user with sales access right,
you'll see all the payment_token linked with the acquirer
We should avoid both situation and show only the payment_token
from the legit partner_id
the one of the current user or the one given as parameter
closesodoo/odoo#44346
X-original-commit: 9edad5d9018ae357e955a5e21e9366e56caa8e31
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Co-authored-by: Damien Bouvy <dbo@odoo.com>
Fix error like "TypeError: {4} is not JSON serializable" when
serializing the session object (e.g. for external storage)
closesodoo/odoo#41360
X-original-commit: e91e38fa4bd12ba9d2027e7778a10252e08b9a86
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Antoine Vandevenne (anv)