diff options
| author | Damien Bouvy <dbo@odoo.com> | 2019-12-31 09:18:54 +0000 |
|---|---|---|
| committer | Damien Bouvy <dbo@odoo.com> | 2019-12-31 09:19:34 +0000 |
| commit | 525d363b560ca5b3671850163ecd0ec9e6c8a290 (patch) | |
| tree | a2ee911a06efe9d0298a61264333eb6e39be364d /addons/web/static/src/js/views/basic/basic_renderer.js | |
| parent | aca2b7191936f0b72a3a24aea1568b7d32c27a16 (diff) | |
[FIX] payment_stripe: better error handling
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.
Diffstat (limited to 'addons/web/static/src/js/views/basic/basic_renderer.js')
0 files changed, 0 insertions, 0 deletions
