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>
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
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
The ZIP code is an optional field. When saving a payment method, this
generates a traceback since `partner.zip` is `False` while the field
expects a `string`.
opw-1829829
- This commit fixes crashes occuring when the expiry date for a credit card was invalid.
Instead of crashing we now warn the customer that the expiry date is invalid.
As some flows were broken, this set of fixs improve the different routes for all acquirers
See commit messages for more information
Thanks to @jpr-odoo for his first implementation and to @tde and @fgi
If the user has no Zip code, country or city, authorize refuse the payment, but Odoo doens't show any error.
The commit invite the user to log in in this case or to fill his missing information
Previous to this commit, if a user hadn't properly set up his
Authorize.net credentials, when getting a response from Authorize.net's
servers, we would expect some attributes to be in the response's body,
but this is not the case if the credentials are wrong, thus we would
have an unexpected error like "NoneType object has no attribute text"
which is only a sympton of the real error (bad credentials and no
error-checking).
This is fixed by checking if the response body contains an error
message, if it is the case we raise an UserError with the error code and
the error message (which is only shown if debug mode is activated).
OPW 788261
It seems that Authorize.net returns an 'Error' status when transactions
fail (note that it can also return an Ok status for different types of
failures).
This is incoherent with the way the authorize requests are processed,
since an Error resultCode will raise a ValidationError, rollbacking the
complete cursor transaction. This makes little sense, since there should
be a trace of the payment.transaction in the backend (preferably with an
explanation for the failure).
This fix adds an error processing step to the response handling of
authorize.net - while before, it was assumed that an 'error' result
meant an issue in communication/setup, now it is treated as an error
in payment and the payment.transaction status is set accordingly.
I've added a test for this and it was green (pinky promise), but this
particular test suite is deactivated (or perhaps only on nightly, I need
to check the nightly process with @nim-odoo).
This reverts commit fb093726d7.
In my hurry, I forgot part of this debug feature, which made it crash
because I tried to stringify a element instead of a tree
Nicolas Lempereur