Commerce APIs: It all begins with integration

For those of you not familiar with the term “API”, let’s discuss its meaning.

An “Application Programming Interface” is, simply, the interface that allows one piece of software to communicate with another.  In most cases, this interaction between differing pieces software occurs because a developer invests the time and effort to code their software to the interface (API) to reach the software behind the API.  Another way to describe this concept is that API’s open access to systems versus requiring a lengthy integration into a closed system.

So why are they a topic of discussion?  Simply, APIs represent growth opportunity…

Take, for example, Twitter.  Twitter, in its infancy, provided their service via a website.  The service was valuable to its users, people used it heavily, and then they opened access to the service via an API.  Today, I use twitter via TweetDeck on my iPad…through the web interface on my computer…and have it feed any content I create to Facebook.  The service gained substantial traction because of where it is integrated.

When properly designed, APIs allow services to be quickly embedded in thousands of software applications…rather than just a few.

How does this apply to commerce?

It’s simple really.  When a payment transaction is initiated, that transaction is being routed to a payment service.  This service offers an interface.  It is also a strong possibility that this interface is dated, language specific, and limited in choice of features and functionality.  It is almost guaranteed that the waiting time for support on an integration leveraging legacy interfaces is lengthy…and the cost will be substantial.  So the Software developer is faced with the onerous task of performing multiple, one-off integrations to achieve their business requirements.

The IP Commerce APIs, in contrast, support Software Company integrations regardless of language or development methodology.  In addition, they provide access to multiple payment tenders and value add services from multiple providers, and expedite commerce-enabling software that enable the Software developer to focus on their core competency…their software.

You may notice I used the term “commerce-enable” above…this is a bit of my own language…but it is an important piece to the puzzle of Commerce APIs.  Adding payments to software can be quite difficult and Commerce APIs solve for this.  However, adding payment acceptance across multiple types (Credit Card & Check Verification) including Value-Added Services (Tokenization & Risk Management) coupled with Single-Sign On (to streamline the customer experience) available thru a workflow engine…this is a “commerce solution.”

Let’s consider two examples, of varying complexity, that demonstrate Commerce APIs in action:

An eCommerce Website:

The process of adding payments to a website involves using APIs to efficiently ensure the website can accept payments for their goods.  This simple example requires the use of APIs and, when these APIs are properly designed, additional services can be quickly added to the website as the customer requires them; ensuring their payment solutions grow at the speed of their business and shopping cart abandonment is minimized.

Multi-Channel, Multi-Service:

A Software Company developing software for general contractors and builds a compelling solution that allows their customer to accept orders by telephone and via walk-up business.  An additional requirement is purchase card (SKU level) transaction data and recurring ACH billing for invoices.  Multiple services…multiple “channels” of acceptance.

In addition, they enable their customers to export transaction data directly into QuickBooks, their accounting tool, which ensures they “Never Enter Data Twice”, a substantial time saving feature for their customer.  Moreover, the customer desires to use the same credentials in the solution –for purpose of authentication –that they use for QuickBooks.

The workflow appears highly complex.  The workflow requires Commerce APIs.

But the power of this solution doesn’t end at the time of integration.  The service provider who owns this customer relationship is able to up-sell Risk management services to the customer as a result of the solution leveraging APIs offered through the IP Commerce Platform.

Does it sound complex?

It is.

The process of designing APIs, and the software they provide interface to, to ensure complex workflows like these requires deep technology and industry expertise.  And after the technology is implemented, the process and people required to support it become as important as the technology itself.  Building highly complex commerce workflows requires a partner that understands your development process and requirements.

This is not an “example” for the sake of discussion.  This is what the Commerce APIs are being used for daily.  Customer requirements are met, Software Company solutions are built, Service Provider’s services are consumed, and a Managed Commerce Services Platform (that which the APIs connect to) is used to provide the governance and enablement of these complex workflows.

Governance?  Enablement?  SSO?  Tomorrow, we discuss Federated Identity.

What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below…

June 8, 2010

Posted in IP Commerce, Software Companies.