writing POS software, interfacing with hardware

I’m funding a pizzeria which will be run primarily by my cousin. I’m a software engineer and I’m considering writing my own POS software. I have a good handle on the software side of things: building the interface, database, etc. Yes, I know it is quite a lot of work. :wink: At least we don’t do delivery. Anyway, what isn’t clear to me is exactly how to interface with the hardware. Does anyone here have experience with that?

I haven’t purchased any hardware yet, so for the questions below we can assume that I buy whatever hardware is good, reasonably priced, and easy to interface with.

How do I communicate with the printer? I expect I will buy a USB thermal receipt printer for < $200. Does it show up in Windows as any other printer would? I guess it will only print text?

How do I communicate with the cash drawer? I’ve read that the cash drawer can be triggered to open by the printer whenever it prints. Is this true for all printer + drawers? What should I look for when choosing a printer and cash drawer to make sure I get this feature?

How do I communicate with the card reader? I see some readers say “keyboard emulation” or “keyboard wedge”, so I expect my app will get keystrokes, cool. What keystrokes do I get for a credit card? I expect I get the name, card number, and expiration? Anything else? What is the difference between a 2 and 3 track reader when swiping a credit card?

Will I be able to tell from the card reader if a card is a debit card? I’d like to be able to swipe a credit or debit card, and if debit have the customer enter their pin on a pad. Is there some requirement that customers have to swipe their own debit card?

I have found Point of Success, which I see is popular with this forum. I am definitely consider it, but I am still interested in the above info. :slight_smile:

The POS hardware interface is not difficult at all. All POS printers have an available Windows printer driver. We use printer-controlled cash drawers. You can send drawer codes to the printer using a control font or send the drawer kick codes separately. Some current POS printers like the Star TSP 100 or the Epson T20 will print any Windows font and a logo quickly if it is using a fast interface like USB or Ethernet. For older technology printers you need to use a resident printer font to get it to print fast.

If you are using a keyboard emulation card reader you don’t need to do anything but receive the text input. The computer sees it as a keyboard. The trouble is that when you use this type of mag stripe reader the credit card input can be seen by keylogger software and that’s bad. Current technology mag stripe readers encrypt the credit card mag stripe content for better security. The information you need to process a credit card is on track 2. Track 1 and 3 can be used for other purposes.

I have never seen a debit card that is not Visa or MasterCard branded. You cannot differentiate a credit card from a debit card based on the content of the mag stripe. To support credit card processing in software you develop you must either use an out-of-scope processing technology or go through a credit card data security validation. The former is complicated and the latter is more complicated and also expensive!

Of course I think your time would be better spent building your business rather than reinventing a point of sale system that costs a fraction of what your time is worth!

I’m happy to answer any more questions you have.

Thanks a lot for the reply Jeff!

The printer sounds pretty straightforward, thankfully. Now I just need to choose which one to buy! I’ve read 2 color paper is expensive, and black seems fine anyway. Printing a logo would be nice. Using USB or ethernet is no problem. Given this, do you guys have any printer suggestions?

I’m not too worried about a key logger since I can lock down the computer, but it’s good to think about.

I already use Stripe for credit cards in a separate business, so once I get the card data it’s easy to charge. For debit I can charge using a Chase API.

I’m now thinking it would be best to have a card reader where the customer swipes either their credit or debit card. If the reader can’t tell the difference, I guess they first have to choose credit or debit? That’s unfortunate. If debit, they enter their pin using buttons (no stylus!). If credit, they are done if they don’t need to sign (will be common), otherwise they sign with a stylus. If I can’t find a reader with a digital signature pad that also has pin buttons, then they can just sign a paper receipt. I guess the reader could also have a display telling the total, “please enter pin”, etc. Do you guys have any suggestion for a reader that might meet my needs? I expect my exact needs are very common.

I live far (different continent!) from the pizzeria, so what I can contribute is limited to organization, business stuff, and remote IT stuff. I looked at POS software before I heard about Point of Success. I was quite put off by both the quality and the cost, so I started looking at what I could do myself. I am still open to using an existing software solution and will check out Point of Success today. :slight_smile:

I think you are asking questions that are more technical than most PIZZA PEOPLE would have answers to. You should look for a programming forum or save yourself time and get Point of Success.

Just my opinion.

I agree some of my questions are pretty technical, but I’d bet some pizza people have experience with the hardware I’m discussing. Also I still need to buy hardware, even if I choose Point of Success.

Count me as another Point of Success fan. For how good and cost effective the program is, I can’t imagine building my own from scratch. Just inputting all my data and setting everything up has consumed the last month and a half of my life. I can’t imagine having to write all that code, create financial report templates, ect. I’ll probably wake up in a cold sweat tonight thinking of running my own system and discovering a bug during a Friday night rush.

I wrote my own POS system in the early 2000s. It was enough to do all the basic functions. Back then I wrote it in Visual Basic.

Unless you are an exceptionally efficient and quick programmer, have a few others to help you, or don’t plan on opening the restaurant for a while, it will take too long to write from scratch. Your questions on, no offense, easy things like how to print to a printer and popping cash drawers tell me that you are pretty much working from the ground up. Not a problem, as I had to learn most of that as well, but i also had an unlimited amount of time working on my program, whereas you don’t sound like you do.

I’d suggest getting something first and writing your software while the restaurant is already operational. I know it sounds redundant, but you will learn a lot (and get a lot of ideas to “borrow” or to do differently) by actually seeing and using one of these modern POS systems.

