Shopping Cart
1 April 2007
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.
|
