The Dos and Don'ts of Integrating Receipt Printers: Q&A with Star Micronics
By: POSGuys - 3/20/2023

We’ve received a lot of questions from software developers lately asking us for our advice on how they should integrate a receipt printer into their POS software. We wanted to get these questions answered by bonafide professionals so compiled all the most commonly-received questions and hosted a Q&A session with Star Micronics, one of the largest receipt printer manufacturers in the industry. Here are the key takeaways from our conversation:

Key Takeaways

1. Don’t assume all receipt printers are made equal or will integrate the same. Some use different languages and the type of application you’re developing will change your integration approach. Additionally, receipt printers aren’t like normal document printers. They have special requirements.
2. There are two main ways to develop a receipt printer into your software. Cloud-based printing setups and native setups. Cloud printing is great because it can run on any operating system since it's accessed over the internet. It's also great because it's a one-shot-and-you're-done solution, eliminating the need to develop each operating system. BUT it requires an internet connection and you’ll need to host a web server. Security concerns may arise as well. On the other hand, Native printing setups provide flexible connectivity options, including USB, USB Lightning, Wi-Fi, Ethernet, or Bluetooth. In particular, Windows and Mac development is usually easier since you use the driver. At the same time, native applications are limited to the operating system they're designed for and may require different development for each operating system.
3. Don’t save receipt printer integration until the last minute. The later you are in the development process, the less options you’re going to have.
4. Getting a receipt printer integrated is only part of the bigger picture. Don't forget to consider how your end users will source the hardware you've certified, how they will install it on their system, and who will support them if they run into technical issues.
5. If you're feeling stuck, reach out to an expert. There's plenty of free resources available for developers and POSGuys can connect you with them.

A Transcript of our Conversation 
Please Note: This conversation's transcript was generated using computer AI. There might be small grammatical errors. Please call us for more information 
Colton: Hey everybody, this is Colton with POSGuys.com. Today we have something a little different here today. Over the past year, we've been getting a lot of requests from software developers who have been coming to us asking for our opinion on how to develop certain parts of their receipt writer for point-of-sale software. Either for new software altogether or looking to integrate a new printing solution to an existing setup. I thought that the best approach would be to get some experts on the line here. So today, I have two representatives from Star Micronics. They're one of the industry's largest printer manufacturers, and they do a ton of work with us here. I'll pass it over to you all if you want to introduce yourselves, say who you are, and what you do."

Mark (Star Micronics): Hi everyone, my name is Mark Rasho and I am the integration manager here at Star Micronics. We have one of our integration specialists here, Oreo.

Oreo (Star Micronics): Yeah, so my name is Oreo. Like Mark said, I'm one of the integration specialists here at Star. I usually work with software developers just to make sure that their solutions are integrated with the right approach.<div style=" display: block; float: right; padding: 1%; margin: .5%; width:30%; line-height: 175%;">
<img title="StarQA" width="100%" src="https://az417327.vo.msecnd.net/content/images/cache/tsp100ivlarge_560_420.png" alt="StarQA" />
</div>

POSGuys: Well, thank you all so much for being here. I really appreciate it. So I'll start us off here. It's my understanding that there are two main approaches when you're looking to develop a receipt printer for your point of sale software. You could either go with a native application or a cloud application, and both are pretty popular nowadays. The cloud is a little more popular now than it has been in previous years. Could you all explain very briefly what the difference is between those two solutions and what some of the pros and cons might be with going either way?

Star Micronics: Yeah, so you're right that there are two approaches to consider: the native versus cloud-based approach. With native applications, we're typically looking at an application that's designed for a Windows or Mac computer, similar to older library software that only runs on Windows. Native applications are limited to the operating system they're designed for, so if you design an application for Windows, it won't run on a Mac due to the differences in programming language and operating system.