Don’t worry, I understand your concerns and I have the coding skills and time necessary. :slight_smile: What I don’t have is the hardware in hand, so it isn’t clear what interfaces the hardware has and how software talks to it. This information isn’t readily available, even from manufacturers. I want to make sure I buy the right hardware. After that, I may give up on writing my own POS software, I haven’t decided yet.

Jeff answered most of my questions: the printer uses a standard Windows printer driver and can control the cash drawer. I’ve looked more into how charging cards can work, and I think I’ll go with TSYS for the processing and an Ingenico iCT250 payment terminal:

The workflow is:

  1. Enter transaction amount from the POS into the Ingenico.
  2. Swipe card, customer may choose credit or debit, enter their pin.
  3. The Ingenico prints a receipt for the card charge (only shows total).
  4. POS prints a second, itemized receipt.

Is this the workflow you guys use? This is ok, but I don’t like that step 1 is time consuming and error prone. Is it possible for the POS software to tell the Ingenico the transaction amount? I just found the Ingenico Developer Portal and registered, so hopefully that will help me figure it out.

I’ll be quite blunt…you’re foolish to try to write a functional POS program in a cost & time effective time frame…

Yes, I could build my own car from scratch or grow all my own vegetables while raising my own chickens & cows…

But it it the best way to do it? Sometime we don’t see the true vision…

Patriot’sPizza,do you accept cards? How does your workflow compare to what I outlined in my post above yours?

we use Square & at times I’ve had 9 drivers on the road (college joynt) & everyone luvs signing @ the door…the drivers luv it too…doesnt interface perfectly with P.O.S., but as an Auditor, my paper flow @ close out is easy…basically, Square is just another form of cash/check…the driver can run his report & figure out what is due to the house & what is theirs…

Patriot’sPizza, interesting, thanks for sharing. Square’s flat rate 2.75% pricing is interesting for a business with $10-$12 average tickets. The lowest interchange + card brand rates (cool site, one of the few that are transparent about actual fees) are about 1.65% + $0.12, so for a $10 ticket about $0.28 is taken, for an actual rate of 0.28 / 10 = 2.85%. That means Square loses money on the deal! It’s good for you though, so that’s really cool. :slight_smile:

I’ve now learned a lot about card processors. This is a good PDF:
This site is great if you are looking:

I’ve found a processor that will do interchange + %0 discount rate + $0.08, $5/month, no minimum volume. This seems good compared to any other processor I’ve found. Even with a good rate, it’s still brutal for low average tickets. Eg, the same $0.28 interchange from the last example + $0.08 = 0.36 / 10 = 3.6% actual rate (or a little worse since that was the lowest possible interchange cost).

I’ve been in contact with Ingenico. Turns out the iCT250 can’t be controlled by software but the iPPxxx can. I’ll likely be going with an iPP350 and writing my own software. It’s going to be a lot of work, but a really cool system! :slight_smile: I’ve spec’ed out the hardware:
This will run 2 registers, a pre-oven make line screen, and a post-oven make line screen. My software will handle moving items from the register to the make line screens and allow for tracking all sorts of metrics.

and how will your system handle online orders, driver dispatch, marketing, refunds, inventory, sales reports, discounts, coupons, special offers…sorry, I thinkk your driving a time consuming sinking ship…good luck tho…

Thanks. :slight_smile: I’ll build the register interface, inventory tracking, reports. We don’t deliver. Building software is what I do, it’ll be awesome. :smiley:

I wont beat this dead horse any longer, as I have to harvest my wheat & grind into flour, then press my olives for extra virgin oil, while mining my salt…

Imagine you have been making flour, pressing olives, and mining salt professionally for over 20 years. You’ve built a great business doing it and you use the profits to open a pizzeria, then people tell you that you should just buy your flour, olive oil, and salt because doing it yourself is a lot of work. :slight_smile:

I think we’ve made our thoughts clear on the matter. Nate didn’t come here asking if he should do this or not. He just came with some questions. I know I couldn’t fit it in to all my responsibilities, but if he wants to take it on, I say good luck and I’m sorry I don’t have the info you’re looking for. Sincerely, I hope you can make it work.

Actually very interesting topic. We all get used to what we are comfortable with and I think if Nate is talking about building just another legacy POS system then I would tell him to not waste his time but if he is heading into eCommerce territory and thinking then… integrating and making functional a few pieces of hardware is really not a big deal. I would think that as others have mentioned (on other threads here) there is a sea wave of change in the way people manage and do business and software will continue to evolve and get better. I have used Point of S. since 2009. I work overseas and have VOIP lines to a PBX that directs people to one of our two shops. That signal then goes to an adapter that turns it into analog so the Caller Id box can recognize the signal which then comes out of the Id box via a serial with a usb adapter connected to the server computer which has to be running windows to work with Point of S. I still get the last two digits dropped from the phone number and that is really frustrating. This is just one small real problem I have which I realize isn’t shared by those in the US on a traditional copper telephone line.

I don’t regret buying our 2 licenses from Point of S aside from a few trust issues regarding replacing servers and having to get new unlock codes. If we continue to grow we will need a better and smarter solution. Looking at drupal, if there is anyone on this board that is interested I would invite them to connect. eric@…plusmywwwsite listed to the left.

Kudos to you for wanting to write your own. As a software engineer myself, sometimes we do things just to say we can, lol. Nonetheless, I wish you success in your endeavor. If you need to integrate online ordering with your POS, let me know.