Teach Yourself E-Commerce Programming with ASP in 21 Days phần 5 ppsx

188 <td>
189 <a href=”processOrders.asp?showpage=<%=showPage%>&
➥
oid=<%=RS( “order_id” )%>&os=2&showOrders=<%=showOrders%>”>
190 Not in Stock</a>
191 </td>
192 <% END IF %>
193 <% IF RS( “order_status” ) = 3 THEN %>
194 <td bgcolor=”lightblue”>
195 <b>Shipped</b>
196 </td>
197 <% ELSE %>
198 <td>
199 <a href=”processOrders.asp?showpage=<%=showPage%>&
➥
oid=<%=RS( “order_id” )%>&os=3&showOrders=<%=showOrders%>”>
200 Shipped</a>
201 </td>
202 <% END IF %>
203 </tr>
204 </table>
205 </tr>
206 </table>
207 <%
208 RS.MoveNext
209 WEND
210 %>
211 <hr>
212 <% IF RS.PageCount > 1 THEN %>
213 Page:
214 <%

215 FOR i = 1 TO RS.PageCount
216 IF cINT( showPage ) = i THEN
217 %>
218 <b><%=i%></b> |
219 <% ELSE %>
220 <a href=”processOrders.asp?showpage=<%=i%>&
➥
showorders=<%=showOrders%>”>
221 <%=i%>
222 </a> |
223 <%
224 END IF
225 NEXT
226 IF allPages <> “” THEN
227 %>
228 <b>All</b>
229 <% ELSE %>
230 <a href=”processOrders.asp?showorders=<%=showOrders%>&
➥
allPages=1”>
231 All
232 Day 10
LISTING 10.8 continued
14 0672318989 ch10 3/30/00 8:18 AM Page 232
Checking Out 233
10
232 </a>
233 <%
234 END IF
235 END IF

236 %>
237
238 </body>
239 </html>
The first line in processOrders.asp includes the adovbs.inc file. You must
include this file because the processOrders.asp page makes use of the ADO
constant adOpenStatic.
In lines 3–8, all the form and URL variables are retrieved. These variables represent such
things as the current page, the ID of the order being updated, and the new order status.
Lines 10–16 assign default values to variables that don’t have a value. For example, if no
page of orders has been selected, the page defaults to the first page.
In lines 18–20, a connection to the Microsoft Access database is opened. The System
DSN named
“accessDSN” is used to open the connection.
Lines 22–37 are used to update the status of a particular order. This is accomplished with
a SQL
UPDATE statement. The UPDATE statement changes the value of the order_status
column for the database record with a certain order ID.
When an order’s status is changed to shipped, the
order_shipdate column is also updat-
ed to reflect the current date. Otherwise, if any other status is selected, the order_ship-
date column is assigned the value NULL.
In lines 40–61, the order information is retrieved from the database. The information is
drawn from three tables: the Orders table, the Products table, and the Users table. A SQL
ORDER BY clause is used to retrieve the last orders placed first.
Line 46 is used to restrict the orders retrieved. For example, you can use the HTML pick
list to view only shipped orders. Line 46 adds a clause to the SQL
SELECT statement that
retrieves only the orders with a certain order status. This statement is skipped if the All
Orders option is selected.

The
PageSize and AbsolutePage properties of the Recordset object are used to display
only a certain page of orders at a time. The PageSize property sets the number of records
to show on a single page. The AbsolutePage property sets the page to display.
The HTML pick list is created in lines 74–95. This pick list enables you to view only
those orders with a certain status (for example, shipped) or all orders.
ANALYSIS
14 0672318989 ch10 3/30/00 8:18 AM Page 233
The bulk of processOrders.asp, lines 97–210, are used to display the details of a partic-
ular order. A WHILE WEND loop is used to loop through all the orders for a certain page.
The information for each order is formatted and displayed.
An HTML table is displayed in lines 160–204. This table contains a list of possible order
status values in each of the table cells. The current status of an order is highlighted with
a blue background.
Finally, in lines 212–236, a list of page numbers is displayed. By clicking on any one of
these page numbers, you can navigate to a particular page of orders. The list of page
numbers is created with a
FOR NEXT loop. The PageCount property of the Recordset
object is used to retrieve the number of pages.
Summary
In today’s lesson, you learned how to work with transactions. You learned how to create
both transactional Active Server Pages and ADO transactions. You learned how to use a
transaction to guarantee that a series of steps either succeeds or fails as a whole.
Next, you learned how to create a checkout page for the shopping cart. You learned how
to update a customer’s address and payment information. You also learned how to trans-
fer a customer’s shopping cart to the Orders table.
Finally, you learned how to process completed orders. You learned how to create a page
that enables you to view and update the status of customer orders.
Q&A
Q ADO transactions seem really great. When shouldn’t I use them?

