It is worth noting, when considering the technical side of supplementing a payment solution with a Commerce Module, that there are two audiences whose needs must be met. If the implementation experience solves for merchant customer pain, but is overwhelming for the Software Company, there will simply be no adoption. Similarly, if the implementation is simple for a Software Company, but does not solve for merchant customer needs, there may be minor adoption with little (to no) ultimate usage or adoption.

As IP Commerce is not in the business of building merchant facing applications, we had to take both sides of the equation into account when designing how Commerce Modules are developed and brought to market. I can discuss more of the marketing/business requirements and how they relate to platform implementation theory (i.e. single-sided network effects) at some point in the future…but, for this post, the focus is solely on handling credentials.

In a post entitled Federated Identity: Overlaying Integrations with Appropriate Security Controls, I spent a fair bit of time discussing the concepts behind Federated Identity. But the term, Federated Identity, is not one you will likely hear the majority of Software Companies using. It is worth noting that this differs by the vertical that the Software Company services. For example, those who know, understand, and deploy their application according to the principles of SaaS will, likely, be familiar with the conceptual implementation of Federated Identity (generally) and often well versed in specific components of implementation (such as Single-Sign On).

In general, however, we have heard the terms:

• consistent customer experience
• no repeated logins
• simple access control

or variations thereof.

These statements are usually referring to a Single-Sign On (SSO) style implementation. Leveraging the same set of credentials, seamlessly and securely across multiple applications, goes a long way towards solving the issues of customer experience.

To truly understand how we have addressed this issue, I must present a bit of back story.

Transaction Originator Authentication

As the Platform experienced growth, and we continued to supplement the available Commerce APIs and Payment Services, we recognized there was an industry-wide issue. The majority of payment services in the market do not implement any form of authentication of the “originator” when processing transactions. Instead of verifying the originating point of the transaction, they (usually) require that certain bits of data are passed within the body of the transaction. Importantly, this “identity” data (loosely using the term identity here) is rarely protected adequately. The result is, as you might expect, an available vector for the submission of fraudulent transactions.

Recognizing this, early, IP Commerce has made strong authentication of the transaction originator a requirement. As a Platform, we are able to extend this requirement to the edge (point of acceptance) and perform the authentication on behalf of the service provider. The technology that was implemented leverages the best practices of Federation in a fashion that is not onerous to the Software Company but enables the exposure of multiple services, from multiple providers seamlessly and securely.

SSO Toolkit for Commerce Modules

With this infrastructure in place, consumed by all Software Companies using IP Commerce APIs has enabled us to build an SSO Toolkit for Commerce Modules. This enables the Module developer to build to an infrastructure that has the inherent capability of ensuring their solution can be simply consumed…and will work seamlessly with other software, and services, also leveraging the Platform.

What I, personally, find exciting is the “how”.

The image above is a diagramme of the interaction when a Software Company desires to incorporate the capability of a Module within their payment application. The process is as follows:

1. The merchant customer logs into the payment application by entering their user/password credentials.
2. The payment application invokes the Commerce Web Services SignOnWithToken() operation to retrieve a sessionToken.
3. When required the payment application initiates the module authentication process by sending a GetURL() message to the module-specific SSO URL specified by the Commerce Module provider, and passes the sessionToken and merchantProfileID for validation.
4. The Commerce Module responds to the payment application with a dynamically generated, single-use URL that grants the user access to the module.
5. The payment application redirects the merchant customer to the module URL (received in step 4) to access the functionality provided by the module.

As you can see it is a relatively straightforward flow.

What is even more compelling is that this same GetURL() call is used both by the Module provider and by the Module consumer. In essence one API provides for both the SSO authentication necessary for Software Companies building and using modules.

There was a term used in the process flow above, “session token”, that bears a bit more explanation.

Without getting into too great of detail*, this token is the output of a Commerce Web Services SignOnWithToken() operation. This operation is what facilitates the authentication of an identity token (a signed and encrypted authentication token) that is used for the purpose of transaction origination authentication. Upon authentication of the identity token, a session token, which is short-lived, is issued for the purpose of all future operations.

As a result of this interaction, which is the transaction originator authentication described above, the Commerce Module does not ever receive, persist, or interact with the long-life (identity) token. In addition, the URL that is returned to the application is validate for single-use only.

