Question

I'm designing an e-commerce application and I'm concerned about users occasionally experiencing this:

  1. A user orders a product and is redirected to the payment processor.
  2. While the user is paying, another user orders the product and it's now out of stock.
  3. The user completes payment, but the order can't be created because the product is out of stock.

This can be avoided by reserving the product before attempting payment. But there's some complexity in doing so - if the payment fails, products need to be un-reserved, and a timeout is needed in case the user never completes the payment process.

So my question: is it worth implementing the reserve process? Or is this scenario rare enough to just not worry about it and resolve things manually if it does happen?

The answers probably depends on exactly what's being sold. However, I don't know this - I'm developing generic software to be used by all sorts of vendors. I could make it configurable, but still need a sensible default.

Was it helpful?

Solution

You have two excellent answers (I've upvoted both). But they each address only a part of the problem, and this is why I feel obliged to come with a third answer

Your challenge is hybrid:

  • It's a business problem, exactly as Rik D pointed out: ultimately, the business is responsible for deciding how to deal with customers.
  • It's a user experience problem, exactly as 1201ProgramAlarm pointed out: and good IT products should promote good user experience.
  • But it's also an IT capability problem: if you want to reserve real-time, your online ordering system must be seamlessly connected to a back-end stock management system (1201ProgramAlarm clearly made that point). Personally, I know a lot of small businesses that still struggle with such an endeavour (inaccuracy mentioned by Rik is only one of the potential symptoms in that regard).

It is a hybrid problem because it cannot be solved by just looking at one side of the medal. Business cannot come out with a good requirement if they don't know what's possible. Business experience in a shop is very different from the online experience in the browser, so some digitally native insights are also needed here. Both business and IT considerations have to be analysed together. Of course, ultimately, business people should have the final world, but after this dialogue.

In your special case, you do not have business people. Whatever choice you will make might, you'll lose: If you can't reserve, some will prefer a platform that can; If you oblige to reserve, small businesses will prefer less constraining solution.

So, in conclusion, if you can:

  • offer both approaches as a configuration option (to enlarge your market)
  • propose reservation by default (because that's what market leaders do, and your customer all dream of being one day a market leader ;-) )

OTHER TIPS

This isn’t a software problem, it’s a business problem.

You should ask the business how they want to handle the situation. Perhaps they simply want to take the order and ship it a little bit late. For generic software, offering an option for the store owner to ignore empty stock and take the order is valid.

It’s not up to us, software developers, to decide how the business should work.

Another thing that comes to mind is that stock is often inaccurate. Even with a reservation system in place such as 1201ProgramAlarm described, it’s possible that a product is actually not in stock even if the system thinks it is. In this case your software might need a feature for customer service to reach out to the customer and offer them their money back or offer a replacement product, or some other option to make the customer satisfied. This could be much more valuable for the business then a reservation system for items in a shopping cart.

Look at it from the user's side: would you like to order a product, go thru all the payment details page (including, for example, entering credit card data), having your card charged, then having the system come up and say, "Oops, we seem to have run out of those"? Then you'd have to refund or undo the transaction, which may incur fees for the retailer.

It is much better to put a hold on a product (reserve it) when it is ordered. This is like putting the product into your shopping cart in a brick and mortar store. In either case, if the cart is abandoned it will eventually be put back on the shelf.

If the order sits in the cart long enough, it would need to be refreshed. At that time you may notice that it is out of stock, and the user can be notified.

The additional complexity of the reservation system will make for a much better experience for your shoppers.

With so many good answers it seems strange to say that you and they have missed something. But I think you have, and I think that it may help you.

Payment processors do not just let you charge credit cards. In fact I am not at all sure that they let you charge cards at all. What they actually do is this:

  1. Obtain authorisation from the card issuer for a charge of the amount specified. This may or may not succeed.
  2. Charge the card according to the authorisation. This will only fail in really exceptional circumstances.

There is no reason not to do 1 before reserving the goods. It costs the cardholder nothing.

As for 2, you have three choices:

  • Charge automatically at the time of authorisation. This is the simplest but it does mean that you need to be ready to refund, and refund fast, if for any reason the goods cannot be sent.
  • Charge automatically at some later time. This is not appropriate for you, but it is the best choice of sellers of revocable digital goods. I do it. The card is charged 72 hours after purchase. Thus if anything goes wrong (wrong purchase, fraud, etc) I can prevent the charge before it happens, as long as the problem reveals itself fast.
  • Charge manually still some later time. This is best for physical goods. Having reserved the goods at the time of authorisation, you make the actual charge immediately before sending the goods.

Not to make any specific recommendations- but the broader landscape may offer you (and other readers) some better choices.

If you are selling a time sensitive product, sold on first come first serve basis, reserving the product doesn't makes any sense, a valid example is a ticket to a concert or an airline ticket, in such cases you are often connected to the ticket distribution systems in real time.

For cases where time is not of much relevance the product could be reserved and later made available if the payment fails or the user doesn't complete it, a valid example is of selling TVs online, maybe. In case you do not want to reserve the product then it would become more complex and you might end up making calls to the dependent system several times.

Yes, the UX is important but you also need to keep in mind that if you don't hold the inventory database or if multiple other online vendors are selling the same items you are actually racing against them as well.

Licensed under: CC-BY-SA with attribution
scroll top