Accelerating Electronic Payment Processing
A payment processing firm uses .NET and
the Web services programming model to
improve connecting to its platforms.
by Jason Salas

It's a fundamental concept of marketing science: If you provide consumers with choices, they'll be more inclined to do business with you, viewing the available options as an implicit indicator of quality. Concord EFS Inc.'s mission is to provide merchants with options in advanced payment processing services, and in doing so, stay ahead of the game. As a leading provider of card transactions and payment processing, the company's success is rooted in its ability to intelligently apply technology for its network of small- to enterprise-level merchants to accelerate their business transactions. And giving developers more selection in accessing its system made it possibly the first electronic payment processor to provide open-architecture Web service access to process payments.

In November 2000, Don Schroeder, director of product development for Virtual Cyber Systems Inc., a wholly owned subsidiary of Concord, was tasked with conceptualizing a system that would extend and optimize the company's virtual value chain in electronic payment processing for online shopping and brick-and-mortar point-of-sale environments. He had to design a solution that would provide distinction from and competitive advantage over other payment gateways and solutions. The system also needed to be something merchant developers could tap into easily.

Don Schroeder and his team used .NET's open technologies to expand Concord's electronic payment system. Bottom front row from left to right: Tim Fournier, Ron Pugh, Jerome Ferland, Don Schroeder. Top back row from left to right: Gordon Grieb, Dave Stange, Francois Bergeon.

Traditionally, payment processors such as Concord provided only closed-network access, using costly and complex technologies such as dial-up modems, frame relay, or satellite connections. Schroeder recognized that by using an open architecture he could base the app's architecture on open technologies. This would make it attractive to a wider range of developers, allowing merchants to tap into Concord's resources more easily and providing them with substantial reductions in support and development costs. This likewise would create similar economies of scale for Concord, as Schroeder noted that his team's support workload diminished dramatically.

Schroeder's team realized the Internet as a logical choice for a transport mechanism. "We thought the best solution would be to create a native gateway because most existing online merchant services' gateways are not processors, so there are inherent cost add-ons and the added difficulty of dealing with multiple entities for a payment solution," he says. "The processor is at the center of the payment system—we wanted to create a hub where transactions could be seamlessly facilitated." He decided to base development on the Web services model, taking advantage of its use of open technologies such as Simple Object Access Protocol (SOAP) and XML.

Schroeder then chose .NET as his team's development platform because of its tight integration with XML and because it would provide the rapid-response platform necessary given the aggressive timetable. "It just made good sense," he says. "We could see where things were heading with emerging technologies like SOAP. We specifically liked the Web service model based on SOAP, so we abstracted this concept from .NET and built our framework around that model. The idea at the time was that when .NET and other Web service-aware development tools became available, developers could easily tap into our Web service."

Figure 1 Interfacing With EFSnet

More Choice Provides A Better Solution
The instrumental component that drives Concord's EFSnet Web service success is its flexibility. "We feel we've built a great application for handling payment processing transactions, but we're more concerned about the people who will be coding to us," Schroeder says. By utilizing multiple platform-independent messaging protocols as interfaces—such as SOAP, XML, and Common Gateway Interface (CGI)—supported by a variety of programming languages and scripting subsets, Schroeder's team increased accessibility, making the Web service more accommodating to a broader range of merchant-end developers. "CGI and XML are alternatives to SOAP; I refer to them as the past, present, and future," Schroeder adds.

This pragmatic approach has allowed greater appeal toward developing client apps to access EFSnet, taking into consideration the wealth of platforms in use by its network of merchants. It allows coders to make choices based on their own system requirements and skill sets, making EFSnet more relevant in a diverse number of business environments (see Figure 1).

The EFSnet Web service provides real-time electronic payment processing using an HTTPS connection for transport. It exposes functionality to facilitate authorization, processing, settlement, and fund transfers to and from the client (see Figure 2).

Version 1 of EFSnet consisted of single-transaction methods such as credit card pre-authorization/settlement, card credits/debits/refunds, and transaction voids. Version 2 now supports batched transaction methods and recurring transactions for user-defined, scheduled processing.

Figure 2 Interfacing With EFSnet

Lifting the Hood
Concord designed an n-tier application based on hybrid .NET architecture, coupling front-end ISAPI Extension DLLs processed through mid-tier COM+ objects with a back-end Oracle8i ADO data-access layer. Schroeder's team initially considered building a custom software development kit to distribute to merchants, but after weighing the potential scenarios based on the population size he was working with, the answer became obvious. "The idea of supporting and managing multiple platform-dependent apps was extremely unappealing," he says. "That really left us with only one option—a Web service."

