Skip to content
Snippets Groups Projects
Commit cb9d7982 authored by Denis Ledoux's avatar Denis Ledoux
Browse files

[FIX] payment, website_sale: condition to recreate a payment transaction

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 f89e8f9d,
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
parent b4949f75
No related branches found
No related tags found
No related merge requests found
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment