Robert Carter
Microsoft Developer Network
August 1999
Summary: Discusses the Duwamish Books, Phase 4 sample application payment functionality. (6 printed pages). Includes overview information about transactions, authorization codes, and authorization methods.
Introduction
A Transaction Primer
Show Me the Authorization Code
First Things First: Get a Merchant Account
Authorization Methods
Are You Secure?
Summary
A key element of any online enterprise is its payment functionality. After all, that's how you get paid for your work and the service you provide, right? This article discusses how we configured Duwamish Books for the money part of e-commerce, and lists an array of options available to complete this important piece of your Internet business puzzle.
E-commerce is still in its infancy, even as Web storefronts ring up millions of dollars of sales each day. While you may think all those purchases you've been making on the Web lately were done entirely online, in truth there's a strong possibility someone obtained a credit-card authorization by reading your credit-card number from a computer screen and hand-entering the transaction information as they would when you enter a bricks-and-mortar store. Hardly cutting-edge, but it works.
Given that the e-commerce industry is in such a state of flux, we focused Duwamish Books on the catalog, inventory, and order-handling segment of a Web business—everything but the payment system. Duwamish Books can handle the transaction information associated with each sale, but we did not go so far as to make technology or infrastructure decisions to accommodate a specific payment scheme. The same goes for shipping and tax calculations. There are many services available that handle those particulars. We've designed Duwamish Books to accommodate their input, but have provided only placeholder functionality in those areas.
The primary difference between an Internet sale and a retail store sale, of course, is that your online store has no cash drawer. Outside of mailed checks or money orders, all of your transactions must be communicated and processed electronically. In your real-world store, you can choose to avoid all electronic or credit-card payments and still stay in business, although you may lose some customers (more if you sell high-priced items). For your Web storefront, chances are you'll lose most, if not all, of your business to someone else if you rely on people mailing you checks. People like me who get completely bogged down by the overwhelming responsibility of purchasing stamps and envelopes, writing a check, putting the check in the envelope, addressing the envelope, placing the envelope in the mailbox—it's a wonder any bills get paid at all. If I can find an alternative on the Internet that lets my fingers do the paying, I'm there.
For your Internet storefront, then, you really need to be ready to accept credit cards from the get-go. Although many other electronic payment schemes are getting press, the vast majority of Internet sales today are done with credit cards. And with the exception of electronic bank drafts (essentially online checks), many credit-card alternatives require special software to be downloaded by the user, which users have been reluctant to do so far. (If you still want to keep the door open for those other methods, several of the options we describe to follow recognize other forms of payment besides credit cards).
To get your money electronically, you have to navigate the electronic financial world via one of several financial networks (see the section "First Things First: Get a Merchant Account"). Those networks search out the home of your customer's credit card (called the acquiring institution), and query the account to ensure it is still active and has a sufficient balance to cover the purchase.
If the purchase is for something you have to ship, you can't capture the funds (what folks in the biz call funds transfer) just yet. You have to wait until you've actually shipped the goods. In that case, you first get an authorization to charge the account. When you actually ship the goods, you ping the acquiring institution again and ask for the funds, referencing your previous authorization code. If you offer downloads or subscriptions, you can proceed immediately to capture.
If you want to examine the authorization code first to determine yourself whether you should in fact ship the goods, you can do that, too. An additional feature, called Address Verification Service (AVS), gives you more information about the requestor—such as whether the billing addresses entered in your form are the same as those on record at the acquiring institution. AVS is something you should strongly consider: It often leads to lower transaction fees and, if it turns out the charge is fraudulent and you don't have AVS and you haven't done your homework, you're the one holding the bag (or not holding it, as the case may be). An excellent article on the InternetDay Web site discusses the details of your authorization code and how to interpret it. You can find it at http://www.internetday.com/archives/060299.html.
All the implementation options we'll be talking about present different ways to get those all-important authorizations and captures. Before you can do that, however, you need to get a merchant bank account that allows you to make Internet credit-card transactions.
At minimum, before you can even begin to accept credit cards online, you need to have a merchant account with a bank that handles Internet-based credit-card transactions. From there, you have a range of options about how you actually process those credit-card transactions.
To get a merchant account, you'll have to give some information about the nature of your business (Beanie-babies auction site? Buffy the Vampire Slayer pirate videos?). How much they'll want to charge for collecting and delivering your money to you will be a function of your credit worthiness, your type of business, the volume of your sales, the bank's receptiveness to the Internet in general, and which payment-processing scheme you choose. Unsurprisingly, how your payment service views your choices will determine how much you pay for their services.
You will definitely pay a monthly service fee and a per-transaction fee. You may also get socked for a software fee, a setup fee, and possibly other fees if you exceed (or don't meet) the maximum (or minimum) transactions you're allotted, or if you're buying a turnkey software solution you install on your own Web servers. As always, it pays to shop around. (The Web sites for the payment processors listed later in this article include lists of recommended banks.)
Be aware that, in general, Internet accounts aren't always greeted with open arms by the financial services industry—primarily for two reasons. First, most Internet credit-card transactions are classified as "card not present" or MOTO (Mail Order/Telephone Order), which means that your customer wasn't physically there signing the receipt and walking off with the VCR. Even though it's the rare clerk who actually looks at your signature when you sign for your stuff, in general, the incidence of fraud is lower. The Secure Electronic Transaction (SET) protocol developed by MasterCard and Visa eliminate the "card not present" conundrum by substituting the digital equivalent of a signature, but SET has been slow to find widespread acceptance because of its complexity and the software requirements it places on end users.
Second, Internet accounts, especially those for adult sites, are also apparently more subject to chargebacks. Banks don't like this. Whether it's because the "card not present" transactions disguise stolen or fraudulent transactions, or simply because husbands want to appear guiltless when their wives (or wives when their husbands) start questioning those supposedly discreet "Internet Service Provider" charges on their monthly credit-card statements, fewer Internet transactions lead to money in your account than a comparable number of real-world transactions. Whether your site would accumulate a high level of fraud and chargebacks is immaterial, at least initially. Over time, as your legions of Buffy fans turn out to be responsible paying customers, you may be able to persuade your provider to lower your service charges.
Once you and a merchant account provider have agreed to ford the river of e-commerce, you still face a few implementation choices. We'll start with low-tech options and gradually work our way higher.
The simplest approach, and according to some reports how most mom-and-pop Internet storefronts handle their online charges, is not to do it online at all. Instead, the Web server simply stores any credit-card information. A worker for the company calls up the transaction and then manually keys in the information via the phone.
Many of these accounts also provide one of those card readers that you swipe cards through, enter the amount of the sale, and then it will access the network and retrieve an authorization code for you. Of course, because you don't have the card to swipe, you have to key in the card number. Pretty labor-intensive for each sale, but not too troublesome if you don't have that many sales per week.
Many merchant accounts offer custom solutions that use a PC and a modem. Instead of keying in sales one by one and copying the authorization codes you're given by hand onto your hand-generated receipt, you enter your transactions into a computer program. It then uploads the transaction summaries and returns your authorization codes in one fell swoop. Don't confuse this solution with real-time Internet validation, however. You will probably have to manually copy and paste your transactions into their custom solution.
Now we're getting to what I think people imagine when they think about e-commerce. In this scenario, the credit-card authorization and fund capture can occur immediately when a site visitor selects your "submit" button. There are lots of options to consider even within this category—including how much information you want communicated, whether you want to enable various fraud-protection schemes, and so on.
But the most important point is that these authorizations can happen automatically, without any intervention on your part. And because you're checking the customer's credit card at the moment of purchase, you can potentially respond within a few seconds if the transaction encounters any problems—rather than later via an e-mail message ("Sorry. The billing address you gave does not match the address you have on record with your financial institution. Would you like to try another card?").
Presumably, you could write your own software module to obtain an authorization code, but it is pretty complicated stuff and would require a commitment to develop competencies that are not core to your business. Fortunately, several companies (known as "payment processors") provide credit-card authorizations (as well as fraud detection and related services) that are the core competency of their business.
Payment processors provide software modules (COM components) that collect customer credit-card and billing information and then connect to their service for verification and authorization. These components are installed (under various license fee arrangements) on the Web server hosting your page and provide an API that is accessed via scripting.
If you plan to modify the Duwamish Books sample application to conduct online validation of credit-card transactions using an online payment processor, you'll want to read Steve Kirk's article, "Workflow Design for a Web Commerce Application", especially the section that discusses the payment.asp page, which collects the customer's credit card and billing information.
To make this easier for you, a number of payment processors are currently customizing the Duwamish Books payment.asp page for use with their systems. We will update this article and add a feature to the Duwamish Books home page at http://msdn.microsoft.com/voices/sampleapp.asp, as payment processors provide this information. The following list includes the companies that we know are working on payments solutions for Duwamish Books. (If you are a payment processor and would like to participate, please e-mail us at duwamish@microsoft.com.)
One thing you should lose a little sleep over is what you ask customers to do when they want to buy something from you. Are you planning to store their credit-card information? Do you want customers to be able to access their customer records and edit their billing and shipping information? Are you comfortable with them leaving your site to do that (as they would with many authorization services)?
Whoever ends up managing all your customers' information, we can't recommend strongly enough that all transaction and customer information be transmitted securely. I consider it a really bad sign if I'm asked to give any financial or personal information and I don't see "https:" in my browser's address bar instead of "http:".
That little "s" tacked on to the end of the beginning of my URL means that the page I'm submitting information to (or requesting information from) is a server using Secure Sockets Layer (SSL). If you're using a "secure" browser that supports SSL (Microsoft® Internet Explorer 3.0 and later, and Netscape Navigator 3.x and later), the page request and response are each encrypted.
If you're really paranoid about security, you could go the extra mile and use software that supports the SET standard, which was developed by a consortium headed by VISA and Mastercard. With SET, everybody has a little more work to do. Customers have to download and run wallet software—and yes, the transactions themselves take longer, but the incidence of fraud is much lower, and you might qualify for lower transaction-fee percentages.
The Internet Information Server documentation includes detailed information on setting up a secure page for obtaining your customer's credit card and other sensitive information. This documentation is available on your Microsoft Windows NT® server via its "localhost" domain: http://localhost/iishelp/—just enter the "SSL" keyword in the index and you'll find the "Security" section of "Server Administration" reference.
E-commerce is what all the buzz is about with the Internet these days, and with good reason. People and companies are beginning to purchase things online in great numbers, and the technical and financial infrastructure necessary to process online payments is still being built.
There are many ways to add payment capability to your site. It mostly boils down to where (and, of course, with whom) you want to spend your money. If you are serious about putting an honest-to-goodness store online using Duwamish Books and real-time Internet authorization processing, you need to find the right balance of software and services provided by software vendors, Internet service providers, and financial transaction-processing services. There are a lot of service options to consider, and you may easily wind up dealing with several organizations for your payment processing.
You'll also face decisions about how to collect and store transaction and customer information. If you don't want the job of maintaining customer records, addresses, and purchase information, you can find services that are willing to assume the management of each for you. Whatever your decision, you should strongly consider a solution that uses SSL or SET to protect your customers from prying eyes.
Comments? We welcome your feedback at duwamish@microsoft.com.