[FIX] payment_stripe: fix multiple usability problems

- 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.

0 files changed, 0 insertions, 0 deletions