Over on the Mac Small Business discussion list, there has been a discussion raging for the past few days regarding payment processors. It started with a comment about a rather controversial decision by Kagi to start adding a license code lookup service to software purchases made on their site. This service costs the end users an extra $5.00. While you can opt out of this “service”, this move highlights a problem with using 3rd payment processors. When you are using a 3rd party payment processor, once the user had decided to give you money you lose a large amount of control over what your user experiences. When your users are about to give you money, the last thing you want to do is upset them.

Another problem is the visual discontinuity that often occurs when using a 3rd party payment site. While some payment processors (like Kagi), allow you to customize your store using your own css, this is a manual process that requires you to send them your css file and have them install it. Any changes you make to your style sheet would also have to duplicated on the second site. There is also usually a fee associated with this procedure.

That being said, there are some definite advantages to letting someone else process your payments, the obvious one being that you don’t have to do it. Every month (or twice a month in some cases), you receive a check for all of your hard work. Many processors also provide you with a license key generation service, saving you from having to roll your own. And after all, creating your own store, and processing payments, and generating your own serial numbers is hard right? Well, no, not really.

Don’t get me wrong, there are a lot of steps involved, and this isn’t something that you want to mess up. However it is not as bad or complicated as you might think. Since we just went through this process, I’m going to take you step by step through what we did. In part 1 of the tutorial, I’ll cover all of the prep work that goes into gearing up for payment processing as well as the client-side stuff needed for the storefront. Then in part 2 I’ll cover the server-side processing that is the meat of the payment processing.

Before we start that though, it might be fun to survey the landscape and see who is using what in terms of payment processors. To do this, lets look at the software that I have purchased over the past 90 days:

• Coda - Panic Software: Own Payment System
• Fission - Rogue Amoeba: esellerate
• FileStorm - Mind Vision: esellerate
• MarsEdit - Red Sweater: PayPal/Kagi

The above list shows that really the choice is yours. No matter what you choose no one is going to think you’re odd. Some people have mentioned that some people may be more inclined to trust Kagi/PayPal verses a proprietary solution. We haven’t noticed any decrease in sales since implementing our own store. If your site looks professional and uses SSL, most people that are willing to use their credit cards online will not think twice about using your online store.

So without further ado, here are the steps that we went through to setup our own payment system.

Disclaimer: I am not an accountant or lawyer, before doing anything involving other people’s money you should check with a lawyer and an accountant.

1. Open a Merchant Account.

   This was the only part that cost money, however it was also the easiest technically. I just went to my local bank, setup a meeting with my business banker, and in a few days I received an email with my merchant account number, and a link to the api to access the payment gateway (the servers that do behind the scenes credit card processing). Its important to sign up for a merchant account with a reputable bank that has an established method of handling online payments. Otherwise you may have to go through an additional sign up process (and pay additional fees) to a payment gateway service in order to handle online credit cards.

   Our bank (like many others) uses the Your Pay API for credit card validation. The Your Pay API has a great set of examples and good documentation that makes implementation easy. Make sure you find out what API your bank’s payment gateway service uses ahead of time so that you can make sure it will work for your situation.

2. Get an SSL certificate

   Having an SSL certificate allows you to setup parts of your site to use the https protocol. This gives you that nice little padlock in your browser that tells the user that your connection is secure and that no one else is listening in.

   Depending on your webhost, this could be easy or moderately difficult. Most webhosts have some package that comes with an SSL certificate or offer it as an add on for a small fee. In the case of our webhost, this was as easy as clicking the “Add SSL Certificate” in our domain manager control panel.

   It is a good idea to create a separate directory in your site structure so that you can put all of your store things there. This makes it easy (for apache users anyway) to force those pages to always use the https protocol. Let’s say you have a directory called “store” where you keep all of your store pages. In that directory, create or modify your .htaccess file with the following code (without the line numbers):

   1. RewriteEngine on

   2. RewriteCond %{SERVER_PORT} !^443$
   3. RewriteRule (.*) https://www.yourdomain.com/store/$1 [R=301,L]

   4. RewriteCond %{HTTP_HOST} !^www\.yourdomain\.com [NC]
   5. RewriteRule (.*) https://www.yourdomain.com/store/$1 [R=301,L]

   Now if you type in http://www.yourdomain.com/store/ you’ll be redirected to https://www.yourdomain.com/store/ and your ssl certificate will be in effect.

