E-Mail E-Commerce: Using Secure HTML E-Mail Order Forms

Direct marketers know that the fewer clicks that are required to place an order, the greater the number of people who will order. One powerful but largely untried method of direct e-commerce marketing is using HTML e-mail that includes an order form which can be submitted to an SSL secure online order taking program.

A Subscription Renewal Example

I began to examine this technique when some of my (lazy) subscribers complained that they had to fill in all the information over again when it came time to renew. They expected me to make it easy. And when I didn't, I thought I might be losing renewals. Since I keep my subscriber file on my desktop computer rather than on my webserver, providing that level of service would require a good deal of database programming.

I decided to offer renewals using an HTML e-mail form pre-filled out with the subscriber's name, address, phone, and e-mail fields. All the subscriber needed to do was fill in his credit card information and submit the form. I used Gammydyne Mailer 13.0b http://www.gammadyne.com/mmail.htm to merge the fields from my Access 97 database into an HTML e-mail form template I had prepared. After thorough testing I mailed it out to those whose subscriptions had lapsed and immediately got a number of renewals using my "Easy Renewal" form, and a smaller number prompted by the e-mail to subscribe on the website. For text-only e-mail subscribers, I included text first in the e-mail package encouraging readers to go to my online form to renew.

Various Uses for HTML E-Mail Order Forms

Here are some uses I can see for such an approach:

• Pre-filled in order forms make ordering easy and tie new orders to your customer's existing account.
• An order form with one or more pictured products offered provides an immediate way to order.
• Since JavaScript is disabled to a smaller or greater degree in e-mail clients for security of the desktop computer, a crude order blank can be made for several products, with checkboxes or a box showing the quantity ordered. This is most effective where shipping is a flat rate or can be prefigured for an order based on the customer's address. Tax, too, can be prefigured for your existing customers. But a true shopping cart isn't available at this point (so far as I know).

I am very excited about the possibilities, because it makes direct marketing approaches via e-mail that much easier to follow through on for the recipient.

Technicalities, Technicalities

I will try to explain to you how to do this, the be aware that you'll be encountering some technical gobbldy-gook that you may need to have your Web designer or programmer at your side to understand. Let me assure you, however, that it IS worth it to work through the technicalities. There is a pot at the end of the rainbow.

An HTML-Email Order Form

You can offer a form to your customers via HTML-email. To fill in the fields on a form you place the information in the VALUE="" attribute. Let me show you an example.

Populating Fields using E-Mail Merge

E-mail merge programs can be used to take data from a database and insert it anywhere in an e-mail message. I set up my e-mailed renewal form to include the name, address, phone, fax, and e-mail data from my subscriber's previous subscription. All that data was merged into the HTML form. I only left blank the sensitive credit card information -- my subscribers could fill in that information when they were ready to renew. In the example above any words surrounded by double brackets are considered by some merge programs as the name of a database field. But programs vary in the characters used to designate a merge field.

Hidden fields, too, can be populated by an e-mail merge program.

It is entirely possible to program your ordering system to relate your customer's latest purchase to his previous orders. Hidden fields can pass directly to the CGI program on the Internet.

Multi-Part MIME

The big majority of my subscribers can read and respond to an HTML-email order form. I've put an example on my website with the ACTION disabled so you can see what it looks like. http://wilsonweb.com/wct4/html-email-ssl-example.cfm I've also included an example of the HTML-template used to create the final e-mails, with the merged fields surrounded by brackets. http://wilsonweb.com/wct4/html-email-ssl-example-template.cfm For those whose e-mail programs see everything as text, I include a text version as part of the multi-part MIME e-mail message. http://wilsonweb.com/wct4/html-email-text-example.txt

Multi-part MIME is the ability of newer e-mail protocols to display HTML only to newer e-mail client programs, or text to older programs. You can learn more about how to use this in two articles:

• "Sending HTML and Plain Text E-Mail Simultaneously," Web Marketing Today, April 28, 2000 http://wilsonweb.com/wmt5/html-email-multi.htm
• "Formatting Dual Text and HTML Newsletters," Web Marketing Today, June 30, 2000. http://wilsonweb.com/wmt5/html-email-dual.htm

