Steps to reproduce:
- install payment_authorize module;
- complete a credit card payment using Authorize.net with a partner name of almost 50 characters;
- confirm the payment.
Issues:
An error message appears.
Causes:
The Authorize.net API define the max length of information.
It is possible that some information exceeds the maximum length.
(https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd)
Solutions:
Truncate information if the number of character is too large.
opw-2990762
closesodoo/odoo#101496
X-original-commit: 9da8882e0b218e95f2662a9c7f980b17b72fe7be
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@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>
The present kanban view of acquirers is not the most appealing
one. It is full of useless information (e.g. "online payment") and the
combination of provider logos makes it look "old".
After this commit, the kanban view will hopefully have a "cool" and
concise look simular to the "Apps"'s kanban view.
Task - 284171
closesodoo/odoo#98345
Related: odoo/enterprise#30585
Related: odoo/upgrade#3803
Signed-off-by: Victor Feyens (vfe) <vfe@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>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit, zombie payment tokens (= tokens linked to disabled
acquirers) could still
1) be used by internal users and
2) reactivated when the acquirer’s state changed to ‘test’ or ‘enabled’.
This is not desirable because zombie tokens should neither be used,
nor reactivated.
After this commit, all tokens related to an acquirer are unassigned
from linked documents and archived as soon as the acquirer’s state is
changed to ‘disabled’. Creating a payment with an archived token is
prohibited. In addition, archived tokens cannot be un-archived anymore.
task-2649806
closesodoo/odoo#93774
Related: odoo/enterprise#28661
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Users can now ask for a refund from Odoo for their transactions done
through Authorize.net. A refund will be triggered from Odoo when
necessary.
Only full refunds are possible.
Note that unsettled transactions will be voided as they cannot be
refunded.
Task - 2678757
closesodoo/odoo#92279
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>
When setting up an acquirer there is sensible information to
be supplied.
There was inconsistency on what was obfuscated and what not.
Now sensible information as passwords and keys is obfuscated
and public information as names and addresses is visible.
Task - 2694139
closesodoo/odoo#81211
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>
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
Step to reproduce:
- Install website_sale module
- Go to the shop
- Add a product to the cart and proceed to checkout
- Click on Customize and activate `Accept Terms & Conditions`
- Deactivate the `Accept Terms & Conditions` or click on a
payment method.
Issue:
UI freeze.
Solution:
Freeze ui only when clicking on pay button.
Unfreeze only if payment process fails (or when displaying an error).
Revert of https://github.com/odoo/odoo/commit/41b91e12eb80cee08e3a25bcc6546ef34937d8cf and adapt it correctly
opw-2702798
closesodoo/odoo#83155
X-original-commit: b6ae8a0a91c58ce503c98ca2a66a4d125907dac1
Related: odoo/enterprise#23639
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
American Express CVC code are 4-digit numbers
Current Behaviour:
Authorize currently only accept numbers up to 999.
Behaviour after PR:
Authorize accept number up to 9999
opw-2727511
closesodoo/odoo#82770
X-original-commit: 9f7821655a2b632f8e36569c438df358c0d23d02
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
createTransactionRequests can return responses like this:
{'messages': {'message': [{'code': 'E00027',
'text': 'The transaction was unsuccessful.'}],
'resultCode': 'Error'},
'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
'accountNumber': 'XXXXXXXX',
'accountType': 'eCheck',
'authCode': '',
'avsResultCode': 'P',
'cavvResultCode': '',
'cvvResultCode': '',
'errors': [{'errorCode': '33',
'errorText': 'Bill To Address is '
'required.'},
{'errorCode': '33',
'errorText': 'Bill To State/Province is '
'required.'}],
'refTransID': '',
'responseCode': '3',
'testRequest': '0',
'transHash': '',
'transHashSha2': 'xxx',
'transId': '0'}}
_make_request() threw out the detailed errors ("Bill To Address is
required" and "Bill to State/Province is required") and only returned:
{
'err_code': 'E00027',
'err_msg': 'The transaction was unsuccessful.'
}
which results in the following vague error on an SO:
The transaction with reference SO1111/1111111 for US$ 100.00
encountered an error (Authorize.net). Error: Authorize.Net: Received
data with status code "3" and error code "The transaction was
unsuccessful."
This commit extracts the transaction errors and appends them to
'err_msg'. After this commit the above response results in this chatter:
The transaction with reference SO1111/1111111 for $ 100.00
encountered an error (Authorize.net). Error: Authorize.Net: Received
data with status code "3" and error code "The transaction was
unsuccessful. Bill To Address is required. Bill To State/Province is
required."
Ideally the error handling logic would be rewritten so that
_make_request() doesn't handle specific errors like this. But changing
it is too high risk in a stable release.
opw-2718318
closesodoo/odoo#82443
X-original-commit: c7b292f7b86679b11527a68093ed70b36dc2fd1a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
A company name >50 chars leads to:
Authorize.Net: Received data with status code "3" and error code "The
'AnetApi/xml/v1/schema/AnetApiSchema.xsd:company' element is invalid -
The value XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX is
invalid according to its datatype 'String' - The actual length is
greater than the MaxLength value."
This limits the company name to the specified 50 chars [1][2]. Cutting
off the company name should be fine for the same reasons as outlined in
64b86f36264c2e655681c7b6bed69e89891107bf.
[1] https://developer.authorize.net/api/reference/index.html#payment-transactions-charge-a-credit-card
[2] https://api.authorize.net/xml/v1/schema/AnetApiSchema.xsd
opw-2725246
closesodoo/odoo#82171
X-original-commit: 412e50290524ed0edc0317b141a296a883b173d3
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
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>
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>
- This replaces the name of `refund_amount` to `amount_to_refund`
for a variable that was renamed elsewhere, which caused a traceback.
- Adyen and authorized `_send_refund_request` now have their return,
as their parent.
- When a refund is initiated from Adyen, it's now easier to change
the merchant reference, thus, we can't count on it anymore to get
the source transaction.
- Fix the automatic refund for authorize.net with the manual capture
task-2634184
closesodoo/odoo#77916
X-original-commit: 747dbf44f37407fd415af645dac652199ac7fa6b
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
It's possible for a payment.acquirer to charge tokens when it's
disabled via the subscription app (_cron_recurring_create_invoice()).
Before this patch it would use the production endpoint. It's
unexpected and can cause accidental charges in a database meant for
testing.
opw-2637659
closesodoo/odoo#76820
X-original-commit: 7316413261ca8294ceffa212d6b5079b6e35daf6
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
Before this commit, it was not possible to refund a payment from Odoo.
Users had to go through the payment acquirer's backend and update the
payment accordingly in Odoo.
With this commit, refunds are made available in Odoo directly from the
payment form, for acquirers that support them. Acquirer can either only
support full refunds or also support partial refunds.
As of now, the only acquirer allowing refunds is Adyen, with partial
refund support.
task-2527891
closesodoo/odoo#70881
Related: odoo/upgrade#2689
Related: odoo/enterprise#19829
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.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 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>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
_prepare_transaction_request() introduced in
35a6c1867d8edc9b58c002a6ff6a63c35a0fc708 is only used for
'authOnlyTransaction' and 'authCaptureTransaction' transaction
types. capture(), void() and refund() still build their own request
parameters. Make this clearer by renaming _prepare_transaction_request()
to _prepare_authorization_transaction_request().
closesodoo/odoo#73373
X-original-commit: da00ae85f69cfde217d09b93113f8b7821aabff2
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This makes it possible to patch only _prepare_transaction_request in
case parameters need to be added.
closesodoo/odoo#73215
X-original-commit: 35a6c1867d8edc9b58c002a6ff6a63c35a0fc708
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@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>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.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>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@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>
Steps:
- Install website_sale and payment_authorize
- Set up a tunnel (e.g. ngrok)
- Log in to Authorize.Net backend
- Go to Account > Response/Receipt URLs > Add Url
- Enter the tunnel URL
- In Odoo, go to Website > Configuration > eCommerce > Payment Acquirers
- Edit "Authorize.Net"
- Credentials tab:
- State: Test Mode
- API Login Id, Transaction and Signature key
- Save, then Generate Client Key
- Configuration tab:
- Payment Flow: Payment from Odoo
- Stop the server
- Replace https://github.com/odoo/odoo/blob/1b9b99dc2643910c1412b564affccf02ba1e55d9/addons/payment_authorize/models/authorize_request.py#L46 with `resp = {'messages': {'resultCode': 'Error', 'message': [{'code': 'E00027', 'text': 'An error occurred during processing. Call Merchant Service Provider.'}]}}`
- Restart the server
- Go to "Website" > "Go to Website" > Shop
- Add a product to the basket
- Check out the basket
- Choose "Credit Card (powered by Authorize) Test Mode"
- Pay Now
- Enter any card data (e.g. 4111 1111 1111 1111 - 01/22 - 900)
Bug:
When the Pay Now process is done, the customer is redirected to
`/shop?error=invalid_token_id`. No errors are shown.
Explanation:
The patch simulates an error from Authorize.Net happening during their
process. Using the special card numbers won't trigger the wanted
behavior.
When getting an error from Authorize.net, a `UserError` is raised. This
error is then caught in the controller to return a formatted message.
However, returning a dict in this part of the code embeds it inside
`{'result': [...]}`. The error message is, thus, not blocking the form's
redirection and the user gets redirected to the form action, i.e.
`/shop/payment/token`. This route requires `pm_id`, but, in this
scenario, it's an empty string. This leads to another redirection to
`/shop/?error=invalid_token_id` as seen here:
https://github.com/odoo/odoo/blob/1b9b99dc2643910c1412b564affccf02ba1e55d9/addons/website_sale/controllers/main.py#L938-L941
Letting the error bubble up forces the backend to return a blocking
error response. This makes the fronted display the Authorize.Net error
underneath the provider selection, and prevents it from redirecting.
opw:2419260
closesodoo/odoo#64482
X-original-commit: 2636b9f5059808b443be67b06fca129cf9d3a913
Signed-off-by: backspac <backspac@users.noreply.github.com>
We can have payment.transaction references of >20 characters. This
happens automatically if you have long sale.{order,subscription}
sequences (especially through website_payment because it adds multiple
suffixes, e.g. SO2020/1234567 could turn into
SO2020/1234567-12-1-1-1). We POST the full reference via the
x_invoice_num variable. Unfortunately Authorize specifies a maximum
length of 20 for this field [1]. So when Authorize POSTs back to
/payment/authorize/return it only specifies the first 20 characters in
x_invoice_num. E.g. when POSTing
{
...
'x_invoice_num': 'SO2020/1234567-12-1-1-1',
...
}
we receive back in /payment/authorize/return:
{
...
'x_invoice_num': 'SO2020/1234567-12-1-',
...
}
This causes _authorize_form_get_tx_from_data() to not find the
transaction which results in a ValidationError.
To fix this also pass the reference in the x_description field. It has
a more generous 255 character limit [1]. Then search using both.
We can't get rid of x_invoice_num entirely because we cannot assume
the payment_authorize.authorize_form will be updated (even more so
because it's a noupdate="1" template). By still using it in
_authorize_form_get_tx_from_data() we ensure that everything keeps
working regardless of whether or not x_description is included in the
template.
[1] p39 in https://www.authorize.net/content/dam/anet-redesign/documents/AIM_guide.pdf
opw-2373433
closesodoo/odoo#61449
X-original-commit: 3a220d3ad2999a21d54924940574ba96a9c07154
Signed-off-by: jorenvo <jorenvo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Thomas Lefebvre (thle)