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
Christophe Simonis