Describe the bug
There can be common edge cases when this fails. Let's take an iDeal payment as an example:
You start the payment, an offer is created, go back and open the app again, a new offer is created, as soon as you finish the payment the first offer is cancelled and an offer_closed notification is sent with X psp reference. For the payment you get an Authorisation notification with Y psp reference. If you are not lucky then the offer_closed notification is going to be the "last" notification for the order and then the psp reference won't match therefore the refund cannot be done.
To Reproduce
Steps to reproduce the behavior:
You start the payment, an offer is created.
Go back and open the app again, a new offer is created, as soon as you finish the payment the first offer is cancelled and an offer_closed notification is sent with X psp reference.
For the payment you get an Authorisation notification with Y psp reference.
Expected behavior
It would be better to store the original pspreference for the order when the async notification from our server or the sync authorisation response from the API is processed.
cyattilakiss
commented
4 years ago
Describe the bug There can be common edge cases when this fails. Let's take an iDeal payment as an example: You start the payment, an offer is created, go back and open the app again, a new offer is created, as soon as you finish the payment the first offer is cancelled and an offer_closed notification is sent with X psp reference. For the payment you get an Authorisation notification with Y psp reference. If you are not lucky then the offer_closed notification is going to be the "last" notification for the order and then the psp reference won't match therefore the refund cannot be done.
To Reproduce Steps to reproduce the behavior:
Expected behavior It would be better to store the original pspreference for the order when the async notification from our server or the sync authorisation response from the API is processed.