The result of this?

A consistent customer experience.
A simple deployment.
Most importantly, merchant customer needs are quickly met and services are consumed more quickly than before thereby satisfying all participating members of the Platform.

This is a simple example of the power of a true Federated Identity infrastructure. There are more examples to come in due course.

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

* Although I am happy to discuss should anyone desire.

• Add a field that reads from a USB swipe control, and a submit button.
• Add a text entry field, a card-type drop-down, maybe something for those 3 digits on a card, and a submit button.

The availability of APIs for commerce integrations has begun to drastically decrease the time required to complete an integration…but the process of adding payments to software is somewhat more complex than a text entry field and a submit button.

One thing that is frequently overlooked during the initial scoping exercise is transaction management.

What happens after a transaction has been settled?
How will the application handle refunds of transactions?
How will the application handle voids of transactions?
How will reporting, both post and pre-settlement, be handled?

These workflows, a requirement by the merchant customer using the application, represent additional development, testing, and integration work for the Software Company or developer. In the case of an eCommerce integration, this typically encompasses more development resources, time, and knowledge than the process of building the initial page for payment acceptance.

How can this issue of time and expertise be addressed?

One of the important capabilities of the IP Commerce Platform is the ability for Software Companies to build workflow and solutions that are valuable to other Software Companies. We refer to these “snap-in business solutions” as Commerce Modules. I will write more, tomorrow, about the technical side of this integration…but, for now, suffice it to say that the experience is seamless from both the perspective of branding & credentials.

There is none who are better suited to solve the pain of a Software Company than other Software Companies.

Introducing the Transaction Management Commerce Module.

Transaction Management, as a Commerce Module, solves for the post-settlement refunds, pre-settlement voids, searching and reporting on transaction information, as well as real-time transaction status and payment details. As a solution, it is hosted in a PCI compliant data center thereby ensuring the implementation does not introduce additional risk to the merchant customer. This specific module was built by aurionPro and leverages their expertise in the Banking & Payments technology sectors.

As you would imagine, there are several targeted business solutions that IP Commerce has identified as potential Commerce Modules based upon our experience with the development community. I, personally, am excited to see what other Commerce Modules the Software community creates to solve for each others pain.

Payment application development is quite interesting…opening APIs for commerce development is compelling…pairing these with a powerful Platform to drive innovation is exciting…enabling Software Companies to build solutions that solve the pain of other Software Companies — that is unique and powerful.

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

Syntax highlighting is just such a circumstance. It is not sufficient to see how the javascript/plugin solution I’m leveraging works on the blog itself…instead I must also see how it is rendered in RSS feeds and on other sites that syndicate this content.

You may ask why I’m installing a syntax highlighting solution on the blog. The answer is simple. There is a wealth of sample code and unique solutions that I’ve accumulated over the the years of interacting with Software Companies who built commerce solutions leveraging the IP Commerce APIs.

It is, now, time to share this information.

If you are interested in doing something similar to your site, or blog, I’m using a combination of the open source SyntaxHighlighter javascript client side code and a WordPress plugin called SyntaxHighlighter Evolved. I have chosen this set of solutions, not only due to appearance, but also as it should allow for viewing source, copying to clipboard, and printing simply by clicking on the code box as rendered.

Below are a few tests of the syntax highlighting feature…please excuse the testing.

UPDATE: I should note that I don’t expect the code to render in the same fashion via a feed as it does on this page…this is due to the nature of deployment of the solution.

A bit of php/html perhaps?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<title>PHP Code Example</title>
</head>
<body>
	<h1>PHP Code Example</h1>

	<p><?php echo 'Hello World!'; ?></p>

	<p>This line is highlighted.</p>

	<div class="foobar">
		This	is	an
		example	of	smart
		tabs.
	</div>

	<p><a href="http://wordpress.org/">WordPress</a></p>
</body>
</html>

Some Java?

package helloworldapp;

/**
 * The HelloWorldApp class implements an application that
 * simply prints "Hello World!" to standard output.
 */
public class HelloWorldApp {

    /** Creates a new instance of HelloWorldApp */
    public HelloWorldApp() {
    }

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        System.out.println("Hello World!"); // Display the string.
    }

}

