|capturing session end event, when user closes browser|
I need help/pointers with some session related issues,
I have been working on a shopping cart and have encountered an issue with how to handle the situation when customer either leaves the session by browsing away from the site/shutting down browser or the session times out.
Well, I think this is a bad idea.
What's to stop the competitors from doing a daily scoop of all your products, placing them all in the cart, making none of your products available?
The way you should work this is allow them to place in cart WITHOUT changing availability or stock status. Update the availability or stock only on checkout.
An extension, even then, it should be moved to pending until the payment clears and is shipped, but at the very least, the first option.
Do this and I think your present issue will cease to be a problem.
Of course. You could lose a sale for a product reserved.
You can use sessions to store shopping cart data.
thanks for you replies guys.
Rocknbil, very good point you are making. I hadn't really thought about that. But this does raise another issue, if two customers add the same product to the cart, only the first to check out will get it, and this was one of the things that I wanted to avoid also. the other user may feel cheated as i would think most people think the product is theirs as soon as it is in the cart.
I did think about another way and that was to make it so that they have to complete the checkout for each product. Although this also raises a usability issue.
NomikOS, I am using sessions for the cart, but the problem was that I thought of updating the stock so that the product would not be bought by a second custmer while the first customer who added the product to the cart was still browsing. The problem with this is how do I reset the stock if the customer never checks out.
I think I might go for the checkout for each product route for now, but still have to think about it.
Out of curiosity; how do the big boys do it? Say Amazon.com - with the amount of customers they have, they must have this issue all the time...
Most of the carts do the stock update during order placement. And some do it after order verification. Because you may accept say western union or checks and so the verification process takes a while. Even with cc it's possible to face fraudulent orders and in the meantime the item won't be available.
And then all this is subject to the nature of products you carry. With single products you could identify if multiple sessions in the database point to the same product and bring up some message in the shopping cart or checkout pages that another customer tries to purchase the item. You can also have some terms and conditions for these items.
Clearing sessions should be done automatically from the garbage collector PHP handler. Usually carts set this up so sessions are cleared if no request to the server with the same session takes place after sometime.
One other note before digging more into sophisticating techniques with the inventory handling, think if you really need it. You must have lots of traffic and sales for this to be a real problem.
|But this does raise another issue, if two customers add the same product to the cart, only the first to check out will get it, and this was one of the things that I wanted to avoid also. |
You are absolutely correct, and I absolutely do not have an answer other than watch the Black Friday footage and learn from Wal-Mart's employees. :-) There's only so much you can do in an automated process.
I've never actually had this happen, but if it does, on receipt of the order we have a contingency plan, but first, an overall management we use.
When placing items in cart, they enter destination zip code (or country for non-U.S.) and before we post to the shipper API to calc shipping, the first step is to check ordered items for stock. If an item is NOT in stock, they are presented options for "what do you want to do?" (I have other posts here for examples.) There's no way that can get past this without knowing and making a decision based on the disposition of stock. This eliminates most of the concern - it may have been in stock when they added it to the cart, but on checkout, we check again. If someone beats them to it, they will know. But note that, this will only happen if user A has completed the checkout process and their payment is posted.
If it still manages to go through with someone being beaten to the punch (as said, they will likely already know) we contact them immediately and explain that while it was in stock when they ordered it, someone beat them to it. We ask what they want to do, and in advance of them asking, we tell them when it will be in.
A further step we take is items are not immediately decremented from stock. We hold 3 tables, stock, pending, sold. When ordered, they are moved from stock to pending, public display only show what's in stock. When order is shipped, we move from pending to sold. If a customer decides to cancel an item in a completed order, we move it back from pending. The overall advantage is from an administrative standpoint, we can see "3 blue in stock, one blue pending".
Thanks for all the replies. :D
[edited by: coopster at 11:38 am (utc) on Apr 22, 2010]