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>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
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
- Activate Invoice Online Payment
- Set Authorize to pay through Odoo (S2S)
- Create a new customer (do not give portal access)
- Create invoice -> send to them
- Open invoice in incognito mode
- Try to pay invoice online with Authorize
An error is raised:
The transaction cannot be processed because some contact details are
missing or invalid: City, Country. Please sign in to complete your
profile.If you don't have any account, please ask your salesperson to
update your profile.
The error is quite confusing, and the user is missing the main point: he
needs to sign in.
There is no reason to display the fact that contact details are missing
for a public user, so this part is now shown only if the user is logged
in.
opw-1981003
closesodoo/odoo#33116
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In the e-comerce, when the user try to add a new card in this payment
methods.
Before this commit, to validate the card, besides of the creation of the
payment token, an amount of $1.5 id charged and refunded.
During the refunded an error was raised. This error arrives because:
payments made via Authorize.net are settled and allowed to be refunded
only on the next day.
https://account.authorize.net/help/Miscellaneous/FAQ/Frequently_Asked_Questions.htm#Refund
<quote>The original transaction that you wish to refund must have a status of Settled Successfully.
You cannot issue refunds against unsettled, voided, declined or errored transactions.</quote>
This means, we can't refund directly after the payment.
Now, we only create the payment token. As Authorize.net verify the card
during the creation of the token, a new verification is not needed.
OPW-1927754
closesodoo/odoo#30905
This commit aims to improve the user experience when using payment acquirers. There currently are no error feedback with some acquirers, which leaves the user wondering what is going on and what is the real status of its payment.
In some cases, the user is currently being redirected to the home page even though the payment has failed. We want to make it more obvious to the user that something unexpected has happened by redirecting to an intermediate page that will provide good feedback on payments status.
Another goal of this commit is to order acquirers by sequence instead of by flow and to select the first acquirer by default. This feature was already implmented in commit fe294fd43e521bd2d339e962f43acf46c3d4cb97, some UI adaptations were needed though.
Related to task #36680Closes#26958
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
- When registering a payment token, validating it using a payment of a small amount (~1.50€) followed by a refund allows ensuring
that the payment method is valid (i.e. checksumming the card number simple ensure the number is valid but not that the card exists).
This commit introduces a generic approach that must be implemented for each acquirer that has tokenization support.
This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
- Introducing a new payment form that handles payment, deletion and adding payment method (only for server2server for the moment).
- On /my/payment_method, changed strings 'Payment Acquirers' to 'Payment Methods' which is more clear.
- Stripe can now be used to pay subscriptions.
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
This commit add s2s communication to the Authorize.net payment
provider, allowing the user to:
- Create a payment token
- Charge a payment token
- Authorize/capture transactions
