Currently, When a user tries to set up a stripe account but his country is not
supported by stripe then he receives a error message at backend side and a
ValidationError ("Stripe Proxy: An error occurred when communicating with
the proxy.") on frontend side.
After applying this commit the error message will be updated to a warning level
which will reduce the noise in sentry. I have also added a condition in
'action_stripe_connect_account' method to check whether the country is
supported by stripe or not and if it is not supported the user will be
redirected to other payment providers page.
sentry-3935758343
closesodoo/odoo#128140
X-original-commit: c7b0d8eebe686d9c38f9f5c71577c80718ffb791
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
When the payment method was detached from the customer, trying to pay
with the linked payment token would end up with a crash because Stripe
failed to send us the payment intent, as it could not create it.
With this commit, we test for the existence of the returned payment
intent and prematurely return in `_send_payment_request` to prevent a
cursor rollback. The transaction is set in 'error' and the error
message is logged in the stdout and on the transaction's state message
field.
closesodoo/odoo#120348
X-original-commit: 4ebf0efc16ef78ca568ef93fb2c36ce404cb0c12
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the "Card" payment method would always be shown on
Stripe's hosted checkout form, even if there is no related payment icon
(VISA, MasterCard, Discover, American Express) set as "supported payment
icon" in Odoo.
After this commit, Stripe is instructed to hide the "Card" payment
method if all related payment icons are unset in Odoo. If at least one
related payment icon is set, the "Card" payment method is hidden. If the
"Supported payment icons" field is left completely empty, all payment
methods are available on Stripe.
closesodoo/odoo#116917
X-original-commit: d7e96a771e92020938658cdd4dc4a41c45f1644e
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, it was not possible to partially capture a
transaction from Odoo, and doing so in the provider backend would often
result in a full capture in Odoo when capture was supported.
With this commit, partial captures are made available in Odoo directly
from the sales order or invoice, for providers that support them.
Provider can either only support full capture or also support partial
ones. It also optionally managed the automatic void of the remaining
amount at the user request when multiple captures are supported by the
provider.
As of now, the only acquirer allowing partial capture is Adyen.
task-2728768
closesodoo/odoo#87251
Related: odoo/enterprise#35205
Related: odoo/documentation#2063
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some providers require additional allowed states due to their refund or
transaction process justifying it. Until now, these extra states were
specified in the `payment` module, which was not ideal as it allowed
every provider in every flow to accept these additional states.
With this commit, additional states are now specified only in the
coresponding flow of a provider that requires them.
task-2869678
closesodoo/odoo#107110
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
For now, you can enable the Stripe payment provider while onboarding
with Stripe Connect.
This raises two issues:
- This will raise errors in online payments because Stripe is not
completely configured;
- The button to continue the onboarding is not working anymore,
preventing the user to finish the configuration of his account from
Odoo.
This commit prevents enabling Stripe if the onboarding has been
initiated but is not finished. It also changes the way constants are
read from const.py to allow patching one of them if needed.
OPW-3149159
closesodoo/odoo#111534
X-original-commit: fa3bcac71d1699aa9b9a7bc1d6b6181a70171662
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Before this commit, the string with the phone number sent to Stripe for the request is not checked and we got this error on the checkout page
---------------------
We are not able to process your payment.
Stripe: The communication with the API failed. Stripe gave us the following info about the problem: 'Invalid string: +1 555-555...5678456789; must be at most 20 characters'
-----------------------
The stripe API does not accept phone numbers with more than 20 characters
The problematic phone number are mostly the one with extention: +1 780-459-5656 ext. 725
But the customer can put anything in the phone field when he buys some product via eCommerce
Now I just limit the phone string to 20 characters, this doesn't affect the res.partner
If the customer had a phone with more than 20 characaters in the res.partner form, it will stay that way. It's only for the stripe request
closesodoo/odoo#109834
X-original-commit: d24cc320854f180989949328396dbbd8ac69bdc9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
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>
Saurabh Choraria