- 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
tbe-odoo