• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 539
  • Last Modified:

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).
Cheers
0
Chris_Granger
Asked:
Chris_Granger
  • 4
  • 4
1 Solution
 
AsbjornGCommented:
Chris,

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.

Real-time:

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).

Synching:

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.

Cheers,

Asbjorn
0
 
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... :-)

Cheers!
0
 
AsbjornGCommented:
Chris,

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.

Example:

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!

Cheers,

Asbjorn
0
[Video] Oticon Case Study

Open office environments can create the dynamics for innovation, but they also bring some challenges. With over 1,000 employees in an open office, Oticon needed a solution that would preserve the environment while mitigating disruptive background noises.

Watch how they did it.

 
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?
0
 
AsbjornGCommented:
Hi Chris,

The XML can be as simple as this:

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

The above signifies a reply of "Sorry, the password didn't match" which is what the user will see. Please visit http://www.w3schools.com/xml/default.asp 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!

Cheers,

Asbjorn
0
 
Chris_GrangerAuthor Commented:
That is fantastic, much appreciated!

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

What do you mean by not using a registered one?

Cheers
0
 
Chris_GrangerAuthor Commented:
...are you storing CC information or are you using a pay gateway?
0
 
AsbjornGCommented:
Chris,

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.

Cheers,

Asbjorn
0

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now