Wednesday, December 13, 2006

How to Stop Digital Thieves with CGI

I'm going to assume you're serious about your business. If you're not, I can't help you anyway. You've gone as far as getting a real merchant account to accept credit card payments online.

You know that this was neither easy or cheap. So does everyone else! So, a merchant account shows that you've made a serious commitment to your business. That's good for customer confidence, which is good for business. So far so good...

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 emails 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 behavior 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 email address. If it contains no characters, the script quits instantly. By testing for the presence of some data in such fields as customer name, email 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.