A You should avoid using transactions whenever possible. You must be particularly
careful with using transactions when you have a large number of concurrent users.
Long running transactions can lock up the records in your database, preventing
other users from accessing the records.
Q When attempting to use the
@TRANSACTION directive, I receive the following
error:
error ‘ASP 0216’
MSDTC Service not running
/tran.asp
Transactional web pages cannot be run if the MSDTC service is not running.
A ASP transactions rely on the Microsoft Distributed Transaction Coordinator. The
Microsoft Distributed Transaction Coordinator is included with both Microsoft
234 Day 10
14 0672318989 ch10 3/30/00 8:18 AM Page 234
Checking Out 235
10
Transaction Server and Microsoft SQL Server. On both Windows 98 and Windows
NT computers, the MSDTC service should start automatically when you start your
computer.
You can manually start MSDTC on either a Windows 98 or Windows NT computer
by using the Microsoft Transaction Server Explorer. Launch this program, select
the name of your computer, and then choose Action, Start MS DTC.
If you have SQL Server installed, you can also enable the Microsoft Distributed
Transaction Coordinator from either the SQL Server Service Manager or the
MSDTC Administrative Console. (Both programs are located in the SQL Server
program group.)
Workshop
The Quiz and Exercise questions are designed to test your knowledge of the material
covered in this chapter. The answers are in Appendix A, “Quiz Answers.”

Quiz
1. What’s wrong with the following script?
<%
Set Con = Server.CreateObject( “ADODB.Connection” )
Con.Open “accessDSN”
SET RS = Server.CreateObject( “ADODB.Recordset” )
RS.ActiveConnection = Con
RS.BeginTrans
RS.Open “select * FROM Orders”
RS.CommitTrans
%>
2. Suppose that you want to copy a particular row from the Orders table to a second
table named Orders_bak. The Orders_bak table is used to back up the data in the
Orders table. How can you copy the row from the Orders table in which the value
of the order_id column is 17 to the Orders_bak table?
Exercise
The processOrders.asp page discussed in today’s lesson enables you to assign
one of four status values to an order: Pending, Credit Card Declined, Not in Stock,
or Shipped. How would you modify the processOrders.asp page (contained in
Listing 10.8) to enable a fifth status value, Back Ordered, to be selected?
14 0672318989 ch10 3/30/00 8:18 AM Page 235
14 0672318989 ch10 3/30/00 8:18 AM Page 236
DAY
11
WEEK 2
Working with Credit
Cards
In today’s lesson, you’ll learn how to implement the most important function
for your online store: how to process customer credit cards. The lesson begins
with a brief overview of the different options available for credit card process-

ing. Next, you’ll be provided with detailed information on implementing one
credit card processing system: CyberCash. In today’s lesson, you’ll learn the
following:
• How to set up and configure CyberCash
• How to use CyberCash to authorize credit cards transactions
• How to use CyberCash to settle credit card transactions
Methods of Processing Credit Cards
There is a wide variety of options for processing the credit cards accepted at
your Web site, too many to be discussed in a single chapter. However, the vari-
ous credit card processing systems can be somewhat arbitrarily divided into
15 0672318989 ch11 3/29/00 4:01 PM Page 237
three different types: offsite payment processors, payment terminals, and component-
based solutions.
Offsite Payment Processors
Severalcompanies enable you to link to their Web sites and they will process the credit
card transactions for you. They host the payment page that prompts the customer to enter
credit card information. After the customer has completed the payment transaction, the
customer is sent back to your Web site.
The advantage of this type of system is that it is very easy to set up. You don’t need to
configure and use the Secure Sockets Layer, and you don’t need to take special precau-
tions to maintain the privacy of the customer’s credit card information. All this is done
for you at another Web site.
The disadvantage of these offsite payment processors is that you lose some control over
the appearance of your payment page. You also never collect credit card information
directly from your customers. Finally, if something goes wrong with the offsite payment
processor—for example, its Web site goes down—the problem is out of your hands and
you can do nothing about it.
One example of a company that offers offsite payment processing is Authorize.Net
(
www.authorizenet.com). To use the Authorize.Net WebLink service, you include the

following HTML form in your ASP page:
<form method=”POST” action=” /><input type=”hidden” name=”x_Version” value=”3.0”>
<input type=”hidden” name=”x_Login” value=”your login here”>
<input type=”hidden” name=”x_Amount” value=”total amount here”>
<input type=”hidden” name=”x_Show_Form” value=”Payment_Form”>
<input type=”hidden” name=”x_Invoice_Num” value=”your invoice number here”>
<input type=”hidden” name=”x_Description” value=”order description here”>
<input type=”hidden” name=”x_Cust_ID” value=”customer id here”>
<input type=”submit” value=”Click Here for Secure Payment Form”>
</form>
This HTML form creates a button labeled Click Here for Secure Payment Form that
links to the Authorize.Net Web site. You can substitute variables for the
value attributes
of the HTML form to enable customers to purchase different products. For example, the
value of the
x_Amount field is the amount that you want to charge the customer’s credit
card.
Another company that offers offsite payment processing is iBill. Currently, iBill offers a
service called the Resellers Subscription Sales service. This service cannot be used to
sell tangible goods. You can use this service only to sell Web site subscriptions and
238 Day 11
15 0672318989 ch11 3/29/00 4:01 PM Page 238
Working with Credit Cards 239
11
informational content. The iBill service is worth mentioning, however, because it is the
only payment system discussed in this chapter that does not require you to have a credit
card merchant account. The only requirement to use this service is that you have a credit
card.
Payment Terminal Solutions
A different approach to processing credit cards is represented by payment terminal solu-

