Home Shop Visit Cart

Shopping Cart
1 April 2007

PayLogos

We have finally upgraded our checkout system to support credit card transactions.  Now you can purchase your Kona coffee without needing to use PayPal.  This upgrade has always been a high priority for us, unfortunately it took longer to implement than expected.

Having a custom website designed and built by a professional can cost many thousands of dollars depending on the artwork, number of pages and overall complexity of the site.  For far less money there are off-the-shelf solutions suitable for small boutique websites willing to accept a slightly more generic look and feel.  Having a background in network programming, I wasn't happy with any of the canned solutions and didn't want to pay an exorbitant sum for something I felt I could do myself.

Designing the first few pages wasn't too difficult.  I spent a fair amount of time reviewing other websites and "borrowing" any ideas I liked.  Then I started to add to more advanced features like PHP, mySQL and RSS.  Once all that was working it seemed that connecting to a payment gateway shouldn't be that much more difficult.  I was wrong, it is far more difficult.  Here are 10 things I had to deal with along the way:

PayPal


PayPal advertises itself as a "trusted" middleman between the customer and unfamiliar merchants.  The standard PayPal system is easy to implement since all the financial details are handled on PayPal's side.  The first downfall is that customers must be redirected away from the merchant's site to complete their transaction.  The second downfall is that many people have developed a dislike for PayPal.  When trying to sell product, you don't want to use a system that customers hate.

PayPal recently introduced "Website Payments Pro" which allows merchants to process transactions through PayPal without transferring the customer to the PayPal site.  This would be great except that the SDK required to integrate this service is a heaping pile of refuse.  I have years of programming experience and have dealt with cryptic SDK's before but after two weeks of pain I finally decided that being my own boss meant I could make an executive decision and refuse the refuse.  So I ditched PayPal.

Google Checkout


Accepting credit cards isn't free for the merchant.  The setup process is often a couple hundred dollars, there is a monthly fee ($20-30) and every transaction has a base fee (20-30 cents) plus a percentage of the transaction amount (2-3 percent).  This all adds up, especially for smaller companies.  Google recently introduced their new Google Checkout service which competes directly with PayPal.  Most importantly, for all of 2007, all transactions through Google Checkout are completely free!  Free was very tempting but I still wanted a solution that didn't force users to leave my website and Google does not yet offer this.  I know I have lost sales by forcing customers to use PayPal and I was afraid I'd lose even more if I simply switched to Google Checkout instead.

Payment Gateway


Making the decision to write my own shopping cart meant I had to figure out how the whole process works.  Here, in a nutshell, is what goes on behind the scenes:
    1) Over a secure connection, the customer presses the "Checkout" button.
    2) Merchant website sends encrypted payment information to the payment gateway.
    3) Payment gateway contacts merchant's bank.
    4) Merchant's bank contacts customer's bank.
    5) Approved or Declines response is sent back from customer's bank to merchant's bank to payment gateway to merchant website and finally to the customer.  If all goes well, the entire process takes only a few seconds.

So what is a payment gateway?  It is simply a middle-man between the merchants and the banks.  The gateway is independent of the credit card companies, the banks, the website server and the Internet service provider.  The most well known payment gateway is probably Authorize.net although there are plenty of others.  We decided to go with a company that partners with Costco.

SSL


With any financial transaction, security is paramount.  SSL (Secure Socket Layer) is the accepted way to encrypt data so nobody can steal it.  SSL provides identity authentication (makes sure the bank is really the bank and not a hacker) while preventing eavesdropping, tampering and forgery.  You can tell if you are on a secure connection simply by looking at the website address, if it begins with https:// (the 's' stands for SSL) then it is a secure connection.  Most web browsers also display some kind of lock icon.

It costs about $100 per year to purchase an SSL certificate.  Alternatively, many ISP's will allow their clients to use their shared SSL certificate for free.  KonaEarth.com is currently using the shared certificate of our web server host.  Unfortunately this means all of our secure transactions are redirected to the URL "https://s.p5.hostingprod.com/@www.KonaEarth.com" instead of the simpler "https://www.KonaEarth.com".  This may confuse and even scare off some customers but we decided it will probably not be a significant problem.

Cookies


A cookie is nothing but a small bit of data stored on your computer.  Every time you request a web page your browser first checks to see if it has a cookie for that page.  If it does, it sends the cookie along with the page request.  The cookie acts like a nametag, identifying you to the website you are visiting so it can respond with your shopping cart and not the cart of the person sitting next to you.

