SOA for Commerce
If you aren’t familiar with the concept of Service Oriented Architecture (SOA), I’d recommend the wikipedia article as it is a quality overview. SOA is one of those architectural methodologies that has been hotly debated. . .some support, others claim there really isn’t a purpose.
Interestingly, SOA forms the underpinnings of a major product in the IP Commerce ecosystem (known as the Commerce Platform). Any of you who have read my musings for a period of time will know that I am the Platform Evangelist for IPC and, as such, I definitely fall into the "support" camp.
<soapbox>Any "technology solution" that addresses both business pain and simplifies technology adoption is the best of both worlds. Without addressing both, new methodologies will always fail.</soapbox>
Perhaps the most interesting segment of the article, to me, was the following:
Business customers today demand flexibility and choice in commerce services. Unfortunately, adding new payment services or accepting new payment types is difficult and costly. Also, for those customers who do manage to offer multiple payment options, transactions are not consistently implemented resulting in the lack of payments-related data in back-office accounting, financial management and business workflow.
This directly impacts business productivity and limits visibility to and control of cash flow. Such inefficiencies also highlight the persistence of a legacy payment industry infrastructure that does not allow the flexibility to add new services to new transaction origination points.
SOA provides a solution that can reduce integration expense by 10 times and, as such, reduce barriers to providing consistent customer interaction across channels. In turn, these advancements benefit payment service providers by increasing transaction volume and provide other value-added utility for the user and business.
One of the things that I’ve learned from my time in the payment industry is that, particularly for the SMB, the decision about what type of payments to accept is when that tender is presented. Basically, something like "Do you accept this?" Followed by "No, should I?" I saw this in SJC last week when a tourist attempted to pay for his morning coffee and bagel with his JCB card. The confusion of the teller was both humorous and disheartening.
The problem, however, extends to when the merchant KNOWS they need to accept a tender but have no simple way to integrate into their existing process. For example, I went into a local store yesterday (Denver area) and a representative from the company providing the merchant services was onsite. We spoke briefly as he was adding a terminal to each of the 4 lanes in the store. . .it turns out that the store was required to support additional hardware in order to accept EBT cards.
So, now, this store has 2 terminals at each lane. . .in addition to a register. 3 completely separate ways to accept payments and a bit of training nightmare for their store employees.
As Chip said in the article above:
Each of these tenders has a unique workflow, unique security requirements, and a unique interface. While there are some providers (e.g. PayPal) that provide support for more than one tender, ensuring that the e-commerce business has the widest range of available tender quickly becomes a daunting task even before considering the businesses other channels. Not only is it necessary to learn multiple interfaces and methods of integration, it is also necessary to certify multiple times. This issue alone can be solved with SOA adoption while protecting the unique value and integrity of each individual service.
I will continue to, periodically, expand more on the benfits and challenges of SOA for both e-commerce and "brick and mortar" payments. Please let me know, via comments or e-mail, if there are any elements or topics you would like me to cover in specific.
(seat 9F from DEN to AUS)
December 10, 2007