Commit f0016849 added the module `sale_async_emails` but not the .pot
file.
closesodoo/odoo#162215
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When processing a transaction, the payment method was searched based on
the received code (e.g., 'sepa_debit') that was compared with the
`payment` module's generic codes (e.g., 'sepa_direct_debit'). This
commit ensures that we now compare with provider-specific codes for
Buckaroo and Stripe.
In practice, this mistake had little to no impact as most provider codes
match the generic ones, and we fall back onto the payment method
selected by the user if we can not find a more accurate one based on the
code.
closesodoo/odoo#161883
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When payment details are tokenized through a validation operation, the
currency to use was usually (except overrides) chosen as that of the
payment provider's company. This sometimes caused compatibility issues
if the selected payment method did not support the company's main
currency. For example, the SEPA Direct Debit payment method only
supports the EUR currency.
This commit allows passing a payment method when getting the validation
currency so that only supported currencies can be returned.
Part-of: odoo/odoo#161883
The payment method's `support_tokenization` field was incorrectly set to
`False` instead to `True`. This didn't prevent the SEPA Direct Debit
provider from tokenizing this payment method because it always creates
tokens when a payment transaction is confirmed. However, the payment
method was not shown in payment contexts where tokenization is required
(e.g., Subscriptions' portal page, /my/payment_method page).
opw-3756773
closesodoo/odoo#161561
Related: odoo/enterprise#60562
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit adds a new module to allow delaying the sending of sales
order confirmation emails, thus removing a performance bottleneck in the
order confirmation flow.
This is particularly useful for "flash" sales in which a large number of
event tickets are sold in a very short time span. When the emails are
scheduled to be sent right away, the email rendering that is part of the
payment post-processing keeps the worker busy. When the system parameter
`sale.async_emails` is set to `True`, the email rendering is delegated
to a cron, allowing the payment post-processing to execute much faster.
task-3782827
closesodoo/odoo#157612
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Both the `payment_custom` and the `account_payment` modules made changes
to the visibility of the `payment_followup` group in the view of the
`payment.provider` model. As these modules didn't depend on each other,
the visibility of the group was determined based on the (random) loading
order or the modules, causing the "Journal" field to be either visible
or invisible on other providers than Wire Transfer.
With this commit, a priority is set on `payment_custom`'s view to force
it to always load after that of `account_payment`.
closesodoo/odoo#156514
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
-When product in combo choices are being archived because of variants creation, replace the archived reference with all newly created variants.
-Add test to reproduce this use case
task id: 3713861
closesodoo/odoo#156301
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Each payment acquirer has its own implementation specificities: some
implement a 'payment with redirection' flow and others a 'direct payment
flow'; sometimes the 'payment with redirection' flow is even implemented
as a 'direct payment' flow through an iframe; one payment acquirer could
support webhooks while another does not and relies on another mechanism
to fetch payment status updates...
It can be tricky to guess where to look in the code to determine how a
payment acquirer is implemented.
On top of that, the online payments ecosystem evolves at a fast pace due
to competition, buyouts, and legislation enforcement. Acquirers are thus
frequently migrated to new APIs that might differ in implementation from
the previous API.
To help figure out the *which*, *why*, *how*, and *when* of payment API
implementations, a README.md file is added to the main directory of all
payment acquirer modules. They can be browsed in human-readable format
on GitHub.
task-2374916
closesodoo/odoo#156084
X-original-commit: 4c19f26df3d39394cce2f183d6df15c5b89c7d27
Related: odoo/enterprise#57921
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Following commit ac90aa07, the Customer object was no longer created on
Stripe for one-shot (non-recurring) payments made with Stripe. This
prevented Radar (Stripe's fraud detection tool) to work effectively as
it could not rely on the customer's name and addresses anymore (see
https://docs.stripe.com/radar/integration#recommendations).
This commit forces the creation of a Customer object even for one-shot
payments.
opw-3694379
closesodoo/odoo#155276
X-original-commit: 20efda51fefcc50861d9c73a483b4291e5b7e85d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The following combinations of payment methods and providers are removed:
- Amazon Pay - Adyen: The payment method cannot be activated because it
requires saving a public key in Odoo, and no field was made available
for that. Also, a custom configuration is necessary and the public key
must be generated through a lengthy process that is too cumbersome for
the added value of the payment method anyway.
- BLIK - Stripe: The payment method is not supported by Stripe when the
PaymentIntent object is created after collecting the payment details.
See https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=payment#enable-payment-methods
opw-3736511
closesodoo/odoo#153481
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
-Move menu options to have 'Close session' and 'Backend' at the bottom of the list
task id: 3759943
closesodoo/odoo#154998
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
When a payment method was updated in a way that prevented creating
tokens with it, that is, by either disabling it, unchecking the
"Tokenization Supported" field, or unlinking it from providers, only the
latter would automatically archive the related tokens after showing a
warning to the user. The two first actions prevented the creation of
future tokens with that payment method, but existing tokens could still
be used.
This commit fixes that behavior by adding the warning and the automatic
archiving of related tokens where they were missing. Preventing further
tokenization with a payment method now consistently blocks payments
through existing tokens, too.
closesodoo/odoo#150120
Related: odoo/enterprise#54700
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
The keyword arguments of the callees were never forwarded to the
`payment.method::_get_compatible_payment_methods` method, preventing
overriding modules from controlling which payment method should be
available depending on the kwargs.
task-3640488
Part-of: odoo/odoo#150120
Issue:
Possible to reproduce in 17.0: when adding a new field to the website
form of the "Extra Info" page in the eCommerce, a traceback is raised
(`OwlError: Missing template: "website.form_field_json"`) when the user
selects "Delivery Point Address" (`sale.order.access_point_address`).
Explanation:
JSON fields (which exist since [1]) are not supported as selectable
types in website forms, and they should not be because customers would
not be able to properly fill them out.
Fix:
Filter out all JSON fields from the list of authorized fields in website
forms; they will not appear in the list of selectable types anymore.
[1]: https://github.com/odoo/odoo/commit/7eeba9d205d2dace571b5d0895ddba6290a512db
opw-3596713
closesodoo/odoo#152545
X-original-commit: 28c3eb5878ad6f3d40a096803f3ba4aef5ef7937
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, it was possible for users to drop website snippets
(e.g., the "Badge" block) inside the inline form of payment acquirers.
At least for Adyen, it would prevent payments because the payment inputs
within the inline form wouldn't load anymore.
As inline forms are part of the payment form widget, which itself is not
customizable by users, this commit blocks the website editor inside the
entire payment form and its children elements.
opw-3607719
closesodoo/odoo#152469
X-original-commit: 814ee63956fce740b8cdae0a235351d8a9e6028d
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some logic of the `payment.provider` and `provider.method` models was
not properly covered by unit tests.
closesodoo/odoo#149833
Related: odoo/enterprise#54930
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When browsing a payment provider's payment methods, the "New" button was
disabled because the action did not allow Kanban views.
closesodoo/odoo#148865
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
When the payment provider was disabled, the "Enabled Payment Buttons"
was shown, although it was not possible to enable them yet. The button
is now hidden until the provider's state is set to either 'enabled' or
'test'.
Part-of: odoo/odoo#148865
When `test_display_name_for_empty_payment_details` was tested around
midnight, the test would fail because it compares the current date with
the token's create date, which would be the day before.
closesodoo/odoo#148781
X-original-commit: 87f94715a09b7681bcd92d1cba4f84d30918c502
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Payment acquirers don't have an `active` field, which makes users
confused when they try to delete an acquirer, and the error message
suggests archiving it instead.
opw-3579946
closesodoo/odoo#142000
X-original-commit: 69166117073f1bf255b62b81eaa744f81353f6b4
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The express checkout form template could not be rendered when no payment
provider supporting express checkout was passed.
closesodoo/odoo#140415
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Commit 4d1a1f1c introduced a systematic check on the kwargs passed to
transaction routes of modules integrating with online payments, but
failed to check the access token of documents whose ID is passed to
payment routes. This allowed retrieving the access token of such
documents by visiting a route that did not check the document access
(e.g., /my/payment_method) and passing an arbitrary document ID
(e.g, sale_order_id=123). The route's controller would reroute the
payment flow to the document's portal page and render the landing route
of the flow on the payment form, with the access token included.
This commit makes sure that we always check the access token of a
document before reading rerouting a payment flow.
closesodoo/odoo#138238
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the payment providers (e.g., Stripe, Adyen...)
available for payment were displayed on the payment forms. The customer
had to select one to process their payment. After that, the customer had
to select their preferred payment method (e.g., Credit Card,
Bancontact...) from a list of payment methods supported by the selected
provider over which the website administrator had close to no control.
This was making the payment forms confusing because the payment methods
were displayed sometimes more than once, if at all, in a non-controlled
order, and behind the selection of a payment provider that customers
should not have to deal with.
As the payment method was selected in an iframe or directly on the
provider's website, the information on the selection payment method was
not available in Odoo. This posed many problems, among which were the
impossibility of assessing whether a specific feature (e.g.,
tokenization, refunds, manual capture...) was available, not being able
to easily identify payment tokens through the payment method logo,
listing available payment methods on the website, sorting and
fine-grained configuration of the available payment method, subpar
payment method-specific display on the payment form (e.g., PayPal that
requires displaying a "Pay with PayPal" button), etc.
In this commit, the payment providers are thus replaced by the payment
methods on the payment forms. All contextually available (depending on
the country, currency, requested feature...) payment methods are
displayed one after the other on a single-level list and in the order
configured by the website administrator. Each payment method is
"powered by" (i.e., linked) to a single payment provider: the first one,
by model order, to support it. This allows, for example, offering the
PayPal payment method through Mollie, which charges low processing fees,
while also offering Klarna through Stripe, which supports more payment
methods but charges higher processing fees.
While doing so, the two different payment forms, "Checkout" and
"Manage", are also merged together in a new, configurable case-by-case,
payment form that is entirely redesigned to offer a better user
experience.
After payment, the information on the selected payment method is saved
on the transaction and eventual payment record and updated with the
information received from the provider.
task-2882677
closesodoo/odoo#120446
Related: odoo/upgrade#5103
Related: odoo/documentation#5717
Related: odoo/enterprise#40666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Anita (anko) <anko@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Valeriya (vchu) <vchu@odoo.com>
Several functions were:
- called with `await` while there are synchronous;
- declared as synchronous while they should have been asynchronous;
- declared as synchronous but their overrides were async;
- explicitly encapsulating their return values in a `Promise` when it
was unnecessary.
This commit also cleans up a few mistakes in comments and docstrings.
task-2882677
Part-of: odoo/odoo#120446
This commit mainly removes the extra indent level left over after commit
odoo/odoo@8ec2e8cf. It also cleans up purely cosmetic code styling
inconsistencies.
task-2882677
Part-of: odoo/odoo#120446
This commit removes a legacy polling system that was present to query
the server about status change of pending transactions in the shop. This
has not been necessary since that all payment flows go through the
/payment/status page, which already polls the server for pending
transactions' state change.
task-3125913
closesodoo/odoo#119473
Related: odoo/enterprise#47603
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The "fees" or "extra fees" or "customer fees" feature was meant to make
customers pay for the processing fee charged by the payment provider
they choose to make their payment. The fee was also displayed on the
payment form to deter customers and encourage them to choose another,
cheaper, payment provider.
In practice, it didn't hold up because:
1. the provider's API must allow sending the fee as a separate amount,
and PayPal was the only supported provider to do it;
2. charging extra fees is highly discouraged by providers, and forbidden
in Europe;
3. the final fee amount depends on the customer, country, payment
method, risk profile... rendering charging the actual fees amount
infeasible;
4. most of the time, only one payment provider is enabled at a time,
thus alienating customers who would have no other choice than paying
the fee;
task-3358581
closesodoo/odoo#132104
Related: odoo/documentation#5517
Related: odoo/upgrade#5053
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit addresses an issue with the checkout form displayed on the
portal page of the Subscriptions app: when only one payment provider was
available for checkout, and it required an inline form to be displayed,
the latter would not be shown, and customers were able to hit the "Pay"
button, resulting in a client error. The problem was that Subscriptions
now simultaneously displays two payment forms on the same page, one for
checkout and one for managing payment methods, which was not supported
by the payment engine.
closesodoo/odoo#120482
X-original-commit: 91d701e34a25d2ceada1679f36a9cdbb96c6c019
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
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>
Prior to this commit, the generation of token aliases in Ogone relied
on the util function `singularize_reference_prefix`, which is intended
to make transaction references (and not token aliases!) more
distinguishable by suffixing a timestamp accurate to the second. That
util function does not guarantee the uniqueness of generated reference
prefixes, which is okay because the final reference is further suffixed
if the prefix happens to collide with an existing reference.
Using the util to generate Ogone's token aliases, however, poses a
problem because aliases *must* be unique. Otherwise, a customer saving a
payment token at the same second as another customer would end up
linking their payment method to the other customer's payment token.
This commit drops the use of the util method and replaces it with a UUID.
closesodoo/odoo#115580
X-original-commit: 61d833ffcd1562950126d3c87c92569fe35a8b08
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
As provider references are included in the memo of `account.payment`
records, it makes sense to set one on demo transactions to mimic what
is done with other providers.
task-3063368
closesodoo/odoo#106486
X-original-commit: 73865f2bd03c7d224f0a64659652e8e40c4ba192
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
- The name of the field `provider_id` on `payment.token` should not be
"provider Account" but "Provider".
- The computation of the display name of tokens crashed when the field
`payment_details` was empty.
- The form view of tokens missed a <group/> element to better display
the fields.
closesodoo/odoo#103621
X-original-commit: ae4079807d29996f4edfd295dcfa194973ada8db
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When the payment views were updated with commit odoo/odoo@f7b8f075, a
hook was improperly renamed to `code`, which doesn't help to figure out
its purpose. This commit renames it to `provider_credentials` which
better fits its role.
While doing so, the view files are also renamed and/or split by model to
increase their readability.
closesodoo/odoo#102976
X-original-commit: 49d126d4fce18761d0261adac00e115b840b9b47
Related: odoo/enterprise#32662
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit replaces the `group` element containing the "Connect Stripe"
button by a `div` element to allow it to contain more elements than the
button without having the elements' `attrs` conflicting with each other.
task-2982357
closesodoo/odoo#102579
X-original-commit: f99b067dbfedca361605f0fc63c7913333950b64
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Bug: Users are able to modify their eCommerce cart after it has been
paid when they fail to return to Odoo through the payment provider's
return route. This prevents the cart from being confirmed.
Steps to reproduce:
1. Install the payment provider Mollie and set it to test mode.
2. Go to the /shop page, add a product to the cart, and select Mollie
for the payment.
3. On Mollie's hosted payment page, use the card number 4111111111111111
with the expiry date 03/30 and the secret code 123. Select 'paid' as
the payment outcome.
4. Confirm the payment but take care not to be redirected to the
/payment/status route. For examples, close the tab before or comment
out https://github.com/odoo/odoo/blob/15.0/addons/payment_mollie/controllers/main.py#L38.
5. Go back to /shop/cart and modify the cart.
6. Wait up to 20 minutes for the "payment: post-process transactions"
cron to try to confirm the cart.
7. Check the cart's chatter: the confirmation failed because the cart's
and transaction's amounts mismatch.
Explanation: The post-processing of the transaction is responsible for
confirming the cart, but it failed to be triggered because the user did
not visit the /payment/status page. The post-processing cron takes care
of pending post-processings after 10 to 20 minutes, which is long enough
for the user to modify their cart.
Fix: Force creating a new cart as soon as the current one is paid and is
being requested by the website.
task-2995504
closesodoo/odoo#102060
X-original-commit: 5f8674621cbf5919e10e32f29b66ae171fe05993
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit removes unused imports and renames some confusing variable
names and helper texts that were changed with commit f7b8f075 when
renaming the term "acquirer" to "provider".
closesodoo/odoo#100348
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit removes code related to refunds that are not implemented in
this version of the Mercado Pago integration.
closesodoo/odoo#92848
Related: odoo/documentation#2149
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Calling `_build_url` for a test class that only inherited from
`PaymentCommon` would raise an error, as the method depends on the
`HttpCase` test class that is only inherited by `PaymentHttpCommon`.
closesodoo/odoo#95860
Related: odoo/documentation#2532
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The button should only be shown if a tokenization-capable acquirer is
enabled (or if a token already exists), but a typo made the button being
shown regardless of that (first) condition.
closesodoo/odoo#97276
X-original-commit: b301844cbdcb07b4e13186cae85257b18ca54654
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The alert block content and style for the transaction status after
payment were computed in two different places: In the dedicated
`payment.transaction_status` QWeb template, and in the
/payment/confirmation` route's controller which, for some reason, was
re-inventing the wheel instead of relying on the dedicated template.
This commit combines the slightly different behaviors in the template
and gets rid of the duplicated logic in the controller to:
- Handle the states 'draft' and 'error'.
- Always show the transaction's state message, and not only when the
transaction was in a state for which there exists no pre-defined
message (`draft` and `error`).
task-2924873
closesodoo/odoo#96348
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>
Due to an oversight, the "Save my payment details" checkbox was shown on
the inline payment form of SEPA Direct Debit acquirers, which should
never happen because the transaction is *always* tokenized with those.
With this commit, the `_is_tokenization_required` method is slightly
refactored to read the provider from the current `payment.acquirer`
record rather than from the kwargs. This conveniently fixes the issue
and prevents it from happening again elsewhere.
closesodoo/odoo#95519
X-original-commit: ebeebd87ed6d687b96dda3006b81356dfa76d0a0
Related: odoo/enterprise#29237
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The SDK of Adyen Checkout is quite large (≲ 1MB) and was always loaded
on all frontend pages before this commit, which hurt the loading
performances.
This commit restricts the loading of the SDK to pages that include one
of the payment forms (either 'checkout' or 'manage').
task-2899271
closesodoo/odoo#95121
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
The documentation page for the external API was moved elsewhere with PR
odoo/documentation#2026.
closesodoo/odoo#94488
X-original-commit: 99eb55e14782bd32c4b2281681a62eb5f3d34407
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: account_payment, sale
This doesn't change anything from a technical point of view, but it
helps to consistently assess whether a method is attached to a route or
not, only by looking at the class' skeleton.
closesodoo/odoo#91359
X-original-commit: 93de42458ed0a7df20a7bc2f2c2b106386293c78
Related: odoo/enterprise#27330
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the public user would be prevented from creating,
reading, or using payment tokens entirely. This was put in place in an
effort to homogenize the way each application interacts with tokens,
and because it was considered more logical to only create tokens when
you can see actually them afterward. This however led to an undesirable
side effect in Subscriptions where customers would pay while being
logged out, thus preventing the token from being saved and failing the
automatic renewal of the subscription.
With this commit, we enable the public user to create tokens from any
payment flow. This also means that when a token is created, its owner
will not see it until they log in. This commit also reverts 2a084c48
which was intended to hide payments acquirers from the public user if
their payment would end up being tokenized.
opw-2789340
closesodoo/odoo#90061
X-original-commit: 4e03d4b6106f10522dd5f1839a0f941ca6b202fa
Related: odoo/enterprise#26741
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, the /payment/pay page would not filter out acquirers
configured to allow tokenization when it was although required for the
payment. For example, for sales order with a subscription product (which
requires tokenization), acquirers that don't allow tokenization would be
shown to the customer if they pay from the /payment/pay page, but not if
they pay from the portal view of the SO.
This commit makes sure the sales order id is correctly propagated to the
Subscription app which then flags the payment as requiring tokenization.
closesodoo/odoo#86202
X-original-commit: 9ab7b2447f2ece46f1a25335ab76f06323f03d22
Signed-off-by: Antoine Vandevenne (anv) <anv@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 uses the `is_html_empty` util method to detect empty HTML
fields in cleaner and more resilient fashion than what was done in
808cc53bb02b0f1851a2a229bd5235a5fb944408.
closesodoo/odoo#84999
X-original-commit: 89f3aa8a979c5236b587f9690595117b52f0dd63
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Commit b6ae8a0a introduced the generic behavior of blocking the UI as
soon as a submit button is pressed in a payment form. The 3DS2 flow of
Adyen was not taken into account, resulting in the impossibility to
enter the additional details required by Adyen.
With this commit, the UI is unblocked at the right time to allow the
user to submit the additional details. Moreover, the submit button is
now hidden as soon as we don't want to show it anymore, rather than
after having submitted the additional payment details.
closesodoo/odoo#84757
X-original-commit: 97f206e0b26c83eb8bf66f7777f1ab5f2de41615
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, an empty line would be shown in the payment forms on
the card of each payment acquirer whose `pre_msg` field was not empty.
This is because displaying this HTML field in a form view and saving it
causes the value `<p><br></p>` to be written on the field, even if it
was left empty. The same issue occurred with the `pending_msg`,
`auth_msg`, `done_msg`, and `cancel_msg` fields that are shown on the
portal of some apps (Sales, Accounting...).
With this commit, the value of these fields is tested before displaying
them. If the value is `<p><br></p>`, the field is not displayed, hence
avoiding to display a blank line.
closesodoo/odoo#84755
X-original-commit: 808cc53bb02b0f1851a2a229bd5235a5fb944408
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
With commit 7b165cd5, it was incorrectly assumed that PDT notifications
sent by PayPal could not be verified with the suggested method
(dedicated to PDT notifications) because they were missing some required
parameters. The code was thus adapted to have their verification done
with the method already in place for IPN notifications, as it seemed to
do the job. It turns out that the PayPal sandbox account that was used
at that time was not properly configured, and that PayPal was then
sending IPN-like notifications instead of actual PDT notifications,
which is the reason why the swap of methods worked.
Actually, once the account is properly configured, PayPal sends
correctly populated PDT notifications that must be verified with the
method dedicated to PDT notifications, as the one dedicated to IPN
notifications stops working in that case.
With this commit, the method used to verify the origin and integrity of
PDT notifications is replaced by the one that was previously removed.
The method is however implemented in a more defensive manner to:
1. accept and process the notification without verification if the
account is not properly configured on PayPal.
2. silently discard the notification if the acquirer is not properly
configured on Odoo. We then rely on the IPN (webhook) to confirm the
transaction.
task-2744043
closesodoo/odoo#83659
X-original-commit: 7367f543498810bbdb018aa3566c7afed5684436
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, it was not possible for a Buckaroo acquirer to
accept asynchronous notifications for payment updates. This is
important because, without them, an acquirer can only rely on
synchronous notifications (i.e. redirect requests from the provider's
checkout page) which can be unreliable and do not allow receiving
status updates, should payments take a bit longer to be confirmed by the
provider.
This commit adds a webhook controller whose route can be configured in
Buckaroo Plaza (backend) to send asynchronous notifications.
task-2687586
closesodoo/odoo#82922
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Lucie Van Nieuwenhuyze <luvn@odoo.com>
Notification handling in some acquirers presents a subset of the
following issues:
1. The signature of synchronous notifications (redirect payloads) is not
checked. (Alipay, Authorize, Buckaroo, Mollie, PayU money, PayULatam)
2. When the signature check fails, we raise a ValidationError which
counts as an HTTP 200 for some providers (it's not the case if they
expect a specific string). (Adyen, Paypal, Sips, Stripe)
3. If a ValidationError is raised when processing the feedback data, it
is allowed to bubble up to the provider. (Alipay, Ogone)
The issues are respectively addressed as follows:
1. If the acquirer implements payments with redirection, make sure that
if either makes a request to the provider to validate the data or
that it verifies the signature. Verifying the origin of the request
is not enough: the payload must be checked too.
2. Instead of raising ValidationError's, raise an HTTP 403 FORBIDDEN
error if the signature check fails.
3. Wrap the call to `_handle_feedback_data` of the webhook method inside
a try/except clause to catch any ValidationError, log a warning, and
acknowledge the notification to avoid having the provider disable the
webhook because of too many failures.
task-2688139
task-2693293
closesodoo/odoo#81607
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Lucie Van Nieuwenhuyze <luvn@odoo.com>
Before this commit, users returning from PayPal to Odoo after payment
could see their session renewed, depending on their browser's
implementation of the `SameSite` cookie attribute. This prevented Odoo
from retrieving the transaction from the users' session.
This commit flags the return route of PayPal with `save_session=False`,
hence allowing all users to immediately post-process their transactions
when they return to Odoo.
closesodoo/odoo#83327
X-original-commit: 33ae5e491609c580a3aeb83568c74cd1acaae336
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, the implementation of Buckaroo's method for
computing the signature of a dataset was upper-casing data keys before
sorting them, in order for the sort to be done in a case-insensitive
manner. The issue is that, as `ord('A') < ord('_') < ord('a')`, two keys
could be incorrectly swapped if they shared the same prefix and one of
the two contained an underscore. For example, `brq_transactions` would
be appended to the signing string before `brq_transaction_type` whereas,
if the sort was based on the upper-case keys, the second would be
appended before the first.
This commit changes the computation of the signature to rely on the
lower-case keys rather than upper-case keys in order to use the same
method as Buckaroo when they compute the signature on their end.
closesodoo/odoo#83202
X-original-commit: 0112d69252a8a8396f9509e240c741fa2e261fb3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, users returning from Buckaroo to Odoo after payment
could see their session renewed, depending on their browser's
implementation of the `SameSite` cookie attribute. This prevented Odoo
from retrieving the transaction from the users' session.
This commit flags the return route of Buckaroo with
`save_session=False`, hence allowing all users to immediately
post-process their transactions when they return to Odoo.
closesodoo/odoo#82938
X-original-commit: b309d3a99f8ff4a43a21c4772c344ed3250e319f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, a toaster notification would be shown in addition to
the dedicated error div in the inline payment form when an exception is
raised while trying to archive a payment token.
closesodoo/odoo#82420
X-original-commit: ff7368a4d140a5fe7cf995d61847e81c6a7fd65e
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, users returning from Adyen to Odoo after payment
could see their session renewed, depending on their browser's
implementation of the `SameSite` cookie attribute. This prevented Odoo
from retrieving the transaction from the users' session.
This commit flags the return route of Adyen with `save_session=False`,
hence allowing all users to immediately post-process their transactions
when they return to Odoo.
While we're at it, the docstrings of the return routes of PayUmoney and
SIPS' have been updated for better clarity.
closesodoo/odoo#74763
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Before this commit, the validation flow with verification (payment of a
small amount with immediate refund) was performed with the use of
validation routes: after payment, the customer was redirected to the
validation route stored on the transaction to trigger the refund. This
implementation had an issue: if the customer never reached the
validation route, they were not refunded their validation amount. This
could happen if the customer closed the tab after paying with an
acquirer offering payments with redirection, or if the validation
payment was asynchronously confirmed through a webhook notification.
This commit gets rid of validation routes and requires acquirers to
immediately refund the validation amount when the payment is confirmed.
This way, a payment confirmation coming from a webhook can trigger the
refund too.
As the only acquirer that implements the validation with verification
flow, Authorize.net now voids validation transactions as soon as they
are authorized.
While we're at it, the logging of processing values is adapted to only
log specific rendering values if a redirect form is rendered.
task-2612977
closesodoo/odoo#74707
Related: odoo/enterprise#20060
Related: odoo/upgrade#2710
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
As validation transactions are authorized rather than captured, they are
refunded with a void request. Before this commit, a voided validation
transaction was mistakenly flagged as canceled while it should have been
confirmed.
This commit makes the distinction between a voided regular transaction
and a validation transaction.
task-2612977
closesodoo/odoo#74581
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@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>
Prior to this commit, not all operations of the Stripe webhook were
encapsulated in a try/except clause. If a `ValidationError` was raised
outside of that clause, it was returned as-is to Stripe.
This commit encapsulates the whole webhook event processing with a
try/except clause to make sure that only an empty string is returned to
Stripe, hence properly acknowledging events.
task-2612977
Commit 3d90d02 removed the integration with the Flexcheckout API but the
dedicated views were left behind, as it was not possible to remove them
in stable version.
This commit removes the unused views in master.
task-2494916
closesodoo/odoo#74505
Related: odoo/upgrade#2699
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Before this commit, the FlexCheckout API was used to process validation
operations only. It proved itself to be:
- unusable without making small payments with immediate refunds
- badly suited to PSD2 due to its Merchant Initiated Transactions (MIT)
- not worth the maintenance cost tied to its complexity given the simple
flow that it implements
- inconvenient to integrate to standard payment flows
- poorly customizable in regard to the hosted tokenization page
This commit thus removes it entirely and drops Ogone's support for
validation operations with it.
task-2494916
Before this commit, it was not possible for an acquirer to support
tokenization while not supporting validation because the acquirer would
be thought to be compatible with either flow based on the
`support_tokenization` field. This was a false assumption because some
acquirers, such as Ogone, can offer to tokenize a payment method in
payment with redirection flow while not allowing tokenizing a payment
method for future usage, without payment.
Note that this was not an issue for acquirers supporting the direct
payment flow because they could either support validation natively, or
seamlessly charge a small amount and refund it immediately to tokenize a
payment method.
This commit makes it possible for a module implementing the validation
operation to filter acquirers based on whether they support it,
regardless of their support for tokenization.
task-2494916
With commit 139dd9d, the Hosted Payment Page API of Ogone was entirely
replaced by the FlexCheckout API. This new API allows customers to
tokenize a payment method for a later use without the need of making a
purchase. However, it proved itself to be less convenient for regular
purchases as it offers less payment options than the HPP, and payments
are no longer cardholder-initiated transactions but merchant-initiated
transactions which have a higher chance of triggering an authentication
check. Furthermore, the payment flow itself is more complicated than
before.
This commit brings back the Hosted Payment Page API to work in parallel
with the FlexCheckout API and the other APIs that were left untouched.
It will be exclusively used for making online payments with a new card.
The validation flow is managed by the FlexCheckout API while the
DirectLink API manages the payment by token and offline payment flows.
task-2494916
closesodoo/odoo#72991
X-original-commit: 4fa7b772c71979f61eb098ff8d005deba834527c
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
