3) Each of input tags includes a variable name. The data which is retrieved from visitor (or directly set if tag includes "hidden" qualifier) is placed in variable name.

4) When visitor presses "submit" button, CGI routine which was specified in form tag is executed. At this time, CGI routine "takes control", meaning browser essentially is waiting for it to complete.

5) This CGI routine can get data from variable names. It retrieves data and does whatever action is required.

6) When CGI routine finishes, it returns control back to web client (the browser).

Some important things to remember about CGI routines:

- You can install CGI routines on your own site if your host allows it - Addr.Com is an example of a web host which allows for CGI routines. Some web hosts do not allow you to install your own routines but do provide some pre-written ones to you. If these are not sufficient for your needs, you can find a remote hosting service to provide necessary functions.

- Generally, if you install your own routines they must be installed in cgi-bin directory of your site. This is a special location which allows scripts and programs to be executed.

- CGI routines work best on Apache-style servers. Windows NT and Windows 2000 does support CGI, but it tends to be slow and problematic.

- If you use a remote hosting service, you must remember that although they appear to be giving you this for free, you are actually paying a price. Usually they want to display advertisements, although some of them actually take visitors away from your site.

- When you write a CGI routine, you have choice of a scripting language like PERL or a compiled language such as C++ or Visual Basic. Anything which can execute on web server is acceptable.

I hope this short introduction to CGI has cleared up some of mystery.

I admit that I discovered this by trial and error - and a lucky guess or two. Your merchant account gateway software may have radically different behavior than mine, but here's what I've learned:

The gateway uses POST method to send customer to your specified return URL (which can be a script as well as a web page). It also POSTs most of its input data items at same time. They are usually ignored, but your script can read them if you want to!

Use names given to form inputs. Have your script extract values of these "named parameters" at time it creates download page. Record what you want to save about transaction in your orders file or database.

Now here's real secret to foiling thieves. Inside script, check to see that variables you extract contain non-empty values. Did you get that? Here's an example:

if ($email eq "") {exit;}

In this example, script expects to get an email address. If it contains no characters, script quits instantly. By testing for presence of some data in such fields as customer name, email address, item #, price, etc., you can tell whether script was called after a successful transaction - or by a thief...

Put all your security checks prior to code that creates download page. If any test fails, script exits and thief is left empty- handed. If your form-handling script can convert a product name to a product ID that's never visible to a browser, this provides even more security. This will be POSTed back to script and you can check for it before allowing download.

Close these security holes and you'll make more money. You may even sleep a little better knowing that people can't steal that product you worked so hard to create. I know I do!