The Power Of An API

Founder/CEO of HyperTrack — a community of logistics tech builders.

A small and scrappy team of engineers packed in a matchbox office room in Mumbai started tinkering with an API in 2012. By 2014, a category-leading public company in San Francisco had moved all new products to that API. This is a story of how that happened.

Remember the time when consumers used to say, "There must be an app for that!"? A decade after the explosion of mobile apps, we now live in a world where software developers say, "There must be an API for that."

Let me take you back to the early days of the API economy. In 2012, a handful of us in Mumbai were building a mobile payments app for restaurant diners in the U.S. Diners could see their itemized bill through a POS-connected mobile app, apply a tip, pay and go without waiting for the check. We had set up a POS system in the office to build and test the experience: Punch in the order as a waiter would, open up the app as the customer would, enter table number, see the check, hit the pay button and check back on the POS if it settled. Now we just needed a way to process the payment.

Having run India's leading e-commerce company at the time, I believed two things to be true about processing payments. One, you will always get lower rates when you cut out the middle man and work directly with the bank. Two, getting the payment flow right between all the parties involved is complex and important. Only one of those two would end up being true.

Our lead engineer came up to me, saying there is this YC company that had just launched a payment API that lets you charge a consumer on behalf of a merchant, take a cut of the transaction, authorize a different amount than what is finally captured and do all this in a private and compliant way. That got me interested because it seemed to fit my belief of getting the payment flow right, yet left me skeptical because it violated my belief of working directly with banks.

"This is just for testing while we build the product; we can always switch it out before we get big," the engineer reasoned. I played along, knowing that it is never as easy to switch out of an API as advertised.

Once the product was ready, we hustled to get a handful of restaurants in the San Francisco Bay area to install it so we could test the product in the wild and make live demos for business development. Our first targets were two-sided marketplaces that aggregated consumers on one side and table-service restaurants on the other. In 2013, the usual suspects were Paypal, Groupon, Yelp and OpenTable. We were fortunate to be able to demo to each of them, share a meal, wow them with the app experience and then walk over to the POS to check out the server's experience.

A few months later, we were acquired by OpenTable in an effort to bring this experience to a network of tens of thousands of restaurants and tens of millions of diners. As the launch date got near, there was a line of payment API startups, traditional payment processors, leading credit card companies and banks pitching to us for their business.

The API we chose easily stood out compared to other startups. Traditional payment processors had a strong desire to do what the API did, though they were too entrenched in legacy systems. Credit card companies could only offer solutions within their networks and could not directly compete. The closest competitor was a big bank that already had a deep relationship with OpenTable and was also the merchant bank for the payments API we were using. Remember my belief about cutting out the middle man; this was exactly the scenario. The myth was about to get busted.

The bank was confident that the API was for startups. We were now in the big leagues and needed a real bank. Though on closer look, their APIs looked like an internal system opened up to us as one of the first users — much harder to use than the APIs we were already integrated with. Though the most decisive part was that the way they would charge was a fee per card addition, per update, per auth, per capture, per settlement and so on. When you add it all up, it was more expensive than the API we were using. That's right: The middleman was cheaper than the bank they were using. It was mind-boggling for the bank, too. They lost the business.

A few months into the release, the API company played a decisive role in our product launch. New product initiatives within the company chose this API over other alternatives. Restaurants started asking if they could use the merchant account with that API to pay their OpenTable fees as well. The network effects started to play out.

This experience converted me into a believer in the power of APIs as a business. Our lead engineer's decision became a wedge in the lever that lifted the weight of a public company 10 thousand miles away. It is no coincidence that I now run an API business empowering logistics tech builders worldwide.

The next time you are building a software solution, think of how you can get to market faster and consider what part of the solution is infrastructure that might end up being a resource sink to own. Factor in the total cost to deploy valuable engineering efforts to build and operate that part of the system. Contrast that with the opportunity cost of market delays and inferior product experiences. When in doubt, Google it. There might just be an API for that!

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?