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. I know
I do!
|