"How to Stop Digital Thieves with CGI" by Steve Humphrey 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 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 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 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: YOUR AFFILIATE LINK

Article # 2

Text Version

"How to Build a List Using CGI" by Steve Humphrey The purest form of opt-in list is the electronic newsletter or "e-zine." You ask people to sign up to get the newsletter, then you send them information about a topic that interests them. Let's look at how CGI can help you to sign them up. Assume that a person can join your list by sending an e-mail message to a special address. Most lists work that way. You put a element on a page and use a CGI script to deal with the info collected by the form. People type (or paste) in their address, maybe even their name (if you ask for it). When they click the "Subscribe" button, CGI sends a message to the server with all the data attached. A CGI program on the server then acts on it. The script will need just a few parts: 1. Code to extract the data (Name, E-mail address, etc.) 2. Code to reject obviously bad addresses [Optional]. 3. Code to build and send the e-mail message to start the subscription. 4. Some type of output. CGI doesn't like to end with no output; the script usually fails to work! For the first step, you can use a subroutine from my book or from almost any script you can read. Just look at the part where "name and value" pairs are being separated. Lines like this: $Name = $val; mean you are copying the current value into a local variable for later use. The easiest way to handle the name/value pairs is to use a function (or "method") from the CGI.pm module. Just add these lines to the top of the script (after the path line, of course): use CGI; $query = new CGI; OR $query = CGI::new(); This creates a "CGI object," which contains all the data from the form. You can pull out the items you want with one line of code each, like this: $First_Name = $query->param("fname"); $Last_Name = $query->param("lname"); $Email = $query->param("email"); Second, after the e-mail address has been copied to a local variable, you can run some tests on $email and try to determine if it's any good. These tests are done by a comparison or match statement. The match operator (=~) is used to see if a pattern exists in a given string of characters. For example, the match statement: $email =~ /getresponse.com/ is TRUE if $email is an address at getresponse.com Note: The "@" character has a special meaning. Using the backslash tells the program to treat it as an ordinary character instead. It's a good idea to check to see whether it even looks like an e-mail address at all. This is more involved than you might think. Your brain can figure it out at a glance, while a script has to check the pattern very carefully. Here's the general way an e-mail address should "look" in order to be valid: /^[\w\d][\w\d\,\.\-]*\@([\w\d\-]+\.)+([a-zA-Z]{3}|[a-zA-Z]{2})$/ OK, it looks pretty weird but it's really just a "regular expression" that defines the pattern of a valid e-mail address. Perl can compare any alleged e-mail address against this pattern. If it fails to match this, it's simply not an e-mail address at all. The subroutine "error" might display an error page or just return the user to the home page, etc. The third piece of the puzzle is having your server send the e-mail message. How this code is written depends on the server your Web site is on and what mail program it uses. You could look at a script that you know is working on the server (maybe one your host gave you) and see if it has an e-mailing subroutine. Recycle good code! You can get even more mileage out of the script by making it send a pre-determined message to the new subscriber. Just write a little subroutine that composes the message you want to send and, at the end of this subroutine, call the e-mail sending subroutine. There's usually a variable that represents either the whole message or just the body. You just add line after line to it like this (to fill in the message body): $body = "This is the first line of the message\n"; $body .= "This is the next line of the message\n"; . . . $body .= "This is the last line of the message\n"; Finally, the script should output something to send back to the user. This can be as simple as returning the user to the home page, or as complex as sending a customized "Thank-You" page. This would be a good time to offer the user a gift for subscribing. It could be a free e-book, etc. Once you have the script in place, test it to make sure it does exactly what you expect. Subscribe yourself to the list and look at any canned message that gets sent. Go back and correct any typos, etc., in the message. Unless you type a lot better than I do, there will probably be at least one. Well, what's left? You've got a fully automated process for signing up new subscribers to your list. You'll reject the addresses you don't want to mail to (autoresponders, etc.). All you need now is for people to use the process. Give them a good reason to get mail from you. It could be valuable information, tips, techniques, etc. It could be a free ad in your newsletter or a chance to enter a contest and win a prize. Determine what will motivate your people. One thing that really works well is to offer some sort of incentive to your current subscribers who will bring their friends into your list. Try something. If it works, great. If not, try something else. =========================================================== 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: YOUR AFFILIATE LINK