tions. A prime example of this type of software is ICVerify (www.icverify.com).
ICVerify is a software product that contains an easy-to-use interface for authorizing and
settling credit card transactions. You can launch the program, type in a customer’s credit
card information, click a button, and the program authorizes a credit card transaction.
ICVerify does not work over the Internet. You must use this program with a modem.
When you authorize or settle a credit card transaction, the program connects to your
processor over the phone line and completes the transaction.
Although it is possible to use ICVerify to perform real-time credit card authorizations, I
do not recommend doing this. ICVerify is better suited for processing credit card transac-
tions in batches. For example, you can manually run ICVerify once a night and run all
the credit card transactions for that day in a single batch.
ICVerify allows you to import CSV files (comma-separated value files). So, to process
the credit cards from your online store, you would need to export the credit card transac-
tions from your database to a flat file in CSV format. You can generate CSV files from
SQL Server by using the Data Transformation Services (DTS). With Microsoft Access,
you can use the Microsoft Access Export option to convert a database table to a delimit-
ed text file.
The main advantage of using ICVerify is that it is one of the cheapest solutions for pro-
cessing credit cards. Because ICVerify uses normal phone lines and not the Internet, the
banks do not need to configure special gateways to accept credit card transactions per-
formed with ICVerify. The end result is that banks typically charge you much lower fees.
Component-Based Solutions
The third and final method of processing credit cards is to use a component-based solu-
tion. This approach provides you with the greatest flexibility over processing credit
cards. You can write Active Server Pages scripts to do such things as authorize, capture,
and refund credit card transactions.
Two examples of this approach are CyberCash (
www.cybercash.com) and VeriFone’s
vPos software (www.verifone.com). We’ll discuss CyberCash in detail for the remainder
of this chapter.

15 0672318989 ch11 3/29/00 4:01 PM Page 239
The advantage of a component-based solution to payment processing is that it gives you
complete control over credit card transactions from your Active Server Pages scripts.
Unlike offsite payment solutions, the customer never needs to leave your Web site.
Unlike terminal-based solutions, the credit card transactions can be processed in real-
time over the Internet.
Component-based solutions have two main disadvantages. First, they are typically more
expensive than terminal solutions because they require the bank to set up a custom
Internet gateway. Second, setting up a component-based solution requires you to write
custom scripts. Writing the scripts can be time-consuming.
Choosing a Method of Processing Credit Cards
So, you might ask, what is the best method of processing credit cards? Which of the
credit card processing systems discussed should I implement at my Web site?
If you want a quick and easy method of processing credit cards from your Web site, I
recommend using an offsite payment processing method such as Authorize.Net
(
www.authorizenet.com). If you want to implement the method with the lowest fees,
seriously consider using ICVerify (www.icverify.com). Finally, if you want the greatest
flexibility, CyberCash might be the best solution (www.cybercash.com).
To make it easier to research the various options for processing credit cards, here is a list
of some of the more popular solutions:
• Authorize.Net (
www.authorizenet.com)
• CyberCash (
www.cybercash.com)
• CyberSource (
www.cybersource.com)
• iBill (
www.ibill.com)
• ICVerify (

www.icverify.com)
• OpenMarket (
www.openmarket.com)
• Signio (
www.signio.com)
Preparing for CyberCash
In this section, you’ll learn how to complete the three requirements for using CyberCash.
You ’ll learn how to open a credit card merchant account. You will also learn how to reg-
ister as a merchant at the CyberCash Web site. Finally, you’ll learn how to download and
install the necessary software for communicating with CyberCash.
240 Day 11
15 0672318989 ch11 3/29/00 4:01 PM Page 240
Working with Credit Cards 241
11
Opening a Credit Card Merchant Account
Before you can use a credit card processing system such as CyberCash, you must open a
credit card merchant account with an acquiring financial institution. Typically, your
acquiring financial institution will be a bank such as Wells Fargo, Bank of America, or
BankBoston. Your acquiring financial institution works with a third-party processor to
process credit card transactions and deposit money into your merchant account.
Before opening a credit card merchant account, you need to check whether the bank sup-
ports CyberCash because not all banks support it. Most banks select and promote only a
handful of credit card processing systems.
When choosing a bank to act as your acquiring financial institution, don’t be afraid to
comparison shop. Banks might charge any of the following fees:
• Application fee—This is a fee that a bank charges you just for applying for a mer-
chant account. Not all banks charge this fee, so you should avoid it if possible.
• Setup fee—This is a one-time fee that a bank charges you for opening a new mer-
chant account. Again, not all banks charge this fee, so try to avoid it.
• Transaction fee—Almost all banks charge you a transaction fee. The transaction

