A Brief History of POS

Did you know the first cash register made in 1879 did not have a cash drawer? Yes sirree, this device was solely designed to keep track of the value and number of transactions – as to combat tally shortfalls by light-fingered staff from the cash box. The first machine was entirely mechanical and was dubbed: “Ritty’s Incorruptible Cashier”.  

In 1884 James Ritty sold the patent (granted the previous year). Later John Henry Patterson bought this patent and company and renamed the business as the National Cash Register Company – today we know this enterprise as NCR and it is the global pioneer of the Point Of Sale (POS) industry.

The first cash register was invented by James Ritty following the American Civil War. He was the owner of a saloon in Ohio, and wanted to stop employees from pilfering his profits. He invented the Ritty Model I in 1879 after seeing a tool that counted the revolutions of the propeller on a steamship. With the help of John Ritty, his brother, he patented it in 1883.

With the cash register becoming the single source of truth for the business owners, staff and customer business boomed in the early twentieth century. Cash registers got bigger and more ornate and were a treasured piece of equipment set on the shopkeepers’ countertop.

Adding A Bell To The POS Alerted The Store Manager To Money Being Added To A Cash Box Next To The Register Machine

NCR employee Charles F. Kettering Kettering invented the electric cash register in 1906, which made ringing up sales physically much easier for sales clerks.

During his five years at NCR, from 1904 to 1909, Kettering secured 23 patents for NCR. He attributed his success to a good amount of luck but added, “I notice the harder I work, the luckier I get.”

The NCR corporation also went on to invent the magnetic credit card strip and self check-out machines and refined the initial patent of the cash register to include a drawer to hold money and a paper roll for receipts. 

By the fifties, the retail industry exploded and business was booming as manufacturing increased post-second war. As a result, every well-respected business updated their Point of purchase machine to a modern model – that was electric and used liquid crystal display (LCD) screens, buttons replaced keys, credit card magnetic stripes, and thermal printing was popular options.

Doshii NCR POS

By the 1970s technology companies like IBM had identified retail and payments as an industry ready to adapt to their electronic cash register which is recognisable as a modern POS solution today.

The cash register now went from a glorified calculator with a drawer, to a powerful device that enabled large retail outlets to track sales, minimise register errors, collect inventory data and provide better service at the counter. In 1979 the bar code became widely used to be read by the scanner at goods receiving and checkouts to increment, decrease, price, track or replace stock. Software became sophisticated and by 1981 the first restaurant-specific POS was released. 

Fun Fact: A packet of Wrigleys Juicy Fruit chewing gum was the first item to be bar code scanned

Doshii API Barcode QR Code

In the mid-1980s touch screen was unveiled for the hospitality industry.

A decade later the operating system for POS was Microsoft Windows platform and later the Microsoft Opos retail platform was released. This is the API which connected many POS terminals with the retailers Point of Sale solution.

The First API Connected POS to Merchant Payments

