Reforming Retail

Why Processors/POS Need A Universal API to Stay Alive

We published a provocative article with help from our friend Gregory Puff that detailed a coming decline in processing revenue for brick and mortar merchants. This article, which is requisite reading before going further here, explains why merchant acquirers need to be hyper-aware of the happenings in mobile ordering (not to be confused with in-store, mobile payments) because it comes with a hefty price tag.

In the near term mobile ordering is going to consume processor revenues at the POS. Make no mistake about it. We anticipate this could be upwards of 30% for merchant acquirer revenues in the restaurant vertical over the next 5 – 10 years, and possibly higher for retail as it continues its move to omnichannel.

How do acquirers stem the bleeding?

It all starts with POS.

Bidirectional integration to POS systems are becoming easier – and standard practice – now that POS companies are investing in APIs (20 years late is better than never). But unless you control the POS asset the API might be horrendously built (if you’ve seen data structures for legacy POS systems you’ll know how bad engineering often was) or the POS might even charge you for an integration. To mitigate this risk processors must have a POS asset that they know they can integrate into easily, and the best way to accomplish that is to either own a POS or have a very close and strategic relationship with one.

So now that you’ve got a POS, what do you do?

Before we give a direct answer we’re going to use Apple as an example to really get the point across. Did you know that Apple has spent billions working on a maps competitor to Google Maps? But how many of you actually use Apple Maps as your go-to map solution when way-finding? Sans Apple fan boys the number of raised hands is likely 0.

The reason is that people – especially consumers – love best of breeds. They also love aggregators. Here’s a list of the top apps for iPhone in 2017. Notice how not one retailer makes the list? Amazon is the only “retailer” on here but it’s really an aggregator of ecommerce for tens of thousands of third party sellers.

Another way to look at this is by examining Yelp’s monthly mobile app users, at 29 million, and compare that to any large restaurant app, like Pizza Hut, which only has 2 million downloads. We chose Pizza Hut because they’re the largest pizza brand and pizza is a restaurant category associated with high volumes of online/mobile ordering.

What can the acquirers learn from Apple’s maps experience and the restaurant industry case study on aggregation?

To save themselves the payments industry is going to need to ban together for a universal API.

For starters, a native ordering app from the POS/processors can integrate into the POS system. This means orders passed through the ordering app will hit the processor’s rails to get them their pound of flesh. So we would encourage all acquirers to starting thinking about an ordering app that’s either an additional fee (as Toast has done) or free (as Heartland has done with Xenial).

However, legacy POS and payments companies have struggled to build decent software: it’s just not in their culture or DNA. So the best bet is to either acquire or partner with an online ordering solution and white label it. By the way, third party ordering aggregators with hefty commission fees are simultaneously making your sales job for your ordering app easier, too.

This non-software culture is only magnified when you realize that the processors will need to get consumers to download their ordering app. And if we’ve learned anything from the comparison to Yelp and Pizza Hut it’s that consumers seek aggregation, which presents us with another problem.

The US restaurant POS market is still massively fractured. Shift4 and Heartland/Global have brought some consolidation to the table but if we believe there are 650,000 US restaurants then each of the above acquirers only represents about 15% of the industry. (Retail is a totally different ball game and we still don’t know why nobody has made a POS aggregation play there yet.) If Heartland or Shift4 were to create an online ordering app for their restaurant customers, what are the odds that a considerable number of consumers pick it up? Wouldn’t consumers be more likely to use the app if they could find many more restaurants?

Welcome to the prisoner’s dilemma.

In a nut shell the prisoner’s dilemma is game theory that helps explain why competitors who should rationally cooperate refuse to do so. In this case the POS and payments companies who can pool together to achieve critical market share for an aggregated online ordering app will likely find friction at the idea of working together even though we can clearly see how 30% of their collective revenues are at risk.

For the record (and for some humble pie) we actually tried our hand at getting a universal API started in early 2017 but failed to get traction. Put simply, there were too many POS players. The payments market is thankfully consolidating the POS industry – so there are fewer cats to stuff in the bag – but now you’re dealing with a different kind of problem child.

Will the industry come together to solve this material problem?

The game plan is pretty straightforward from where we sit.

  1. Create a JV among the larger players. Have them each seed some capital for a place on the cap table and get a third party entity spun up to be responsible for the neutral, white label online ordering app. Leave enough room in the cap table to incentivize the management team and make it attractive for follow-on investors if needed
  2. Distance the JV from the non-software/data culture of their payments/POS owners. The reasoning is pretty straightforward here
  3. Each of the founding companies of the JV must appoint a technical counterpart from their company that can assist with documentation and development to their POS assets. This role is to liaise the JV’s efforts, not to develop the application; but they must have power to put items on the engineering roadmap of their own company
  4. Once the application is complete the POS/payments partners must start pushing the application through their channels. The goal should be to get as much adoption among merchants as possible, even if that means sacrificing the small amounts of monthly app revenue at first. Remember, we’re trying to preserve 30% of your net revenues that are otherwise disappearing!
  5. The JV is responsible for a B2C strategy. It can use the rolodex of its investors to develop syndication agreements with the usual suspects: Google, Microsoft, Apple, Yelp, and others
  6. If the app becomes successfully implemented the business model can change and new revenue streams are possible. Since integration and distribution costs have been solved, the app can be a flat fee or a small percentage of order volume and still be materially more economic than other third party ordering  aggregators
  7. Rinse and repeat for reservations and other brick and mortar products that need a two-sided marketplace

Will payments companies do this? No idea. They probably won’t even think about these things until interchange starts nosediving – and it eventually will. But by then the underlying cause of interchange’s decline will likely be the same entity that closes the door on these opportunities. By that we mean the entity that eliminates interchange will, by definition, need a two-sided platform between merchants and consumers at scale.

At that point there’s nothing keeping this entity, which we very much think could be Amazon, from developing any number of consumer applications for ordering, reservations, and who knows what else. In fact, Amazon already has a head start.

So do we bet on Amazon to disrupt brick and mortar payments faster than the processors can work together to build software? The odds should be 20-1 in the acquirers’ favor, but that’s only if we assume logic prevails. The prisoner’s dilemma shows how that can be a dangerous bet to take.


Add comment

Archives

Categories

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