Just as it was coming up to the 1999 holiday season, housewares marketer Cooking.com made a critical decision to bring its outsourced online payment processing system inhouse. It was a bold move for the fledgling company, which debuted with a Website in September 1998 and launched a print catalog operation in December 1999.
Cooking.com had been using an application service provider (ASP) for online payment processing and authorization during its first year of business. The ASP model, which enables companies to outsource applications via the Internet, had supplied the site with real-time credit-card authorization and processing and order confirmation without requiring the marketer to invest heavily in IT resources.
But in gearing up for the ’99 holiday season, Santa Monica, CA-based Cooking.com was concerned about security, reliability, and speed, says Jae Yim, director of site development. Transaction volume had reached a threshold—Cooking.com won’t reveal numbers—that rendered the ASP model less than satisfactory, Yim says. Because orders had to travel over the public Internet to be processed and approved, the real-time credit-card approval and order completion was subject to delays of up to 30 seconds, not to mention occasional downtime—just the kind of thing that practically begs shoppers to shop elsewhere. “Think of a brick-and-mortar where the cash registers didn’t work,” Yim says. “It’s really critical that people can purchase from the site, because other sites are just a click away.”
So Cooking.com chose to purchase server-based payment processing and authorization software from Austin, TX-based ClearCommerce. According to ClearCommerce’s vice president of emerging technologies, Julie Ferguson, the flat fee for the software is $75,000. In comparison, an ASP typically charges nominal one-time set-up fees and monthly charges as well as a per-transaction processing fee of $0.20-$1.00. Cooking.com also set up a private direct link to credit-card processer First Data Merchant Service via a frame relay line, a type of continuous, dedicated connection.
The evaluation process behind Cooking.com’s decision underscores the salient points in selecting an online payment processing solution. The decision is simultaneously straightforward and complex.
On the one hand, the basic options are clear-cut: You can outsource, buy, or build your payment processing application. On the other hand, arriving at your decision requires extensive thinking about present and future volume, average order size, market segment, site performance, reliability, scalability, security, and IT environment.
A matter of time
One key factor that distinguishes e-commerce from other card-not-present transaction environments is the sense of immediate gratification that users derive from shopping online. “Shopping online is almost like walking out of a store with the product—customers want to leave the Website knowing that the product is in stock and their payment has been accepted and the order is being shipped,” explains Larry Bouchard, group manager of product management for Dallas-based Paymentech, which hosts a variety of transaction processing services for direct merchants.
In that light, deciding whether to implement a real-time payment processing and authorization solution or one that offers users the appearance of real-time is critical. Just more than 60% of online merchants use real-time payment processing and authorization systems, says Avivah Litan, vice president of the payment services group for Gartner Research in Washington. Merchants can offer the appearance of real-time order processing by sending an e-mail confirmation of order receipt and a second confirmation that the order has been processed and shipped. Ideally, customers won’t be aware that the payment wasn’t authorized and processed in real-time—unless you have to contact them because their credit card wasn’t approved.
Real-time processing was a key requirement when Cooking.com migrated to the ClearCommerce solution, Yim says. The site had provided it from the beginning and didn’t want to alter customer expectations with the new solution. Also, in the event of problems with customers’ cards, “we didn’t think it would be a good idea to call people back—especially if they wanted the order the next day,” Yim says. “From a customer service perspective, it’s not a pleasant phone call, and there’s the fear of alienating the customer. From a process perspective, that would also be a lot more work for our customer service reps.”
But opting for non-real-time processing and authorization doesn’t necessarily translate into poorer customer service, notes Dave Dierolf, vice president of information technology at consumer electronics cataloger Crutchfield. The Charlottesville, VA-based marketer promotes same-day shipment of orders received by 6 p.m. Eastern time, and its use of offline authorization and processing of credit-card payments hasn’t impeded that service goal, he says. While Crutchfield’s call center order-takers receive credit-card authorization for phone orders before the end of the call, online orders are manually entered into the company’s homegrown order processing system and then authorized via one of three private, direct links to First Data. “Our credit-card processing system preexisted the Net, and it has served us best to run Internet orders through the same way,” Dierolf says. “Our philosophy is that we are one company, so regardless of whether the customer is mailing in the order, calling, or placing it online, we have an integrated strategy.”
Dierolf estimates that the time lapse between receipt of online orders and order entry is no more than five minutes. About one-third of the approximately $200 million company’s orders come in via its Website; of those orders, 30%-40% flow through without intervention, Dierolf says. But given the nature of ordering stereo components—users often select items that aren’t going to function well together—online orders generally need at least some scrutiny by a customer service rep anyway.
While Cooking.com relies on real-time authorization and processing, and Crutchfield uses a non-real-time system, a third option exists. You could implement real-time card authorization but process payments in batches. “For many companies,” says Andrew Ari Clibanoff, an analyst with New York-based Jupiter Research, “it’s beneficial to batch payments for a better discount rate.” Ferreting out fraud
Besides the sense of immediate gratification, another major distinguishing factor of online card-not-present transactions is the increased need for fraud detection. Fraudsters are constantly uncovering new ways to use the Net to conduct deceptive transactions. And the perpetrators can bombard a site with multiple fraudulent orders more quickly than they can by calling an 800-number.
“There’s the potential to be hit very rapidly online,” Dierolf says. “If someone has stolen a credit card and calls us on the phone 50 times, he’ll eventually talk to the same operator. But on the Web, he may submit 50 orders and not be noticed.”
Merchants can get around that by programming in system alerts when a certain number of orders are placed on the same card in a given day. But the possibility underscores the need for payment processing and authorization systems to offer an extra degree of fraud detection as well as to work with a merchant’s existing fraud detection methods, from the basics such as address verification systems to customized algorithms that invoke red flags on suspect orders. (For more on preventing online fraud, see “Ask the Experts,” December 2000 issue.)
“The software solutions on the market are extremely sophisticated, but merchants want tighter integration with their current business operations,” Clibanoff adds. “That’s where a disconnect is happening, and over time a lot of vendors will work with merchants to identify how to integrate their technologies with current business operations.”
Clibanoff’s research indicates that when traffic at an e-commerce site exceeds 100,000 unique visitors, and when average order sizes are $150 and up, fraud rates increase. “The merchant’s goal should be to implement a fraud system that pays for itself, and to do that on a budget of less than 1% of sales,” he says.
Most payment processing vendors offer some degree of fraud detection, but they may not be robust enough for your liking. With both its ASP and ClearCommerce, Cooking.com devised a number of its own fraud-detection techniques to integrate into its payment processing system. Clearly, the fraud-detection capabilities of your various payment processing options will factor in heavily when it comes time to make a decision.
Hiding the seams
While the Internet is a different beast that requires some rethinking of any existing payment processing and authorization solutions, your online payment processing shouldn’t stand noticeably apart from your offline solution. From the perspective of both your external customers and your internal business departments, it should be seamlessly integrated with your existing systems, says ClearCommerce’s Ferguson.
Technically, that requires selecting a system with flexible application programming interfaces (APIs) that will make it easy to integrate with existing settlement and reporting systems, the storefront and the shopping cart, and the order processing and fulfillment systems.
Ferguson suggests that if your site’s current or anticipated volume exceeds 1,000 transactions a month, you should consider an inhouse solution. (Then again, Ferguson works for a company that sells inhouse solutions.) But Clibanoff notes that if a marketer is already outsourcing payment processing for phone and mail orders, it may want to extend its outsourced solution to the Web initially and bring it inhouse over time. That can be a challenge, even when the decision has clear-cut drivers. For Cooking.com, the migration to an inhouse solution was part of a complete site overhaul, including a migration from Microsoft Site Server to a homegrown storefront and shopping cart and to Windows 2000 for its Web and database servers. The company, which has built up a 3 million-name house file, ran into difficulties when, approaching deadline, it discovered that the class of frame relay line it had purchased from its telecommunications vendor was not compatible with Windows 2000.
Rather than start over with a new frame relay line—which typically takes six to eight weeks to install—Cooking.com opted to set up the ClearCommerce software on a Sun Solaris server. That introduced a new operating system into its environment—Solaris is a flavor of Unix —which in turn has required additional IT resources.
“We didn’t have a Unix guru on staff,” Yim says. “A couple of us knew enough Unix to get around it, but we didn’t have any Solaris expertise. ClearCommerce sent some of its people to help us implement it, but we’ve had to outsource staff who know Oracle and Unix. That’s been our biggest problem.” It seems, then, that even bringing payment processing inhouse requires outside help.
New York-based Leslie Goff writes for publications such as The New York Times and Computerworld.