Before this commit, it was not possible to partially capture a
transaction from Odoo, and doing so in the provider backend would often
result in a full capture in Odoo when capture was supported.
With this commit, partial captures are made available in Odoo directly
from the sales order or invoice, for providers that support them.
Provider can either only support full capture or also support partial
ones. It also optionally managed the automatic void of the remaining
amount at the user request when multiple captures are supported by the
provider.
As of now, the only acquirer allowing partial capture is Adyen.
task-2728768
closesodoo/odoo#87251
Related: odoo/enterprise#35205
Related: odoo/documentation#2063
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some providers require additional allowed states due to their refund or
transaction process justifying it. Until now, these extra states were
specified in the `payment` module, which was not ideal as it allowed
every provider in every flow to accept these additional states.
With this commit, additional states are now specified only in the
coresponding flow of a provider that requires them.
task-2869678
closesodoo/odoo#107110
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
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>
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>
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>
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>
- 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>
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>
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>
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>
Demesmaeker