Before this commit, when paying a confirmed SO with the token access with Stripe,
Clicking on the button "pay now" wouldn't do anything, because the id of the SO couldn't be retrieved
After this commit, the regex that does just that is more generic and the flow works
OPW 1881192
closes#26884
- Create an order from the eCommerce
- Choose to pay with Stripe
- Enter the credit card info, validate
There is a short window of time (before the reload of the page) where
the user can click on 'Pay Now' again.
This is because the HTML is completely replaced, including the button.
We restore it when necessary.
opw-1866332
Purpose
=======
Currently, users have to retype email in the stripe payment popup.
For event registration, the email address must be typed 3 times (the first
for the registration information, the second for the billing information
and finally for the payment on the stripe popup)
Specifications
==============
As the email is already filled on billing information view, isn't
necessary to retype in the payment form.
- 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.
Before this commit:
On portal (My Account > Invoices > Pay Now), a stripe payment in a normal
currency (eg: a non integer currency) would debit the amount *100.
This comes from b335ae0348 which added a workflow to handle integer
currencies but it also sent the *100 amount to /website_payment/transaction
that would create a TX with that amount instead of the normal amount.
Now, the normal amount is correctly sent to the backend, the multiplied amount
is just sent to StripeCheckout handler to correctly display the amount on the
popup after clicking on "Pay Now".
Note: the amount will be multiplied on the backend independently ecda057e11
In case an invoice is required to be paid thanks to the route
'/my/invoices/', the user is redirected to '/shop/payment/transaction/'.
If website_sale is not installed, this causes a crash.
Complement of 2bd17285ea
opw-813481
As some flows were broken, this set of fixs improve the different routes for all acquirers
See commit messages for more information
Thanks to @jpr-odoo for his first implementation and to @tde and @fgi
This commit b335ae0348 previously sent currency instead of currency_id on
/website_payment/transaction route resulting in a cast error.
Now, we send the currency_id as the route expect
This closes#19468, closes#22165
- Before this patch, stripe doesn't get displayed.
It was a bug related to the fact that stripe doesn't respect how the generic payment form works.
So to make it work, we were relying on small hacks that got broke by changes on the payment form.
To fix the bug we are no longer adding an event to the pay button of the payment form, instead
we listen all the changes made to the DOM and detect if a form with an attribute 'provider' set to
'stripe' is added.
If so, we open up the Stripe payment form.
- Fix ACL issue when trying to pay with Stripe on eCommerce without being logged.
Closes#20202
opw-776200
- There was no feedback to the user when executing the Charge
transaction in server-to-server mode, while it could take several
seconds, with the normal UI/action buttons still available.
- Stripe integration was almost working along with `website_quote`
payment, but entirely broken with `website_payment`, and partially
broken with `website_sale`.
Fixing it required:
+ More leniency in processing optional transaction parameters, which
may or may not be present in the various payment flows.
+ It also required more precautions when locating the transaction for
which the Stripe Charge was to be created, which passed in different
manners in the session. The route now supports an explicit `tx_id`
to allow forcing the transaction without risk of mixing different
payment flows.
+ FIXME: There is still some amount of duplication and bad modularity
in the handling of the various payment flows in relation with
Stripe.
- We provided very little metadata to the Customer and Charge APIs of
Stripe. We now pass more names and references to make Stripe payments
easier to manage in the Stripe dashboard.
- In some cases, selecting Stripe as payment method caused a second
inclusion of `stripe.js`, raising a JS error because of the
duplication.
- Strip whitespace in emails: the Stripe API raises an error for
transactions done with invalid emails, including with
leading/trailing whitespace.
Customers will have a hard time figuring out the problem
by themselves, so we should at least strip whitespaces.
To reproduce:
- Buy a product costing 0.01
- Validate the cart, pay with Stripe
- Enter the credit card info, validate
Stripe cannot process the transaction (minimum charge is not met), but
the user is not warned about it. The Stripe pop-up is closed and the
error is recorded in the console silently.
opw-765775
JS code managing transaction creation through acquirer 'Pay Now' form
button is improved in order to be less website-sale dependant. It now
takes parameters for access token and URL to call in Json. Class used
to bind JS is now o_payment_acquirer_button in order to be more generic.
eCommerce module is updated accordingly. Future commits will probably
make Online Quote (website_quote) use it.
Access token field is moved directly in sale module. Indeed future commits
will improve customer portal and access tokens will be used in other module
than website_quote. This commit already moves the field.
Moreover some strange code in website_sale already uses access_token even
if it does not exist in that module. Moving the field solves that issue.
Finally so_token defined in stripe is renamed to access_token to have the
same naming through all addons.
The module `payment_stripe` was apparently not designed to work with
module `website_payment`, althought the payment method is available. For
example:
- Go to '/my/home', select "Pay Now" on an invoice
- Try to pay with Stripe ==> nothing happens
This commit brings the necessary modifications to make it compatible
with `website_payment`. Moreover, it prevents the creation of 2
`payment.transactions`, which was not necessary.
opw-693421
! This is a backport from 10.0 (9010ed0a) !
opw-693017
Original commit message:
A side effect of commit b9d1239eff if that the method `sale_get_order`,
which is used to retrieve the SO, will also update information on this
SO (change partner, change pricelist...). We therefore need another way
to retrieve the SO.
opw-692919
! This is a backport from 10.0 (815f085) !
opw-693017
Original commit message:
When a user tries to pay a website quote thanks to Stripe, the button
spins and nothing happens.
In the case of a quote, the jQuery selector is not correct.
opw-692341
! This is a back-port from 10.0 (fb010a1) !
opw-693017
Original commit message:
When a user uses Strip and clicks on "Pay & Confirm", a "Bad Request"
error can pop-up. This is because it tries to reload the page, while it
should only display the Strip pop-up.
This is simply due to a `preventDefault` done after the event is
performed, and not before.
opw-692341
A side effect of commit b9d1239eff if that the method `sale_get_order`,
which is used to retrieve the SO, will also update information on this
SO (change partner, change pricelist...). We therefore need another way
to retrieve the SO.
opw-692919
When a user uses Strip and clicks on "Pay & Confirm", a "Bad Request"
error can pop-up. This is because it tries to reload the page, while it
should only display the Strip pop-up.
This is simply due to a `preventDefault` done after the event is
performed, and not before.
opw-692341
When a user tries to pay a website quote thanks to Stripe, the button
spins and nothing happens.
In the case of a quote, the jQuery selector is not correct.
opw-692341
show logo, merchant name, description, currency and amount on the stripe
checkout page.
Add the field stripe_image_url to display the logo that was configured according
to https://stripe.com/docs/checkout
Do not use company logo as there is no guarantee on the image ratio.
Closes#12378
As explained in 15f27b26, the transaction information should be computed when
hitting the "pay now" button, not at page rendering (e.g. in case of users going
back to previous page).
Stripe do not work as typical providers as it does not redirect to the provider
page but opens a popup.
The route /shop/payment/transaction/<id> needs to be called manually.
Contrary to other payment acquirers all transactions through stripe are
s2s transactions. Because of this payment_stripe has to create it's own
payment.transactions which is unusual.
Because of this payment_stripe needs a sale order id which will be
provided by website_sale in request.session. website_quote doesn't do
this so this extracts it from the return_url, just like
website_quotation.js does.
opw-678117
Lucas Perais (lpe)