Processing’s New Look
Peter Lucas
As merchants clamor for lower acceptance costs and higher levels of service, processors are starting to respond with
service-oriented architecture. This is a new way of linking terminals to back-end systems that can do away with age-old
integration hassles, but can also create new headaches if not done right.
Historically, merchants have not had much control over the systems through which they process payments. If a store wants to accept a
new form of payment, such as an electronic check, its processor has to send out a service representative to install the application code
in the POS terminal—a lengthy process that can take days and results in frustration and lost sales for the merchant.
Just as maddening for merchants is that every change a processor makes to its operating platform requires each terminal running on
the platform to be updated. This can be done through the addition of a software applet. In extreme cases, it requires the merchant to
lease a new terminal or purchase it outright. Understandably, merchants don’t find either proposition particularly appealing.
A more efficient approach would be to allow changes to the payments platform to be made at the merchant level in real time.
Under such a scenario, once a merchant is integrated to the processor’s platform, any changes to the merchant’s software package can
be downloaded through a Web browser on a desktop computer that plugs into the store’s payments system.
The stumbling block, however, is that processors typically operate proprietary platforms. While this exclusivity has allowed
processors to add features that differentiate their services in the marketplace, it limits their ability to add new software applications and
quickly distribute them to merchants. Software developers must write their applications to each processing platform and then undergo a
certification process.
This cumbersome exercise has made it harder for merchants, especially small and mid-size businesses, to jump ship for a processor
offering cutting-edge payment applications, a better discount rate, or both, as they incur substantial upfront integration costs to do so.
Processors eager to swipe business have begun to reduce or entirely waive platform-integration and terminal-leasing and maintenance
fees to entice merchants to come aboard. While an effective tactic, this has created fierce price competition that has dramatically
trimmed margins.
Platform Independence
So, how to deliver new payment services without costly integration hassles and margin-busting giveaways? Processors looking for an
answer have begun to adopt something called service-oriented architecture (SOA), which allows applications to be delivered through
the Web browser on a desktop computer-based terminal.
The primary payoff of SOA for processors is that it eliminates the need for merchants to recode their terminals for each new
application or upgrade, thus allowing for delivery of new applications on demand. It also can eliminate the need to deploy traditional
POS terminals, since SOA supports operation of a POS terminal on a desktop system. The result is lower merchant operating costs and a
higher level of service.
While the cost for SOA software varies by merchant, it is a fraction of the cost of having to license or purchase a POS application
and terminal to run it, according to SOA experts.
“Service-oriented architecture allows merchants to mix and match processing services and make tweaks to their system as needed
without requiring custom interfaces on the front end,” says John Nickerson, vice president of product for Dallas-based processor
TransFirst. “SOA enables protocol independence on the back end, which extends the reach of our services to merchants and opens the
door wider to the software-development community.”
SOA could speed up adoption of alternative payments and other innovations. That’s because it makes it easier for processors to push
services such as mobile payments further into the marketplace using an array of menu-driven applications that can be accessed and
implemented by merchants of all sizes without the need for IT expertise.
What’s more, the elimination of integration and maintenance costs is especially attractive to mom-and-pop merchants, which pay
higher merchant fees because of their lack of volume or because they primarily do business online. For them, SOA could lower
acceptance costs.
The open standards used within SOA also allow merchants to integrate desktop applications, such as Excel spreadsheets, into their
payments systems for real-time transaction reporting.
“There is a lot of growth on the front end of transaction processing, but what is lacking is a cost-effective way to integrate the frontend terminal to the back-end platform,” says Alfred “Chip” Kahn, chief executive and founder of IP Commerce Inc., a Denver-based
provider of SOA software. “If software services are delivered through the Internet, it becomes a more cost-effective way for processors
to acquire customers.”
To understand SOA, processors must realize it is as much a business methodology as it is a technology. In essence, SOA is an
application architecture in which all functions are platform-independent. Software developers no longer need to write their applications
specifically to each processing platform. Instead, they write code to a set of operating standards any processor can adopt.
Reversing the Model
Thanks to the flexibility of SOA, any payment application can run on a POS device linked to any processing platform. SOA’s open
standards also allow processors to reuse applications in common across payment types and make them available to merchants via a Web
browser, creating increased operating efficiencies and greater visibility of data.
For example, a processor operating authorization platforms across 12 payments channels, such as mobile payments, e-commerce,
retail, and so on, can use SOA to consolidate the common functions within each platform, thereby eliminating data silos for the same
function, in this case authorization.
“SOA can be used to extend common functionality across an ATM, POS device, kiosk, or other service-delivery device,” says
Michel Jacobs, senior vice president for new-solutions development at Scottsdale, Ariz.-based processor eFunds Corp. “It is a truly
hardware-agnostic environment.”
In addition to TransFirst and eFunds, several processors and payments providers have begun to adopt SOA and roll it out into the
market. This group includes Dallas-based Chase Paymentech Solutions LLC, San Jose, Calif.-based PayPal Inc., San Francisco-based
biometric technology provider Pay by Touch Payment Solutions, and BankServ Inc., a provider of automated clearing house, Check 21,
and related services, also in San Francisco.
With the exception of eFunds and Pay by Touch, all of these companies are members of a consortium formed last year by IP
Commerce to support its IP Payments Framework, which provides an SOA infrastructure. EFunds is partnering with IBM Corp. to
deliver SOA-based payments solutions. In addition to that from IP Commerce, SOA infrastructure is being provided by Redmond,
Wash.-based TPI Software LLC.
These companies, along with IBM, are creating an SOA infrastructure in the transaction-processing industry that supports loosely
related and interoperable software applications independent of the underlying hardware platform and programming language.
What results from software changes being made on the back end and downloaded via the Web browser is that the software supports
the processor, which is the reverse of the current processing model. Think of SOA as the pure software-as-a-service model that such
visionaries as Oracle Corp. chief executive Larry Ellison began talking about in the 1980s.
Data Security
“SOA goes beyond hub-and-spoke architecture because software developers write to the SOA architecture, not the individual
processing platform,” explains Bill Pittman, president of TPI Software. “Even Microsoft is moving in this direction.”
TPI and IP Commerce are Microsoft Corp. software-development partners. Their applications are designed to work with Microsoft’s
Vista operating system, the latest version of Windows that was set to become available to the general public last month.
Processors running TPI and IP Commerce software are linked to merchants using Windows Vista Business through tools that
facilitate two-way messaging between the two parties via the Web browser. Processors can download new applications and upgrades
and even initiate a sales contract in real-time.
“The terminal is not the right place to put the application, because it does not allow for the provisioning of the application into other
applications,” says IP Commerce’s Kahn. “SOA makes it easier for a processor to connect software applications across their platform.”
On a broader scale, it opens the door for processors to interface with merchants running Microsoft applications. “With the protocol
independence SOA provides, this can expand our sales by opening our services to any Microsoft user that wants to drive payments,”
adds TransFirst’s Nickerson. “That’s a big plus because we have limited internal resources to sell our product.”
It can also provide better data security because transaction information is stored with the processor, not at the merchant site. With
each database intrusion garnering headlines, security is likely to become a strong selling point for SOA with processors, according to
software experts.
By moving transaction data out of merchant locations, processors can encrypt the data in real time, ensuring protection even if their
platform gets hacked. “The card companies want to limit access to card data,” says Pittman. “Not storing it with a merchant for any
length of time is a big security benefit because merchants are vulnerable.”
’Stealth Mode’
Yet, as attractive as SOA looks on paper, processors need to remember it is a combination of technology and business methodology. In
order for it to be properly implemented, processors must embrace the viewpoints of both the IT department and business strategists. If
one group or the other dominates implementation, the likely result will be the creation of application silos, rather than a hardware-
agnostic environment that leverages existing applications on a single platform. Result: operating costs will not be lowered and crossselling opportunities to merchants will not increase.
This is the challenge confronting large processors and banks. There can be a lot of territoriality within these organizations that can
prevent the implementation of an SOA infrastructure, according to Jerry Silva, research director for delivery channels and retail banking
at researcher TowerGroup.
“Some banks are actually developing SOA under a stealth mode so managers in one line of business don’t feel they are carrying
the development costs of another department,” says Silva. “SOA is an internal governance issue, which is why if it is not
championed at the highest level of the organization or done in stealth mode, there can be hindrances to its development.”
What is likely to resolve such internal territorial disputes is competition. Processors that are slow to adopt SOA may soon find
themselves losing business if merchants perceive SOA lowering their cost of acceptance and significantly raising the level of service.
“There will be processors that are going to get caught off guard,” predicts TPI’s Pittman. “Taking away terminal-leasing and
maintenance costs through the use of SOA will drive down merchant acceptance costs.”
SOA will also make it easier for processors to deliver applications to accept payment through wireless mobile devices such as Treos
and BlackBerrys, as well as cell phones, a more than $16 billion market. To penetrate mobile commerce, processors need to provide
merchants with applications beyond credit card acceptance, such as prepaid cards and accounts, as well as give merchants the ability to
have transactions billed through a cellular phone carrier.
That sounds complicated, but it may be a tailor-made opportunity for SOA. “SOA is a way to get more discrete and complex
payments applications into the market by eliminating the complexities around the infrastructure,” says Stephen Reade, senior vice
president for product management and product marketing for Pay by Touch. “As software developers gain a clear mandate for the types
of payment applications consumers want, they will build more robust and innovative applications. SOA will allow them to be
distributed more readily.”
The trick will be to avoid building new silos just as the old ones are crumbling.
An SOA Primer
As a combination of technology and business methodology, service-oriented architecture (SOA) is a collection of best practices and
patterns related to distributed computing based on open standards.
Although SOA is built on similar principles as Web services, it is not the same as Web services, which is a collection of
technologies, such as SOAP (Simple Object Access Protocol, a protocol for exchanging XML-based messages), and XML (extended
markup language). Rather, SOA is a design for linking computing resources (principally, applications and data) on demand to better
service customers and support integration and consolidation activities within complex systems.
When implementing SOA, here are some basic principals processors need to keep in mind for development, maintenance, and
usage, according to a study on SOA by Jerry Silva, research director for delivery channels and retail banking at Needham, Mass.based research firm TowerGroup.
Reusability of Existing Applications—Prior to SOA the number of total connections to a processing platform was considered the
metric for deriving the cost of integration. Under SOA, the more connections made to existing applications across the platform, the
lower the integration costs.
Architecture Built for Change—By converting key processes into components in SOA, changing the existing platform
infrastructure requires less integration.
Orchestrating Processing—By decoupling applications from connections to the platform, new business processes are
orchestrated rather than built from scratch. This shortens application-development time, allowing faster response to changing market
conditions.
Not All Applications Are SOA Compatible—Applications that require reliability and throughput across the enterprise will not
benefit from conversion to SOA.