3. Setup the storefront page

   Now, the rest of this article is going to get slightly more technical. Our implementation requires some javascript and php use, however you don’t have to be a guru in either by any means. If your webhost has rails support, you can skip these next few sections by downloading the Potion Factory’s open source potion store. If you don’t have rails support, read on!

   The store front page is the page people see where the put their payment information in. A lot of people split this into two parts, a page where you specify the products that you want, and a page to collect the payment information. I choose to follow Panic’s approach to this and have it all on one page. Some people think that they need to use some kind of shopping cart system. The shopping cart is a great metaphor for sites like Amazon, but lousy for small ISV’s. If you can count your offerings on one hand, you probably don’t need a shopping cart.

   There are 3 basic sets of information you need to collect here:

   1. What the customer is buying
   2. The customer’s contact information
   3. The customer’s payment method

   What the Customer is Buying

   For the “What the customer is buying” section you need a way for the customer to specify how much of each of your products you want. You also need to show how much it costs, and preferably have a running total. Depending on your situation, you may also want to implement a way for the customer to enter an upgrade code (such as their license key from the previous version), and have the price change accordingly.

   Most of this is basic html so I won’t cover that, however the dynamic price updates does require a bit of javascript:

   1. var itemPrice = 6495.0;
   2. function updateField()
   3. {
   4.     var totalAmount = document.form1.itemQuantity.value * itemPrice;
   5.     document.getElementById(”calculatedTotal”).innerHTML = “$” + (totalAmount/100).toFixed(2);
   6. }

   .
   .
   .

   7. <input class=”qtyFormField” size=”3″ type=”text” value=”1″ name=”itemQuantity” onChange=”updateField();”/>

   .
   .
   .

   8. <div ID=”calculatedTotal”>$64.95</div>

   As you can see there is nothing fancy here. Whenever someone updates the itemQuantity field (line 7) the onChange event is fired. This causes the updateField() function to be called. That function multiplies the itemPrice (set in line 1), with the number in the item quantity field. Line 5 then takes that amount and formats it to look like a price and puts the result in the calculatedTotal div.

   A couple of things to note here. First of all, notice that I have the price hardcoded in the javascript, you may be thinking, “that’s lame, what if someone changes it locally to give themselves a discount?”, well this value is checked against the server side code that processes this form (more about that code later). This does however bring up a crucial point, Never trust anything that comes from the storefront page! Anyone can change this information and some people can change it in ways that can be very bad for you. We’ll look more at this as we proceed.

   Also notice how the item price is set to 6495.00 and then shown to the user using:

   (totalAmount/100).toFixed(2)

   This is to fix problems with how floats are calculated.

   I’ll cover dynamically checking the upgrade codes in part 2 of the article.

   The Customer’s Contact Information

   This is pretty basic so I’m just going to skim over it. You’ll want to collect things like name, address, email, etc…

   The Customer’s Payment Information

   Here you’ll want to collect the type of credit card, (while this isn’t usually necessary for processing, it is good to have for your records), the credit card number, expiration date, and CCV code, (the 3 or 4 digit security code that people use these days to make your online ordering more secure).

4. Client-Side Validation

   Now that you have collected all of that information it’s time to do the first stage of validation. All Client-side validation does is to give the user a chance to correct their mistakes.

   Client-side validation is not a security measure!

   To perform client-side validation, you can modify your <form> tag to look like this:

   <form name=”form1″ method=”post” action=”process.php” onsubmit=”return checkFields()”>

   When the user clicks the submit button in your form, the first thing that happens is that the onsubmit event is fired. This causes the checkFields javascript function (which we’ll discuss shortly) to be called. This is the function that will perform the client-side validation. If it returns true (i.e. everything is good), the form will be submitted to the process.php page. If it returns false, nothing will happen.

   In the checkFields function, there are basically two things you’re going to check. First, make sure that that your quantity fields are numeric, and second make sure that all of your required fields have data in them.

   1. function checkFields()
   2. {
   3.     if(isNaN(parseInt(document.form1.itemQuantity.value)) || document.form1.itemQuantity.value < = 0)
   4.     {
   5.         alert(”Please enter a valid quantity.”);
   6.         document.form1.itemQuantity.focus();
   7.         return false;
   8.     }
   9.     if(trimString(document.form1.FirstName.value).length == 0)
   10.     {
   11.         alert(”Please enter your first name.”);
   12.         document.form1.FirstName.focus();
   13.         return false;
   14.     }

   . . .

   Lines 3 - 8 Makes sure that that the data entered in the itemQuantity field is a real number greater than 0. If it’s not valid, the user is prompted to fix it and then focus is set to the itemQuantity field. The function then returns “false” so that the form won’t be processed.

   If that first check turns out ok, we then move on to lines 9 - 14 which check that the FirstName field has something in it. If not, the user is again prompted to fix it and the focus is set to the FirstName field. The function again returns false. You’ll need to repeat lines 9 - 14 for all of your required fields.

   Now in the case of the State/Province and Zip Code fields, they may only be required for US or Canadian addresses. So to prevent other users from having to put in bogus data, we can do the following:

   . . .
   1. // For US and Canada only
   2. if(document.form1.Country.value == “US” || document.form1.Country.value == “CA”)
   3. {
   4.     if(trimString(document.form1.State.value).length == 0)
   5.     {
   6.         if(document.form1.Country.value == “US”)
   7.             alert(”Please enter your state.”);
   8.         else
   9.             alert(”Please enter your province.”);
   10.         document.form1.State.focus();
   11.         return false;
   12.     }
   13.     if(trimString(document.form1.ZipCode.value).length == 0)
   14.     {
   15.         alert(”Please enter your postal/zip code.”);
   16.         document.form1.ZipCode.focus();
   17.         return false;
   18.     }
   19. }

   . . .

   20. return true;

   Before we attempt to validate the state and zip code fields, we first check to make sure the user has specified either a US or Canadian address. (Other countries may use states and zip codes in their addresses, and if you know they do, feel free to verify the fields in those cases). In line 2 is where we check for the country. In order for this check to work, everyone would have to type United States and Canada exactly the same way, since they aren’t likely to do that, use a select box for your country field.

   Lines 4 - 12 check for a value in the state field, and prompt the user to correct it should the value be missing. (Note that for Canadian users we ask them to fix the province rather than the state. Lines 13 - 17 check the ZipCode field just like we checked the other required fields.

   Finally if we’ve reached the bottom (line 20 in our abbreviated example), all of the fields have passed client-side validation and so we return “true”. The form is then sent to the process.php page for final processing.

If you’ve followed this far along, you now have an SSL-secured storefront that allows you to collect the quantity of items that the user wants, collect their contact and payment information, and validate that all of the required fields have data entered. This concludes part 1 of the tutorial, in part 2 I’ll cover the server-side processing that is the meat of the payment processing.