Now there's the issue of selling stuff to people online. Your order form leads them to feed their credit card info to a secure
gateway, using software you bought or leased from (or through) your merchant account provider. Finally, the transaction is
approved or denied.
If approved, the software generates a receipt and e-mails you and
the customer each a copy. At this point, the customer is returned to a page you specified. In the case of downloadable
products, this is often the page where they download your product. So, you've got the entire process fully automated.
For a product or service with a fairly low price point and a potential for many thousands of sales, this seems ideal. You
can quite literally make sales and earn income 24 hours a day.
So, what's the problem?
The form code on your order page is the problem. If someone uses the ViewSource function of their browser, they can see all
your code. If they have even a tiny bit of initiative and skill,
they can locate the URL of your download page. After all, it's right there in your form code!
CGI provides two ways of fixing this problem. One involves using
a script that makes it impossible to view the source code. You can find a source for such a script by searching the web. Expect
to pay a lot for this technology.
Another way is to make the return path a script instead of the actual download location. The script would be used to create
and display the download page. It would not be visible to the surfer, since it's not an HTML document. The script can also
record details of the transaction for book-keeping purposes.
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
behaviour than mine, but here's what I've learned:
The gateway uses the POST method to send the 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 the same time. They are usually ignored, but your script can read them
if you want to!
Use the names given to the form inputs. Have your script extract
the values of these "named parameters" at the time it creates the
download page. Record what you want to save about the transaction
in your orders file or database.
Now here's the real secret to foiling the thieves. Inside the script, check to see that the variables you extract contain
non-empty values. Did you get that?
Here's an example:
if ($email eq "") {exit;}
In this example, the script expects to get an e-mail address. If it
contains no characters, the script quits instantly. By testing for
the presence of some data in such fields as customer name, e-mail
address, item #, price, etc., you can tell whether the script was
called after a successful transaction - or by a thief...
Put all your security checks prior to the code that creates the download page. If any test fails, the script exits and the 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 the
script and you can check for it before allowing the 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!
Steve Humphrey promises that you can learn to use CGI to turn your
own Web site into a marketing machine in two hours or less with his
excellent CGI learning system: "Learn to Use CGI in 2 Hours."
Required reading for anyone who wants to automate their Web site
or their marketing efforts.
Click
here for immediate access.
|