On the other hand, cloud-based applications remove that barrier entirely. They can run on any operating system because they're accessed over the Internet. You simply go to the application's website and can do whatever you need to do, including printing and placing orders. Cloud-based applications are becoming more popular because they're a one-shot-and-you're-done solution, eliminating the need to develop for each operating system.

With native applications, you typically have a flexible connectivity type, including USB, USB Lightning, Wi-Fi, Ethernet, or Bluetooth. More recently, you'll probably see USBC, which Android currently uses and iOS is migrating to. With USBC, you have power delivery and faster communication.

The differences between Android, iOS, and Windows typically involve the cost of the devices, with Android being more cost-effective, and the extra step you need for iOS, which requires an MFi approval from Apple to have it in the Apple Store. Windows and Mac development is usually easier as you use the driver, but we also have an SDK that gives you more control compared to the driver."

POSGuys: At the end there, you mentioned that an SDK provides more control than a driver. Can you give an example of what that might look like?

Star: Yes, let me explain. When it comes to printing applications, one common feature is the ability to open the cash drawer. This can be done with both the SDK and the driver, but with the driver, you only have two control options: always open the drawer or never open it. That means on every transaction, the drawer will either open or stay closed.

However, with the SDK, you have more control. You can program the application to send the command to open the drawer only when it's a cash transaction, but not when it's a credit card transaction. That way, the drawer will only ever open when cash needs to be handed to the customer as change. This is just one example of why the SDK offers more control than the driver.

POSGuys: That's actually a really good example. I've been getting a lot of requests lately from developers looking to do something just like that, as well as from end-users. So that's a really good example.

Taking a step back, back in the day, Windows was king, and everybody had a Windows-based application. That was the bread and butter. Then we started to see these iOS applications pop up. And as Mark mentioned before, now Android is really big. So it's kind of at this point where customers, the people that are using the software, are expecting to be able to use that software from any device that they use. That's kind of the set expectation or the gold standard.

And I imagine with the native setup, you must have to develop a separate printing application for each type of device you want to run on, is that correct?

Star: Partially correct. It's not a hard requirement to create a separate application for every one of those platforms. That's something that's becoming popular these days with cross-platform programming languages like React Native, and you have .NET Xamarin or .NET Maui now, since they moved from Xamarin. With cross-platform applications like React Native, you can use one programming language, and with that, you can use that application on Windows, iOS, and Android. Yes, you are still creating three separate applications, but you're using one programming language, and that makes things easier. So one application you've already created for iOS can easily port to Android because it's just a wrapper around the programming language it uses to make things work on the other operating systems.

It depends on what your solution is and what exactly you have in mind for this solution. It's usually best to reach out to Chris guys; they will get you in contact with us, or you can reach out to Star directly. Then we would speak with you to get the entire scope of the project and then kind of go over what the best approach would be to develop a solution."

POSGuys: Yeah, that's a really good point. Okay, so keeping that in mind, let's take another step back and look at the other type of setup we were talking about before, which is a cloud application. Could you break down for the people watching this what a typical cloud application looks like and how it works?

Star: Cloud-based applications are usually hosted on a web server and can be accessed over the internet. The biggest difference between cloud and native being that native needs direct communication with the device or the same network. This isn't a requirement of cloud print as any device, including the printer with internet access, will be able to communicate with the server directly. Typically, there are two ways of connecting a printer to the internet: Ethernet and Wi-Fi. However, Star has created TetherLAN, which is for devices with a cellular application, such as a 4G or 5G device, tablet, cell phone, or hotspot. That device can provide internet access to the printer via USB cable, so there's no need to have it hardwired or connected to Wi-Fi. A 4G or 5G device is going to start being able to do that, and this is great for franchises who want a turnkey solution, as it opens up more options for them.

POSGuys: That's a really good point, and I imagine that gives the end users a lot more flexibility with how they want to lay out their stores. In this day and age, end users are expecting to be able to use the software in a number of different ways, and how the changing landscape of what a retail or hospitality application looks like is something that's really important for our people.

