Jump to content
Larry Ullman's Book Forums

Recommended Posts

Firstly, an amazing book as usual! Your ability to break down code into English is invaluable and unparalleled!

I am working on a site with sometimes limited inventory (perhaps as few as 4 of something). The client expects to sell in "bursts," ie, they send out an email, and people flood the site to purchase the items, effectively creating a race condition.

 

Obviously, I can't have someone purchasing something that someone else has already purchased, so I have to remove it from the available stock as soon as possible. On the other hand, it is vital to the success of the system to minimize events where items are tied up in incomplete orders, ie, orders that have been placed but not cleared financially. I am not locked into paypal or any credit card authentication system for checkout yet, as choosing which to use largely depends on the resolution of this issue.

 

At present, I feel that using a system like Authorize.net is my best bet, as I would have the chance to stop the sale right up until the moment that the user is submitting the financial data and thus making the sale final. My client would like to offer both paypal and on-site credit card payments, but is not insistent upon it. Any solutions or thoughts on this would be greatly appreciated.

Link to comment
Share on other sites

The only idea I have for this is a time limit for completing a purchase, so from when they 'add to basket' or 'purchase' they have 10 mins to finish the order, but for as long as they are still adding the 10 mins gets refreshed with each new item added.

I have never tried it but I can't see it being too hard, timestamp the basket, each additional purchase updates the time as they are still active on your site. You could give them 5-10 minutes on your site and 10-20mins with the payment processor, so once they have clicked to pay.. you could cancel out the site time-limit and start the payment time-limit. Most payment processors allow you to send additional hidden information, this could be the timestamp once the payment is completed you can cancel the time-limit.

 

If either time-limit is exceeded then the item becomes available again. Or you could simply set a overall 30min time limit to any basket to be completed from first addition. This is only 1 idea and I am sure others will come up with maybe a better solution.

  • Upvote 1
Link to comment
Share on other sites

Thanks for the response! That would certainly be easy to implement, but I feel like that still has the same inherent problems, with products popping in and out of availability. Plus, the success would depend entirely upon your conversion rate. If %100 percent of people who put something in their cart wind up following through to checkout, then that would work great; however, that's not going to be the case. I also don't like the idea of putting any sort of pressure onto the consumer.

 

At the moment, I'm still leaning toward reducing the available stock once the order is placed (very last thing before processing payment), even if the payment hasn't cleared, and then allowing the admin to cancel the order at their discretion, (if a payment is taking too long, for example), and thereby return the items in the order to the available stock.

Link to comment
Share on other sites

This is just my opinion, without actually using paypal live but just in testing mode.

I haven't implemented Authorize.net at all as of yet so I can't speak about that.

With paypal, even if customer pays, maybe the payment won't go through because for example, one hour later customer cancels order, or credit card rejected as stolen, or many other reasons. First you have to wait for a short time for ipn to confirm payment but then payment could always get canceled later. So I think this is an issue that only partly can be solved by the way you structure payments.

 

In case you run out of product, won't the company make more? Your product wouldn't ship today but you can send your customer a notice that there is delay. So why not just accept all orders?

 

This got me thinking, why not look into practices and regulations of mail order when it was done the old way, mail-in or phone-in order (and still is). They had the same problem but it's speeded up now. When they can't fulfill order in reasonable time they must notify customer there will be a delay. That's by law, but in your case it's for customer satisfaction. Nevertheless, they have the principles all in place already.

Link to comment
Share on other sites

Greetings Abigail, thanks for your input!

The stores I'm working on are for an overstock company, and a small arts business. Once a product has been sold, there is no guaranteeing that there will be more stock at a later date.

The phone-order idea is a great idea! I'll be sure to post anything I find through that avenue, thanks!

Link to comment
Share on other sites

  • 2 weeks later...

Thanks for the nice words on the book and apologies for the late reply. This has been on my "to reply" list for days!

 

My inclination is to do what Craig suggests. For example, I know when ordering tickets online to a popular event, I'll be given like 2 minutes to complete the order, because they don't want those tickets to be unsold for too long.

Link to comment
Share on other sites

  • 4 months later...

Whew, sorry I haven't been on in so long - been coding stores! ;)

Larry, I can't recommend your books enough!

 

I figured I'd come here and give an update/get some input on my solution. So, I wound up structuring my order/payment flow a little bit differently. As a side note, my whole store is object oriented.

 

When the person goes to place an order, it does not actually enter the system as an order until the system has in some way been notified of payment. In the case of Paypal, I set up the "express checkout." As soon as they complete the order, it is entered into the system at the same time as the first transaction. This is also the point at which I deduct the products from the site inventory.

 

I wound up using this approach because, as stated above, I needed to be able to ensure that there was no over-selling of stock. The moment before they click "submit order" on my site (express checkout goes my site->paypal->my site), I check that everything in their cart is valid and in stock, then submit the info to paypal, then record the response. As soon as I get a response that says the payment was not rejected (even if it's just pending), I add the order and reduce the stock.

 

From there, I leave it up to the site administrators whether or not to cancel the order if it's been pending for too long. I have a page in the admin section that shows them how long orders have been "pending payment," and highlights/notifies them after a month of being pending. If they decide that the order is just not going to make it through, they can mark it as canceled, the products will automatically be added back to the store inventory, and the appropriate financial info is handled (depending upon their payment method).

 

At this point, short of two people ordering within milliseconds of each-other, there is no chance of stock being over-sold.

Of course, if anyone can see any sort of foreseeable downfall to this, vulnerabilities, etc, any input is much appreciated.

Link to comment
Share on other sites

Thanks for your reply and explanation. My only feedback is that this doesn't avoid the risk of over-selling stock, for the exact reason you mention: if two people order within SECONDS of each other (not milliseconds; you have to factor in the time it takes the user to fill out the form). On most sites, the odds are low, but on a busy site or a popular product, it could be quite easy to get multiple orders virtually at the same time.

 

Now, I'm not saying that you haven't handled this well, I'm saying this is a delicate balance and I don't want you to mistakenly think you've prevented over-selling when you haven't.

  • Upvote 1
Link to comment
Share on other sites

While I know that nothing can make it truly impossible to oversell, it did make a big difference implementing paypal's "Express Checkout" system, vs website-payments pro. It takes the user's info, pre-approves the purchase based on an estimate of the total cost, and then returns them to the site, along with token/session info. Then, from your site, you actually authorize the payment. So I can check the stock literally right before I tell paypal that I want to commit to the pre-approved transaction.

 

That being said, I still installed an email warning list if any product inventory goes negative.

  • Upvote 2
Link to comment
Share on other sites

 Share

×
×
  • Create New...