fee is the amount the bank charges you every time you process a credit card.
Transaction fees can range anywhere from 10 cents to 50 cents a transaction.
• Monthly minimum fee—Some banks, but not all, charge you a monthly minimum
fee. If your sales do not meet a certain threshold, you are charged this fee.
• A discount rate—Most banks retain a percentage of each transaction. This percent-
age is called the discount rate. Discount rates typically fall in the range of 2.00%
to 3.00% per transaction.
When researching the fees a bank charges, it is important to separate the bank’s fees
from the fees charged by CyberCash. CyberCash charges additional setup, transaction,
and monthly fees over and above the bank’s fees.
Depending on your credit history, opening a credit card merchant account can be very
easy, difficult and time-consuming, or impossible. If you already have an established
Unless you plan to use a wallet (see Day 20, “Working with Wallets”), you
must install a server certificate and enable the Secure Sockets Layer (SSL)
before you can use the CyberCash service. You must use SSL to protect the
privacy of customer credit card information when the information is entered
at your Web site. For more information on configuring SSL, see Day 8,
“Building the Transaction Databases.”
Note
15 0672318989 ch11 3/29/00 4:01 PM Page 241
brick-and-mortar business, opening a merchant account might take only the time and
effort necessary to complete a one-page application.
If there are problems with your credit history, you might be forced to pay higher fees.
Again, don’t be afraid to comparison shop. CyberCash maintains a valuable list of
acquiring financial institutions at its Web site. To see this list, go to
/>Registering at CyberCash
After you have opened a credit card merchant account, you are ready to register at
CyberCash. CyberCash will lead you through the registration process in a series of
HTML forms (see Figure 11.1). To register at CyberCash, go to the following URL:
/>You will be asked for the following information:

• The legal name of your business
• Your Doing Business As name (DBA name)
• Your business address
• Contact information, including phone number and email address
242 Day 11
F
IGURE 11.1
CyberCash registra-
tion.
15 0672318989 ch11 3/29/00 4:01 PM Page 242
Working with Credit Cards 243
11
After you have registered, you will be given a CyberCash ID (CCID), hash secret, and
merchant key. You will need this information when you install the CyberCash software,
so record this information and keep it in a safe place.
After you have registered, you can download the CyberCash Merchant Connection Kit
(MCK) and the CyberCash documentation. The MCK contains the components you will
need to communicate with CyberCash to process credit card transactions. It also contains
several sample scripts. (Sadly, most of these sample scripts are written using PERL
instead of ASP.) At the time of this writing, the current version of the MCK is version
3.2.0.4.
Immediately after you register at CyberCash, your CyberCash account is not “live.” All
the transactions are performed in test mode. This is good because you want to test your
scripts before you actually start charging credit cards. When you are ready to go live, log
in to the CyberCash Merchant Control Panel and select the Going Live option (see
Figure 11.2). You can access the Merchant Control Panel at the following URL:
/>FIGURE 11.2
The Merchant Control
Panel.
Installing the CyberCash Software

After you download the MCK from CyberCash, you need to install it. The installation
procedure for the MCK is a little confusing because you need to run two installation
15 0672318989 ch11 3/29/00 4:01 PM Page 243
programs. First, you must install the MCK itself. Next, you need to execute the build-
merchant installation program from Start, Programs, CyberCash Merchant Connection
Kit.
You must enter the following information to complete the installation program:
• The fully qualified domain name of your computer—For example,
www.yourdomain.com.
• Your CyberCash ID (CCID) and hash secret—You receive this information from
CyberCash after you register.
• The name of your store and a customer service phone number.
• Your merchant key—You receive your merchant key from CyberCash after you
register.
• The URL of your secure server—For example,
. You
must have the Secure Sockets Layer configured on your server to use CyberCash.
When you run the build-merchant installation program, you must specify the computer
language you want to use with CyberCash. You are given the choice of using PERL, C,
or ASP. Because this book is on Active Server Pages, I assume you want to choose ASP.
The installation programs add two virtual directories to your Web site. One virtual direc-
tory is named
mck-shared and the other directory is given the same name as your store.
These directories contain the configuration files that CyberCash needs to process credit
card transactions. They also contain some sample Active Server Pages scripts.
The most important file that the installation program installs is named
merchant_conf.
This file contains configuration information specific to your CyberCash account. It’s a
normal text file. You can open and view it with Notepad. Typically, this file is located at
c:\inetpub\wwwroot\yourstorename\mck-cgi\conf\merchant_conf

The installation program also installs two important components: the MessageBlock and
the Socket components. You will use these components in your Active Server Pages
scripts to communicate with the CyberCash service.
After you finish installing the CyberCash software, you can test your installation by
launching your Web browser and opening the following URL:
/>Opening this page in your Web browser will open a test page that enables you to test var-
ious functions of CyberCash. For example, you can test the process of charging a credit
card (select the script named Direct Connect Credit Sale).
244 Day 11
15 0672318989 ch11 3/29/00 4:01 PM Page 244
Working with Credit Cards 245
11
Authorizing a Credit Card Transaction
Two steps are involved in transferring money from a customer’s credit card account to
your merchant account. First, you must authorize the transaction. Next, you must capture
the transaction. Capturing a transaction submits a transaction for financial settlement.
Both steps—authorization and capture—must be completed for the money to be trans-
ferred into your account.
In this section, you will learn how to create Active Server Pages scripts that enable you
to authorize credit card transactions with the CyberCash service. Remember, however,
that the transaction is not complete until you capture and settle the transaction. This sec-
ond step will be covered in the next section.
To authorize a credit card transaction, you use the CyberCash MessageBlock and Socket
components. These are ActiveX components you can use in your Active Server Pages in
the same way as you would use the Ad Rotator and Browser Capabilities components.
The MessageBlock component represents a message that you either send or receive from
the CyberCash service. Before you authorize a transaction, you load the MessageBlock
component with a list of values. For example, you add the customer’s credit card number
and credit card expiration date to the MessageBlock before you send it.
The CyberCash Socket component is responsible for sending the message to the

CyberCash service. It’s a standard WinSock component. It imitates the process of posting
an HTML form.
The script in Listing 11.1 uses the MessageBlock and Socket components to authorize a
credit card transaction. (This file is included on the CD-ROM that accompanies this book
with the name
Authorize.asp.)
LISTING 11.1 Authorizing a Credit Card Transaction
1 <%
2 FUNCTION addForm( theFormData, theName, theValue )
3 IF theFormData <> “” THEN
4 theFormData = theFormData & “&”
5 END IF
6 theFormData = theFormData & Server.URLEncode( theName )
7 theFormData = theFormData & “=”
8 theFormData = theFormData & Server.URLEncode( theValue )
9 addForm = theFormData
10 END FUNCTION
11
12 ‘ Set the location of Cash Register and Configuration File
13 paymentURL = “ />INPUT
continues
15 0672318989 ch11 3/29/00 4:01 PM Page 245
14 configLoc = “C:\\inetpub\\wwwroot\\yourstore\\mck-cgi\\conf\\merchant_conf”
15
16 ‘ Create MessageBlock Object
17 Set Args = CreateObject( “CyberCashMCK.MessageBlock” )
18
19 ‘ Create the Merchant Offer Form Fields
20 formData = addForm( formData, “mo.cybercash-id”, “test-mck” )
21 formData = addForm( formData, “mo.version”, “3.2.0.4” )

22 formData = addForm( formData, “mo.order-id”, “11111111” )
23 formData = addForm( formData, “mo.price”, “usd 1.50” )
24 Args.Add “MO”, formData
25
26 ‘ Create the Credit Payment Information Fields
27 formData = “”
28 formData = addForm( formData, “cpi.card-number”, “4111111111111111” )
29 formData = addForm( formData, “cpi.card-exp”, “02/00” )
30 formData = addForm( formData, “cpi.card-name”, “Stephen Walther” )
31 formData = addForm( formData, “cpi.card-address”, “877 Oakgrove” )
32 formData = addForm( formData, “cpi.card-city”, “Berkeley” )
33 formData = addForm( formData, “cpi.card-state”, “CA” )
34 formData = addForm( formData, “cpi.card-zip”, “94108” )
35 formData = addForm( formData, “cpi.card-country”, “USA” )
36 Args.Add “CPI”, formData
37
38 ‘ Send the Fields to CyberCash
39 set SockObj = Server.CreateObject(“CyberCashMCK.socket.1”)
40 set Result = SockObj.SendCCServer( paymentURL, configLoc, Args)
41
42 ‘ Display Status and any Error Message
43 Response.Write “<hr>Status=” & Result.Lookup( “MStatus” )
44 Response.Write “<br> “ & Result.Lookup( “MErrMsg” )
45 %>
The script in Listing 11.1 contains the bare minimum of code necessary to per-
form an authorization transaction with CyberCash. It charges Stephen Walther’s
credit card account the amount of $1.50. This information is hardcoded into the script.
Lines 12–14 define two variables named
paymentURL and configLoc. The paymentURL
variable contains the URL of the CyberCash program that performs the credit card autho-

rization. The
configLoc variable contains the path of the merchant configuration file
(merchant_conf). Before you use this script, you must enter the correct path of the
merchant_conf file on your server.
Next, in lines 16 and 17, an instance of the CyberCash MessageBlock component is cre-
ated. In lines 19–36, a number of values are loaded into the MessageBlock component.
This is accomplished with the
Add method of the MessageBlock component.
246 Day 11
LISTING 11.1 continued
ANALYSIS
15 0672318989 ch11 3/29/00 4:01 PM Page 246
Working with Credit Cards 247
11
In lines 19–24, the merchant offer fields are added to the MessageBlock. Here’s an
explanation of each of these fields:
•
mo.cybercash.id—This field is used to determine your identity. You are given
your CyberCash ID when you register. You can also look in your merchant_conf
file to find your CyberCash ID.
•
mo.version—The version of the Merchant Connection Kit.
•
mo.order-id—A unique identifier that contains an order ID. The order ID must be
25 characters or fewer. It can contain letters, numbers, periods, underscores, and
dashes. Every time you perform a transaction, you must use a new order ID.
•
mo.price—The amount that the credit card should be charged. The first three char-
acters represent the currency code. In Listing 11.1, usd is used to represent US dol-
lars. When specifying the amount, you must trim any leading digits.

In lines 26–39, the credit information fields are added to the MessageBlock component.
These fields should be self-explanatory. They represent such things as the customer’s
credit card number, credit card expiration date, and home address.
You should notice that a function named
addForm() is used to add each of the fields to
the MessageBlock object. This function is created in lines 2–10. The name and value of
each field must be URL encoded before it is added to the MessageBlock. Also, all the
fields must be joined together with an & character. The addForm() function performs
both these tasks.
In lines 38–40, the MessageBlock is sent to CyberCash through the Socket component.
The
SendCCServer() method accepts three parameters: the URL of the CyberCash pro-
gram that processes the transaction, the path of the merchant configuration file on your
server, and the MessageBlock object. The SendCCServer() method returns a new
MessageBlock object that represents the results of the transaction.
In lines 42–44, two fields are retrieved from the MessageBlock returned from
CyberCash. The
MStatus field contains a status code. It can have any one of the follow-
ing values:
•
success—Indicates the transaction completed successfully
•
success-duplicate—Indicates the result of a previously successful transaction
•
partial-success—Batch with failed transactions
•
failure-hard—Failed transaction; trying again will not help
•
failure-q-or-cancel, failure-q-or-discard—Failed transaction due to a com-
munication failure; may be retried

15 0672318989 ch11 3/29/00 4:01 PM Page 247
• failure-swversion—Transaction failed because you are using an old (or nonexis-
tent) software version
•
failure-badmoney—Failed transaction because of a credit problem with the finan-
cial institution
In line 44, the
MErrMsg field is displayed. This field contains a more verbose explanation
of any error that occurred when attempting to process the transaction. If the credit card
was successfully authorized, this field will be empty.
The first time you execute the script in Listing 11.1, you will see the screen shown in
Figure 11.3. The next time you execute the script, you will receive the following error:
Status=failure-hard
CR message: MerchantAuth: Order ID ‘11111111’ has been completed already
The error results from the fact that the same order ID was submitted more than once.
Every time you perform a new credit card transaction, you must use a new order ID. The
easiest way to generate a new order ID for each transaction is to use an autonumber field
in an Access database table or an identity field in a SQL database table.
248 Day 11
F
IGURE 11.3
The Authorize script.
Integrating the Authorization Script into Your Store
The authorization script in Listing 11.1 is too simple to be useful. All the values, such
as the credit card number and purchase amount, are hardcoded into the script. In this
15 0672318989 ch11 3/29/00 4:01 PM Page 248
Working with Credit Cards 249
11
section, you will learn how to modify the script so that it can be integrated into the
online store discussed in previous lessons.

The first thing we need to do is to convert the script in Listing 11.1 into a function.
By making the script into a function, we can pass different values for the credit
card number and purchase price. Listing 11.2 contains the modified script. (The
authorizeFunction.asp script is included on the CD-ROM that accompanies this book.)
LISTING 11.2 Authorize Function Script
1 <%
2 FUNCTION addForm( theFormData, theName, theValue )
3 IF theFormData <> “” THEN
4 theFormData = theFormData & “&”
5 END IF
6 theFormData = theFormData & Server.URLEncode( theName )
7 theFormData = theFormData & “=”
8 theFormData = theFormData & Server.URLEncode( theValue )
9 addForm = theFormData
10 END FUNCTION
11
12 FUNCTION authorize( orderID, price, cardnumber, cardexp,
➥
cardname, cardaddress, cardcity, cardstate, cardzip, cardcountry )
13 ‘ Set the location of Cash Register and Configuration File
14 paymentURL = “ />15 configLoc = “D:\\inetpub\\wwwroot\\test-mck\\mck-cgi\\conf\\merchant_conf”
16
17 ‘ Create MessageBlock Object
18 Set Args = CreateObject( “CyberCashMCK.MessageBlock” )
19
20 ‘ Create the Merchant Offer Form Fields
21 formData = addForm( formData, “mo.cybercash-id”, “test-mck” )
22 formData = addForm( formData, “mo.version”, “3.2.0.4” )
23 formData = addForm( formData, “mo.order-id”, orderID )
24 formData = addForm( formData, “mo.price”, “usd “ & price )

25 Args.Add “MO”, formData
26
27 ‘ Create the Credit Payment Information Fields
28 formData = “”
29 formData = addForm( formData, “cpi.card-number”, cardnumber )
30 formData = addForm( formData, “cpi.card-exp”, cardexp )
31 formData = addForm( formData, “cpi.card-name”, cardname )
32 formData = addForm( formData, “cpi.card-address”, cardaddress )
33 formData = addForm( formData, “cpi.card-city”, cardcity )
34 formData = addForm( formData, “cpi.card-state”, cardstate )
35 formData = addForm( formData, “cpi.card-zip”, cardzip )
36 formData = addForm( formData, “cpi.card-country”, cardcountry )
37 Args.Add “CPI”, formData
INPUT
continues
15 0672318989 ch11 3/29/00 4:01 PM Page 249
38
39 ‘ Send the Fields to CyberCash
40 set SockObj = Server.CreateObject(“CyberCashMCK.socket.1”)
41 set Result = SockObj.SendCCServer( paymentURL, configLoc, Args)
42
43 ‘ Return Status field
44 authorize = Result.Lookup( “MStatus” ) & Result.Lookup( “MErrMsg” )
45 END FUNCTION
46 %>
The script in Listing 11.2 is very similar to the script in Listing 11.1, except the
code for authorizing a credit card transaction has been converted into a function.
The authorize() function accepts 10 parameters that contain the credit card informa-
tion. The function returns the result of the transaction.
For example, to authorize a charge of $2.00 on Stephen Walther’s credit card, you would

use the following statement:
result = authorize( “111119”, “2.00”, “4111111111111111”,
➥
“02/00”, “Stephen Walther”, “899 Oakgrove”, “Berkeley”,
➥
“CA”, “94108”, “USA” )
There are three ways in which you can integrate the authorize() function into your
store. First, you might authorize the credit card transaction immediately after the cus-
tomer clicks the Checkout button on the shopping cart and places an order. To do this,
you would need to modify the doCheckout2.asp page to include the authorize()
function.
The advantage of this approach is that if, for whatever reason, the credit card transaction
fails, the customer will immediately know it. In that case, the customer can attempt the
same transaction again or try a different credit card.
Instead of authorizing the credit card transaction immediately after a customer checks
out, you could integrate the
authorize() function into the page where you process cus-
tomer orders (
processOrders.asp). The advantage of this approach is that you can
check whether items are in stock before performing the transaction.
Finally, you could create a standalone ASP page devoted to the task of processing credit
cards. The page in Listing 11.3 contains a standard HTML form that has all the fields
necessary to perform an authorization. (This page is named
processCards.asp on the
CD-ROM that accompanies this book.) By completing the form fields and clicking
Authorize, you can authorize a credit card transaction (see Figure 11.4).
250 Day 11
LISTING 11.2 continued
ANALYSIS
15 0672318989 ch11 3/29/00 4:01 PM Page 250

Working with Credit Cards 251
11
LISTING 11.3 processCards.asp
1 <html>
2 <head><title>Process Cards</title></head>
3 <body>
4 <center>
5 <font face=”Arial” size=”3”><b>Process Cards</b></font>
6 <p>
7 <form method=”post” action=”processCards2.asp”>
8 <table bgcolor=”#cccccc” border=1>
9 <tr>
10 <td align=right><b>Order ID:</b></td>
11 <td><input name=”orderID” size=”20”></td>
12 </tr>
13 <td align=right><b>Amount:</b></td>
14 <td><input name=”price” size=”20”></td>
15 </tr>
16 <tr>
17 <td align=right><b>Card Number</b></td>
18 <td><input name=”cardnumber” size=”16”></td>
19 </tr>
20 <tr>
21 <td align=right><b>Card Expires</b></td>
22 <td>
23 <input name=”monthExpires” size=”2”> /
24 <input name=”yearExpires” size=”2”>
25 </td>
26 </tr>
27 <tr>

28 <td align=right><b>Customer Name</b></td>
29 <td><input name=”cardname” size=”20”></td>
30 </tr>
31 <tr>
32 <td align=right><b>Customer Address</b></td>
33 <td><input name=”cardaddress” size=”20”></td>
34 </tr>
35 <tr>
36 <td align=right><b>Customer City</b></td>
37 <td><input name=”cardcity” size=”20”></td>
38 </tr>
39 <tr>
40 <td align=right><b>Customer State</b></td>
41 <td><input name=”cardstate” size=”20”></td>
42 </tr>
43 <tr>
44 <td align=right><b>Customer ZIP:</b></td>
45 <td><input name=”cardzip” size=”20”></td>
46 </tr>
47 <tr>
48 <td align=right><b>Customer Country:</b></td>
INPUT
continues
15 0672318989 ch11 3/29/00 4:01 PM Page 251
49 <td><input name=”cardcountry” size=”20”>
50 </tr>
51 <tr>
52 <td align=right colspan=2>
53 <input type=”submit” value=”Authorize”>
54 </td>

55 </tr>
56 </table>
57 </form>
58 </center>
59 </body>
60 </html>
252 Day 11
LISTING 11.3 continued
FIGURE 11.4
Submitting an autho-
rization transaction.
When the form in Listing 11.3 is submitted, the authorize() function is called in
processCards2.asp. The processCards2.asp page simply shows the result of the trans-
action (see Figure 11.5). The complete code for processCards2.asp is included in
Listing 11.4. (processCards2.asp is also included on the CD-ROM that accompanies
this book.)
15 0672318989 ch11 3/29/00 4:01 PM Page 252
Working with Credit Cards 253
11
LISTING 11.4 processCards2.asp
1 <! #INCLUDE FILE=”authorizeFunction.asp” >
2 <%
3 ‘ Retrieve Form Fields
4 orderID = Request( “orderID” )
5 price = Request( “price” )
6 cardnumber = Request( “cardnumber” )
7 cardexp = Request( “monthExpires” ) & _
8 “/” & Request( “yearExpires” )
9 cardname = Request( “cardname” )
10 cardaddress = Request( “cardaddress” )

11 cardcity = Request( “cardcity” )
12 cardstate = Request( “cardstate” )
13 cardzip = Request( “cardzip” )
14 cardcountry = Request( “cardcountry” )
15
16 result = authorize( orderID, price, cardnumber, cardexp,
➥
cardname, cardaddress, cardcity, cardstate, cardzip, cardcountry )
17 %>
18 <html>
19 <head><title>Result</title></head>
20 <body>
21
22 <center>
23 <% IF result = “success” THEN %>
24 <table bgcolor=”lightgreen” border=1 cellpadding=15>
25 <tr>
26 <td>
27 <font face=”Arial” size=”4”><b>Success!</b></font>
28 </td>
29 </tr>
30 </table>
31 <% ELSE %>
32 <table bgcolor=”yellow” border=1 cellpadding=15>
33 <tr>
34 <td>
35 <font face=”Arial” size=”2”><b><%=Result%></b></font>
36 </td>
37 </tr>
38 </table>

