Issue
- Install eCommerce
- Add Stripe
- Pay with invalid cart
Traceback
Cause
When I improved stripe error, I didn't checked if
an error could have no event
Solution
Check if the error has an event
OPW-2186385
closesodoo/odoo#44414
X-original-commit: 772c02743b5e6610a75e65e408c956eb6057a47d
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
In some cases, Stripe will return the result of a transaction with
a faulty HTTP Status (e.g. 4XX statuses) - not because the request
was malformed, but because the payment failed. It is a bit unfortunate
that Stripe would not differentiate between payment status and request
validity, but that's the state of things.
This commit ensures that such a response will be logged correctly, by
making the call to `raise_for_status` conditionnal on the response object's
status code and internal structure, forwarding the response's json to the
validation flow if the status is in the 4XX range and a `code` key is
found in the response, as described in https://stripe.com/docs/error-codes
While testing this fix, it became apparent that some error message
processing in the frontend was not correctly handled as well - instead
of purely rejecting the promise, a failed payment should still send its
payload to the backend, to allow the server to put the transaction in
the correct state according to the response.
Reproduce the issue
- Install eCommerce
- Activate stripe, use testing credentials and select
Configuration > Payment Flow > Payment from Odoo
- Create a contact that has a trailing whitespace at the beginning
of the email
- Grant him portal access, and a password
- Open your browser devtools
- Login to the web shop with this portal user and buy an item using
stripe
1. Error Dialog: Server Error (HTTP 500)
2. The exception received by the front-end is not clear
3. When the 500 error is fixed, we still have a error dialog
=> bad UX
Cause
1. The raise was removed but we need to keep it because
it allows the true error to be raised (bad request)
2. The "invalid email address: x" is lost when we raise the
exception
3. In V13, all catch & guardedCatch open a error dialog if we
don't set preventDefaulted to true on the error's event
This commit changes restore the raise, change the error message and
disable the error dialog for this case.
OPW-2126196
closesodoo/odoo#41087
X-original-commit: b8d013285ba54c8d3ab4a3857604dfca3e479b39
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
In case the Stripe API call fails, an Internal Server Error page is
displayed to the user, which is not user friendly.
opw-2126196
closesodoo/odoo#40678
X-original-commit: 95a452f6d928de2e8532027893a353167ffdd389
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
before this commit, when try to make payment with
empty card details, it will raise error dialog.
after this commit, error will be append to acquirer
form
task - 2089999
closesodoo/odoo#39729
X-original-commit: 01b143b971a85d6da673df6c536917ad4754b83a
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Makes it easier for users to match Odoo payments with information
from the Stripe dashboard.
closesodoo/odoo#39465
X-original-commit: 0a55cb29542da20bb9d0543e2b30d125124f861b
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Adapt the API changes in Stripe. Use correct test data existing in
Stripe dashboard for our test account.
closesodoo/odoo#39455
X-original-commit: 4dab64285ab410f239935437b273a0c97951e902
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Althought most of the SCA compliance stuff was already there,
the flow was slighlty changed to better support some flows in 12.0
Reflect this changes in 12.5.
* External payment fetching the stripe API need valid account/key in order
to perform the tests.
* 1st test is testing the previous stripe API, it has been disabled.
* 2nd test is testing for values removed by 595c0ad8ee, the test has
been updated to only ensure the form renders without error.
* 3rd test is testing for amount sent as integers while stripe requires
as cents.
closesodoo/odoo#37160
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
PURPOSE
Test frontend and UI tools of eLearning.
SPECIFICATIONS
Recent commit 5193f0d010 introduced a tool method to parse errors and ease
their management. A variable typo was done by mistake, fixed in this commit.
LINKS
Task ID 1937768
closesodoo/odoo#36085
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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 big images are probably never going to be used for the following models:
- pos category
- fleet brand
- livechat channel
- mail channel
- payment acquirer
And if big images are needed some day the model should use image.mixin instead.
PR: #34925
In case of failure at token creation, raise a proper UserError instead
of a generic traceback.
opw-2025723
closesodoo/odoo#34420
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Configure Stripe with 'Save Cards' set to 'Let the customer decide' or
'Always'.
- Go to the eCommerce, buy an item
- Use Stripe to pay, make sure to check 'Save my payment data'
No payment token is saved.
It occurs because 2 calls are performed to `/shop/payment/transaction`.
The second call, which is used to record the transaction, doesn't
contain the `save_token` parameter is not sent.
Ideally, we should only make a single call, but since Stripe works a bit
differently, we can't prevent it (in stable, at least). Therefore, we
work around it by searching the checkbox value.
opw-2008275
closesodoo/odoo#34242
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The previous commit introduced some changes for SCA/PSD2 but some things
were missing; most notably, registering payment cards in a s2s flow used
the old Charge API that is not SCA-ready.
This commit uses the SetupIntent API instead, allowing to register the
card prior to payment. The global flow is described in the Stripe
documentation in more details: https://stripe.com/docs/payments/cards/saving-cards
Unfortunately, given the complete flow of payments, it is not possible
to use the PaymentIntents API since this would require having the
reference of the transaction before it gets created (the TX is created
after the form submission, but the token must already exist at that
point). Since this is meant to be backported, this changes are kept
minimal in this feature branch. The PaymentIntents API would have been
better since registering a card during a payment makes it more likely
that future off-session transactions will not require an authentication
step. We'll have to live with that for now; it's difficult to know
exactly how this will affect customers before PSD2 goes into effect on
september 14.
Another branch might completely change the flow soon-ish to a more
asynchroneous model, although it may miss the v13 freeze date -_-
There is two payment flow in stripe:
1) Redirection Flow (Form Based):
in this flow, the user will redirect to stripe website for payment
- create a session for a user and redirect the user to stripe with that session
- after successful payment, the user will redirect back to odoo
- get all the details of charge by using payment intent API
- if user have tick save data then the token will be created
2) S2S Flow:
after clicking on pay now button, one popup display with card element
element is provided by a stripe with all validation facilities
After submitting details, payment flow is
- create payment method with card element on stripe
- create a customer with partner email on stripe
- attach customer to the payment method on stripe
- create a token with customer and payment method in odoo
- create payment intent in odoo
- make a request to stripe
- after successful request, payment will be charged for that card
task- 1986267
closes: https://github.com/odoo/odoo/pull/33978
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Jason Van Malder