views:

1260

answers:

5

I would like to implement an online ordering system for restaurants. I am starting to research this a bit, and wanted to throw it out here.

  1. Is there any open source projects already started out there I could work with and contribute to?
  2. Would it be easier to just roll my own? -If so, any suggestions on where to start? ASP.NET, Ruby on Rails, PHP???
  3. Payment processing? I am pretty sure I would go through Google Checkout. Any drawbacks to google checkout?


EDIT2- Looking around online I feel most commerce sites are geared towards product and shipping them. The few that are out there seem like it would be a chore to implement and high cost entry. I may just have to look at developing something for now. Any ideas/suggestions on where to start(Question #2 from above)???

@Balloon - I don't think SMS would be a solution for getting the orders in. The restaurant doesn't have a cellphone dedicated for itself. I was looking towards making a phone call when a recorded message that there were orders queued, until they were acknowledged from the restaurant online that they were being processed.

EDIT- superjoe30 gives a link to his online ordering system. I took a quick look, and it looks great! I want to clarify this is for a cafe, therefore the ordering must reach the cafe in almost real time. Any delays in getting the order to the cooks, would slow things up, taking away the benefit of online ordering at a cafe.

Any suggestions on getting the order to the cafe immediately after the payment is processed? I think email would go unnoticed. I believe there is a way in .NET to make a phone call to the cafe, that could alert them of an order and have them print it out.

+1  A: 

As for software that is already available, most servers come with AgoraCart. It's open source, you can customize the appearance, and it comes with an admin back-end for your client.

As for rolling your own, it's possible (I did it), but you have to be very careful not to screw up, as bugs in ordering systems are extremely costly. Working diligently, I would predict a 1-2 month schedule.

Authorize.Net is a good way for payment processing. Very nice scripting interface in any language. Don't forget to check out mod10 checksum for javascript credit card number verification.

superjoe30
+1  A: 

There a few that I was able to find on SourceForge.

Depending on how complicated their system would need to be depends on how difficult it would be to roll your own. I would look into these open source ones to see if any of them may fit your needs. I don't have any experience with any of them so I can't say if any are better than others.

DanV
+2  A: 

@Justin,

OP asked about an ecommerce solution, as far as I recall WordPress and Drupal aren't shopping cart apps. Perhaps that's the reason your reply was modded down.

@nuggs -

1/ If you're building this app as a commercial concern, i.e. it pays the rent then be realistic and choose a shopping cart app that best suits the requirements. Don't go spending time rolling your own, find a good one and integrate it. Don't get hung up on open source and the hope that one day you might contribute back, be realistic.

2/ Don't roll your own, get one off the shelf, your time is money. For a couple of hundred pounds you can pick up a commercial product like Cactushop. If you go down the F/OSS route then make sure the project has a decent predigree and ongoing development. Don't think that because the cart app is F/OSS you'll be able to maintain it should the project go tits up, the codebase could be a complete nightmare or utilise techniques and technology beyond your skills and capabilities. Trust me, I've been there with an open source Perl app that looked like line noise.

3/ PayPal and Google are great for getting started because they provide a foot in the door to being able to accept online payments with very little entry cost. However at higher transaction volumes they aren't the best value for money. As your volume of transactions increase you may want to look at a dedicated payment processor such as HSBC, ProtX, SecPay etc. You'll get better support (i.e. people who answer phones) and better tech support when things go wrong. In addition to whoever you choose as a payment processor, make sure you have a fall back prepared. It's not unknown for any of the well know processors to have bad hair days. Be prepared for these scenarios. Your secondary processor may cost more per transaction but at least you can still take payments.

And finally, be fair to your customer, estimate the app properly. If he's not happy to pay for your time, software or services that will help you bring the app in on time then walk away. Don't make a rod for your own back by giving your time and effort away free.

Kev
"as far as I recall WordPress and Drupal aren't shopping cart apps." Yes, but there's always http://www.ubercart.org/
Pete
+1  A: 

For instant notifications of new orders, you might want to look into integrating with an SMS gateway to send text message alerts. There are some solutions out there that are pretty easy to integrate with and the text messages can be bought in bulk to reduce the cost.

Chris Roberts
A: 

For notification, what about finding/creating a simple app that fetches email from a POP account and prints it out whenever there's a new message? Then you can just send the orders to the email address as they come in. Or you could go completely old school and look at using a email-to-fax service and have them set up a fax machine at the café :)

Erlend Halvorsen