Developer forum

This will happen if the user somehow views the cart in the browser before the callback comes in - or if the payment flow is some way otherwise disturbed.

Examples

You can i.e. have the cart open in one window, start the payment in another and when the payment window is open (and the cart was converted to an uncompleted order), the user navigates window 1 which will downgrade to a cart. Then payment is completed in window 2 and the callback is looking for an order that does no longer exist.

Can also be a payment that has gone through when driving on E45 near Kolding, but G5 falls out because the speed is 200km/t and then the receipt is slow because of lost signal - user is impatient and while checking his facebook and speeding, he is navigating back in the browser and this would also happen :-).

Some things like that...  We try to take care of most things.

If you see this a lot, it could indicate an implementation issue that needs to be addressed. I have seen solutions where minicarts (from another cart page) are fetched after payment has started - can also make things like this happen.

BR Nicolai

Hi Nicolai,
We have noticed situations like this and I agree there are a lot of potential causes out of our control.

We have fixed this situation in one of our solutions by storing the original OrderID on a custom field on the order, and in the callback from the Payment provider, we check both the OrderID and the custom field when trying to identify the order to be updated.

It's not very elegant and maybe there are better ways. Like using a unique identifier that is used in the payment communication, in order to avoid this type of change between request and callback.

Just saying.

Adrian

Yeah - but there are a lot more scenarios - and compatibility issues.

Many gateways have a very strict rule that an orderid cannot be re-used. So if you start payment, go back, and start it again with the same orderid, you cannot complete the payment.

The order do have a unique ID and that is the one used in the log entry above to locate the correct order object and mark it as complete instead of failing.

I see. In our case, there was no issue with this scenario.

But I am wondering how they (payment providers) handle in this case a situation where you have placed an order and for some reason the payment fails? Don't they allow a retry of the payment? I would assume that it would mean a payment for the same OrderID

And now that I am thinking, you will never try the same OrderID as you will always send the new orderID for a secondary payment (assuming the OrderID changes), but it allows you to validate payment on the callback if the OrderID used to start the payment matches the unique identification.

The current issue is not starting a new payment session but making sure that a started payment session would validate the initial order, even if the OrderID has changed in the meantime.

Adrian

I don't know why they have that restriction - my guess is security and fraud detection. Some allow retries, but most do not.

In later versions (9.14+) we can based on orderid history locate the correct order. But things will mismatch in logs etc. This is done for all gateways.