Article # 3

Text Version

"Increase Traffic by Programming a Contest!" by Steve Humphrey Visitors come to your site and don't buy on their first visit. It often takes 6-7 visits before they buy. So, how do you get their business if they don't come back? For that matter, how do you get them to come back? One answer is to run a contest. Not just any old contest will do! It must be crafted to keep them returning again and again. Lots of smart people will tell you that running a contest will help but they don't tell you how to do it. Here's a blueprint you can alter to suit your purposes. Every aspect of the contest was handled by CGI scripts and a couple of web pages. Even selecting the winner was done by a script. This final script simply located the persons with the most referrals. It drew one at random if there was a tie for first place. One of my clients came up with the basic idea and we developed it together as a team. People would get one "entry" into the contest when they signed up for one or more of his newsletters. They would get another "entry" for each person they referred. It was hugely successful. During the 60 days of the contest, over 45,000 new people had subscribed to my client's newsletters. They were coming back to his site over and over again. Orders for e-zine ads poured in. At the end of the contest period a week-long cruise vacation to Montego Bay, Jamaica was awarded to the winner. Generally, if the prize is valued at over $500, some authorities in your state may expect to be notified. There are various requirements; check with the appropriate state agency for details. We posted a complete set of rules for the contest on the Web site. We announced the contest itself as well as the current front-runners in each issue of my client's newsletters. Each person entering the contest was assigned a Personal Identification Number (PIN). The PIN was used to connect them with their referrals. Next, a person was given the chance to tell their friends about the contest. We made everything as easy as possible for the contestants. All they had to do was supply the e-mail address and name and the scripts did the rest. They'd be shown the message that was about to be sent to their friend. We were making every effort to be honest with them and not cause any ill will. When their friend(s) entered the contest, using a PIN we gave them, their "referral count" would be increased. To win, a contestant had to get the most referrals. In the event of a multi-person tie for first place, the software would automatically conduct a random drawing. During the contest, each contestant was able to use a special Web page to monitor the contest. They'd see the top-ranked contestants and the number of referrals each one had made. They could log in with their PIN and see their own referrals, too. They were able to come back to the site at any time and enter new referrals. We added a small form that would look up their PIN in case they'd forgotten it. They could send their own e-mails to friends to tell them about the contest. They could place e-zines ads giving contest details and a PIN to use. Keeping up with all those contestants, who they referred, how many they referred, etc., was a job for a database engine. Since we had MySQL on a server we controlled, we used that. The scripting was done in Perl. Two Perl modules were needed: DBI.pm and the MySQL module for Perl. The modules are chunks of Perl code that let a script send commands in SQL (the generic language of databases) from the script to the MySQL database engine (program). You can use a different database; you just need the database- specific module so Perl can "talk" to it through the DBI module. DBI is needed regardless of which database you use. Specific modules exist for Oracle, PostGres, etc. We verified the e-mail addresses of all the winner's referrals; we would have to disqualify a contestant if any of the addresses were faked -- and award the prize to someone else. We designed the code so that any attempts to cheat actually decreased your odds of winning -- and it was all automatic! Thousands of names and e-mail addresses are in the database. The referral counts have been reset to zero and we are ready to launch another contest at any time we choose. The programming effort, for the most part is all done. We'll just have to edit the contest page(s) and the rules page to reflect the new prize and the new "start" and "end" dates. We can easily get *at least* as large a subscriber boost with our next contest! Here's the bottom line: You'll get more visitors, and they'll visit again and again. You get to show them your offer enough times to win their business. No matter what product or service you're selling, an automated referral contest is something you should seriously consider. =========================================================== 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. YOUR AFFILIATE LINK

Ads
All you have to do is copy the ad you want below and paste it on your website or in your newsletter.  Your affiliate ID needs to be inserted.

 

Ad #1

Learn to Use CGI to Fully Automate Your Web Marketing -- IN ONLY 2 HOURS! E-mail Forms, Order Scripts, Viral Marketing, Tell a Friend Scripts... All of this is done with CGI. Finally! A system that makes CGI so easy to understand - *anyone* could learn it in just a few hours. Click here for immediate access: YOUR AFFILIATE LINK

««back to top