The maximum length for nameOnAccount is 22 characters [1]. Entering a
longer name results in an unclear error message:
Server Error
We are not able to process your payment.
E_WC_26: Please provide valid account holder name.
A maxlength="22" on the input was considered as well, but it would be
confusing for users and bank transactions with the first 22 characters
should be accepted.
opw-2688384
[1] https://developer.authorize.net/api/reference/features/acceptjs.htmlclosesodoo/odoo#79950
X-original-commit: 64b86f36264c2e655681c7b6bed69e89891107bf
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: jorenvo <jov@odoo.com>
Before 660dc0ebaf it was possible to use Authorize to pay via your bank
account using the "Redirection to payment acquirer" option. Since the
refactor removed the redirect it was no longer possible. This commit
reintroduces that feature.
It does so by adding new form elements that accept bank account
information. Additionally it reintroduces the `billTo` and `customer`
parameters that Authorize requires when processing ACH payments.
task-2628318
closesodoo/odoo#75289
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
This commit also drops the payment with redirection flow in favor of
the direct payment flow only, while preserving the currently used APIs.
See the merge commit for more details.
task-2333030
Co-authored-by: Adrien Horgnies <aho@odoo.com>
Closing the Authorize.net popup with the little "x" doesn't call the
responseHandler. Looking at the documentation (and source) of
AcceptUI.js it seems there's no clean way to detect this.
Because of this the "Pay & Confirm" button remains disabled, requiring
the user to refresh the page.
To solve this don't disable the button at all. Presumably it was added
to avoid issues when spamming the button with clicks on a slow
connection. But simulating this with a slow connection doesn't cause
any issues.
When AcceptJS is not yet loaded it's loaded with web.ajax.loadJS(). It
correctly handles parallel calls before loading is finished and
returns the same promise. AcceptJS correctly ignores subsequent click
events on the button, because it immediately blocks all clicks on the
body (and grays it out).
Using a MutationObserver was also considered but this approach is much
less messy.
opw-2367166
closesodoo/odoo#60870
X-original-commit: 63f759b63284efc5fb9f5dc7dfbe4e2aed982ad0
Signed-off-by: jorenvo <jorenvo@users.noreply.github.com>
Without this you have to overwrite the entire function.
closesodoo/odoo#57696
X-original-commit: c2e980c3798c3cf75e4f96b71c7bc81dbad6b78c
Signed-off-by: jorenvo <jorenvo@users.noreply.github.com>
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>
Replace website_published and environment by a generic state on
payment.acquirer
Payment acquirers aren't enabled by default. When setting their state to 'enabled' or 'test', it is verified the required fields for the provider are set.
add accept js of authorize.net to make s2s flow pci compliance
after clicking on pay now button, one popup display with card inputs
popup is provided by a authorize with all validation facilities
After submitting details, payment flow is
- get the temp token information from authorize
- create a token with that temp token information in odoo
- make a request to authorize for charge
- after successful request, payment will be charged for that card
task- 2025821
Joren Van Onder