Overselling due to stock update logic

[stevel]

As many of you know, the product quantity on hand does not update until the checkout is complete. This makes it possible for, say, two customers to each add a "last remaining" product to their cart and complete checkout, meaning you've sold two but have only one. I also notice that the update done in checkout_process.php is not "safe", in that if two customers check out at the same time, the resulting count can be wrong, because it does not use an

"atomic" update.

 

This has caused real problems for one of my stores where in some cases a "hot selling" product will oversell, and worse, leave the quantity field wrong. I have been asked to figure out how to fix this.

 

A simple but incomplete fix I thought of (and tested but did not push live) is, on entry to the checkout process, clear the active cart and then do a cart->restore_contents() to reload from the saved cart (which should be there since the customer had to log in in order to go into checkout.) This will catch the cases where the product went out of stock between the time it was added to the cart and checkout.

 

However, I don't like this and customers probably wouldn't either. If you put something in your cart, it should stay there until you either check out or your session expires (I can see an opportunity for abuse too, but I think it is limited.) The question is, how to implement this in a way that does not require extensive code changes and doesn't lose items?

 

A possible implementation: When an item is added to the cart, subtract from stock then and not on checkout. When the session expires, before deleting the session, add back to stock everything in the cart. If the item is removed from the cart or quantities updated, update stock accordingly.

 

Have others solved this problem for their stores? If so, how? I searched the forums and contributions but did not spot anything related to this issue. All ideas appreciated.

[Jan Zonjee]

As many of you know, the product quantity on hand does not update until the checkout is complete. This makes it possible for, say, two customers to each add a "last remaining" product to their cart and complete checkout, meaning you've sold two but have only one. I also notice that the update done in checkout_process.php is not "safe", in that if two customers check out at the same time, the resulting count can be wrong, because it does not use an

"atomic" update.

 

This has caused real problems for one of my stores where in some cases a "hot selling" product will oversell, and worse, leave the quantity field wrong. I have been asked to figure out how to fix this.

I have never seen fixes for this, but it is indeed a problem area in osC.

 

It is even worse: once you added an item to your cart and were logged-on so your cart stays stored you can checkout with items that are sold out or do not even exist any more (products_status is 0).

 

This was discussed a while ago. In the thread is some code to prevent that scenario.

[stevel]

It is even worse: once you added an item to your cart and were logged-on so your cart stays stored you can checkout with items that are sold out or do not even exist any more (products_status is 0).

Well, this problem at least I don't have, as a previous webmaster of my store (I inherited it) added code to restore_contents() so that stock and product existence is checked when restoring the cart from the database. It's similar to the code in the thread you mentioned (though more complicated because this store also allows backorders and tracks them.) It wasn't until you mentioned this that I looked at the stock osC code and found none of this code, so my partial fix I mentioned isn't applicable without further customization.

 

I'll pursue the idea I had about deleting the session cart, but I keep thinking of ways it can go wrong so I'm not happy about it. On the other hand, I can't think of a better approach that doesn't have even more problems.