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>
Need to check and mark legit uses of HTML as Markup. Also fix some
title formattings which are not great (mostly around translations) and
de-escape titles which don't need to be escaped anymore.
This commit brings back the possibility to pass invoice ids in payment
links, a feature that was lost with commit 573ed74c. If such an id is
present in the payment link URL, the transaction that is created must
have a reference starting with the name of the invoice, and must be
linked to it.
task-2494916
closesodoo/odoo#72992
X-original-commit: 6c13a361400332955cdf5ac5a14bd1970b4f66ef
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Issue
Use Safari (or equivalent) browser
- Install e-commerce
- Go to Website -> Configuration -> Payment Acquirers
- Activate Ingenico in test mode
(write aaa in required fields)
- Go to shop, and add product to card
- Go to checkout
- Select Ingenico payment mode
- Click on Pay button
- When on the ingenico page, press back
The page is blocked and the button is disabled.
Cause
When clicking on Pay button, the page is locked and
the button is disabled.
With Chrome, when coming back to previous page,
this one is regenerated and therefore adapt the button.
In Safari, it is not the case.
Solution
On `pageshow` event, if event have `persisted` attribute set to
to true, meaning using cache, then reload page.
Fixes https://github.com/odoo/odoo/issues/69453
opw-2510281
closesodoo/odoo#70906
X-original-commit: c89224940bcc59aab4bddefa95b2b0ef7713e02f
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
`_(xyz)` will wrap them in an underscore.js object, which when used in
a string context will just return the string. So it's basically a
no-op, but it certainly doesn't translate the terms.
closesodoo/odoo#70476
X-original-commit: 92352ed2b5524c97b0aeeba3193c6a8d93ed82a1
Related: odoo/enterprise#18172
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
Steps:
- Install account,payment
- Go to Invoicing
- Create an invoice
- Click Actions > Generate a Payment Link
- Follow the generated link
- Pay
Bug:
The transaction is not linked to the sale order in the link table
`account_invoice_transaction_rel`
Explanation:
This fix is broadly mimicking the behavior of the sales module regarding
the link of an order to a transaction, adding `invoice_id`s where they
are needed throughout the payment process in order to link the
transaction to the invoice.
opw:2451534
closesodoo/odoo#67296
X-original-commit: 7c6d06fa5858f79f3b22cdeaf74cdc26a642742f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Before this commit payment tokens had no name for Test Payment Acquirer
After this commit tokens generated by Test Payment Acquirer have a name
that combines the last 4 digits of the card number and the card account
holder name
https://github.com/odoo/odoo/issues/50965closesodoo/odoo#61848
X-original-commit: e20f0650acbd1a7a918375a70ec5c89606523a7b
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
STEPS:
* install website_sale
* setup few delivery options
* setup online payment (e.g. paypal)
* at website add products to cart and proceed to checkout page
* slow down internet speed
* click "Pay now"
BEFORE: while it's loading, you can change delivery option. So, you have SO
changed, while in payment page you see old total amount
AFTER: it's not possible to change delivery options through UI
Note that it is not possible to pay less that what you should at anyway.
opw-2324543
closesodoo/odoo#61723
X-original-commit: eb3ed89f8440050fc32f9a7b29fb2b6ab8fd6b59
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Co-authored-by: Romain Derie <rde@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>
Issue
- Install "eCommerce" and "Inventoy"
- Activate "Fedex" delivery connector in settings
- Publish "Free Delivery" and "Fedex US" delivery method
- Put the "FedEx" one above the "Free Delivery"
- Go to shop and add an item to cart
- Set an adress with no ZIP code and checkout
- Select a payment methode and pay
Order is generated without selecting a delivery method
Same behavior happend when using only "Fedex" as delivery
method.
Cause
The flow make the `payment.payment_form` trigger start after
`website_sale_delivery.checkout` JS module.
In 'start' function of `payment.payment_form`, the `disabled`
attribut is removed from button if no checkbox_cgv is present
and therefore break the `disabling` managemet since
`disabledReasons` payButton data are not sync anymore.
Solution
Remove 'disabled' attribut only if has `disabledReasons` data on
payButton (checkbox_cgv feature alter `disabledReasons`).
opw-2355407
opw-2357605
closesodoo/odoo#60359
X-original-commit: 04e589e80b3ef48640f275cb20d31c17c2126c69
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Steps to reproduce:
- Go to the website shop
- Add a product in the cart
- Add your address and click on checkout
- On the checkout, enable Terms & conditions
Bug:
The button was always enabled even if the check box with the terms & conditions were not
checked.
opw:2313437
closesodoo/odoo#55821
X-original-commit: 0415da51960819ec9c989e15a9229bd6d583ba1b
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Go to Accounting / Customers / Invoices
- Pick any invoice not paid
- Action: Generate a Payment Link
- Open the link
- Refresh the page having Javascript disabled
- Click the Pay Now button
Traceback
Cause
If JS is not loaded, the values in the form fields are
not bound as expected.
It can also happen with slow connections and fast click
on the button at the loading. Before the JS is entirely
loaded (as it is lazy-loaded).
Solution
Button disabled by default, wait the page to be loaded
and then activate the button
OPW-2255760
closesodoo/odoo#54128
X-original-commit: 0e7071f249e69c5cca519ec66120530eb0f97153
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
From the PoV of the customer, there is no difference between an
authorized payment and a captured payment; they should get redirected to
the confirmation page in both cases.
closesodoo/odoo#42780
X-original-commit: 452676737dd657a5d31a88fa89cc136cbe69b96a
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Issue
- Install e-commerce
- Add stripe as payment acquirer
- Go in website > shop
- Add something in your cart and process checkout
- In developer tools > network set online to slow 3g
- Spam the pay now button
- Go in Website > Configuration > Ecommerce > Payment Transactions
Multiple transactions have been created for your order.
Cause
The pay now button doesn't stay disabled during the payment process.
Solution
Disable the button and enable it only when the process is done.
OPW-2148899
closesodoo/odoo#41910
X-original-commit: 76a0e4fea0d9a15b3d193e00dd473c4488d18640
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
before this commit it shows error dialog when rpc fail
after this commit, error dialog will not be shown to user,
instead we have already shown error in payment form
task- 2045189
closesodoo/odoo#39571
X-original-commit: e3644c6b59271c521abc151d3c533331836fdc90
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Avoid trailing space:
In translation content, these tends to be skipped during translation,
making the message inconsistent. There is already a translation for
the term without the space so can reuse it.
Merge "setup"
Use the same writing to avoid having two similar messages
Remove unnecessary comma
Merge PayPal and Paypal
Courtesy of Primesh on Transifex
closesodoo/odoo#38348
X-original-commit: c1fb136cc684eba0cdeec302f27268ccda7fa5d2
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
before this commit:
the icon was not there in proper position
after this commit:
the icon is at proper position
task- 2074108
closesodoo/odoo#37352
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
- allow acquirers to arbitrarily include info about the tx in the
processing page
- pending is now a valid state that could require customer action in the
payment processing page - don't blindly redirect to the return url of
another tx if a pending transaction is there
This latest change might mean that customers with many tx attempts might
have a sub-par experience as they may need to click manually on the
redirect url of a successful tx while before they were redirected
immediately.
PURPOSE
Test frontend and UI tools of eLearning.
SPECIFICATIONS
Recent commit 5193f0d010 introduced a tool method to parse errors and ease
their management. A variable typo was done by mistake, fixed in this commit.
LINKS
Task ID 1937768
closesodoo/odoo#36085
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The purpose of this commit is to expose SEPA Direct Debit acquirer to
the Odoo community edition. The dedicated module, though, is restricted
to the enterprise edition.
Minor changes in following modules:
- base: added ir.module.module record
- payment:
- added data to expose the new payment acquirer.
- added 'to_buy' field to track whether the payment acquirer is
restricted to enterprise users.
- allow multi word payment acquirer name. It was breaking on the first
underscore.
task-1870363
closesodoo/odoo#26427
The terminology of the boolean_button is translated with
_t(opt_terms.string_true)
which can work only if the variable content is already present in the
translation map.
This commit adds js files that do nothing but add the terms in the
translation map. This way it will be exported by babel js export and
the translation will be loaded by the web client
Closesodoo/odoo#34774closesodoo/odoo#34954
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
* payment, im_livechat
Inline scripts using `odoo.define` cannot work anymore as the boot.js
file loading will be deferred.
Most of features which used an inline script should probably be entirely
refactored. This commit focuses on removing the inline scripts
with a minimal diff (or at least tried to).
Note: for the website livechat, the inline script was kept as it seems
to be a longer refactoring to get rid of it (even though it is clearly
possible). The inline script was however adapted to make sure it works
with lazy loaded JS in the frontend.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
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 -_-
- treat s2s transactions as such
- don't filter out tokens saved on acquirers that are not set for full
s2s mode, as tokens might get created through a form and still be usable
- detect the submit event as well as the click on the 'Pay Now' button
to avoid completely wrecking the payment flow by pressing the return key
- correct start override in JS should chain promises
When paying an eCommerce order with an acquirer which doesn't
redirect (payment_flow: s2s) the "Pay Now" button is correctly
disabled after clicking it. This prevents a user from clicking it
multiple times and being charged multiple times.
When paying with an existing payment token however the button was not
disabled and the user gets no feedback his request is being
processed. Charging an existing payment token takes a while (~5
seconds with Authorize) and so it's possible users will hit the button
multiple times.
This disables the button when reusing an existing payment
token. Additionally it now uses the correct font awesome icon (fa-lock
instead of fa-plus-circle).
opw-1981064
closesodoo/odoo#33196
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Antoine Vandevenne (anv)