We've been in the weeds a lot technically speaking, so I wanted to kind of get us out of that for a moment. I know I see a lot of software developers and end users make some common mistakes, but I'm interested to hear from you all since you are working with these software developers every day. What are some of the really common mistakes that you're seeing ISVs making when they're starting to develop their software to work with your printers?"

Star Micronics: I think the biggest mistake that we see developers make or companies make as a whole when they're trying to develop point-of-sale solutions is that they bring up their drawing board to go about, 'Okay, what's this project going to look like? What are the timelines? Stuff like that.' But they never bring the printing portion in until the very end. So, I don't know if it never crosses their mind that they're going to want to print receipts for customers, but we typically see developers reach out to us when they're in that final stage. They finish developing everything, and now it's like, 'Oh, we got to print a receipt,' and then they're like, 'Okay, let's reach out to the different receipt companies to see, okay, can your receipt printer work with our solution?' This solution has already been made, so now we're stuck in the box of, okay, we have to make it work with their solution, right? What I would say is, if you bring the receipt companies in during that initial stage, so that we can see what programming language would be best. Some SDKs are in C-sharp or Java or whatever, and if you're using something completely different, then now you're forced to go find a third-party library outside to get your application to work with the printer. But if we're involved from the very beginning, not necessarily from the start of your project when the idea comes to you, but once we get to that stage of okay, we want to start developing, bring us in. Our integration team usually helps support the entire integration process, so the earlier we're brought on, the easier things get."

POSGuys: That's a really good point, you know. On my side, I can't even count on my fingers the number of times I've run into developers who come to me at the very last minute and say, 'I haven't done the receipt printer, and I have people that I need to present this to in a week. Can you help me out?' And it's really difficult. The other big thing, um, that my company personally deals with a lot is the Supply Chain management side of things. You know, and if you don't sort of keep in mind the supply chain from a hardware perspective, you know, especially with receipt printers, and we've seen this in the last couple years, and you develop for very, very narrow types of applications that require very specific printers, it can put your end users in a really tough spot, you know? And that makes your software not look good at the end, right, when they're not able to get the tangible things that they need to run a business. So, that's a really good example, Oreo. Thanks for bringing it up.

Star Micronics: And, uh, I think one other example is developers think every printer works the same, right? Or when they think of printers, they're thinking of the document printers, right, like the HP Laser, because everyone is used to like an HP printer, right? Everyone went to school printed with like HP printers, you have to go to the library to print stuff, so everyone is thinking of printers in that way, but that's not exactly how receipt printers work. They have the emulations that they use, the kind of commands that they understand, right? Some printers are image only, some printers support text, right? So, these are things you need to consider when developing your application because the final format of the contents of the receipts determines what printer you use, right? Because if you're, if when you're developing your application, you're generating the contents as images, then you can use an image printer, but with that, you can't use a text-based printer, right? So, those are the little things to consider as well before choosing a printer or how best to generate the data for the receipt.

POSGuys: Yeah, that's a good point. Perfect. Well, gentlemen, that sort of wraps up the list of questions that I get from most of my end users. And I really appreciate you all both for being here. If you're watching this video now and you have any other questions, I know this was a relatively brief overview, it's a big topic. So, if you have any questions about, you know, what sort of printers you should be using, what kind of application you should be considering, definitely feel free to reach out to us, POS Guys, and we can get you connected with Star Micronics and sort of get you off on the right foot from the very beginning. And that's super important, as Oreo had sort of explained. So, with that, thank you all so much for being here.

Star: It's been a pleasure to have you. Yeah, thank you so much. Appreciate it."

[1]: https://posguys.blob.core.windows.net/content/images/blog/79004/QAVideo.jpg

The Dos and Don'ts of Integrating Receipt Printers: Q&A with Star Micronics By: POSGuys - 3/20/2023

Recent Posts By POSGuys

The Dos and Don'ts of Integrating Receipt Printers: Q&A with Star Micronics
By: POSGuys - 3/20/2023