Case Study by David Hollander, SparkWeb Interactive
KP MacLane is a high-end clothing brand that designs and produces their products in New York. When rebuilding the website, Chris from Revelation Concept chose FoxyCart and FoxyShop (a FoxyCart WordPress plugin) to create their new shopping cart solution. One of the key pieces was the inventory system. FoxyCart doesn't have any native inventory features because they don't store your product information. FoxyShop does manage inventory automatically, but after the site launched, Chris realized there was a problem.
KP MacLane was featured in a piece on CBS Sunday Morning, and received a huge infusion of traffic all at once. They had low quantities of some products and some customers were adding products to their cart and checking out while others were still on the checkout page. The inventory for the products on the checkout page hadn't been able to be deducted from the store's inventory because it doesn't happen until the datafeed runs on a successful checkout completion. In most low-to-medium traffic scenarios this wouldn't be a problem but the combination of a huge influx of traffic and low-ish inventory numbers was resulting in some overselling.
Chris contacted me for help and we were able to work out a solution. I built a temporary database table that stored the session ID, the product code, the product quantity, and the date it was added to the cart. Then, I used the FoxyCart SSO feature to redirect back to the website on a checkout attempt, but instead of checking to make sure that the user was logged in, we were using the feature to do an inventory check.
First, the SSO endpoint removes all temporary inventory locks older than 15 minutes and any locks for the current session. Then it checks the current cart (using cURL and the FoxyCart JSONP) and checks the current FoxyShop inventory levels for each product minus the other existing temporary locks in our new table minus the current cart contents. If the value is less than 0 for any items, it uses the FoxyCart API to remove that item from the cart and then redirects back to a "We're sorry but we've just run out" page which has a "Try checking out again" link. If all the inventory levels were fine, the system puts new inventory locks in for all products in the cart and then uses the API to add the session ID as a checkout session value so it can be tracked later. Then it redirects back to the checkout.
Now on the checkout template, I built a countdown function to show exactly how long the user had to finish the checkout. After the countdown runs out at 15 minutes, the user gets redirected back to another "Your Checkout Timed Out" page on the main site.
The locks would automatically time out after 15 minutes, but it's a lot cleaner to remove these locks after the checkout has completed, so in the datafeed endpoint, I added a check for the session ID and if it was there in the custom fields, I ran a query that removed those locks in our temporary table.
Now this is a complicated system that is overkill most of the time, but very important during times of heavy traffic. So I built the checkout template to skip the countdown feature if the session ID didn't exist as a custom field. And this couldn't exist if the SSO hadn’t put it there. So in the end, all the customer has to do to turn the functionality on and off is to toggle the SSO feature in their FoxyCart settings.
This code is written specifically for FoxyShop, but if you'd like to do something similar you can download the code here for inspiration: http://www.foxy-shop.com/wp-content/uploads/2012/04/foxyshop-inventory-custom.zip.