Perhaps some C#?

// Hello2.cs
using System;

public class Hello2
{
   public static void Main()
   {
      Console.WriteLine("Hello, World!");
   }
}

And, finally, a rather lengthy sample of an authorization transaction using the Commerce Web Services REST interfaces that should be collapsed by default requiring a click to expand (at least on this page).

<AuthorizeAndCaptureTransaction xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.ipcommerce.com/CWS/v2.0/Transactions/Bankcard/Rest">
     <ApplicationProfileId>#APPID#</ApplicationProfileId>
     <MerchantProfileId>#MERCHID#</MerchantProfileId>
     <ReportingData xmlns:d2p1="http://schemas.ipcommerce.com/CWS/v2.0/Transactions" i:nil="true"/>
     <Transaction xmlns:d2p1="http://schemas.ipcommerce.com/CWS/v2.0/Transactions" xmlns:d2p2="http://schemas.ipcommerce.com/CWS/v2.0/Transactions/Bankcard" i:type="d2p2:BankcardTransaction">
          <d2p1:CustomerData>
               <d2p1:BillingData>
                    <d2p1:Name i:nil="true"/>
                    <d2p1:Address>
                         <d2p1:Street1>1400 16th Street</d2p1:Street1>
                         <d2p1:Street2 i:nil="true"/>
                         <d2p1:City>Denver</d2p1:City>
                         <d2p1:StateProvince>CO</d2p1:StateProvince>
                         <d2p1:PostalCode>80202</d2p1:PostalCode>
                         <d2p1:CountryCode>USA</d2p1:CountryCode>
                    </d2p1:Address>
                    <d2p1:BusinessName>AcmeInc</d2p1:BusinessName>
                    <d2p1:Phone i:nil="true"/>
                    <d2p1:Fax i:nil="true"/>
                    <d2p1:Email i:nil="true"/>
               </d2p1:BillingData>
               <d2p1:CustomerId>cust123x</d2p1:CustomerId>
               <d2p1:CustomerTaxId i:nil="true"/>
               <d2p1:ShippingData i:nil="true"/>
          </d2p1:CustomerData>
          <d2p1:ReportingData>
               <d2p1:Comment>COMMENT</d2p1:Comment>
               <d2p1:Description>DESCRIPTION</d2p1:Description>
               <d2p1:Reference>REFERENCE</d2p1:Reference>
          </d2p1:ReportingData>
          <d2p1:Addendum i:nil="true"/>
          <d2p2:ApplicationConfigurationData i:nil="true"/>
          <d2p2:TenderData>
               <d2p1:PaymentAccountDataToken i:nil="true"/>
               <d2p1:SecurePaymentAccountData i:nil="true"/>
               <d2p2:CardData>
                    <d2p2:CardType>Visa</d2p2:CardType>
                    <d2p2:CardholderName>John Doe</d2p2:CardholderName>
                    <d2p2:PAN>4012000033330026</d2p2:PAN>
                    <d2p2:Expire>0409</d2p2:Expire>
                    <d2p2:Track1Data i:nil="true"/>
                    <d2p2:Track2Data>4111111111111111=09041011000012345678</d2p2:Track2Data>
               </d2p2:CardData>
               <d2p2:CardSecurityData>
                    <d2p2:AVSData>
                         <d2p2:CardholderName>Test Cardholder</d2p2:CardholderName>
                         <d2p2:Street>1400 16th Street</d2p2:Street>
                         <d2p2:City>Denver</d2p2:City>
                         <d2p2:StateProvince>CO</d2p2:StateProvince>
                         <d2p2:PostalCode>80203</d2p2:PostalCode>
                         <d2p2:Country>USA</d2p2:Country>
                         <d2p2:Phone i:nil="true"/>
                    </d2p2:AVSData>
                    <d2p2:CVDataProvided>NotSet</d2p2:CVDataProvided>
                    <d2p2:CVData i:nil="true"/>
                    <d2p2:KeySerialNumber i:nil="true"/>
                    <d2p2:PIN i:nil="true"/>
               </d2p2:CardSecurityData>
          </d2p2:TenderData>
          <d2p2:TransactionData>
               <d2p1:Amount>11.00</d2p1:Amount>
               <d2p1:CurrencyCode>USD</d2p1:CurrencyCode>
               <d2p2:AccountType>NotSet</d2p2:AccountType>
               <d2p2:AlternativeMerchantData i:nil="true"/>
               <d2p2:ApprovalCode i:nil="true"/>
               <d2p2:CashBackAmount>0</d2p2:CashBackAmount>
               <d2p2:CustomerPresent>Present</d2p2:CustomerPresent>
               <d2p2:EmployeeId>49</d2p2:EmployeeId>
               <d2p2:EntryMode>TrackDataFromMSR</d2p2:EntryMode>
               <d2p2:GoodsType>NotSet</d2p2:GoodsType>
               <d2p2:IndustryType>Retail</d2p2:IndustryType>
               <d2p2:InternetTransactionData i:nil="true"/>
               <d2p2:InvoiceNumber>545</d2p2:InvoiceNumber>
               <d2p2:OrderNumber>885380</d2p2:OrderNumber>
               <d2p2:SignatureCaptured>false</d2p2:SignatureCaptured>
               <d2p2:TerminalId i:nil="true"/>
               <d2p2:TipAmount>0</d2p2:TipAmount>
          </d2p2:TransactionData>
     </Transaction>
