Allow configuring a webhook in Stripe to send s2s notifications to Odoo
when a Checkout payment is completed. Note that SetupIntent and
PaymentIntent events are not listened to, since they are handled 'live'
with the customer actively present; the main use case for Stripe
webhooks is a Checkout session that gets interrupted before the customer
is redirected to Odoo (e.g. network loss, browser crash, closing the
tab, etc.)
The webhook should be configured to send its events to
<base_url>/payment/stripe/webhook and should only subscribe to
checkout.session.completed events to avoid spamming the Odoo server with
useless notifications.
closesodoo/odoo#52754
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.
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
Apparently missed in 07ab8b6cd2
In Python 3, there is no Exception.message attribute anymore, this would
lead to cascading exceptions in the stripe_s2s_create handler.
closesodoo/odoo#28141
This commit aims to improve the user experience when using payment acquirers. There currently are no error feedback with some acquirers, which leaves the user wondering what is going on and what is the real status of its payment.
In some cases, the user is currently being redirected to the home page even though the payment has failed. We want to make it more obvious to the user that something unexpected has happened by redirecting to an intermediate page that will provide good feedback on payments status.
Another goal of this commit is to order acquirers by sequence instead of by flow and to select the first acquirer by default. This feature was already implmented in commit fe294fd43e521bd2d339e962f43acf46c3d4cb97, some UI adaptations were needed though.
Related to task #36680Closes#26958
- This commit, fixes a crash triggered when the user is paying a quote while having his browser language set to a language not defined on the Odoo database.
This is due to the fact that the field 'name' on the model 'account.analytic.account' is translatable.
Stripe sends a json query to the server with the user's browser's language on the 'Accept-Language' http header field.
By doing this, Odoo add a 'lang' key to the context, which is then used to translate translatable fields.
- 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.
- When registering a payment token, validating it using a payment of a small amount (~1.50€) followed by a refund allows ensuring
that the payment method is valid (i.e. checksumming the card number simple ensure the number is valid but not that the card exists).
This commit introduces a generic approach that must be implemented for each acquirer that has tokenization support.
This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
- Introducing a new payment form that handles payment, deletion and adding payment method (only for server2server for the moment).
- On /my/payment_method, changed strings 'Payment Acquirers' to 'Payment Methods' which is more clear.
- Stripe can now be used to pay subscriptions.
The email of the recipient must be specified in the charge.
The checkout.js prompt creates a token with the email specified as the name but
to get an email confirmation that the charge succeeded, the receipt_email
parameter must be set.
Side note: the receipt_email is not enough to send email confirmation, it must
also be enabled on Stripe dashboard that generated the access tokens.
Reference: https://support.stripe.com/questions/email-receipts
opw-697759
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
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
Adrien Horgnies