emergent commerce & technology

Follow Us! on Facebook Follow Me on LinkedIn Follow Us! on Twitter Subscribe to the RSS Feeds

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).

Read the rest of this entry »

After the Swipe: Transaction Management

There is a perception – perhaps even a misconception – among those looking to do a payments integration, that completion of the project should be something like one of the following use cases:

  • 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?

Read the rest of this entry »

Syntax Highlight: a test

When testing new functionality on the blog, I (typically) obscure the actual process of testing. However, there are a few circumstances where this isn’t tenable.

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.
Read the rest of this entry »

“Open” APIs: a definition

There is a propensity in the technology industry, most industries for that matter, to latch onto adjectives and begin to use them excessively. In the process of descriptive repetition, the importance can be masked or diminished. With that said, the usage of the adjective, typically, is appropriate and connotes unique value…after all, the initial usage had to be compelling enough for it to gain popularity.

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…”

Read the rest of this entry »

A theme update, and a request

Just an extremely brief note that I have completed* an upgrade of the main blog theme this weekend.  There are a few minor cosmetic tweaks left (completing the links page, etc.) and a fair amount of behind-the-scenes work…

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

Cheers!

* in large part