Commerce Business Rules: Managing Workflow & Value in the “Cloud”
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…
June 10, 2010