Submitting to a Secure Server

If an e-mail client supports HTML fully, then it is capable of submitting a form. The trick here is to submit the form to an SSL secure URL. Here's an example:

When you're dealing with customer's credit card information you're expected to handle that information securely -- not pass it unencrypted through cyberspace so that a cybercrook can steal it. When the form action goes to a URL beginning with http:// the transmission is normal, that is, insecure. But when you use a URL beginning with https:// a different and very complex submission protocol is used to ensure privacy.

This is the process involved in submission -- greatly simplified:

1. Customer clicks on submit key
2. Prompts browser to open to https:// URL named in the FORM action tag
3. Browser and SSL server exchange public passwords, determine a random number to use to encrypt a message.
4. Data is encrypted using the agreed upon random number as the key.
5. Encrypted data is transmitted to the SSL server.
6. Browser displays the secure "thank you page" following the transaction

If the customer's web browser is incapable of establishing a secure "socket" or data pipeline on port 443 in Step 3 above, then the process stops and the customer's browser sees some kind of failure message. If the data cannot be sent securely it is not sent at all. It does not somehow slip over to an insecure mode. In other words, customers may be upset that the order failed, but not that their credit card escaped unencrypted into the vast world of cyberspace to be sucked up by an evil cyberhacker.

Different from Secure E-Mail

It is important to realize that this is not "secure e-mail" at all, but a method that activates the customer's web browser to make a secure connection with a secure merchant website. Secure e-mail is different. Both the sender and the recipient must have an encryption program, trade public passwords, and then send and receive encrypted messages. With a web browser, the encryption system is automatic -- this is the beauty of the system.

How Many Users Have SSL-Capable E-Mail Client Programs?

I am convinced that a big majority of Internet users in the US are using SSL-capable e-mail client programs. Recently I polled readers to my weekly Doctor Ebiz newsletter readers, and asked them to send their results by means of submitting an HTML-email form connected to an https:// URL which required a secure connection. While this cross-section may not be identical to other readership pools, here are the preliminary results. Note: this sample is very low on AOL 4.0 and 5.0 which see text only and cannot submit forms.

According to my survey of 812 respondents from Doctor Ebiz, 86% were able to successfully submit to a secure URL. About 11% complained of problems doing so. And about 3% reported text only e-mail programs.

The Negatives

The biggest problems merchants face will be with AOL, Yahoo, and HotMail users. These may represent 20% to 30% of users in some groups. In addition, some corporate users will find their ability to execute CGI programs to SSL protected pages restricted. Eudora users are mixed. While Eudora 3.x isn't really HTML capable, Eudora 4.x and 5.x users have the option of selecting MS Internet Explorer as their default HTML viewer. Those users have full HTML capability, including submitting to a secure CGI program. However, those who select Eudora's native HTML viewer will find their HTML capabilities limited to the basics, and cannot submit to SSL secure webpages. Mac users had mixed experience. Of my sample, 21 Mac users were able to submit to an SSL protected site, while 5 were unable to do so.

A second difficulty with HTML e-mail forms is that they only work if the form is submitted when the user is online. They can be filled out off-line. But if submitted when the user is off-line, submitting may or may not force them online, depending upon their configuration. Put a reminder next to the submit button to remind customers to make sure they're online before submitting their order.

A third problem merchants will face is developing a single order form that places the order without clicking through several screens on the website. Most shopping cart programs are not configured for single-page ordering, so a shopping cart isn't the answer. I'm using a jerry-rigged Perl script that isn't fit for public distribution. Your CGI programmer can probably design a form that will interact automatically with your payment gateway a product database and an orders database. In browsing through the CGI Rescource Index http://cgi.resourceindex.com/Programs_and_Scripts/Perl/Shopping_Carts/ I found at least one form that might work for this purpose, The Rainbow Garden Merchant Order Form 1.4, though I can make no guarantees since I haven't tried it. http://www.io.com/~rga/scripts/cgiorder.html If you find a good one, please let me know.

You can probably think of other ways to use HTML e-mail order forms. E-mail e-commerce is still in its infancy, but why don't you try helping it to walk -- down the street to your bank.