39 <% END IF %>
40 <a href=”processCards.asp”><b>Continue</b></a>
41 </center>
42 </body>
43 </html>
INPUT
15 0672318989 ch11 3/29/00 4:01 PM Page 253
Settling Credit Card Transactions
After you authorize a credit card transaction, you must capture and settle the transaction
in order for the money to be transferred from the customer’s account to your merchant
account. Exactly how this second step is performed depends on the arrangement you
made with your acquiring financial institute (your bank).
There are three different processing models for capturing and settling transactions. First,
in the AuthCapture model, transactions are automatically captured when they are autho-
rized. In other words, you do not need to do anything special to complete the transaction.
If your online store sells tangible goods, such as the candy store discussed in previous
chapters, your merchant account will most likely not be set up to use AuthCapture. The
AuthCapture model is intended for use when products or services can be delivered to a
customer immediately. For example, your bank might set up your merchant account to
use AuthCapture if you plan to sell subscriptions from your Web site.
A second processing model is the Auth/PostAuthCapture processing model. If your mer-
chant account is set up to use this processing model, you must capture the transactions
that have been authorized as a separate operation.
The Auth/PostAuthCapture model is intended for use when a product or service is not
immediately delivered to the customer. For example, if your online store sells candy, you
might not be able to ship the candy immediately after it has been ordered. In this case,
254 Day 11
F
IGURE 11.5
Results of authoriza-

tion.
15 0672318989 ch11 3/29/00 4:01 PM Page 254
Working with Credit Cards 255
11
you should not capture the transaction until you are actually ready to ship the merchan-
dise. You authorize the transaction when an order is made, and you capture the transac-
tion when the order ships.
If your merchant account has been set up to use the Auth/PostAuthCapture processing
model, you must explicitly capture transactions after they have been authorized. The eas-
iest way to do this is to use the CyberCash Merchant Administration Server. (After you
register, you should receive instructions that enable you to access the Merchant
Administration Server from your Web browser.) To capture authorized transactions, log
in to the Merchant Administration Server at
and select the
option Query Local Database and/or do PostAuths/Voids/Returns (see Figure 11.6).
F
IGURE 11.6
Capturing transac-
tions.
Finally, your merchant account may be set up to use the TerminalCapture processing
model. In this processing model, there are two additional steps to completing a transac-
tion after it has been authorized. First, the transactions must be marked to be included in
a batch. Next, the batch must be sent to the processor for settlement.
When using the TerminalCapture processing model, you can configure the CyberCash
service to automatically mark and settle transactions for you. To automatically mark
transactions to be included in a batch, enable the Auto-Mark feature. To automatically
submit transactions for settlement, enable the Auto-Settle feature. You can enable both of
these features by going to the Merchant Control Panel (
)
and clicking the Automark/AutoSettle Preferences link.

15 0672318989 ch11 3/29/00 4:01 PM Page 255
If you use the TerminalCapture processing model, you can also mark and settle transac-
tions by using the CyberCash Merchant Administration Server. To mark a transaction for
a batch, log in to the Merchant Administration Server at and
select the option Query Local Database and/or do Marking/Unmarking/Returns. To sub-
mit transactions for settlement, select the option Assemble and Submit a Batch.
Your credit card merchant account is set up to use one of these three types of processing
models: AuthCapture, Auth/PostAuthCapture, or TerminalCapture. If you do not know
which processing model you should use, you should contact your bank. Alternatively,
you can log in to the Merchant Control Panel (
) and select
the Merchant Configuration link. Your processing model will be listed on this page.
Summary
In today’s lesson, you learned how to process credit cards. In the first section, you were
provided with a brief overview of the various options for processing credit cards, such as
Authorize.Net and ICVerify. The remainder of this chapter focused on one credit card
processing service: CyberCash. You learned how to open a credit card merchant account
that you can use with CyberCash, register at the CyberCash Web site, and install the
CyberCash software. Next, you learned how to create Active Server Pages scripts to
authorize credit card transactions with CyberCash. Finally, three different processing
models for capturing and settling credit card transactions were discussed.
Q&A
Q What is the SET standard and how is it relevant to processing credit cards?
A SET stands for Secure Electronic Transaction. It is a standard for transmitting cred-
it card information over the Internet that was developed by, among others, VISA
and MasterCard. The SET standard has not been widely adopted, mainly because it
requires customers to download and install special software on their Web browsers.
Q How does CyberCash protect the privacy of credit card information as it is
passed across the Internet?
A All communication between your Web server and the CyberCash service is

encrypted using triple DES encryption. This is done automatically when you use
the CyberCash MessageBlock and Socket components.
However, you are responsible for protecting the security of customer information
when it is entered into an HTML form at your Web site. You must use either the
Secure Socket Layer (see Chapter 8) or a wallet (see Chapter 20) to protect a cus-
tomer’s payment information.
256 Day 11
15 0672318989 ch11 3/29/00 4:01 PM Page 256