This chapter takes you through all aspects of the Introduction Service site that are related to securely and efficiently setting payment options, collecting money, and downloading information to an off-line database. Further, this chapter introduces additional systems and vendor issues regarding electronic commerce transactions on the Internet. While you explore the approach taken for the Introduction Service, take note of the alternative options presented as well as standards described for enhancing the approach, detailed in this chapter. Overall, this chapter serves as a hands-on introduction to dealing with money on the Net.
Tracking customer payments and available payment plans requires tables that should be separate from your standard member information tables.
Whenever possible, business sites should enable flexible administrative control over billing options for the non-programming site manager.
Internet commerce generally focuses on securely and efficiently authorizing credit cards, but you also should understand the standards and financial services infrastructure that is continuing to develop.
In the development of a database to manage the billing and payment features of a business Web site, two key types of information must be trapped. First, the payment options available to the site user, and second, the actual payment transactions that occur between an end consumer and the site.
The payment/billing options, or the Payment Plans can be hard coded into .asp files, but creating a table of values offers a much more flexible approach. With a PaymentPlans table, you can set parameters to control the range of options and the type of administrative flexibility built into the site. Key information includes, at a minimum, a description of the payment plan and the cost.
When users make selections from a set of payment plans, information regarding payment total and method of payment must be captured to a second table. This table could be part of the member's information table; generally, however, members will make payments over the life of their account, and, often, separating the payment information, such as the credit card number, from the member table can offer added security as well.
For the Introduction Service, we implemented two tables, including the Billing table for capturing individual transactions, and the PaymentPlans table for storing parameter driven and administrator controlled payment plan types.
The Payment Plan types table contained 8 fields, allowing description and promotion options to be stored. This information is then used to dynamically generate HTML pages as users move through the billing section of the New Account sign up process. The PaymentPlans table layout illustrated in Table E.1 includes:
Table E.1 PaymentPlans Table for Providing Payment Plans, Which Could Be Edited by Site Administrators
| Field Name | Type | Size | Description |
| SysPlanID | Number (Long) | 4 | Primary Key |
| Description | Text | 125 | Long description for display on Active Server Pages |
| ShortDescription | Text | 25 | Short description for display on Active Server Pages |
| Price | Currency | 8 | Price for initial promotional period |
| Price2 | Currency | 8 | Price for membership after promotional period |
| SysDays | Number (Long) | 4 | Length of promotional period |
| OptionsOrder | Number (Byte) | 1 | Additional options selected |
| UpgradeOption | Yes/No | 1 | Flag to define as Upgrade option only |
A billing transaction represents an actual payment plan selected by a member during either the New Account or Account Renewal process. The 12 fields trap credit card-related information, member ID, plan type, and time/date stamps. Specific fields are shown in Table E.2.
Table E.2 Billing Table for Capturing Member-driven Payment Information
| Field Name | Type | Size | Description |
| SysInvoiceID | Number (Long) | 4 | Primary Key |
| SysPlanID | Number (Long) | 4 | Index Key to PaymentPlans table |
| SysPlanDuration | Number (Integer) | 2 | Days for use of Amount1 price field |
| SysMemberID | Number (Long) | 4 | Index Key to Member table |
| Amount1 | Currency | 8 | Promotional price |
| Amount2 | Currency | 8 | Regular price |
| SysTranDate | Date/Time | 8 | Date/Time flag |
| BillingCardType | Text | 50 | Type of credit card used |
| BillingCardNum | Text | 50 | Card number |
| BillingExpDateMonth | Number (Integer) | 2 | Expiration date, month |
| BillingExpDateYear | Number (Integer) | 2 | Expiration date, year |
| NameOnCC | Text | 50 | Name on credit card, defaulted to member name |
Payment Plan Setup involves managing the administrative issues involved in offering parameter driven Payment Plan options to members. This does not concern so much the method of payment used such as Visa or MasterCard, but rather the services and prices that members choose from setup options maintained by site administrators. The section "Enabling Internet-based Payment Mechanisms" dives into the issues and approaches used to capture payment information. In contrast, the current section deals with setting up a parameter-driven approach for offering members selections during the billing process.
Only four administrative pages drive this process. These are similar to the administrative parameters discussed in Appendix D. These pages include:
Figure E.1 displays a list page for looking up and displaying linked payment plan options for editing. This provides the first screen to the site administrator in editing the available payment plans set up for the site.
This displays a list page for looking up and displaying linked payment plan options for editing.
The list page (generated by the code illustrated in Listing E.1), much like simple lookup pages that we have dealt with many times up to this point, provides a database lookup of the PaymentPlans table and displays all current plans. The list page enables a site administrator to either begin editing an existing plan type or to add an entirely new plan type.
Listing E.1 BILLINGTYPES.ASP-List Page for Displaying Current Payment Plans in Use by the Site
<%
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
sql = "SELECT * FROM PaymentPlans ORDER BY optionsorder;"
Set rs = Conn.Execute(sql)
%>
<html><head>
<title>Administration - Payment Plans</title>
</head><body bgcolor="#FFFFFF">
<h1><center>Administration - Payment Plans</center></h1>
<p><a href="http://www.1st-site.com/secure/billingtypesadd.asp">[ic:ccc][Add New Payment Plan]</a></p>
<%Do While Not rs.EOF%>
<p><a href="http://www.1st-site.com/secure/billingtypesdetail.asp?[ic:ccc]value=<%=rs("sysplanid")%>"><%=rs("shortdescription")%></a></p>
<%rs.MoveNext
Loop%>
<center><p><a href="http://www.1st-site.com/secure/index.htm">[ic:ccc]Return to Admin Homepage</a></p></center>
</body></html>
<%Conn.Close%>
Once the site administrator has selected an option from the current page, the site administrator will be moved to the .asp file displaying the payment plan details or displaying a blank form allowing the administrator to add new payment plan. Whether on the detail view page (billingtypesdetail.asp) or on the new plan add page (billingtypesadd.asp), the site administrator can then create a new payment plan or edit the existing plan she has selected. Figure E.2 displays the detail or add page. This page looks the same with the exception that if the detail of an existing plan has been selected, the form fields will be populated by existing values; in contrast, while adding a new plan, these fields will be empty.
This shows the display for add or detail page of the Payment Options editing area.
The add page varies from the edit page in that it does not default the form fields with current data; other than that, these pages produce the same resulting HTML form. The example in Listing E.2 illustrates the code used for generating an HTML form when the site administrator is editing an existing payment plan defaulted with text and check box values from the existing PaymentPlans table values.
<%
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
sql = "SELECT * FROM PaymentPlans WHERE sysplanid =" & request("value")
Set rs = Conn.Execute(sql)
%>
<html>
...
<form action="billingtypesupdate.asp" method="POST">
...
<p><b>Long Description: </b><br>
<textarea name="description" rows=5 cols=60 max=255 wrap>[ic:ccc]<%=rs("Description")%></textarea>
<P>
<table>
<tr><td width=20%><b>Initial Price: </b></td><td>
<input type=text size=10 maxlength=10 name="price" value="[ic:ccc]<%=rs("price")%>"></tr></td>
...
The update page generated by the detail or add pages is illustrated in Listing E.3. This page conditionally determines what action has been selected, including update, add, or delete, and then implements the database action, based on values passed from the detail or add page.
Listing E.3 BILLINGTYPESUPDATE.ASP-Conditional Database Action to Either Insert, Delete or Update the PaymentPlans Table
<%
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
...'Testing Uncertain Values
'--------------------------
...'Evaluate Update, Delete, Add condition
'--------------------------
if request.form("btn")="Update" then
'Update
'------------
sql = "UPDATE PaymentPlans SET"
sql = sql & " PaymentPlans.shortdescription ='" & shortdescription & "',"
sql = sql & " PaymentPlans.description ='" & description & "',"
sql = sql & " PaymentPlans.price =" & price & ","
sql = sql & " PaymentPlans.price2 =" & price2 & ","
sql = sql & " PaymentPlans.sysdays =" & sysdays & ","
sql = sql & " PaymentPlans.upgradeoption =" & upgradeoption & ","
sql = sql & " PaymentPlans.optionsorder =" & optionsorder & " "
Set rsUpdate = Server.CreateObject("ADO.Recordset")
rsUpdate.Open sql,Conn,3
elseif request.form("btn")="Delete" then
'Delete
'------------
sql = "DELETE FROM PaymentPlans WHERE PaymentPlans.sysplanid=" [ic:ccc]& request.form("value") & ";"
Set rsDelete = Server.CreateObject("ADO.Recordset")
rsDelete.Open sql,Conn,3
else
'Add
'------------
set rsInsert = Server.CreateObject("ADO.RecordSet")
Conn.BeginTrans
rsInsert.Open "PaymentPlans", Conn, 3, 3
rsInsert.AddNew
rsInsert("shortdescription") = shortdescription
rsInsert("description") = description
rsInsert("price") = price
rsInsert("price2") = price2
rsInsert("sysdays") = sysdays
rsInsert("optionsorder") = optionsorder
rsInsert("upgradeoption") = upgradeoption
rsInsert.Update
Conn.CommitTrans
rsInsert.Close
end if
%>
... 'HTML
<%Conn.Close%>
Once you implement the payment plan options by either using the method described in "Payment Plans Setup and Management with Active Server" or by using some other method, the next task is the accepting and tracking of member payment transactions. Active Server Pages with the ADO component enables members to make selections and submit payment-related information for storage in a database. The task of taking that stored information and then translating it into actual cash deposited in a checking account, however, still requires either custom components, third-party software, or human intervention.
The following sections, not only address both the Active Server Pages and ADO-based approach to capturing the payment information, but also go a step further by describing both the Introduction Service's approach and other options for collecting and tracking payments. When diving into Internet-based payment mechanisms, you need to cover:
Following the coverage of these tasks, you will be introduced to the evolving technologies, vendors, and standards in the electronic commerce area that you should watch for opportunities to offer enhanced methods for dealing with the "money" part of a business site.
The first step in collecting money from a member of the Introduction Service occurs in both the New Account and Edit Account areas of the site. The process is virtually identical for both areas, and so the payment options section, which follows looks at only one, the New Account sign up process. As we discussed in Appendix B, the user enters a 5-step process to sign up for a new account. In Appendix B, we carefully examined the first 3 steps involved in the set up of a new member record in the system. The final 2 steps involve, first, presenting payment options based on the PaymentPlans table, and second, validation and storage of the information that members provide.
Dynamically presenting Payment Plan options for the new member involves looking up information in the PaymentPlans table and displaying that information in an HTML forms-based format that enables the new member to select the options she wants and the related payment mechanisms and amounts that will be charged. Figure E.3. displays the first of two steps in the payment pages of the New Account sign up process, and Listing E.4 illustrates the code invoked to create the HTML page.
All payments accepted by the Introduction Service are based on the credit card as the payment mechanism. Other mechanisms such as checks, debit cards, and digital cash services are discussed briefly in "Emerging Payment Technologies, Vendors, and Standards."
This displays the payment screen in step 4 of the New Account sign up process.
Generating the payment page in step 4 of the New Account sign up process involves a lookup and display with the support of a database similar to SQL statement lookups of databases which we have covered many times throughout this book. The necessary HTML forms-based options must be displayed for members to select a payment plan and to input credit card information.
A function enabling the formatting of a long integer as currency was required at the time this site was put into production. Since then, Active Server Pages has implemented masking or formatting-related features to allow the more easy display of numbers in a money format.
Listing E.4 NEWACCT6.ASP-First Payment Plan Related Page in New Account Sign Up Process
<!--#include file="validatenew.asp"-->
<%
'Lookup of Payment Plans and Member Name
'-----------------------------------------
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
sql = "Select * FROM PaymentPlans ORDER BY optionsorder;"
Set rs = Conn.Execute(sql)
sql = "Select LName, FName FROM Members WHERE MemberID=" [ic:ccc] & session("MemberID") & ";"
Set rsName = Conn.Execute(sql)
name = rsName("FName") & " " & rsName("LName")
%>
...
'Function for converting number to currency
'-----------------------------------------
<script language=vbscript runat=server>
Function cvtdollars(price)
intlen = len(fix(price))
pricelen = len(price)
if fix(price) = price then
cvtdollars = "$" & price & ".00"
elseif (pricelen - intlen) < 3 then
cvtdollars = "$" & price & "0"
else
cvtdollars = "$" & price
end if
end function
</script>
...
'-----------------------------------------
'Code not shown representing the
'table/form tags for displaying payment plans and
'credit card options, SEE CD ROM for complete source
'-----------------------------------------
Once the Payment Plan selection and credit card information have been submitted via an HTML form, the system should validate and then store that information. Storing the information involves inserting the payment record into the Billing table for use in whatever accounting/tracking system may be in use.
See "New Account: Step 2," for more information about inserting records in a database, in Appendix B.
Validation, in contrast, can take on a large variety of forms. Without revisiting the steps involved in using VBScript to evaluate data entered, the focus of validation will instead center on the Introduction Service's acceptance of credit cards. With a focus on credit cards as the only accepted method of payment, a very specific set of validation steps emerge. Validation steps can be implemented up to and including the actual authorizations and capture of funds from the credit card's issuing bank. With all credit card transactions, the primary validation steps include:
Credit Card Authorizations Process
Before continuing with a review of the Introduction Service, you need to understand what is involved in processing financial transactions. Processing of financial transactions involves institutions and computer networks that we have not discussed up until now. To review, the network-based communications that take place throughout the sections of the Introduction Service we have reviewed to this point include only the client browser, whether it is being used by a site administrator or a member, and the servers used for database, Mail and Web serving activities. To perform a credit card transaction, a credit card number provided by the member to you, the merchant, must be submitted to the Merchant's bank, which then submits an authorization request to the credit card's issuing bank.
In the "real" world, a credit card authorization process can be illustrated by the following example of a consumer visiting a gas station to buy gas. The consumer stops and pumps the gas, just as a member of the Introduction Service uses the Service's features. The consumer then sees a billing amount on the pump, similar to the displayed payment plan options and amounts discussed in the previous section, "Dynamically Presenting Payment Options." The consumer then provides a credit card to the merchant. For the Introduction Service, the member submits the credit card for your current processing step. At this point, you, as the merchant, have two primary options for accepting this transaction-On-line or Batch authorizations of the credit card.
Batch is simlar to the consumer handing the card to the gas station attendant and having the attendant make a carbon copy of the card information with a simple mechanical card swiper. This batch approach, like the storing of the credit card in a database, enables the merchant to submit copies of the charges to the merchant bank at a later time for collection. The problem with this batch approach is that the credit card account may be closed, over its limit, or stolen. The merchant just doesn't know the status of the card at the time of purchase. This situation reflects the state of most merchants currently operating on the Internet.
In contrast, the gas station may have a direct electronic connection for authorizing credit cards, either through a machine at the pump, a smart cash register, or a small electronic device, probably from Verifone, plugged into a phone line by the cash register. With this direct connection, the gas station can process the credit card number, merchant identification number, and the transaction amount through a network that contacts the credit card's issuing bank for an authorization. If a successful authorization is completed, the gas station's merchant bank receives the information necessary to allow the money to be transferred, probably ending up in the gas station's merchant account by the next business day. This capability to connect to an authorizing network or "interchange" for real-time point of sale authorizations and capture of money currently exists on the Internet. You will be introduced to the forms it currently takes in the section "Emerging Payment Technologies, Vendors, and Standards."
Introduction Service's Specific Validation Steps
In contrast to on-line authorizations, the Introduction Service stopped short of capturing funds at the point of purchase and chose instead to implement a batch processing of credit cards. The Introduction Service authorizations are completed off of the Internet through a dial-up software program.
Although many Internet merchants today perform batch authorizations of credit cards, on-line authorizations have become increasingly easy to implement with the increase in vendor-provided software tools and the growing openness of banks to accept merchants processing Internet-based transactions.
The gas station in the preceding batch processing example could only take a copy of the credit card for all processing to be done later. Unlike the gas station, the Introduction Service, (with the support of computer technology) at the point of purchase, can complete two levels of validation that might not normally be completed till the merchant bank attempted to deposit the funds. The two tests include a basic test that the expiration date of the card is greater than or equal to today's date, and the second, more important test, check digit validation. The check digit validation relies on published and well established standards supported across all credit card issuing banks for defining a valid number range.
From the entry of the credit card number on the HTML form in step 4 of the New Account sign up process, the information is processed through a check digit function. This function evaluates each number in the string of numbers provided and applies the check digit logic illustrated in Listing E.5
Listing E.5 BILLINGUPDATE.ASP-Check Digit Evaluation of Credit Card Information
<Script Language=VBScript runat=server>
Function validcard(CreditCard)
' Input is a credit card number in the form of a string.
' Validates numbers which use a "double-add-double MOD 10"
' check digit Output is False if not valid, True if valid.
'---------------------------
'Staring Evaluation of card
'---------------------------
ValidCard = False 'Assume invalid card
If (CreditCard <> "0") and (CreditCard <> "") then
CC = Trim(CreditCard) 'Trim extra blanks
CheckSum = 0 'Start with 0 checksum
Dbl = 0 'Start with a non-doubling
'---------------------------
'Beginning backward loop through string
'---------------------------
For Idx = Len(CC) To 1 Step -1
Digit = Asc(Mid(CC, Idx, 1)) 'Isolate character
If ((Digit > 47) And (Digit < 58)) or (Digit = 32) Then
If Digit <> 32 Then
Digit = Digit - 48 'Remove ASCII bias
If Dbl Then 'If in the "double-add" phase
Digit = Digit + Digit 'then double first
If Digit > 9 Then
Digit = Digit - 9 'Cast nines
End If
End If
Dbl = Not Dbl 'Flip doubling flag
CheckSum = CheckSum + Digit 'Add to running sum
If CheckSum > 9 Then 'Cast tens
CheckSum = CheckSum - 10'(same as MOD 10 but faster)
End If
End If
Else
ValidCard = 0
Exit Function
End If
Next
'---------------------------
ValidCard = (CheckSum = 0) 'Must sum to 0
Else
ValidCard = 0
End If
'---------------------------
end function
</script>
Once the card number passes an expiration date evaluation and a check digit evaluation, additional code not illustrated in Listing E.5 is processed to insert the information into the Billing table as a valid billing transaction. At this point, the system assumes that the member has paid in full; if, however, in the accounting/tracking steps a site administrator identifies a credit card authorization failure, they will edit the member account to show they are no longer paid in full.
The final component of the Introduction Service involved in accounting/tracking primarily takes place off of the Internet without the assistance of Active Server Pages. The Introduction Service accounting system has been custom developed to track and maintain account information. For your site, you should consider open accounting systems if you do not already have an accounting system in place. If you have an accounting system or other database infrastructure in place, the challenge becomes integrating the Internet-based database services into your current system. Ideally you may directly connect the same systems you currently utilize in the development of your Active Server site. Because most major databases today have ODBC drivers that can be used, you may find connecting directly to your existing systems to be a viable and effective solution.
Open Accounting Systems means systems in which data is stored in a standard data structure that can be accessed by other programs. Prior to making an investment in an accounting system, carefully consider your ability to export or share accounting information with other computer programs
There are several reasons that you may find yourself required to connect two separate systems together in a batch mode like the Introduction Service:
Regardless, if you need to keep two systems in sync, first, you should evaluate the possibility of implementing a scheduled synchronizing process via a replication feature of the database servers or through a well-planned, automatic file download and upload process. If, like the Introduction Service, however, you need two separate systems, you may consider the approach implemented for this Service.
The Introduction Service keeps its off-line accounting/tracking system up-to-date with the Internet-based database through the manual use of administrative pages for generating a download file, which then gets imported into its accounting system. The Service's download process utilizes the Text Streaming component to dynamically create a file on the server for download by an administrative user. The administrative interface has a very simple HTML forms page, which generates the download page illustrated in Figure E.4
This is the download page for updating the off-line accounting/tracking system.
Once the file is successfully downloaded, the administrative user presses the update button, which flags the records as having been downloaded. Specific account information is downloaded any time a change occurs, which results in a new or modified account/members record. This process only involves two .asp files: one file for the streaming of all flagged records to a text file with an associated update to the records download flag, and a second file to toggle the download flag back, acknowledging that the information has been downloaded successfully. Listing E.6 illustrates the first .asp file or step in the download process.
Listing E.6 DOWNLOAD.ASP-File for Streaming Records to a Text File in a Set Format and Updating Download Flag
<%
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("firstsite")
session("filecounter") = session("filecounter") + 1
%>
<HTML>
<HEAD><TITLE>Download Page</TITLE><HEAD>
<BODY bgcolor="#FFFFFF">
<H1><CENTER>FileMaker Pro Download</CENTER></H1>
<%
'set conn = session("conn")
sql = "UPDATE Members SET"
sql = sql & " Members.Download = 2"
sql = sql & " WHERE Members.Download = 1;"
Set rsupdate = Server.CreateObject("ADO.Recordset")
rsupdate.Open sql, Conn, 3
Set rs = Server.CreateObject("ADO.Recordset")
sql = "Select * From Members Where Download > 0;"
rs.Open sql, conn, 3
%>
<%
set Txtfile = Server.CreateObject("Scripting.FileSystemObject")
FileRoot = "download.txt"
FileName = "c:\wwwarea\hotsites\wwwroot\1stsite\secure\" & cstr(FileRoot)
' Set to open for writing and to overwrite other files
Set a=Txtfile.CreateTextFile(cstr(FileName),True)
'---------------------------------
' Load array with lines for file
'---------------------------------
dim txtline
Do While Not RS.EOF
Set rs2 = Server.CreateObject("ADO.Recordset")
sql2 = "Select Top 1 * From Billing Where SysMemberID="[ic:ccc] & rs("MemberID") & " ORDER BY SysTranDate DESC;"
rs2.Open sql2, Conn, 3
If not rs2.eof then
txtline = """" & rs("MemberID") & """" & ","
txtline = txtline & """" & rs("AdmStatus") & """" & ","
txtline = txtline & """" & rs("Maiden") & """" & ","
txtline = txtline & """" & rs("Pass") & """" & ","
txtline = txtline & """" & rs("FName") & """" & ","
txtline = txtline & """" & rs("LName") & """" & ","
txtline = txtline & """" & rs("Address1") & """" & ","
txtline = txtline & """" & rs("Address2") & """" & ","
txtline = txtline & """" & rs("City") & """" & ","
txtline = txtline & """" & rs("StateID") & """" & ","
txtline = txtline & """" & rs("Zip") & """" & ","
txtline = txtline & """" & rs("HMPhone") & """" & ","
txtline = txtline & """" & rs("HMAreaCode") & """" & ","
txtline = txtline & """" & rs("WkPhone") & """" & ","
txtline = txtline & """" & rs("WkAreaCode") & """" & ","
txtline = txtline & """" & rs("Email") & """" & ","
txtline = txtline & """" & rs("ProfSex") & """" & ","
txtline = txtline & """" & rs2("SysPlanID") & """" & ","
txtline = txtline & """" & rs2("SysPlanDuration") & """" & ","
txtline = txtline & """" & rs2("SysMemberID") & """" & ","
txtline = txtline & """" & rs2("Amount1") & """" & ","
txtline = txtline & """" & rs2("Amount2") & """" & ","
txtline = txtline & """" & rs2("BillingCardType") & """" & ","
txtline = txtline & """" & rs2("BillingCardNum") & """" & ","
txtline = txtline & """" & rs2("BillingExpDateMonth") & """" & ","
txtline = txtline & """" & rs2("BillingExpDateYear") & """" & ","
txtline = txtline & """" & rs2("NameOnCC") & """" & ","
txtline = txtline & """" & rs("AdmStartDate") & """" & ","
txtline = txtline & """" & rs("ProfPrefID") & """" & ","
txtline = txtline & """" & rs("ReferredBy") & """"
a.writeline txtline
End If
RS.MoveNext
Loop
RS.close
%>
Your file can now be downloaded by clicking below:<br>
<a href="<%=fileroot%>"><%=fileroot%></a><p><hr>
Once you have successfully saved your download file, press
the Update button below. <b>It is imperative that you check
the data you saved before pressing this button.</b> By
pressing the Update button, you are acknowledging that you
received your download correctly.
<FORM action="toggledownload.asp" method="POST">
<center>
<input type=submit name="btnUpdate" value="Update">
</center>
</FORM></BODY></HTML>
<%Conn.Close%>
Once the file has been successfully downloaded, a second .asp file is executed to acknowledge the successful download and to flag all of the downloaded accounts back to their original status.
Although you have been introduced to the batch approach to accepting credit cards, you should be aware of the on-line authorizations approach as well. Several vendors currently provide mechanisms for accepting credit cards for on-line authorizations, but by far, the most well-known company is CyberCash. We have worked with Verifone and their vPOS system for Microsoft's Merchant Server, and we are currently working with CyberCash. Both approaches offer a very preliminary implementation of the Secure Electronic Transaction (SET) standard promoted by Visa, MasterCard, and a series of other companies.
Referring again to the gas station example to explain SET, the full implementation of SET would be like the gas station installing the mechanisms that authorize your credit card for payment at the pump prior to your pumping the gas. In this case, the gas station attendant never actually sees your credit card number and, instead, only gets the authorization code and transaction information. This is equivalent to the use of a "wallet" in your Web browser when full SET becomes available. This approach provides more security and accountability than you get today in most "real world" situations. Because the merchant never actually sees your card, the potential for fraud and other abuses is reduced dramatically. In addition, the direct nature of this transaction further reduces chance of error in the process. Unfortunately, the current implementation of SET more closely resembles the situation in which you hand your card to the gas station attendant and he swipes the card through an electronic reader or smart cash register. In this situation, the merchant has the opportunity to see and save your credit card number.
Developments to watch include the capability to do coin or small transactions as well as debit cards through CyberCash and other service providers. Also CommercNet, a non-profit, member-driven company provides a good source of information on upcoming development. For more information on these companies visit http://www.commercenet.com, http://www.cybercash.com, and http://www.visa.com.
We have worked closely with Wells Fargo and, more recently, Bank America and are happy to note a complete turn in the position of these major banks. While Wells Fargo has been very progressive in many areas already, both banks have demonstrated a real commitment to facilitate commerce over the Net and no longer voice caution and doubt to would-be electronic commerce companies. This shift has made banks willing to issue merchant accounts for Internet-only companies as well as to facilitate the rollout of the SET standard. This commitment comes from leading financial players, ranging from vendors like Verifone to the networks managed by Visa and MasterCard to the banks and clearinghouses like Wells Fargo and Bank America. A clear movement has begun, not only in the progressive technical companies, but also in the core institutions that act as the gatekeepers of commerce.
With the conclusion of this payment discussion, you should now be ready to implement a comprehensive business site with the capability to build and track a membership, manage an interactive service, provide a comprehensive administrative environment, and bill and collect payments. At this point, you just need to decide what you want to build.
© 1997, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.