At Square, prospective API partners can get an API key without talking to a human. At many other POS companies this is also true: there’s a self-service model for third parties that wants to integrate while strategic integrations are sourced by POS staff. This approach drastically simplifies complexity for the POS company, third parties, and even the merchant.
Don’t believe us?
What follows precisely demonstrates why you shouldn’t take any other approach to your API.
The full article can be found here; the article discusses the migration to cloud POS and why it’s happening. Note – you will need a login (it’s free) to read the entire article. That said, we’re pasting the relevant text from the article below.
Matt Eisenacher, chief concept officer for the 42-unit fast-casual chain, said the off-premise revolution has created multiple options for delivery. But it’s also created a “pinch point” at the POS level because the chain’s legacy POS provider must approve all integrations. Tired of the bottleneck, Piada found a way to “hack” the system by creating their own “middle-ware” that talks to its back of house and front of house systems.
Mr. Eisenacher was much kinder than we would be in his situation: he is not outing his current POS provider (it’s Aloha). He is likely doing so because he knows all-too-well how this large POS company could screw over his business. In being so diplomatic Mr. Eisenacher is downplaying the real problem with this legacy POS company’s API model:
It hurts everyone involved.
First, this API model ironically hurts the POS company. It should be clear that merchants like Piada are now associating this integration pain with their POS provider, especially since finding a substitute POS with open APIs is no further than a Google search away. Not only that, the integration process costs the POS company more money: by approving every single integration the POS company is tying up resources that could be better spent chasing material partnerships.
This slow approach hobbles the expanded functionality of the POS meaning the POS company will need to explain why certain features cannot be made available to merchants using their systems. This in turn lowers the POS company’s sales and competitive positioning; it’s why this particular POS company has seen a 15% decrease in sales over 2018.
Second, the API model hurts prospective partners. This particular legacy POS provider must approve every single integration partner. That takes a lot of time. To cover that cost this POS provider charges a 30-40% perpetual revenue fee just for approval. So if your solution is priced at $100/mo per store, $30-$40 will be going to this POS company just because they’re a POS company. They’re not selling, supporting, or otherwise helping the partner. What a winner proposition, eh?
The only silver lining in this particular instance is that the data for this legacy POS provider is available locally – if it had been a cloud POS a partner would be forced to work through this “partnership” model to access merchant data. Naturally, third parties are telling end-customers how unworkable the POS “partner” is and that’s undoubtedly contributing to the sales decline this POS company is experiencing.
Lastly, the API model hurts merchants. As should be obvious in his quote, Mr. Eisenacher has to bear the costs of “hacked” integrations to get solutions to work. That occurs because the market works around inefficiency, in this case manifested as the POS company’s API model. Merchants under this POS provider must also bear the increased costs that stem from that 30-40% tax. If you think the third party provider is going to swallow the tax, you’re crazy: it’s being passed along to the end-merchant.
Accordingly merchants that choose this legacy POS provider are confronted with significantly fewer options. This eventually becomes a death spiral as customers flee, and we believe we’re witnessing the early stages of that now.
The takeaway here is to be in the business of being a value added partner. Don’t strangle innovation because you can’t do it yourself.
Interesting you didn’t go on to explain that while you can easily get the Square API, if you build the integration it will need to be listed in their marketplace where it is subject to the same fees as NCR/Aloha. (I believe it is currently at 25% of the MRR)
ADP has the same program and so do many others. I think the elephant in the room is that the API for many of these POS companies may not provide what many require for full integration and once the development begins, there are many who ask for fees to “certify” the integration, “maintain” the integration and “support” the integration.
In essence, while the API’s are “open” the integration may not be. Restaurants could look for vendors who have multiple POS integrations and work with them to get access to the POS data they need.