![\"\"](\"https:\/\/i0.wp.com\/reformingretail.com\/wp-content\/uploads\/2017\/04\/417346-back-up-your-cloud-how-to-download-all-your-data.jpg?resize=770%2C433\")
<\/p>\nThe good ol’ days of integrating to legacy POS were plenty painful… and pricey. Extracting data was not so complicated as was the injection of data – say from online ordering.<\/p>\n
Cloud, much to its benefit, makes these troubles a thing of the past.<\/p>\n
Maybe.<\/p>\n
<\/p>\n
The costs of integrating to legacy POS systems stemmed from two main sources.<\/p>\n
First, there was the issue of market fragmentation. There are over 280 restaurant POS softwares in the US. I have yet to find anyone who can produce a similar figure for overall retail softwares but it’s surely at least five times as large given a highly stratified retail industry. And the 280 figure doesn’t include POS systems that are too small to track… it could very well be in the 500-1,000 range for domestic hospitality software alone.<\/p>\n
Added to this is the fact that POS companies (ISVs) were stingy with both their dealer lists and their customer lists. This means a third party services provider – let’s say an online ordering company – would aimlessly call prospective customers until one was interested. Once they had a fish on the line they would need to figure out what POS they were using, and how to get into the files. Which brings us to our next point.<\/p>\n
Second, most POS companies were cloistered about their systems and database schemas. In order for the online ordering company to know how to pull data out and push data in, they needed to learn what the database looked like and how to write to it without corrupting up the files. The POS companies were of very little help here (with notable exceptions like POSitouch), though there were a few that viewed the online ordering company as an opportunity to earn $50,000 for some pages of documentation.<\/p>\n
The online ordering company would then get frustrated and “hack” their own integration to the POS. All of these different hacks – usually a software agent downloaded locally to the POS database – had associated costs. Naturally the laws of economics went undenied and this ISV behavior led to increased costs for the online ordering company which were then passed to the merchants. Ironically, these selfish positions will spell the demise of legacy POS as we know it.<\/p>\n
Now that cloud is in full force, it will be fascinating to watch how they evolve. While the architecture of cloud POS allows for easy technical integrations via an API, will that integration be free?<\/p>\n
Here’s an example to consider.<\/p>\n
The same online ordering company finds a merchant interested in their solution. That merchant is using cloud POS X. The online ordering company is relieved to learn they won’t have to build and support a hacked integration agent to transmit data, which ultimately means lower costs for product delivery.<\/p><\/blockquote>\n
So is the integration to POS X free?<\/p>\n
There are two sides to consider.<\/p>\n
From the perspective of the online ordering company, they sourced and sold the merchant. They’re willing to do some technical lifting to ingest the API from POS X to deliver their solution, and that has associated costs. But they must also recognize that ingesting an API is not only a much tighter integration, with lower risks for corrupted files and lost data, but a cheaper technical effort than building and supporting a hacked POS integration agent.<\/p>\n
From the perspective of the ISV, they’re building and supporting an API architecture to enable seamless third party integrations, and that has associated costs. But the API reduces significantly the number of troubleshooting calls they’d otherwise receive in dealing with a merchant using a hacked POS integration. And being able to market your easy integrations to a bevy of third party solutions becomes valuable positioning in your sales efforts to merchants.<\/p>\n
I’m not sure there is a right answer here.<\/strong><\/p>\n
So long as the cost of integrating to a cloud POS is less than the third party company would have spent on its own hacked POS agents, it would seem like a good financial deal. On a perpetual revenue share basis – as is the case for most POS app stores – it’s probably cheaper to support a hacked POS agent, however.<\/p>\n
It probably boils down to how ISVs view their position in the ecosystem. Is developing a solid architecture with API integrations a cost of doing business? Does charging third parties for access make their products more expensive to your merchants and thus put you at a disadvantage?<\/p>\n
The jury is still out. Only the market will reveal which way this ends.<\/p>\n
<\/p>\n
<\/p>\n