Consistency In Customer Experience: Single-Sign On
As I mentioned yesterday when discussing Transaction Management, one of the key components of Commerce Modules (as offered through the IP Commerce Platform) is the ability to quickly and simply drive a consistent customer experience. Hence the statement of a “snap-in business solution”…
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).