OPOS, full name OLE for Retail POS, a platform-specific implementation of UnifiedPOS, is a point of sale device standard for Microsoft Windows operating systems that was initiated by Microsoft, NCR, Epson, and Fujitsu-ICL and is managed by the Association for Retail Technology Standards. The OPOS API was first published in January 1996. The standard uses component object model and, because of that, all languages that support COM controls (i.e. Visual C++, Visual Basic, and C#) can be used to write applications.

The OPOS standard specifies two levels for an OPOS control, the control object which presents an abstract hardware interface to a family of devices such as receipt printer and the service object which handles the interface between the control object and the actual physical device such as a specific model of the receipt printer. This division of functionality provides a way for the application development to write to an abstract hardware interface while allowing the application to work with a variety of different hardware. The only requirement is that a hardware vendor supplies an OPOS compatible service object with their particular hardware offering.

Typically a manufacturer of point of sale terminals will provide along with a terminal operating system an OPOS control object package with a software utility that is used to configure OPOS settings. Such a utility will specify the settings for an OPOS control object and indicate the service object to be used with a particular OPOS profile. When the point of sale application starts up, it loads the OPOS control object and the OPOS control object, in turn, loads the service object specified by the current OPOS profile. The Windows Registry is typically used as the persistent store for device settings. The hardware device manufacturer will normally provide a utility for device-specific settings used by the service object.

In 2010 the iPad became a popular mobile device to feature in stores and restaurants and the software to run the preferred POS solution relies on connectivity to remain in the cloud. Transactions occur in real-time and payments can be taken at the table or away from the counter.

Starrtec Tablet API Integration Image Doshii

Since 2016 POS has become the centre of an omnichannel platform that can connect and integrate with a number of useful Apps and management tools for venues to customise their customers experience and manage their staff, inventory, reputation, loyalty programs, pricing and analytics. 

Doshii Omni-channel POS

Observation: With the world becoming less dependent of coins and notes and most transactions now occurring via debit, credit cards or mobile wallets the cash register may no longer require a cash drawer at all in the near future.

With Doshii venues are able to connect to what matters to them most. Seamlessly processing bookings, orders, payments, gift cards and providing analytics from their point of sale system.

Learn which Apps can bring your venue more revenue with Doshii – Sign Up For Free Today


View The Doshii App Marketplace Here

Get into contact today and get connected with Doshii

Everything about API Integration

Doshii CTO, John Twomey, has been working on a blog series covering all aspects of API Integration.  The first articles of the series have been released. For more on this series make sure to follow us on Facebook, LinkedIn, and Twitter, or sign up for our newsletter.


What is API Integration

API Integration Basics

Architecting Multiple integrations via one API

App Integration Challenges

POS Integration Challenges

API Integration Best Practices

Data Modeling Best Practices

Business Logic Best Practices

API Integration Maintenance

API Integration Real-Time Communication

Feeling Stuck?

API Integration Security…coming soon

Integration Monitoring…coming soon




What is API Integration

Application Programming Interfaces (API’s) provide a documented pathway for accessing the features and functionality of third-party systems through a (typically) stable and controlled interface. By leveraging API’s effectively, a developer can quickly and easily integrate with or expand upon a preexisting external system.


API Integration Background

Prior to the widespread adoption of web-hosted REST/HTTP API’s, service-oriented architectures, and other supporting aspects, integrating with a third-party solution could be a mammoth undertaking. In the worst-case scenario, it could mean attempting to reverse-engineer a way to communicate with the system using disassemblers, packet sniffers, and similar tools. Often this would mean dealing directly with the solution’s inner workings, with no guarantees that its core business rules would be enforced should a developers’ code accidentally break them. Often the next update to the software being integrated with would break some or all of the integration, requiring hasty and sometimes extensive revisions.


Such is the developer’s world in the absence of a published API. And such is the importance of having, and being able to effectively use an API. What an API brings to the table is an officially supported, documented, (hopefully) stable, and (hopefully) safe roadmap for integrating with an external system. APIs provide access to a service through a consistent interface, regardless of the technology being adopted by the client


In our case, we at Doshii have a common interface into all of our POS, regardless of their underlying technologies, allowing Apps a re-usable communications layer to interface with POS systems.


Gone are the disassemblers and the packet sniffers, and the need for the developer to worry about any of the system’s business logic, security constraints, or other internal machinations. If the API is well-managed (not every API is), breaking changes should be a rare occurrence that comes only after plenty of warning. In essence, an API frees a developer to focus purely on their own solution and allows them to talk with external systems in a safe, secure, and maintainable way.

Modern Era

The importance of being able to understand and work with third-party API’s had only increased as technology has trended towards a more cloud-based, SaaS-oriented model. Even with small projects, giving users the option to authenticate using their Facebook, Google, or Twitter account is nearly a de rigueur requirement these days, with far deeper integrations hardly uncommon. And with a huge budget and a large team of world-class hackers maybe you could find your own way into the massive and extremely complicated systems operated by these top-tier technology companies. But why would you bother, when every one of these companies provides a public API supporting authentication (amongst a myriad of other things)? The only answer is that you wouldn’t, and it would be crazy to even try.


Instead, you would check the published API’s, and quickly discover that all three companies have authentication API’s standardized around something called OAuth2. And you would integrate using that, confident that your integration will be secure, stable, and maybe even flexible enough to accommodate any other OAuth2 provider out there. And after that, the sky’s the limit. Want to integrate with Slack? There’s an API for that. Or maybe Jira? There’s an API for that as well. Or maybe you just want to sell some stuff from Amazon or stream some cool music. All of that can be accomplished, and in every case, it’s accomplished by using a published webservice API. So, as we move into the modern era of distributed, cloud-based solutions, the answer to almost any question is “there’s an API for that”. Being able to navigate, understand, and leverage those API’s effectively is key.


With Doshii this means that:

  • No matter how many businesses you connect with through Doshii, you only need to maintain one integration
  • You can be sure of a stable Interface where any changes will be announced in advance and backward compatibility is of paramount importance
  • Detailed documentation of an existing standardised connection
  • Simplified process for development and integration
  • An experienced API Development team available for support, consultation, and implementation
  • Allow your development team to focus on product development rather than integration and maintenance
  • You have confidence in a trusted, secure connection
  • And a Dashboard to monitor all your integrations and help troubleshoot issues

Get Started With Doshii


Back to Top


API Integration Basics

APIs can come in all shapes and sizes. However, most successful APIs follow similar patterns in terms of structure, security, data formats, and protocols. Understanding these key aspects can be the difference between a successful API integration and hours of frustration.


Features of an API Integration

While there exists a nearly endless series of options with respect to how to create an API Integration, most webservice APIs will be defined by a handful of key features.



Most typically, a webservice API will be accessible over HTTP. This isn’t a given as technically anything accessible over the Internet may be classed as a “webservice”, however it’s generally a safe assumption. Webservice APIs that use any other strategy are quite rare, outside of the embedded-device space.

Slightly more common is layering a higher-lever protocol on top of HTTP, such as SOAP. While once quite common and still quite relevant in the .Net sphere, this strategy has been gradually losing ground to smaller and lighter APIs that run directly over HTTP



The most common approach to structuring a HTTP-based webservice API is called the RESTful paradigm. A significant topic in and of itself, in essence, this approach means that different HTTP Verbs are used to perform different operations. For instance, you might need to use a ‘POST’ request to create something, a ‘PUT’ request to the same URL/endpoint to update it, and a ‘DELETE’ request (again to the same URL) to delete it.

How closely a wbservice follows this approach varies widely. Some keep it formal and expect the integrator to be fluent with their ‘PUTS’ and ‘POSTS’, ‘GETS’ and ‘DELETES’. Others may take a more middle-ground approach and follow a simplified “use ‘GET’ to read, and ‘POST’ to write” pattern. Others may be more laissez-faire about it and take an “all (or most) operations can be performed using both ‘GET’ and ‘POST'”, leaving the integrator free to do whatever is more convenient on their end.

Generally, any pattern is fine, so long as there is one. A quality API will not stipulate arbitrary REST-related requirements with no discernable rhyme or reason.


Response Format

Although APIs have used (and will continue using) a variety of data formats, with public webservice APIs XML and JSON are the dominant players by a wide margin. Although XML was established first and adopted into pretty much everything back in its heyday, it has been rapidly losing ground to the lighter-weight and more human-readable JSON.

Many APIs will allow an integrator to choose whether they want to receive their response in XML or JSON. Where only one format or the other is offered, it’s often possible to judge the age of an API by the data format it returns; XML tends to be preferred by older webservice APIs, and JSON is more common in newer APIs. Some high-level protocols, such as SOAP, may essentially dictate that one format or another be used.

In general, however, if you’re comfortable working with XML and JSON you’ll have no problems talking with most published webservice APIs.



For a modern webservice API integration SSL is the de facto minimum standard when it comes to security. Some APIs may layer additional security on top of this, such as request signing and other cryptographic techniques to verify the origin of the request and guarantee that its contents haven’t been tampered with. For instance, Amazon operates all of their APIs over HTTPS and in addition to that requires API consumers to implement a fairly involved request-signing algorithm.

As a general rule, however, SSL is “secure enough” for an API integration and represents the common starting-point for most webservice APIs. Requiring additional security over and above what SSL offers is somewhat rare, and often costs more in frustration than what it gains in added security.

While increasingly uncommon, it’s not unheard of for a webservice API to operate over plain HTTP with no encryption or other forms of security. This may be okay, but only if the API is neither receiving nor transmitting any personal user data or other sensitive information (including API access/secret keys!). If the API contains any sensitive information, you should not use HTTP!


Other Important Bits

While not part of the API itself, documentation is also of critical importance to an integrator. In the absence of documentation, connecting to an API is all but impossible. Without quality, consistent, up-to-date documentation the task can easily become a frustrating exercise in trial-and-error.

High quality documentation that uses consistent, intuitive terminology to explain concepts and important aspects of an API can be a critical factor in a successful integration. In the event you’re attempting an API integration and you discover that important API documentation is incomprehensible, inaccurate, outdated, or just plain missing, it’s a wonderful opportunity to take a step back and see if maybe there’s an alternative API available that can be used to accomplish the same task.

That’s why here at Doshii, we’ve created a detailed API integration documentation hub, which we constantly keep updated with guides for integrating with our platform. Check it out here


Putting it Together

Success as an integrator depends upon having a good understanding of the defining features of a modern webservice API. A solid knowledge of these basics will help when assessing the relative strengths and weaknesses of different APIs, so that the best candidate can be chosen and wasted time and frustration can be avoided. Combined with quality documentation this should help you quickly develop a clear understanding of

the API and identify any gaps between your own system and the API as early as possible so that any potential issues can be planned for and addressed.

To learn more about integrating with Doshii and to speak with our technical team, get in touch through our contact page.

Get in Touch

Back to Top

Architecting Multiple integrations via one API


The complexities of integrating with third-party API’s can quickly multiply due to the rapid proliferation of competing API’s and standards. This significantly increases development, testing, and maintenance time/costs, but can be mitigated against by integrating with a ‘middleware’ API that delegates to various third-party services.


The Proliferation Problem

While the rapid growth and adoption of webservice API’s and standards have been a real boon for the software industry, nothing comes without a cost. The cost, in this case, is a rapidly expanding and constantly evolving frontier in which there are often multiple offerings in any given domain, several of which often proving desirable candidates for integration.


As we saw in the previous articles What is API Integration, and
API Integration Basics, the answer to “How do I do X or integrate with Y?” is almost always “There’s an API for that”. However in many cases, the answer actually comes back more along the lines of “There’s 5 or 6 different API’s for that, which one do you want to use?”, and then as an app developer or POS integrator you have to choose. What’s the one API you’re going to integrate with? Or do you invest the time and effort that it takes it integrate with several of them? And the extra time it takes to maintain those integrations?


For Example

Say you’re creating a solution that allows a user to browse and purchase digital music from within your application. Amazon offers an API that will let you do exactly that. And so does Apple. And so do Bandcamp, Spotify, Murfie, and others. Each one may offer some catalog items that the others don’t. And wouldn’t it be great if your solution could seamlessly integrate with all of them?

Certainly, it would! But the cost of doing so is very high. Although each API ostensibly performs the same function, each one is independent and structured differently from the others. Where one codepath should logically suffice, you’re going to need five. Each one is going to have its own credentials, its own authentication strategies, its own API quotas and limits, and its own quirks that need to be smoothed over if you want your users to have a seamless experience. And once you’re done you’re going to have to track changes to each API and ensure your app is updated and maintained accordingly.


Thus the proliferation problem should be obvious. Unless you’ve got the development might of a Google, Apple, Amazon, or Microsoft there are more API’s out there than you can realistically integrate with. You’ve either got to settle for an integration with a single API and dealing with frustrated users upset that they can’t find any content from ‘API B’ within your solution, or else dive in and try to support as many parallel API’s as you think you can get away with.


A Better Solution

Imagine if instead of talking to a bunch of related API’s individually your application or POS system could talk to a single service that internally handled communication with each of those related API’s and then just shipped you the result. It might look something like this:


Doshii Industries API Integration


We’ve added a “middleware” layer that sits between your solution and the rest of the world. And now instead of talking to a whole bunch of completely different and differently-structured API’s your solution only needs to integrate with one API; the middleware’s. It’s connecting to the same amount of information, if not more, however, the complexity on the application/POS side has been drastically reduced. This carries with it a corresponding reduction in development, testing, and maintenance effort; or in other words, time and money.


Doshii Middleware API Integration Platform


You’ll notice that the middleware has a proper name. It’s called Doshii. Doshii provides API integration, management, and aggregation as a service. This frees up your time to focus on your actual product and saves you from having to worry about whether to integrate with one service or several and from the complexity and overhead associated with the latter option. And of course, it’s all accomplished through an API.


Strangely enough, it seems that the answer to the proliferation problem is yet again “There’s an API for that”. By leveraging a middleware API such as Doshii, your solution can gain the benefits of multiple parallel API integrations without any of the added development costs. There’s no longer a need to implement and maintain multiple codepaths that all accomplish the same logical task. And dealing with changes, updates, and maintenance as all of those API’s evolve? Well that all becomes Doshii’s problem; you don’t have to worry about it!


By placing a ‘middleware’ webservice between your solution and the webservices that it ultimately wants to communicate with, multiple integrations can be replaced with a single implementation and API proliferation becomes much less of an issue. The power and flexibility that this kind of solution provides are difficult to overstate.

Get Started With Doshii

Back to Top

App Integration

What to watch out for when integrating with Multiple Apps

Directly integrating a mobile app with pre-existing POS systems can present unique challenges not usually encountered when working with modern cloud-based APIs. These challenges can be both technical and business-oriented and tend to stem from the entrenched, walled-garden nature of most POS systems.

Read More

Back to Top

POS Integration

What to watch out for when integrating with POS Systems

To meet their business needs many venues will require integrations with various webservice APIs from their POS systems. While performing an individual integration does not generally pose any special challenge, small difference across APIs and schemas can quickly lead to increased complexity.

Read More

Back to Top

Doshii API Integration Best Practices

API Integration Best Practices Overview

There are a number of challenges that must be overcome when integrating with multiple external APIs. This article discusses some common design practices and patterns for doing so.

Data Modeling

The heart of any non-trivial application will be its data model. Ideally, you’re already using an ORM framework like Hibernate, ADO.NET, CoreData, ORMLite or one of a plethora of options for your particular technology stack, though whether you’re doing that or connecting directly to a relational database, or just writing your data out to some JSON or CSV (or proprietary format) datastore somewhere, some basic principles will always apply.


This first is that you should always model the state your application stores in terms of how your own business logic understands it. There are no bonus points for unnecessary complexity or convoluted relationships here. Just think about how your application needs to work with the data, what information it needs, and in what order it needs it, and go with the simplest design that works.


Once you’ve got a baseline data model that covers your core business requirements, it’s time to take a look at the external API’s that you’re integrating with and work out how they best fit into your model. The specifics will vary depending upon the features you’re providing, however at a high level what you want to do is annotate your baseline data model with additional fields provided by your external API’s. And you want to limit this strictly to those fields that are necessary for successfully communicating with your external API’s.


For instance, maybe an external API provides ‘Order’ fields like ‘orderId’, ‘purchaseDate’, and ‘revision’. In most cases ‘orderId’ will be the only field from that list that you actually need to add as a field in your data model. The rest is just noise that you’re better off ignoring.


API Integration Best Practices Doshii

Business Logic

Your business logic is the bridge between the persistent state within your data model and your application’s UI. It’s the glue that holds the app together and allows your end-users to accomplish useful things.


Having modular, extensible, and maintainable business logic is critically important to the long-term success of an application, particularly in the case of an app that relies upon multiple external API integrations.


When implementing your business logic, try to define logical operations based upon how your solution needs to work with or upon objects from its data model. Ensure that these operations broadly follow the principle of single responsibility; which is to say don’t have a ‘registerAccountAndPlaceOrder’ operation when you could instead have separate ‘registerAccount’ and ‘placeOrder’ operations.


Keep each individual operation as focused and concise as you can get away with, and allow more complex tasks to be defined as a series of operations. It may seem like a small thing, however putting in the effort up front to ensure that your business logic is focused, concise, and modular makes things much easier when the time comes to start wiring in external API’s.


API Integration Best Practices Data Doshii

Layering Abstractions

There’s an adage in computer science that goes roughly along the lines of “any problem can be solved by adding another layer of indirection”, and at a fundamental level, this is correct in regards to the problems introduced by external API integrations. We’ve already touched briefly on the broad classes of problems and challenges typically encountered in this space, and now that your application has a fit-for-purpose data model and some well-structured business logic we can look at some common solutions.


Business Logic -> Data Model

The majority of external API’s that you integrate with will act as data sources for your application. You’ll pass them a search query and they’ll send back a list of matches, or you’ll tell them to perform an operation and they’ll send back some JSON or XML describing the result. In most cases, you need to keep track of this information.


The problem is, of course, that even within the same category/domain/problem-space, every external API you integrate with is going to have a completely different data format. Even when they’re all describing logically the same thing!


To solve this, the first layer of abstraction you’ll want to add is one that sits between your business logic and your data model. This layer should be able to accept as input the raw data from any of your supported API’s and produce as output a populated, normalized object ready for insertion into your database.


Which is to say, if your business logic implements a ‘placeOrder’ operation, and this operation delegates to an external API for actually placing the order, then you should have a layer that can accept the raw order data from the external API and return an ‘Order’ object suitable for insertion into your application’s database.


What this setup does is it frees your ‘placeOrder’ operation, your data model, and any of your business logic that later interacts with the ‘placeOrder’ result from having to know anything about the external API that was used to actually place the order.


This means you’re now able to switch to a different API provider and/or connect additional API’s without needing to modify any of these things. The required changes are limited solely to the translation layer sitting between your business logic and your data model, which is hugely powerful and gives your app a great deal of flexibility!




Business Logic -> External API’s

At this point, you’ve solved the problem of getting information from an external API into your local data model quickly and easily and without needing to have tons of API-specific code sprinkled around throughout your application. That’s great!


However many external API’s will require an object to be carried forwards across multiple calls as part of its business lifecycle. For instance, maybe your user wants to cancel that order that they placed using ‘placeOrder’. The external API will likely provide a ‘cancelOrder’ feature, but in order to work it’s going to need to receive the object that it originally sent to your ‘placeOrder’ operation, and of course, it’s going to expect you to send that object according to its internal requirements. So we’re not done just yet.


The next layer of abstraction that you’ll want to add to your app is one that sits in between your business logic and and external API’s it integrates with. This layer should be able to take as input an object from your data model (in your internal format) and an operation (like ‘cancelOrder’), perform that operation by making the necessary API call(s), and then return the API response as output.


With this setup, your business logic remains free to work purely against its own internal representation of its data. All the mapping and translation that’s required to convert an external API response to an internal data object (and vice-versa) is handled by additional layers designed for that one specific purpose.


This keeps your core application code clean and focused, and again makes it very easy for you to swap out or add additional API integrations as your requirements change. This is very powerful, and all comes thanks to the addition of two relatively straightforward layers of abstraction.



Rinse and Repeat

Done correctly, the steps above should allow you to easily connect to additional external API’s that fit in the same category as the one(s) you’re already interfacing with. To connect to a new category of API’s (for instance, to enable a completely new in-app feature), simply repeat the process as needed. This does add work, but if you focus on only implementing what you need and adding features only as required rework can be kept to a minimum and the impact of breaking changes to an external API can be mitigated, if not avoided entirely.


Also, note that there may be various supporting bits and pieces that need to be tacked on in support of the layers described above. In particular, this may include things like configuration, credential management, and request signing for each individual API. Where possible this should be abstracted out to its own layer (yet again), so that these functions are decoupled from your core business logic, allowing either to change independently with minimal impact to the other.

Back to Top

API Integration Maintenance

API Integration Maintenance

How an API Platform dramatically reduces development costs when scaling

Whenever a third-party API is integrated with an application, long-term maintenance concerns arise. These concerns can be different depending upon whether a direct integration is performed or a middleware layer is deployed between the application and the third-party API, and the differences can factor when deciding which approach to pursue. In this article, we’ll provide an overview of API Integration Maintenance, and some things to consider when integrating.

Read More

Back to Top

API Integration Real-Time Communication

How Doshii enables real-time async communication between Apps and POS

API Integration Real-Time Communication

WebSockets provide a persistent, socket-like connection between two endpoints. Learn how webSockets and webhooks can be leveraged to reduce overheads and improve performance/responsiveness within an application. In this article, we’ll provide an overview of API Integration Real-Time Communication, and how webhooks and websockets help in bridging the communication between a server and client.

Read More

Feeling Stuck?

Doshii offers an out of the box solution that can provide your application many of the same benefits discussed above with only a fraction of the coding time, effort, and expertise required. We’re here to help so please don’t hesitate to get in touch for more information.


Get in Touch

Back to Top