Before this revision, in the ecommerce,
a new payment transaction was created only
when the transaction reference was different than
the order number, meaning that the transaction id
in the user session no longer refers to the current order,
that the user created a new order which has nothing
to do with the transaction he has in his session
variable `sale_transaction_id`
This made sense when the transaction reference
strictly matched the order number, but,
since f89e8f9df2,
this is possible that a payment transaction reference
number no longer strictly matches its order number,
as the transaction reference can contain `-1`, `-2`
at the end of its reference, meaning there was
already another transaction existing with the sale
order number as reference. But the transaction
is still about this order.
Therefore, from this revision, the condition on
which a new transaction has to be created
should no longer be based on the transaction
reference, but to which `sale_order_id` the transaction belongs.
In addition, we add two more conditions for which a new transaction
should be created:
- The transaction has been cancelled or in error
- The acquirer has changed.
For the second case, this is to handle a corner case:
- The user selects one payment acquirer (Ogone), then click
on "Pay now", and is therefore redirected to the payment provider website (Ogone)
- Then, the user opens a new browser tab on the ecommerce, on his cart,
choose another payment provider (Paypal), then click "Pay now" and is
redirected to this second payment provider website (Paypal),
- Then, the user comes back on the first tab, on which he is on the first
provider website (ogone), and pays/validate the payment
- Then, we receive the payment feedback (either from the user/DPN, either from
the server to server call/IPN)
Before this revision, this use case would have lead to the feedback from the first
provider (`/payment/ogone/accept`) while the transaction is set with the second
payment provider (`Paypal`), therefore breaking the payment validation.
Creating a new transaction when the user changes of payment provider solves this issue.
He will nevertheless be able to pay twice, on each provider, but it was
already the case before.
opw-659294
The computed fees can depend on the country.
There was a typo about it:
there is no `country_id` field on the `payment.transaction` model,
it's `partner_country_id`.
Therefore, the computed fees according to the country
were not always correctly computed.
e.g. for Paypal, where the domestic fees
are lower than the international fees, it always
computed the fees as international.
opw-651778
Christophe Simonis