To Reproduce
============
- on a db with sales, website and Stripe payment aquirer activated
- on the portal of a user add two payment methods, an expired card
and a valid one
- create a SO and generate its payment link
- try to pay with the invalid card first -> and error (card was declined)
- try to pay with the valid card -> error (same idempotency key)
Problem
=======
the generation of the idempotency key is based only on dbuuid, transaction's
reference and the scope. So in this use case it will generate the same key.
Solution
========
The idempotency key prevents issues where the customer is charged twice for
the same thing. In this case, we don't want to prevent anything since the
customer is on the page. It's suggested to use idempotency keys only for offline
payment when the customer is not in front of the payment page (e.g. when the cron
charges the customer for his subscription)
opw-3091354
closesodoo/odoo#108163
X-original-commit: 089387087010ae917494d5072f00d72c572b7d09
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Video 1 (Issue): https://drive.google.com/file/d/1oXYcDJgaT9gmhkjE08yJlXwIL1qPwS1Y/view?usp=sharing
Issue:
When using the register payment with a token with any of the payment acquirers,
if there is a concurrent access error during the reconciliation process,
the payment intent is sent multiple times to the acquirer, making the card charged multiple times.
Steps to reproduce:
-Have a V14 database (only tested this version) with sale_mmanagement, payment_stripe and invoicing
-Configure Stripe with your public and secret key (2FA is now enforced for Stripe accounts, therefore,
we don't have a generic test account anymore. You have to create your own.It is quite fast and easy to do)
-Have a portal user PU with an already registered payment token PT
-Go to Invoicing
-Create a new invoice I:
-Customer PU
-Add anything in invoice lines
-Confirm I
-Register a payment for I:
-Journal: Stripe
-Saved Payment token: PT
AT THIS STEP, YOU MUST ENSURE A CONCURRENT ACCESS ERROR WILL RAISE DURING THE RECONCILIATION
-Create Payment
Log analysis:
A first payment intent is sent to Stripe. The card is charged and Stripe answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
A retry is done.
A payment intent is sent again to Stripe, The card is charged AGAIN and Stripe answers that all went as expected.
We try to process the payment, but a concurrent access error occurs.
For each retry, the intent is sent and the card is charged.
If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side
(others have been rollbacked) but there will be 3 on Stripe's side and the card will be charged 3 times.
This PR mitigate this behaviour.
It doesn't address the root cause but by adding the idempotency key to the headers with the hash of the transaction
reference and the database UUID, we prevent mutliple payments to happen.
OPW-2662964
closesodoo/odoo#103515
X-original-commit: 5fe1c1bbba4d754eed7e8927b82752969d6f563d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Problem: If you have a customer assigned to an invoice/quotation
without an e-mail address and then share a payment link with
the customer. If the customer clicks on 'Pay', he won't be
redirected to Stripe's checkout page. He'll get instead 'Invalid
e-mail address: False' (see the image attached).
Explanation:
When there is no e-mail address defined, Odoo sends 'False' to
Stripe but Stripe sees it as the e-mail address which is indeed
Invalid. To solve the issue we replace False by None for the email
value of a customer without email address.
opw-3007866
closesodoo/odoo#102867
X-original-commit: 647a5fd79b88d4ea00eca2d6c1f9d9a2259a8414
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
When saving a payment method from the `my/payment_method` page
validation is used as the type of operation. In the present
validation operations were incorrectly filtered and treated as a
payment.
After this commit validation operations are processed in the
`_stripe_create_checkout_session` function as it should.
Task - 3001168
closesodoo/odoo#101923
X-original-commit: 7f371db1af160a5e89f9476540aee35f79769068
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: adyen, authorize, demo, razorpay, stripe.
The param `create_refund_transaction` from `_send_refund_request` became
useless following this commit:
https://github.com/odoo/odoo/commit/e4c63126b45854b10f08ab14dee5eb1d4ed98bb0
It was only used for Authorize.net, which now works without calling this
param.
task-2869910
closesodoo/odoo#101105
X-original-commit: 6855d65df7a83037ee5e2202966fa4e67dae7d5a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit enables eCommerce customers to pay with the express payment
methods Apple Pay and Google Pay from the cart page.
For the moment, only Stripe supports this additional feature but it
was designed to make it easy to implement with a new provider.
task-2754209
closesodoo/odoo#88374
Related: odoo/enterprise#29915
Related: odoo/documentation#2392
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, tokens were prefixed with usually 12 X’s. To improve
readability, modernity and to shorten the length, this commit changes
token prefixes to a standard of •••• 1111.
task-2832669
closesodoo/odoo#94978
Related: odoo/upgrade#3738
Related: odoo/enterprise#29190
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
For modules that fully implement Stripe Connect, i.e. that sign requests
with their own API keys, there was no way to pass contextual data to the
proxy when making those requests.
This commit addresses the issue by populating the `proxy_data` param
present in all proxy's routes' signatures with an extendable `dict`.
task-2917229
closesodoo/odoo#96279
X-original-commit: 5df308c58e02c9ca3287c124c0df4e359817ce16
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Computing the fields instead of storing them allows to implement the
feature for each provider more easily, without needing a migration
script.
task-2841744
closesodoo/odoo#91961
Related: odoo/enterprise#27618
Related: odoo/upgrade#3535
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit removes the access to stripe credentials through model
helper methods.
closesodoo/odoo#87972
X-original-commit: 61faa2b32880d60c8cfb7c7761cd313383c26a0b
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some payments may be confirmed asynchronously, and we need to be aware
of their status, even if they are not in a "checkout session complete"
event. Relying on successful payment or setup intents instead manage
more use cases.
task-2733725
closesodoo/odoo#84150
Related: odoo/upgrade#3350
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Prior to this commit, the url build using the concatenation between the
base url and the webhook url path produced a wrong url with two
consecutive slash.
This commit prevent from building a wrong url, using the url_join api
method.
In the commit d3f4619b , the base url was fixed but there was a
remaining url-join error.
Original commit: 4296b2653
closesodoo/odoo#86073
X-original-commit: 8b4d7fa3ae9d470bd12d5c09d6270a637311c0c4
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
Users who select Stripe as their payment acquirer will now have the
possibility to capture manually the amount later (e.g. when delivering
the product).
task-2278434
closesodoo/odoo#69598
Related: odoo/upgrade#3290
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit fixes the webhook base url to use the override defined in
the payment acquirer model.
It ensures the base url follows the same logic as the success and cancel
urls defined in the `checkout/sessions` request payload.
closesodoo/odoo#85558
X-original-commit: d3f4619b731d71ccd2af26b9fa148d2957773680
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
- Log the traceback when a proxy request raises an exception.
- Don't log the traceback returned by the proxy when an exception is
raised on IAP.
closesodoo/odoo#85503
X-original-commit: 529608eb12082463648ded5b46e40d8ce03aab53
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The Stripe Connect onboarding only allows to create production accounts.
This is problematic because, before this commit, it was possible to set
the state of an acquirer linked to a connected account to 'test', even
though the payments would actually be made on the live environment of
Stripe.
Additionally, this commit fixes a minor display issue that caused the
"Connect" button to be shown when an API key was set, while it should be
hidden as soon as an API key is set.
closesodoo/odoo#85444
X-original-commit: 4f9b19b9a9891cb0c39dcb88991de174be60cef9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit lighten payment onboarding form in order to take advantage
of the Stripe Connect Onboarding Flow. It integrates the Stripe
Onboarding using the IAP proxy.
Purpose
=======
Help users easily onboard with Stripe by using the Stripe Connect API.
Specifications
==============
During the payment onboarding, if the user selects Stripe, they will
start the Stripe Onboarding. (NB: The process uses a proxy that handles
the Stripe Onboarding calls and signs them with the Stripe Connect key)
1) A call is made through the proxy to get the Stripe account token;
2) A call is made through the proxy to get the Stripe account link which
contains the URL of the Onboarding;
3) The user is redirected to the Stripe Onboarding;
4) The user completes the Stripe Onboarding;
5) The user comes back to the acquirer form of Stripe and is able to get
their keys.
6) The user can directly create their webhook after having copied/pasted
their API keys.
During the website sale onboarding, the user doesn't go through the
onboarding wizard but is directly prompted to activate their account.
Note that the Onboarding status isn't stored in the database so there is
no call to Stripe API to validate the account status.
API Documentation :
- Connect Onboarding: https://stripe.com/docs/connect/standard-accounts
- Webhook creation: https://stripe.com/docs/api/webhook_endpoints/create
task-2685160
task-2691213
closesodoo/odoo#84639
X-original-commit: 085f4af4e57c43127413585a8df5b3aa47843339
Related: odoo/enterprise#24376
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
Before this commit, most acquirers needed to run several successive
searches for the transaction whose reference was received by a
controller in notification data. This is because the security checks
run on the notification data require access to the acquirer through the
transaction record which was immediately discarded.
Starting with this commit, all `*_feedback_data` method are no longer
decorated with `api.model` and can use the transaction record they're
called on if provided. They are also renamed to `*_notification_data`.
task-2737144
closesodoo/odoo#83850
Related: odoo/enterprise#23938
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
An overridable model method was added in a previous commit in order to
neutralize a database.
This commit introduce the implementation of this method for the payment
modules.
Also, a `_neutralize_fields` helper method is added on the
PaymentAcquirer model to simplify the neutralization of the various
payment modules.
Part-of: odoo/odoo#67825
The logs for payments contain the transaction reference whenever possible.
Before logs for transactions contained the reference or the id of the
transaction in an inconsitent way. No transactions are identified by
reference whenever possible.
The logs for payments for the same function on different acquirers should
have the same format. Same flow step for different acquirers had
information passed in different formats. Now at each step of a transaction
flow log messages have the same format regardless of the acquirer.
Overall the payment logs should have an uniform format. Hopefully
understanding log messages related to transactions should be easier, as
now log format is independent of the acquirer and transaction are easily
identified by reference.
Task - 2545450
closesodoo/odoo#79547
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Fix two issues:
The search of suitable payment token was searching on the journal_id
field of the payment acquirer that is no longer stored.
Change it to now search on the acquirer_id directly, since we have
this information.
The _inverse_journal_id method on payment acquirers would create
new payment line with the manual payment method when no provider
are given to an acquirer, or no payment method is existing for
a given provider. This would cause issues with the creation of
multiple line with the same name on a same journal, which would
trigger the constrains blocking that.
closesodoo/odoo#74990
X-original-commit: a3a2fcb0b299fafbf359ec9015da5c85cdb57b3a
Related: odoo/enterprise#20193
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, the payment function `_get_validation_amount` was
overridden by Stripe to specify a validation amount of one currency unit
while that amount was in fact never passed to Stripe in the validation
flow. The amount stored on the transaction was therefore incorrect.
This commits removes the override to let the default amount of 0 being
set on validation transactions.
task-2612977
closesodoo/odoo#74543
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Issue:
Payouts reference on Stripe are display as:
`SUB123 - ODOO_PARTNER_456789`.
Cause:
When making a Stripe request to create new customer, the description
is formated as : `ODOO_PARTNER_456789` .
Solution:
Replace customer description format as :
`Partner: Mitchel Admin (id:456789)` .
Inspired by: https://github.com/odoo/odoo/commit/3bc1e0175d85a70806999109e928c234e8cc2ca4
opw-2593621
closesodoo/odoo#74109
X-original-commit: 07033a07ca49923a1c5095c371302fb894363c07
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Users may want to be able to have transactions coming from multiple
payment acquirers to be registered in the same journal.
This will allows that.
Task id #2414749closesodoo/odoo#67331
Related: odoo/upgrade#2500
Related: odoo/enterprise#17258
Signed-off-by: William André (wan) <wan@odoo.com>
- The acquirer reference was never saved.
- Transactions with operation 'offline' were not processed.
- If Stripe rejected an offline payment, an exception would be raised.
This lead to Subscriptions assuming that the processing itself failed
and prevented the transaction to be processed. Instead, the exception
is now caught and the transaction's state set to 'error'.
task-2494916
closesodoo/odoo#71602
X-original-commit: e93b3b3c5b9bc86768a5d26ed456ef11cfb40734
Related: odoo/enterprise#18680
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Special character in reference (eg. '#' character in invoice sequence)
might cause error after payment not showing it was successful.
With this changeset, when a payment reference is used inside an url, we
quote it.
opw-2479658
closesodoo/odoo#68585
X-original-commit: 47645c2f170d5a7c09ae80d4e0de6c3a821f7b36
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commits drops the direct payment flow supported by the SetupIntent
API in favor of the payment with redirection flow, supported by the
Checkout API only.
See the merge commit for more details.
task-2333040
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
Steps to reproduce the bug:
- Let's make a bancontact payment with Stripe on mobile from the web shop
- Stripe redirects you to Odoo
- Your phone asks on which browser you wanted to redirected to Odoo
- Choose one
Bug:
An internal error was raised.
When you clicked on a browser (the same you were using or a new one, whatever)
Odoo will resend a request to Stripe. But this request will have wrong data in it.
Stripe will answer with:
Stripe: entering form_feedback with post data {'error': {'code': 'resource_missing',
'doc_url': 'https://stripe.com/docs/error-codes/resource-missing',
'message': "No such payment_intent: 'py_1I6c4UKhH8RhRq18TJs2CP0z'",
'param': 'intent',
'type': 'invalid_request_error'},
'reference': 'S00002-1'}
opw:2422031
closesodoo/odoo#64385
X-original-commit: a42075c9f913f4a20b28f97f0f6786f5a7b2968a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The `name` field is not required on the `payment.icon` model. Therefore,
in case the payment icon name is not set, a traceback is raised due to a
`False.lower()` statement.
opw-2409755
closesodoo/odoo#62646
X-original-commit: 54434a4fdd71b1e344255fb6f3e42d731ba91f3b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If a merchants didn't enable a local Payment Method Type (PMT) on Stripe
side (such as bancontact), his customers eligible for it (ex.: Belgian
and paying in EUR) won't be able to pay using it.
This commit fixes this issue by adding a condition on the payment icons
assigned to Stripe: if the payment icon related to a given payment
method is not listed as a supported payment icon, the related payment
method is not offered to customers, unless the payment icon does not
exist at all.
User can enable PMTs through (Payment Acquirers > Stripe
> Configuration > Supported Payment Icons). This concerns: ideal,
bancontact, eps, giropay and p24.
This solution is not entirely satisfactory but it isn't possible to
fetch enabled PMT from Stripe.
opw-2335482
closesodoo/odoo#60740
X-original-commit: 1d0f23599bbd425c81131a5f6c1c22531ffcd0ee
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
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>
Issue
- Install eCommerce, Stripe
- Setup stripe for testing
- Order something
- Open stripe payment interface (not with odoo)
- Go back with the stripe interface button
Order Cancelled
- Go back with browser back button
- Enter your data
Can pay but order still cancelled so
you paid for nothing
Cause
I fixed a linked error in
b8b9a04ff5b5b2ba40b26632
but I didn't mind that we should cancel
the stripe payment intent too
Solution
Cancel the stripe payment intent so that
filling the stripe form by following
those step will returns an error from
stripe
OPW-2282946
closesodoo/odoo#53819
X-original-commit: 5acb2a649a2f2490725283c7f4cff5a5183d8ed0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
- Go to Website > Configuration > eCommerce > Payment Acquirers
- Activate Stripe
- Configure Stripe
- Go to Sales
- Create a quotation
- Send quotation by email
- Click on "Customer Preview" smart button
- On Website, click on "Sign & Pay" or "Pay Now" if already signed
- Sign it and confirm on "Accept & Sign"
- On payment wizard, select "Credit Card (powered by Stripe)"
- Validate with "Pay & Confirm" button
An error message appears.
opw-2262990
closesodoo/odoo#51815
X-original-commit: 3c5117eaac96604a3306c90480d106e0e36fed2f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Revision 29b3b67a16 introduced payment with iDeal but accidentaly
introduced an issue where some payments did not go through (in fact,
some cards could not be saved, preventing the payment to occur).
This fix prevents this issue from happening by clearly differentiating
between returns from the Checkout process and from the Elements process;
in the case of a Checkout flow, the 'card' key is always present in the
data dict but can be equal to None if a non-card payment method was used
(e.g. iDeal) while in the case of an Elements (payment from Odoo) flow,
the 'data' key is never present and the card information has to be
downloaded using a get request to the Stripe API.
opw-2253269
closesodoo/odoo#51269
X-original-commit: f0ba15cda070e968699cf77ac0ba58234dbdaf51
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Issue
- Install eCommerce
- Set Stripe up (API keys)
- Go on Shop
- Add a product > Checkout
- Pay with stripe
- Go back when arriving on Stripe payment page
(top left link)
Empty error box
Cause
This behavior is not handled by payment_stripe
Solution
Cancel transaction when going back.
It will display a message "transaction cancelled"
OPW-2195385
closesodoo/odoo#47113
X-original-commit: b8b9a04ff5b5b2ba40b26632e2395b7cdb7ea300
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.
Abdelouahab (abla)