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'`
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
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
- Stripe needs to have the amount in integer, so we have to multiply by 100 the amount.
Which sometimes create float representation errors and remove/add ~1 cent on some transactions (i.e 72.60€)
- When creating a Stripe charge, we have the possibility to send the customer email.
This is then used by Stripe to send a payment notification (receipt) to the customer.
This was never done by Odoo, this commit introduce this feature.
OPW-1829945
Before this commit, when accessing the payment page with arbitrary amount
(/website_payment/pay?reference=Testinvoice&amount=150.0¤cy_id=6&country_id=)
A traceback was thrown because the keys concerning the partner were not present in the dictionary
that prepares the values for the form that we send to Stripe
Considering that those info are not mandatory for stripe (although not very good practice -- the more info the better to verify an identity)
we ignore them if not present
After this commit, the public route works fine
OPW 1832164
closes#23948
Horacio Tellez