When Square released its first set of developer application programming interfaces (APIs) about five years ago, the focus was to attract partners able to give its sellers tools to more effectively manage their point of sale data.
The archetypical example, Square Developer Platform Lead Carl Perry, told PYMNTS in a recent conversation, was QuickBooks. Square merchants, he noted, were spending an “inappropriately large amounts of time” manually inputting their payments data in QuickBooks — something that could easily be solved by an API.
However, since then, he noted the Square development platform and its purview has grown and changed pretty significantly. What started with less than 10 partners, has now expanded to more than 270. The focus has changed too — from merely making the information within Square more easily accessible, to building a broader commerce and financial services platform that will let any developer create applications that help Square sellers better grow their business.
That thinking has resulted in developer toolkits such as Reader SDK, or the InApp Payments API released earlier this year, which opened developer access to its reader hardware and enabled in-app payments for merchants respectively. It is also what prompted the release of the launch of the Orders API earlier this month — consistent with Square’s interest in giving its sellers more omnichannel capabilities.
“We do not believe we will build every single solution that can help every seller improve their business, or that we even should. However, we can create the platform that lets any third party build any seller focused solution and then deeply integrate into Square and the commerce ecosystem it has built,” Perry said.
The Origin Of Orders
Square’s primary area of focus over the last few years has increasingly been on the emerging omnichannel market, and how to best help optimize its seller for it. Offering order online and pick-up in-store was the next logical step in building that capacity. It is a natural outgrowth of how merchants are already using their point of sale and how they want to be able to leverage in the future to make sure they can meet and serve potential customers wherever they happen to encounter them. Order, in short, he noted, makes it possible for sellers to use their POS product as an online and in-app fulfillment and management hub.
“What we have learned from talking to our merchants is that omnichannel is more than making a payment or sale in three or four different channels. That is just the beginning of the problem. What sellers are really looking for a solution that offers them a deep understanding of their sales across channels as a unified whole.”
By their nature, he noted, orders can be a complex undertaking — they can span multiple channels and even numerous payment methods at a time. Moreover, he said, the overall order journey and the data and capabilities required by it go beyond the simple payment experience. Orders, Perry said, represent “the long-lived cycle of the customer journey” from discovery, to purchase and through pick up.
“A payment can’t represent that entire life cycle. Making online ordering possible really requires an understanding that entire end-to-end journey.”
Today, he noted, developers often provide that experience by deploying multiple devices to manage orders and take payments — a bolted together experience that creates unnecessary inefficiency. The goal for Square Order API is to replace that fragmented path using their Square point of sale devices as online and in-app order fulfillment and management hubs.
Expanding The Payments Revolution
When it comes to their direct offerings via the developer platform, Perry noted, Square’s perspective is still very much the same as it was in its earliest days when it was rolling out its first point of sale device: create a revolution by making it possible for anyone to accept payments. What it means for that to be a “revolutionary” offering, however, has changed a lot since Square launched a decade ago.
“Just making payments possible is a starting point, the more we talked to sellers, and the more we understood their businesses, the more it became apparent that was the very tip of the need iceberg. The question isn’t if we are going to do more — the question has always been how do we expand out and also at the same time dive deep into specific domains with services for sellers.”
The answer to that question is twofold. The first is obvious: Listen to the seller and the developers and build the things they say they need. That is how every service Square offers directly through its developer platform came to be — merchants said they wanted and needed it. However, he noted, the reality they have also experienced is that they can’t build for every merchant need, and it isn’t even useful to try. But what Square can do is offer up the merchant ecosystem they’ve united around their POS devices and the kernel of commerce services they’ve developed in-house — an attractive conduit to business for developers who collectively really can build everything.
“Intentionally, Square has created an open commerce platform. Anyone can sign up to use our APIs, we don’t block anyone. A developer can sign up; a competitor can sign up. [It] doesn’t matter to us, we want everyone to be able to use these APIs and easily map them across systems.”
Some firms, he noted, will take Square of the box and use it to run their entire commerce operation. Others, usually larger firms, are less like to do that because they have legacy systems in place upon which their whole operation runs. They might have some use for some part of Square’s system — but aren’t looking to upend their enterprise entirely.
Square, Perry noted, is happy to do business with any seller — which is why they’re immediate future will look a lot like their immediate past; making it easier for any commerce player to tap into Square’s development ecosystem and integrate with their expanding menu of offerings.