</AuthorizeAndCaptureTransaction>

Please advise if you see any strange behaviours or unexpected formatting/etc.

Let’s consider the adjective “open”.

As defined by Princeton WordNet, the usage of the word open that is most applicable to our discussion is as follows:

S: (adj) open (accessible to all) “open season”; “an open economy”

“Accessible to all…”

What is the goal of an API strategy? Accessibility. If you are a Service Provider (payments or otherwise) attempting to gain market share, ensuring accessibility of your service via APIs gives you an opportunity to partner with Software Companies & developers. If, however, your service is only available through a proprietary interface — or a dated set of specifications — the challenge of adoption is multiplied.

Open is accessible.

But there is more to “open” than just accessibility.

Consider the business of a Software Company…as they make a decision about how to bring their solutions to market, they face the challenge of all business…customer requirements dictate timeline and real, tangible cost dictates the complexity of integration that can be undertaken. As a result, a Software Company can only choose a discrete number of partners and tools to leverage.

Will your API be chosen? It depends on whether your APIs can be consumed in the fashion the Software Company expects. I will discuss this in greater detail this week when enumerating the decision making process regarding REST and SOAP implementations of web services.

Open is flexible.

Flexibility is powerful…but insufficient when considered alone.

If presented an API (or set of APIs) that they know how to use and offers some of the services required (at least notionally), the next step becomes an exercise in planning for future requirements. The comparison of volume of available services, value-added workflows available through the API, and the future capabilities presented is a very important process. The Software Company requires the ability to choose their services not only today…but in the future.

Open is choice.

This phenomenon, or perhaps requirement (as it relates to the payments industry), is elucidated by my IP Commerce colleague Peter Osberg in a post entitled Messages From The Edge: Taking Care of Customers – Payment and Provider Choice in APIs on PaymentsAPI.com.*

When a Software Company or Developer references “open” they are often speaking to the availability of choice. Choice in tenders offered and choice in providers leveraged coupled with choice in their development tools. Regrettably, the concept of “open” is foreign to many traditional participants in the payments industry – whose proprietary services and platforms effectively restrict choice.

So, what is “Open”?

Open is accessible.
Open is flexible.
Open is choice.

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

* PaymentsAPI.com is curated by IP Commerce and more information can be found in About Payments API.

I request that you advise me of anything that seems a bit wonky, broken, or otherwise out of sorts.

Cheers!

* in large part

…it is a tale told by an idiot, full of sound and fury, signifying nothing

In truth…most people who quote that leave out the reference to idiots (a minor kindness).

The discussion of APIs, however, differs greatly. I could enumerate, in painful detail, exactly how APIs are affecting/have affected the industry today. But most of you, as readers, are already familiar with the concept.

Instead, let me provide you an example of the interest that is being generated in the concept of Open APIs.

This evening, at the Twilio office in San Francisco…36ish people will gather to be part of the Open API Economy Meetup. That, in and of itself, is not terribly surprising. What is important, is taking a look at the topics that are slated as potentials for discussion:

• Keeping an open platform while supporting the core business
• Unexpected challenges, lessons learned, battle stories
• Attracting and cultivating a developer community
• The API standards issue
• Developing partnerships
• Metrics for success
• Effect and opportunities of cloud computing
• Security, versioning, and evolution of the API
• Choices around methods, design, markup, etc.
• REST vs SOAP

Not only are these important topics…these are the RIGHT topics to be discussed.

I am, unfortunately, unable to attend this particular session…However, the topics identified above have prompted some interesting thought processes. For example, when developing our Commerce APIs** we were faced with the decision of REST vs SOAP. Over the course of the next week, I will discuss the thought process that went into our decision process as well as items to keep in mind when planning your own API strategy (for partnership in commerce, or for other implementations).

At its simplest, I am thrilled that this level of discussion is occurring in technology in general. The prevalence of APIs (particularly those that are “open”***) is what will truly drive innovation in all sectors of business over the upcoming few years. The extensive experience that IP Commerce has in providing payment APIs to software companies provides perspective that is of value.

What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below…In particular, if there are items from the list above you desire addressed in writing, I am happy to oblige.

* Particularly those who know me from my government consulting or enterprise retail days…
** Commerce Web Services in particular
*** “Open” as a definition is another topic that is worthy of discussion

This blog, managed by IP Commerce, is focused on the discussion surrounding API strategies and the payments industry.  Myself, as well as several other folk from IP Commerce & other industry participants, are partnering together to further the discussion about the topic of APIs.  As I have reiterated, over the last week, the experience that IP Commerce has with software companies & developers looking to add payments to software is something that should be shared.  That is, truly, what PaymentsAPI.com is about.

I remain convinced that better voice-of-customer is beneficial for the entirety of the industry.  We have that customer experience and are excited to share what is required to truly deliver comprehensive, open APIs for payments.

The first post Now Open Payments API goes into greater detail about the “why” for the launch and I encourage you to read it.

You may wonder how this affects this blog.

It doesn’t…really…what it does enable is me to continue to comment on payment industry trends, technology trends in general.  In addition, I will be broaching some more detailed technological questions/answers that have arisen over the past year.  If there are topics related to payments, in general, that you desire covered Contact Me and I am happy to oblige.

More information for the industry.  More discussions of APIs.  More opportunities for all of us to learn and benefit

There was a series of inter-related commentary related to the topic of platform governance that deserve mention. I have pulled brief quotes from each of the posts, but encourage you to read them in their entirety.

The first, and really the genesis of the discussion, was from Brad Burnham (on the Union Square Ventures blog) and is entitled Web Services as Governments:

A lot of people have begun using the term ecosystem to describe these big platforms. That captures their decentralized, emergent character, but ecosystems do not have a central point of control. Apple decided to eliminate third party analytics between one release and the next. That doesn’t happen in an ecosystem. The right analogy is a government.

This was followed by an analysis piece from Bob Warfield (on the SmoothSpan blog) entitled Web Services (and Platforms) as Governments:

In the end, companies have to decide what they are.  If their primary purpose is to be a platform, they rely on others to a greater or lesser extent for their livelihood.  They must decide as “governments” how to treat the merchant class.  They need to worry about how they will be regarded by that class.  In many of the cases cited, the problem is these organizations are not primarily focused on being platforms.  They want to own it all.?

Following this, Derek Pilling (a Managing Director with Meritage Funds) authored a piece entitled Platforms:  Of Governance and Taxes on his Non-Linear VC blog.

Governments get their revenue from the collection of taxes; and the government gets to set its own tax code. The same goes for platforms, they get to determine how they will monetize their platform. If you are building on a platform, make sure the tax code is well established, stable and predictable. If the tax code is not clear, you are at risk.

As I said above, reading these posts (in the order indicated) and comments is an excellent thought exercise and will greatly deepen your understanding of Platforms as a business strategy.

Derek, in particular, makes a extremely interesting…and extremely important…point.

At the end of the series last week, I mentioned the importance of “commercialization” for a Software Company leveraging not only APIs in general, but Payment APIs in specific.

