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.
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>
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>
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>
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>
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'`
Antoine Vandevenne (anv)