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>
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>
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Set the transaction to the state 'error' when Authorize.net responds
with that status, as it will display a message to the customer to detail
the problem.
opw-2231276
X-original-commit: 005607fce4a22394a9f67cc4eaa52f8bf89780f0
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>
It is possible to define required fields from the Authorize.net backend
without which no customer profile can be created. These fields include
data that Odoo sometimes does not have at all (fax number, anyone?);
however including the phone number is a meaningful option.
Before this commit, if the 'phone number' was required by the
Authorize.net configuration and was correctly set in Odoo, this still
did not work because we did not include the phone number with the
customer profile creation request payload.
We do now.
opw-2215332
closesodoo/odoo#48420
X-original-commit: 034c04efa4ccecd40f657eae97ef2b04934d570c
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
- Select 'capture manually' in Authorize.net Payment acquirer
- Do an online transaction
- Click on the Capture button at Payment transaction windows.
An error message is returned:
The element 'transactionRequest' in namespace
'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element
'amount' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List
of possible elements expected: 'splitTenderId, order, lineItems...'.
This because the keys `amount` and `refTransId` are inverted in
`createTransactionRequest`:
https://developer.authorize.net/api/reference/index.html#payment-transactions-capture-a-previously-authorized-amount
A simple fix is to swtich them. Indeed, the Odoo 13.0 requirements is
Python 3.6+, in which the keys order at iteration is the insertion
order. Although this was officially part of the specification in 3.7,
the change is already available in 3.6.
Closes#45891
opw-2201667
closesodoo/odoo#46206
X-original-commit: ae3885295795f8c150bd40af266004016fd300c5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
We cannot assume reading the value of a monetary field has the
decimals specified by the currency in decimal_places.
Right after creating a record with a monetary field it may have a
different amount of decimals.
To reproduce this:
>>> tx = env['payment.transaction'].create({
'amount': 10.87,
'acquirer_id': env['payment.acquirer'].search([], limit=1).id,
'currency_id': env.ref('base.USD').id,
'reference': 'test'
})
>>> tx.id
130
>>> tx.amount
10.870000000000001
<Restart odoo>
>>> env['payment.transaction'].browse(130).amount
10.87
Authorize requires us to send a correctly rounded amount. The
following response is returned when sending 10.870000000000001:
{'messages': {'message': [{'code': 'E00027',
'text': 'The transaction was unsuccessful.'}],
'resultCode': 'Error'},
'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
'accountNumber': '',
'accountType': '',
'authCode': '',
'avsResultCode': 'P',
'cavvResultCode': '',
'cvvResultCode': '',
'errors': [{'errorCode': '5',
'errorText': 'A valid amount is '
'required.'}],
'refTransID': '',
'responseCode': '3',
'testRequest': '0',
'transHash': '',
'transHashSha2': '',
'transId': '0'}}
To work around the issue always round when we read amount.
Lower level solutions were considered in #45248 but for now we'll
stick with this higher level and lower risk patch.
opw-2188889
closesodoo/odoo#45362
X-original-commit: 7485927f0eb152086efcaaf4a30260e503267c41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Makes debugging possible without having to run the db locally and
manually adding _loggers everywhere.
Parts of the error are logged already, leading to messages like:
...payment_authorize.models.payment: The transaction was unsuccessful
Unfortunately they don't show the reason. The entire response is
something like:
{'messages': {'message': [{'code': 'E00027',
'text': 'The transaction was unsuccessful.'}],
'resultCode': 'Error'},
'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
'accountNumber': '',
'accountType': '',
'authCode': '',
'avsResultCode': 'P',
'cavvResultCode': '',
'cvvResultCode': '',
'errors': [{'errorCode': '5',
'errorText': 'A valid amount is '
'required.'}],
'refTransID': '',
'responseCode': '3',
'testRequest': '0',
'transHash': '',
'transHashSha2': '',
'transId': '0'}}
Since we log the full request above, let's also log the full response.
PS. this was present before but was lost with 26f3d8465d.
opw-2188889
closesodoo/odoo#45259
X-original-commit: d269bba3b9f4f4fa567a2a7084396bdf08422fa4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fine-tunning of 937b5c076e7175bec664ed0cf4b77505e342f1e2
Have a multiwebsite setup
have a payment installed for one of the two websites
Make an order on that website and try to pay
Before this commit, the transaction doesn't come back to odoo's
payment success controller
This was because the return url was set to the web base url ICP
After this commit, the payment success page is opened as we took
the request's url as the return url
opw-2080352
closesodoo/odoo#39643
X-original-commit: a9fb15b33fd041ee420581a5ba450017db06e0c7
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.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
- convert XML format request to JSON
- remove refund method from the request, as there is no use of it,
we will never validate card as authorize.net validate card by itself,
so there is no case for the refund
- verify token while creating it
- make verify validity field invisible in case of authorize
task- 2025821
This commit extends the changes introduced by 88de93114 to adapt
Odoo payment flows to the switch in transaction signature done
by Authorize.net.
The initial fix was not sufficient for flows that mixed redirection
payment flows and server-to-server flows (e.g. paying a quote with a
card that gets saved then using the token to pay for a subscription).
The problem comes from the fact that the server-to-server API uses
the API Transaction Key and API Login ID as credentials to authenticate
requests; there is no need for a signature since this data is never
publicly exposed on the website and a MITM is mitigated by the fact
that it would need to be done between the Odoo server and the
Authorize.net servers (both of which use https in a normal deployment)
which is admitedly more complex than doing a MITM on a Starbucks wifi.
On the other hand, the 'redirection' flow will include all transaction
parameters as inputs in an html form, therefore the signature is
required to ensure that the values have not been modified by a website
user or a mitm.
Since both flows can coexist on the same configuration, we cannot use
the same field depending on the payment flow configuration - we need
both fields to be stored for the provider.
This commit therefore has to introduce new fields on payment.acquirer
record that can store the signature key for authorize in addition to the
usual authorize fields. Instead of adding a new module, this commit uses
non-stored computed fields that will generate System Parameters entries
for any acquirer of the 'authorize' kind when set through the interface.
closesodoo/odoo#34670
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
https://docs.python.org/3/library/stdtypes.html#truth
By default, an object is considered true unless
its class defines either a __bool__() method that returns False
or a __len__() method that returns zero
Since etree elements are iterator, they define a len function.
However it turns out that customerProfileId has always no children.
So bool(find(x)) is always False; the intended meaning was find(x) is None.
opw 1999427
closesodoo/odoo#34922
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The callback will usually check the transaction's state during
its execution, hence it should be executed after the state change
closesodoo/odoo#34666
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
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'`
When transaction is approved, if for any reason the `customerProfileId`
is missing from the response, the transaction is aborted.
It should succeed even if we cannot create a customer profile.
opw-1998505
closesodoo/odoo#33501
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
opw-1920083
Before this commit, an error arrived when creating a customer profile
without email.
Now, if the email don't exists we send an empty string to Authorize.
closesodoo/odoo#30075
When creating a customer profile in Authorize.Net we specify a field
merchantCustomerId that is composed of:
ODOO-{partner-id}-{8-random-characters}
But the limit of this field is of 20 characters:
https://developer.authorize.net/api/reference/index.html#payment-transactions
So if we have 1 million partner, we may have eg. a partner 1000005 that
would result in an ID `ODOO-1000005-af123c5b` that is too long and
results in an error.
With this changeset, the generated ID is truncated to 20 characters so
this should theorically be alright for up to 9.99*10^15 partners (the
postgres limit for an integer is 2.15*10^9 so this should be safe
enough).
opw-1962422
closes#32423
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
`firstName` and `lastName` should be filled in for Australia, but the
implementation is not correct since:
- it assumes that the name is first name + last name, which is not the
case in all countries (e.g. France)
- it doesn't take into account that the name could be a company name
This reverts commit 26974d4e5f.
for the payment processor wespac there are required fields we do not send.
required:
•Card Number
•Expiration Date
•Amount
•First Name
•Last Name
•Address
•City
•State/Province**
•Zip Code (Postal Code/Postcode)**
•Country
•Email
** These fields are optional if the billing address is not in the U.S. or Canada. If the address is in the U.S. or Canada, the two-digit State/Province code must be provided, along with the Zip/Postal Code.
According to Authorize.net documentation, the state code should only be
used for United States. For the other countries, use the state name
instead.
opw-1854278
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
- Create a SO of 56.16
- Send the payment link to the customer
At payment, the transaction is refused by Authorize because of an
invalid amount.
When looking closely, the data sent to Authorize contains the amount
56.160000000001. This is due to the float representation. To avoid this,
we use `float_repr` instead of `str`.
opw-1832468