But what does the commercialization process truly encompass?

What must be taken into account when choosing a platform provider for your payments integration needs?

Commercialization, in general, goes far beyond the initial step of integration.  Adding payments to software is only the first step in bringing a commerce solution to market.  Upon completion of the integration, the solution must be sold…your customers (in most cases) will need merchant accounts with service providers…that merchant is boarded to the processors systems…there is ongoing support requirements…the need to determine monetization (revenue for your software business) and cost (what does it take to integrate)…etc.

If integration is an event, commercialization is the business.

As the posts above highlight, in varying levels of detail, “APIs” are not sufficient to solve your business needs.  This is why, when I speak with our software company and developer partners, I reiterate the fact that it is not just the tools that are important…it is the people and the process that drive success.

IP Commerce is platform company.

That decision was made upon corporate inception.  That decision is still core in our interaction with the software community.  The Commerce APIs are free for usage…our “tax codes” are clear. Our success is driven by your success.

But, most importantly, we are intimately familiar with the process that you will undergo to achieve success.  This understanding has been bred by interacting with, and enabling innovation, on behalf of software companies over the last 5 years.

Choose your partners wisely.

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

* I’m not entirely certain whether “unintentional prescience” is possible…but, nonetheless

Over the course of the last 5 days, we have discussed several elements that were announced in a Press Release on June 7.  These discussions have included:

• Commerce APIs
• Federated Identity
• Commerce Business Rules

All of these bits of technology enable important, required components to building a holistic payments workflow that includes Value-Added services alongside payment services and coupled with data services.

But how do they all function together?

The Commerce Service Bus.

The Commerce Service Bus is a core component of the Platform and is the technology that supports dynamic and flexible Commerce Business Rules, provides the ability for software companies to include Value-Added services in their workflows, and extends the Federated Identity governance inherent in the Platform.  The exposure of this component and its features, through Commerce APIs, allows for the creation of new, innovative workflows by software companies & developers.

Importantly, time-to-market on these workflows is expedited due to a combination of technology, people, and process.

To be clear, one of the core tenants of IP Commerce (both from a technology & people perspective) is to ensure our Partners…of all types…can enable the services they want with the Partners they have selected.

On the Commerce Service Bus page on the IP Commerce website, there are several scenarios discussed relating to the integration process that a software company undertakes.  The examples below are just a few examples, but will provide you perspective.  Let’s consider a few Use Cases to supplement these scenarios:

Risk Management as a Service

After connecting their service to the Platform, Risk Management service providers are able to position their services alongside the process of integrating more traditional payment methods through a consistent set of Commerce APIs.  For the software company, Risk Management (as a service) is now easily added to any payment integration ensuring customer needs, and opportunities, are quickly met.

A single Platform.  Multiple Commerce APIs.  New opportunities for innovation.

3rd-Party Security Services

The market has, and continues to, demand solutions to secure customer data thereby offsetting risk and resolving compliance challenges (for the software company) more easily.  The Commerce Service Bus enables 3rd-Party tokenization & encryption providers to offer their security services along side the services of traditional processors & acquirers.  Or, the Commerce Service Bus can be leveraged to extend the native service of these providers

No lengthy back-end integrations are required to bring security services to market.

Serial Service Payments

When adding Value-Added Services to an open API, there is a challenge inherent in sequencing and controlling the transaction flow.  The Commerce Service Bus enables Serial Service Payments (as a Commerce Business Rule) to ensure the right services are leveraged, in the right order, enabling service-rich solutions that meet customers’ needs immediately.  For example, a transaction is initiated, runs through Sales Tax calculation services, is tokenized to remove sensitive payment account data, and submitted for processing.  Subsequently, certain non-sensitive data may be published to a separate application workflow accessible only to credentialed users.

Payment application integration with Commerce APIs, overlaid with appropriate security controls through Federated Identity, and managed via Commerce Business Rules.  All of this, and more, enabled by the Commerce Service Bus.

In closing this brief discussion on IP Commerce technology, I invite you to contact myself (or any member of the IP Commerce team) to discuss the technology in greater detail.

Perhaps the most important element to remember:

