Update Basket Item Prices and Availability Mid-Session

[joshpappas]

We're finally updating our sites to use "inventory at checkout" and I'd like to extend the basket timeout to possibly several days or even a week for one of our stores. How often does the basket update pricing or check inventory availability in this type of scenario?

Also, are there any significant downsides to this that I should consider when determining how long to set this?

[oliverands]

I've done exactly that with my store. I now have baskets set to expire after seven days. I can't speak to updating pricing since my prices are static, but the basket checks contents vs. available inventory during the checkout process--I think just before payment is required. So it works like a charm when someone puts an item into a basket but delays checking out and then returns a few days later to do so after inventory is all gone.

I did encounter one issue when I made the change you are considering. When this case occurs, the user is directed back to the basket page and there is an error message that is shown. In my case, for some reason, the error message was not being displayed. So to the user it seemed like an odd loop that wasn't letting them check out because they weren't getting the information that the item was out of stock and that they needed to remove it from their basket before proceeding. I fixed this (I don't remember what I had to do now, but it was easy), and it's fine now. But be sure to test for this so you don't have the problem I did.

The only downside of extending basket timeout significantly is that your number of baskets will balloon--possibly into the tens of thousands. But if you have system resources available for this, it won't be an issue. Make sure you are deleting expired baskets with a scheduled task.

[ILoveHostasaurus]

Hi Josh, on high traffic sites, the long basket timeout, combined with certain code and/or third party modules, can sometimes lead to trouble. The issue is that when running long basket expiry, the baskets-related database tables can grow significantly because bots, hackers, etc. that scan a site will often scan store pages, but not send cookies back with subsequent requests, so you end up with a new session for each request, which results in very large numbers of sessions being kept. Some modules and/or code that's been added may do things against the basket table which result in a full table scan at the database level, which is an extremely slow query relatively speaking. Other queries that need access to the baskets tables will block while the long ones run, and that can result in site availability issues.

We've got someone working on a customization to combat this issue by regularly looking for, and removing, small batches of baskets which have no products associated with them, and are not a logged in customer. There's no harm in those baskets going away because a new one would just be created on the next request if it were actually a real shopper. In theory, this will keep the baskets count down since only legit shoppers' baskets would remain to the expiry you've set.

If you shoot me an email I can give you more info.

[joshpappas]

Thank you both. This is great information.

[ocpxc02]

Hi Josh, on high traffic sites, the long basket timeout, combined with certain code and/or third party modules, can sometimes lead to trouble. The issue is that when running long basket expiry, the baskets-related database tables can grow significantly because bots, hackers, etc. that scan a site will often scan store pages, but not send cookies back with subsequent requests, so you end up with a new session for each request, which results in very large numbers of sessions being kept. Some modules and/or code that's been added may do things against the basket table which result in a full table scan at the database level, which is an extremely slow query relatively speaking. Other queries that need access to the baskets tables will block while the long ones run, and that can result in site availability issues.

We've got someone working on a customization to combat this issue by regularly looking for, and removing, small batches of baskets which have no products associated with them, and are not a logged in customer. There's no harm in those baskets going away because a new one would just be created on the next request if it were actually a real shopper. In theory, this will keep the baskets count down since only legit shoppers' baskets would remain to the expiry you've set.

If you shoot me an email I can give you more info.

Hi David -
We've historically kept a very short expiration period (like 2 hours). Do you think going to 1 full day would cause the potential issues you've described above? And, if so, is that customization something available to all or is it a module for purchase?

Thanks,
Paul

[joshpappas]

I'm following up to revisit part of my original question that hasn't been addressed yet in our stores. I've noticed that product pricing always stays at the price that was set at the time the product was added to the basket. I definitely understand this and wouldn't want it changing constantly, but we do update prices once a year or so (usually an increase) and customers end up checking out for a while afterward with old pricing in place. Is there a way to periodically refresh the basket prices and display a message to notify customers? I've seen similar behavior on other websites. Maybe every time the customer logs in, or after a certain period without basket updates, etc.

[Bruce - PhosphorMedia]

Miva writes the price presented to the user when they add a product to the basket. Which is what you'd expect. Our approach to this is to: 1) Keep a SHORT basket timeout (as in hours) 2) use some custom code developed with the help of Scott Shepard (Southbound) to auto save baskets in a separate database.When they customer returns, we show them a popup of their saved basket with the option to reload it. The reload will take current pricing and inventory into effect.

The upside is you now have a persistent basket for the customer with no impact on the rest of the site.

BTW: It's not a module per se, but rather an Installation that uses a module, so its costs a bit more, but it also means you can put whatever tweeks you need for your site.

[joshpappas]

That's an interesting idea and has got me thinking. Thanks for sharing.