The user should always be redirected when paying with wire transfer.
This is because the landing page displays useful data such as the communication.
Closes#27194
Sips does not accept special characters as a transaction reference.
Replacing '-' solve this issue.
Parsing Sips response was failing when the return url had query parameters.
This was due to the split on '='. Encoding the url solve this issue.
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
- When creating a transaction on the payment page of the portal, the
transaction reference returned was incorrect.
This commit return the newly created transaction's reference.
- The method to compute the reference of a payment.transaction and avoid
duplicate was missing some edge cases (for example if there was a '-'
in the reference).
- The creation of transactions in the route /website_payment/pay was not
checking for duplicate payment.transaction.
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
- Fix an issue where the transaction were always set a 'form_save' thus always creating payment tokens.
- Fix an issue where when the customer paying while not being logged in was crashing.
The issue is due to the fact that we are creating payment transactions linked to no partners, doing so it crashing the code when creating the payment token with no partner set.
- On 'website_payment/pay' if the reference contains a '/' the payment will never succeed.
It is due to the fact that in the template "payment.pay" were setting "prepare_tx_url" and "form_action" using this reference.
But having a '/' in the reference breaks the URL to call to create a transaction.
So when creating a transaction (or even paying in S2S) the payment never succeed and returns a HTTP 404 error.
The generic payment form introduced in 11.0 has changed the way we collect payment and so does the code.
The route /website_payment/pay hasn't been changed to support the new payment form.
This commit fixes this.
It also fixes a bug for when a customer tries to create two transactions with the same reference.
- Fixed 500 errors when trying to display payment form because of variables partner_id/acquirer_id missing.
- Accepted credit cards are now display next to the acquirer name on the payment form
- Online quotation and e-commerce now use the new payment form.
- Added the ability to chose on an acquirer if it uses only form/s2s or both.
(Still need some code cleaning)
Customer portal controller and templates contained in website_payment
module are moved to payment. This module now uses the customer portal
defined in portal module and most of website_payment code is moved
to payment.
website_payment now contain code really related to website, such as
payment acquirers configuration for website.
Christophe Simonis