“Not everyone who wants to, or can deliver, an open API or integration Lab will succeed. Developers don’t have unlimited time or resources and will not create applications on every platform. IP Commerce has the experience, people and process in addition to the technology to make sure our partners succeed and are first to market with clear and endurable advantages.

Efficient integrations to payment services are only a portion of the equation when providing commerce APIs. Ensuring the development community is enabled throughout their commercialization process is paramount and why we are excited to announce these enhancements to our platform.” – Alfred ‘Chip’ Kahn IV  CEO, IP Commerce

There is a word mentioned above…”commercialization”…that is extremely important to Software Companies & developers and is often overlooked.  We will discuss the commercialization process next week.

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

Federated Identity, as discussed yesterday, is about governance and security in commerce workflows but more is required to sufficiently drive the workflows that software companies are building, for their customers.

Federated Identity is one element in the equation of governance.  The other key component, which is unique to IP Commerce APIs and Managed Commerce Services Platform, is called Commerce Business Rules which provides the workflow engine element in addition to their contribution to governance.

Commerce Business Rules are about enabling the unique value that cloud-based solutions can provide to software companies.  Ultimately, adding payments to software is only a portion of successfully building a solution that meets customer needs.

Commerce Business Rules, because of their cloud-based nature, allow for the tailoring of payment acceptance to match required workflow(s).

The rules themselves…if you will let me divert in technology for a moment…are incredibly exciting.  The Platform itself is architected in such a way as to allow for Business Rules to leverage both run-time and out-of-band data to create dynamic workflows rather than just static logic implementations.  They are algorithmic in nature and are easily implemented, easily updated, and are intelligent enough to enable highly complex workflows.

The algorithmic nature of the rules engine provides a lot of flexibility.  Based on developer feedback, we have focused on some specific implementations:

Payment Service Bundling

This is a term you may hear periodically in industry, often in banking.  “I have bundled checking and savings to save you money.”  The concept of bundling services together is what drives customer retention not only for the Software Company but also for the provider(s) of the bundled services.

Interestingly, when an API approach is adopted Service Bundling may not happen at the initial time of purchase.  Rather a customer will purchase their ecommerce application and desire, at a future point, to add additional services (either core payment or Value-Add).  The service bundling capability of the Platform ensures that the remote provisioning and activation of these services happens in the time of business need…not the time of technology deployment.

Serial Service Payments

To understand Serial Service Payments is to begin with workflow.  Let’s consider, again, the Use Case we discussed when considering Commerce APIs:

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.

Look at the services that are involved in this workflow:  Card acceptance, Purchase cards, ACH billing — but these are just the Payments services.  Now let’s consider the “Value-Added Services” in this workflow:  QuickBooks Data Services, Risk Management.

In the Use Case described above, there are 3 payments services and 2 Value-Added Services.  These services must be executed in specific orders in order to be of the highest value.  It is necessary to perform Risk Management against a card transaction prior to submittal in order to achieve all the benefits…but the risk profile for ACH is entirely different.  And how/when do I want to access my QuickBooks data services?

If an API solves for the challenge of integration, what is the technology that enables the complex logic that is inherent in this workflow to succeed?

Serial Service Payments as a Commerce Business Rule.

This is an extraordinarily compelling, and exciting element of the IP Commerce Platform and so I am forcing myself to limit the discussion (I can, and am happy to, talk at length via other channels of communication) but there is another Use Case for Serial Service Payments that bears inclusion.

A software company serving medium to large online retailers could provide greater value by configuring Tokenization before payment processing, adding Adaptive Payments’ IVR-based PIN debit solution to “Save the Sale” on high risk transactions, and data export to ERP systems on the back-end of the payment processing workflow.

Commerce Business Rules ensure that any software company need only develop to the core payment processing APIs, while the IP Commerce Platform performs the heavy lifting of invocation and management of Serial Service Payments.

There is value in the cloud.  And it’s easy to see how valuable this workflow management capability could be to mobile payment developers.

That value lies not only in ease of integration, and security and governance through Federated Identity, but cloud-based rules that manage the workflow and allow for truly new, innovative workflows.

This week we’ve discussed Commerce APIs, Federated Identity, and Commerce Business Rules as capabilities of the IP Commerce Platform.  Tomorrow, it all ties together…the Commerce Service Bus.

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