Every cookie is associated with a web page.  A cookie for KonaEarth.com has nothing to do with a cookie for Google.com.  Unfortunately this also means a cookie for KonaEarth.com will not work for s.p5.hostingprod.com (see SSL above).  When the user switches from the unsecured portion of the website to the secured portion, the cookie is lost.  The solution involves passing the session ID (your name tag) in the URL.  You can see this ID in the URL, it's the '?' followed by a long string of cryptic letters and numbers.  Many other websites use similar solutions.  There are a few additional security steps happening behind the scenes but that session ID is the basis of the solution.

re-POST


When you fill out a form on a web page that data is usually sent using an HTTP POST.  If you fill out a form then try to use the Back or Refresh button, your browser will give you an error message about resending POST data.  This is a common occurrence so it's too bad browsers handle this situation so cryptically.  Even though I know what's going on, Internet Explorer still manages to confuse me when this happens.

As a merchant, I don't want to confuse my customers.  One possible work around for this problem is to issue an HTTP-redirect after the POST data is received.  It's more difficult to code and it generates extra traffic but it prevents that cryptic error message.  The checkout process has a lot of form data and it's important that the transaction goes smoothly.

Validation


Before submitting a credit card transaction it is important to validate the submitted information.  There's no way to know if the information is correct but it is possible to make sure it is at least in the correct format.  For example RFC 2822 and RFC 1035 both discuss valid email address formats, the post office publishes zip codes and the cities they correspond to and credit card numbers are encoded with the Luhn algorithm.

The first few digits of a credit card determine the card issuer (ex: 4=Visa, 5=MasterCard) while the last digit is a checksum computed with the Luhn algorithm.  Using this checksum it is possible to tell if any of the other digits are wrong.  The checksum can't tell if a number is associated with a valid account, only if the user entered a digit or two wrong (ex: entered a 5 instead of 6).  When it comes to validating credit card transactions, every little bit helps.

Chargebacks


Credit card companies only "decline" transactions for insufficient funds or invalid requests.  It is up to the merchant to verify the customer's personal information.  Fraudulent transactions can result in a chargeback and the merchant is held responsible.  Chargebacks can be a huge liability.

The only way for merchants to totally avoid chargebacks is to only accept credit card payments from customers they trust.  This is not realistic.  The next best thing is to gather enough information that you can verify the customer's identity.  The CVS number on the back of the card helps some.  Credit card companies will also verify a customer's billing address.  A phone number and email can help fix problems before they result in a chargeback.  In the end however, there is a lot of faith involved on the merchant's part.

autocomplete=off


When filling out a form, many browsers will try to remember the information so they can fill it out for you next time.  This is usually a nice feature, it gets old having to enter your name and address on every website you come across.  One case where this is not nice is on a shared computer, especially for private data like credit card numbers.

It really should be the user's responsibility to prevent this but in an effort to be a good neighbor, we added the "autocomplete=off" tag to the credit card field.  Autocomplete will still work as normal for all the other fields but it will never try to remember  your credit card number, at least not at KonaEarth.com.  (My friend Derrick earned himself a free bag of Kona coffee for making this suggestion.)

100-Continue


I tested my shopping cart in every way possible before taking it live but there are always last minute bugs.  When we first started accepting credit card transactions customers were often getting denied on the first attempt then accepted on the second attempt.  This problem never occurred with test transactions, only with live transactions.  It turned out to be an unexpected "100-Continue" response from the server.

The details are boring to anybody other than network programmers.  In my defense, I will point out that the HTTP RFC specifies:

An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation

See, it's not my fault.  When complaining about this to a fellow network engineer, he simply said "that's the difference between theory and reality".  After all, the spec does say 'should not' instead of 'will not'.  No matter, once the problem was identified, it was easy to resolve.

Does any of this matter?


It is impossible to tell how many sales were lost because customers didn't want to use PayPal or how many customers will be gained by having a more professional shopping cart.  Was it worth all the effort?  Implementing credit card transactions was not easy but I feel it was worth the effort.  Whether or not my feelings are justified is yet to be seen.




Previous Index Next


Kona coffee HomeShopVisit • Life
RegisterSign InShopping Cart
Site MapContact Us
© Copyright 2005-19 - All rights reserved.