It was important to avoid the complexities of classical distributed computing, specifically in code distribution. Issues such as versioning and deployment were seen as preventable headaches. "Older systems tend to use nasty protocols … as soon as you start distributing code, it can be extremely complex to get cross-platform apps to talk," he says. "We wanted to support a number of messaging protocols that could be easily accessible by a large number of developers."

Another big plus of the app's design is its interoperability—a prime reason Schroeder enjoys .NET's rich multilanguage support. Support for languages such as Visual Basic, Java, Perl, and Python, as well as scripting platforms such as PHP and ASP, extends the effective reach of the application, giving merchants the freedom to write clients in platforms they are more familiar with. Says Schroeder, "You name it, we're doing interop."

The majority of the app was written using the Microsoft SOAP Toolkit for Visual Studio (through the various beta and release incarnations), with custom objects rolled in Visual Basic 6.0 and Visual C++. Although they'd previously used Sun servers, Schroeder's team deployed Windows 2000 Advanced Servers for application hosting, which are load balanced in Concord's multi-site Web farm.

When the app was finally abstracted to a Web service, the team used the release candidate of Visual Studio .NET (VS.NET) to manage connectivity to the app's Web Services Description Language (WSDL) contract. Schroeder says when his team installed the VS.NET release candidate they were able to access resources and start working within the IDE with ease. "The stub code generated by the WSDL Utility really helps out," he says. "There's a great degree of time reduction for ordering the underlying bits that many people don't realize. It really optimizes your app."

Although he is optimistic about SOAP's potential, Schroeder adds that the lack of support for optional parameters in previous versions of Microsoft's SOAP SDK was a minor setback, causing his team to tweak the app to match specification.

The App in Action
Since launching in July 2001, the EFSnet Web service has seen a 30 to 40 percent per month growth rate in merchants using the service. Schroeder says 90 percent of Web service consumers don't currently access the app through the SOAP interface. The majority use the more proven, classical name/value combination approach of CGI HTTPS POSTs, with a growing number of people opting for raw XML strings. Nonetheless, he stands by SOAP's potential. "If a developer chooses to access us through XML or CGI, she still has to worry about the app's plumbing, such as creating and tearing down socket connections," he says. "SOAP abstracts this all away, exposing everything as a local object on your machine. It's phenomenal. The potential for Web services is limitless."

Likewise, although nearly all clients accessing EFSnet are from merchant Web sites, Concord expects accessibility from point-of-sale devices to become common. Schroeder envisions merchants using a variety of clients, and cites an increased interest in the development of custom desktop applications as well as for those running on top of Microsoft Office.

Concord knew developing a Web service with .NET was truly the best way to go. Although Schroeder and his team had concerns that the platforms they were generating their app on were nearly all beta and/or open technologies, the pros significantly outweighed the cons: A Java/Enterprise Java Beans or Visual Basic/COM solution would have mandated costly and unattractive code distribution.

"We're extremely optimistic about .NET's capabilities," Schroeder says. "It was the perfect fit for making our Web service come to life. Because it's loosely coupled, if we're not happy with one particular area, we can change something on the fly and not have to completely redistribute. Older distribution models were premised around release dates; now we can do what we want internally. That's a huge shift in how you build things. We've already had to change things several times, and doing so has been seamless."

To that end, Concord plans to expand EFSnet to include all possible forms of electronic payment (see the sidebar, "Variations on a Theme"), including support for purchase card Level 3 transactions, automated clearing house (ACH) transactions and electronic checking. These augmentations will enable a wider variety of options for consumers, delivering a broader range of options with which merchants can implement more secure, more timely, and more reliable e-business services.

Concord has received kudos from merchant developers. They cite the ease of EFSnet's integration with their own systems—a testament to the work of Schroeder's team in fulfilling its vision. Schroeder also takes pride being one of the first in his industry to implement a Web services-based solution. He says, "The EFSnet Web service is unique in that it is a native Internet gateway to the payment processor, meaning a one-stop shop for merchants and delivering substantial cost savings."

About the Author
Jason Salas is Web development manager for KUAM-TV in Guam. He has worked with technology for more than 11 years as a salesperson, marketer, developer, consultant, instructor, and author. He is also president of the .NET User Group of Guam. You can e-mail Jason at .