Payment systems for e-commerce

Friday Dec 10th 1999 by David Strom
Share:

Processing payments from online storefronts is no easy task. Here's what you need to know for successful transactions.

New Web technologies to improve your site, Part 3:

These days it seems as if everyone is a dot-com company trying to sell something via the Internet. But behind the explosive rise in e-commerce is the very hard issue of how to process payments from online storefronts. This is perhaps the biggest hurdle of any Web storefront owner, especially these days, given the multitude of choices for hosting stores and setting them up. Let's navigate these waters and explain which technology is the best match for a storefront's particular needs.

This is the third installment in a series on new Web technologies. We began with a look at various " Network management tools " and techniques. Last time we described " The caching universe ". In this article let's assume you already have a working Web site and want to take the first step into e-commerce and sell products on your site. Next time we'll examine a variety of outsourcing services and products as well as what kinds of services can be used to augment Web storefronts hosted elsewhere.

Walk like a banker

In order to understand payment processing, you first have to talk and think like a banker. Given that most of us don't have much experience in this department, let's first define a few terms. Every business needs to have a merchant bank account, or an account that can accept credit card payments from customers. In the past, these were harder to come by for cyber-businesses because most banks required at least two years of business history tied to a particular street address. Lately, however, a number of service bureaus, such as First Data Merchant Services, have made it easier to open merchant accounts. And leading provider Authorize.Net today lists dozens of service bureaus that will open merchant accounts for Internet store operators (see http://www.authorizenet.com/pages/reseller_list.htm).

When a customer pays for something via credit card, there are two different stages in each transaction, authorization and capture. Authorization refers to checking the account number to see if it is still valid, has sufficient credit, and hasn't been reported lost or stolen. The address of the cardholder may be matched against that listed in the account, also to deter fraudulent use. Capture refers to approval and posting of the transaction, and shipment of the goods. It can happen in one of three ways: online or during the authorization with the banking network, meaning that the transaction clears both the bank that issued the customer's credit card and the storefront's merchant bank; in a separate step after authorization occurs; and in nightly or hourly batches with a credit card processing intermediary.

There have been many missteps in the short history of Internet payment technologies. The biggest issue has been the acceptance of a single standard that bridges both the banking and the Internet worlds. The trouble here is that the banks are at odds with both users and e-commerce site developers: Banks want iron-clad security, even at the expense of ease of use and/or management.

A good example of how this battle royale has played out in the standards process has been the nonacceptance by Internet storefront operators of the secure electronic transaction (SET) standards. Originally proposed by a consortium of banks and IBM Corp., SET was an answer to keeping credit card numbers away from the hard disks of Internet merchants--essentially a way for merchants to verify customer accounts without having to handle the account numbers themselves. SET went nowhere, however, and has since transformed into a new standard called the electronic commerce modeling language (ECML). ECML is brand new, with its first specification released in the summer of 1999. It tries to structure the data required from shoppers, shippers, and storefronts into a coherent single standard, adding SET credit card account security and a few other Internet standards such as eXtensible Markup Language (XML) for data structure and X.509 cryptographic standards in the process. Again, IBM and various large banks are behind ECML, and we'll see where it goes. If it is going to take hold, it needs to do so in the next 12 to 18 months.

Despite such efforts, financial institutions are still having trouble with the Internet. Witness over the past few months attempts by Citibank and American Express Co. Both firms have come out with credit card products that can only be used for cyber-shopping--and not as regular credit cards. Both are bad ideas because consumers by now are used to using ordinary credit cards for making Internet purchases: By far the vast majority of Web purchases are paid for with credit cards (or corporate purchase orders for business-to-business sites). While the general press continues to write stories about reluctant shoppers who are afraid of getting their credit card numbers stolen over the Internet, Web shopping continues to blossom.

Buyer authentication

The latest innovations in Web payments have to do with personalized shopping portals and new ways to authenticate buyers. The portals involve companies such as ShopNow.com, iGive.com, and eBates.com, and offer buyers a mechanism for receiving rebates for shopping at stores that are members of the portal's network. The benefit for storeowners is to provide visibility and drive traffic to their storefronts. Users benefit by getting discounts for frequent purchases. Only time will tell whether these networks will get established. Still, they are a minimal investment of from several hours to a day or so of programming for any storeowner and worth trying.

There are three ways to authenticate buyers at any storefront. One is to use browser-based cookies--small text files that are created by a Web server on each visitor's hard disk--and tie the cookie to a particular user ID or storefront transaction. While this is relatively easy to implement, many shoppers are unfortunately wary of cookies because of security or privacy issues and have set their browsers to not accept them. As an example, Amazon.com uses cookies to identify returning shoppers, so they don't have to reenter their shipping address or credit card number. This information is stored on Amazon's own computers, and the cookie just contains a small pointer to Amazon's customer database.

A second method is to use a straight database log in, like book and music retailer Borders Group Inc. does on its Web site--www.borders.com. This means that buyers have to remember their user ID and password before they can continue to shop. A third method is to use cryptographic certificates or one of the one-click networks.

Crypto is difficult because you first need to establish a public/private key infrastructure and send the various keys around to your customers. While it sounds good in theory, the practice is much more difficult and requires a great deal of complex set up and configuration to work properly. For that reason, a number of one-click vendors have been established over the past few years to make the process easier for customers to buy things from Web storefronts with a simple, single click of the mouse.

The one-click vendors, including Cha! Technologies Services Inc., qPass.com, iPin, Trivnet Inc., and others, don't use their own form of cyber-money but do provide users with the company's own ID tied to their credit card account numbers. When shopping at a merchant that is a member of their network, users don't have to do anything more than provide their ID and password, and the transaction will be billed directly to their credit card. The idea behind the one-clicks came from Amazon.com--one of the first online merchants to store customer information in a cookie--so returning shoppers didn't have to fill out billing information again. Newer innovations include tying IDs with ISP accounts and consolidating the billing of items purchased with users' IDs to their monthly service account bill.

These one-click providers are useful for sites selling digital goods or for users who want to aggregate a series of small transactions in a single bill, such as a daily "pass" to a newspaper Web site or purchasing inexpensive software upgrades. The problem with the one-clicks is one of critical mass: In order for them to succeed, they have to be accepted at a wide array of online merchants and have thousands of users already set up. To date, one-clicks have met with very limited acceptance.

Making payments, Internet style

The first wave of Web payments began around 1995/1996 with companies that minted their own cyber-money and tried to convince consumers to use it in place of credit cards or real cash for Internet purchases. These companies, such as DigiCash Inc. (which was recently acquired by eCash Technologies Inc.), First Virtual Holdings Inc., and others, failed because people had credit cards, were comfortable using them, and didn't trust the Internet bongo bucks developed by these and other companies. It didn't help matters that these products were difficult to implement, requiring custom programming around poorly documented interfaces, among other technical challenges. As a historical side note, the biggest initial markets were the porn merchants, looking to guarantee their buyers' anonymity.

But we still need an easy way to make payments, and in the past few years a number of electronic wallets have been created. These eWallets store frequently used information such as credit card numbers, shipping addresses, and so forth in a piece of software that resides on users' hard disks and is invoked when they go to a checkout screen on a Web storefront. eWallets are troublesome, however: The software is very hard to set up, very particular about the store and screen layouts, and often doesn't work as intended. For example, in the years I have been using various eWallets, I have yet to conclude a single, successful purchase. Often the wallets don't fill out the fields as intended or don't recognize the particular page as a checkout screen and just refuse to provide any information whatsoever. Many eWallets are on their second or third version, and hope springs eternal for companies such as IBM with its Consumer Wallet, The Brodia Group, Citigroup with its CitiWallet, and EntryPoint Inc. to get them right. A new company called Yodlee.com is taking the wallet concept a step further and using its service to store other information, such as frequent flyer accounts, e-mail IDs and passwords, and other frequently misplaced information.

However, look for lots of smoke and little heat in this department for years to come. A good example of the trouble with eWallets is Microsoft Corp.'s foray into this genre. Microsoft included an eWallet in every copy of Windows 98. Unfortunately, it wasn't enabled by default. Instead it was buried several screens deep in the Internet Options control panels. Then earlier in the fall of 1999 the company came out with its Passport technology. Completely Web-based, there is no software to install on any desktop. However, Passport users are required to sign up for Microsoft's HotMail e-mail service, and can't initially enter payment information until they are about to make their first purchase at a Passport-enabled merchant site. All of this is far too confusing for the average Internet shopper.

Web payment transactions can happen in any one of a number of ways. These include manual entry by a human via a point of sale (POS) terminal in a physical storefront; manual or electronic entry via a PC acting like a POS terminal; electronic entry from shopping cart software on a Web site; or via an electronic Internet gateway into the banking network.

The POS technologies, both manual and automated systems, were the first attempts to connect the computer and banking worlds without having to alter either one significantly. Basically, these vendors, including two companies purchased by CyberCash Inc. (Tellan Software Inc. and ICVerify), sell software that runs on a Macintosh or Windows PC and mimics the standard physical POS terminal found in just about every retail bricks-and-mortar establishment. They communicate via a dial-up modem or via the Internet to send credit card information to the banking network, much the same way the physical POS terminal does. If you want to start receiving payments quickly, take a closer look at these technologies and begin with at least manual processing. These methods will work for up to several dozen daily transactions.

The next step up is to install shopping cart software. This is software that handles the checkout screens on your storefront, and has a link to the payment processing network. Mercantec Inc.'s SoftCart is one of the more popular options and comes with modules to work with various CyberCash technologies as well as other systems. This is adequate for smaller catalogs (less than 200 items), but requires more technical storefronts. The most complex and capable solution is to run your own copy of the CyberCash Cash Register software on your Web site. However, this requires more programming expertise.

As you can see, CyberCash has cornered the market on payment processing, offering a variety of technologies. Begun in 1994 with Cybercoin, its own cyber-money, the company has constantly reinvented itself on almost a yearly basis. Earlier this year CyberCash released its InstaBuy one-click network, which has several hundred merchants signed up, but has been a limited success to date. This could be because of the critical mass issues mentioned above, or because most Internet shoppers are used to paying with credit cards and haven't bothered to investigate these other, more sophisticated methods.

Given this shifting landscape, what should a Web storefront operator do when it comes to accepting payments? If you sell digital content, then look into joining one or more of the one-click networks. And if you have shopping cart software already working on your storefront, first test out particular payment gateway technologies supported by that software.

Next time we'll talk more about what to do in terms of outsourcing parts of your Web content, including looking at the new breed of Web storefront outsourcing service providers.IJ

Related articles:

About the author:

David Strom was the founding editor-in-chief of Network Computing magazine and has written over a thousand articles for dozens of computer trade publications. He publishes Web Informant, a weekly guide to new Web technologies, trends, and services and is a frequent speaker at industry events including Next Generation Networks and Networld+Interop. He can be reached at david@strom.com.

Learning your e-commerce terms

When I first started in the e-commerce area, I had to quickly learn about banking terms and technologies. Unfortunately, there wasn't any ready reference. Now there are plenty of places to go to learn more about payment processing and merchant accounts. Although many of the following list of links are specific to their particular programs, they offer good introductory material for getting started in this rather arcane area.

Payment providers and technologies
A wide variety of choices exist for implementing Internet payment processing on Web storefronts. Here is a scorecard with links to the various vendors.

One-click providers

eWallets Personal shopping portals CyberCash Inc. technologies Standards bodies

Share:
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved