Basic Information regarding shopping cart & stock levels / control

I have a reasonable idea on creating a shopping cart and linking the checkout to a payment gateway. I'm not clear on how the basic process can be linked up with a fairly efficient (but not over the top) stock level / control system. Could someone explain the basics (not programming) of how this process works, explaining how the levels are updated from either end (automatically and manually).
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


My company is currently discussing a solution for this with one of our clients.

We have come up with two options, one real-time and one with regular synchronization.

First, one end must contain the master database (the offline database). The online base will synchronize based on this.


Every time a purchase is made the online system sends a request (could be in many formats, anything from a form post to XML) to the stock management database. The item is deducted, and a response message is returned. If negative the buy receives an error and is not charges (Sorry, we're out of stock), if positive everything goes on as normal. (that's the basic, simple way - of course you may want to add things like security, etc. to complicate it a bit).


Every X hours the stock management database sends a request to the online database, upon which the online DB returns the number of items of each type sold since the last update (XML would be an excellent way of transferring this data). The online database then sends a request to the offline db to find out how many of each item is left in stock. You may also, at this point, reserve X items for offline sales (i.e. if there are 10 left and 5 are reserved, the online db is told that 5 of this item is available).

Let me know if you'd like more thorough and technical info.



Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Chris_GrangerAuthor Commented:
That's excellent, thanks. Any more information about anything would be great, eg - security, a litle more on how the stock management database is handled with incoming/outgoing stock (from the non-e shop side), an example of the XML handling would also be fantastic. Obviously the stock management database is integral for the real time method so I'd assume if the company's servers were not going to be full-time reliable then it might pay to situate this at the same hosting site as the online application, residing on its own server for security sake? I don't understand any advantages with the "Synching" method?

I've awarded the points for your last answer as this was pretty much what I was looking for but the more the better... :-)


In my companys project, all these transfers will happen through http protocol. One side sends a request (sometimes including form data), the other side responds with XML data.


John Doe purchases a T-Shirt from your shop. He enters his credit card information and clicks "submit".

While John waits happilly, the web server sends a https post request to your shop server which contains the code of the item in question. The shop server replies in XML with "1" for "yes, we have it" or 0 for " sorry, out of stock".  If the reply is 1, John's credit card is processed. If successful, another https post is sent to the shop server this time saying "We've sold one of these items". the shop server simply replies "okey dokey" or doesn't reply at all.
John sees the response page saying "thank you for buying a t-shirt, it's in the mail".

As for the XML, vbscript has objects that lets you handle and convert XML very easilly. Making secure connections and verifying IPs is also pretty simple.

For added security, you can also use SSL (https) on both servers, and verify IP addresses on each side.

"I don't understand any advantages with the "Synching" method?"

My company is operating in Cambodia, where internet connections are fickle at best. The only advantage of the synching method is that the sale will still go through even if your connection is down.

Let me know if you have any questions on the above!


CompTIA Security+

Learn the essential functions of CompTIA Security+, which establishes the core knowledge required of any cybersecurity role and leads professionals into intermediate-level cybersecurity jobs.

Chris_GrangerAuthor Commented:
Great Thanks!  

Just out of interest, is it more secure querying your shop server (which then querys the shop db and responds with xml) then it would be to directly query your shop database?

Could you show the syntax for the XML reply and recieve?

Could you explain the "secure connections and ip" bit a little more? EG - Do you mean HTTPS?,  What IP address are you querying and why?
Hi Chris,

The XML can be as simple as this:

  <?xml version="1.0" ?>
  <remark>Invalid Password</remark>

The above signifies a reply of "Sorry, the password didn't match" which is what the user will see. Please visit for more information about XML.

Like you say, the methods I'm describing here are querying a script on the server rather than the database itself. The advantages are that a webserver supports SSL, and the outpur can be formatted as you please (which may also be the case with a database server, I'm not too familiar with that).

All data will be transfered over the HTTP (or HTTPS) protocol. HTTPS if preferable to keep the data safe. Of course this means that your shop server will need a secure certificate installed (but not necessarilly a registered one).

The IP addresses you are querying are those of your web and shop server. As I mentioned, for added security your shop server should make sure that the IP querying it is that of your web server.

Sorry about keeping it short, but there's too much work these days!


Chris_GrangerAuthor Commented:
That is fantastic, much appreciated!

One comment you made was:
" certificate installed (but not necessarilly a registered one)."

What do you mean by not using a registered one?

Chris_GrangerAuthor Commented:
...are you storing CC information or are you using a pay gateway?

The way secure certificates works are, briefly:

You create a new certificate. You can use it instantly, and it works just like any other certificate. However, website visitors people will see warnings that it's an unregistered certificate (meaning the identity of the owner is unknown). You will need to verify your identity and ownership of that perticular certificate with a certification authority (i.e. Thawte, Verisign). The certificate works just as well without registering it with an authority, and unless visitors will be using the secure part of your server there is no need to register it.

I make it a rule never to store credit card information; even if I will not abuse it myself I am still compromising my customers information by storing it somewhere a 3rd party may get unauthorized access to it. I'm using a real-time payment gateway, so there is no legitimate need for me to store the CC info. You should only store this information if absolutely necessary, and if you do store it you should inform your customers about it.


It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.