Reforming Retail

Supreme Court Rules Against Apple’s App Store Fees. This Is Bad News for POS Companies with API Fees

This article is the final part in a series that discusses the dynamics around APIs, integrations, and fees in the SMB world. Here are parts one, two, three, and four.

After an 8-year battle consumers finally caught the break they were looking for: the US Supreme Court ruled that consumers could sue Apple for monopolistic pricing practices over their App Store fees. For a quick refresher, Apple adds a 30% tax on any paid app in their App Store.

The specifics of the issue are a little more murky. In legalese, there was a case in 1977 that pitted The Illinois Brick Company against the State of Illinois. The long and short of it was that brick manufacturers were colluding to increase the price of bricks. The state of Illinois sued and the US Supreme Court ruled that only entities that were directly harmed by the purchasing of bricks could sue; other entities had no standing since they were directly unaffected.

Well, this US Supreme court ruled that consumers were “direct purchasers” under the App Store model while Apple contended that app developers were the direct purchasers. The Supreme Court treated Apple, a platform, like a retailer and broadened the application of direct purchasers.

Apple’s main argument was that their developers were their direct purchasers. Apple would tax these developers and it was up to the developer to decide if they should pass along the cost. Since we’ve never known any private business to simply eat higher COGS without passing along the cost to customers, Apple’s argument is a bit specious. Apple, it seems, believes customers should take up the 30% price hike with developers, not with Apple. The Supreme Court thought differently.

While this ruling just kicks the case back down to the district courts to be re-litigated, the implications here are massive. As far as our readers should care, this ruling holds tremendous learnings for the POS industries and their little app store/API fiefdoms.

In the old days, integrating to POS systems meant deploying a piece of software locally on a server, where all the merchant’s data was held. Maybe you’d get some technical help from the POS provider, but often times you’d need to rely on a savvy reseller who knew the POS system to help you find your way around the file structure.

As time marched on and merchants started waking up to the value that wasn’t being developed by their POS companies – think loyalty, analytics, and more recently online ordering/delivery – they expected their POS to change from overlord to gateway.

Many POS companies embraced the future and built APIs for third party connections. Some of the POS companies rightly viewed APIs as a cost of doing business and invested in the infrastructure under the notion that openness would prevent existing customers from leaving. They also rationalized a secondary benefit that their platform would be more appealing to prospective clients who wouldn’t need to compromise with limited integration options.

Then there was another contingent of POS companies who viewed their API as a way to extract even more financial pain upon their customers. When you’re a hammer, everything looks like a nail, right? Lacking any innovative bone in their bodies, these companies proudly came out demanding material percents of revenue from any third party that needed their API for connectivity; it didn’t matter if the POS company was sourcing or supporting any of the third party customers, either.

We’re free market people, and if these POS companies want to behave this way they’re totally within their rights. But the problem comes in the inherent stickiness of POS.

POS is the nervous system for a merchant. It runs operations, marketing, finance, and all the minutiae underneath each of those categories (labor scheduling, forecasting, payroll, et al.). Pulling out a POS can often be likened to the surgical removal of a vital organ: yes, it can be done, but it’s a slow and painful recovery, and without sufficient preparation it will end very badly for the patient.

When many merchants procured their POS systems – particularly the larger chains – the world was much simpler. There was no such thing as Grubhub or DoorDash. The POS wasn’t the integral connector it is now.

Accordingly these merchant couldn’t have known how their POS would behave when the market changed and the POS did become the central hub for integrations because there was literally no contractual language to serve as a harbinger. With hindsight 20/20, many of these merchants would never have aligned themselves with such greedy POS vendors. Here’s a quote from a C-suite executive of one of NCR’s largest table service customers.

NCR charges us for every third party integration, and we have many. Switching to a cloud POS might actually be less money than we’re paying Aloha in integration fees alone. If it weren’t so hard to replace we would have switched a long time ago, but I’ll tell you this issue is the number one item the board is discussing right now.

Large table service NCR Aloha customer

Here’s a great analogy to demonstrate how frustrating this is.

Imagine you need a pacemaker. You do your research, talk to your physician, and choose Brand A. The surgery goes well and you’re feeling great. Three years later, Brand A decides they need to make more money. Instead of investing in a firmware upgrade, they decide to start billing you per heartbeat. If you don’t like it you’re free to schedule another surgery to replace their pacemaker with one from a different brand.

Sounds fair, right?

This is the problem we have with the situation. Yes, these POS companies have every right to rape their customers for more money (and let’s not pretend the cost to support an API is material), but they do so knowing how hard it is for their customers to flee. Replacing a POS in a larger establishment really is akin to going under the knife, so the market is not exactly elastic. Long term the market will remedy the bad actors, but in the short run it’s very painful.

We think there are three categories of POS providers that merchants need to be most concerned with:

  1. POS companies that refuse to innovate and thusly need any source of “growth” they can find (NCR)
  2. POS companies that have taken so much capital they’re going to need to find other ways to generate revenue (maybe Toast)
  3. POS companies with only one payments processing option that view the POS as a method to prevent payments churn, not a critical business tool

If POS companies want to charge for their API, they’re going to need to supply some value. Any POS company that acts like a payments processor is one we’d keep as far away as possible. The next class action firm might just look at greedy POS offenders with the same knife and fork they took to Apple.

Maybe the US Supreme court will be ruling on the nefarious POS actors before long.

Add comment

Archives

Categories

Your Header Sidebar area is currently empty. Hurry up and add some widgets.