Tag Archives: payment

A new front-end for e-junkie

e-junkieI am been very happy using e-junkie as my payment processor for the last 4 years. I pay them a few dollars per month as a flat-fee and they provide an interface to PayPal, GoogleCheckout and 2Checkout (and others) plus additional features such as sending licence keys and handling coupon codes. It isn’t a fully fledged a registration service like Avangate, FastSpring or Plimus, but it has been adequate for my needs, has responsive customer support and is very cheap. In theory I could have written a load of scripts to do what e-junkie does, but re-inventing that wheel would be a lousy use of my valuable time.

I had been using e-junkie ‘Buy now’ buttons, but things were starting to get complicated with the branching of my single PerfectTablePlan product into three products: PerfectTablePlan Home Edition, PerfectTablePlan Advanced Edition and PerfectTablePlan Professional Edition.  3 products, each with and without a CD and available in 3 currencies is 18 purchase options, not including the choice of PayPal, GoogleCheckout and 2Checkout as processor. I also had additional options for upgrading version (e.g. v3->v4) and upgrading edition (e.g. Home->Professional). Doing all this through ‘buy now’ buttons was clearly going to be a mess.

I looked at the e-junkie shopping cart, but it had a number of shortcomings I couldn’t live with, most notably:

  • It always shows a coupon field. I don’t use coupons very often. A coupon field says to a customer without a coupon “Someone else getting this cheaper than you – sucker!”. There is a good chance that they will hit the back button and start searching for a coupon (I have done it myself). Maybe they will never come back. I only want the coupon field to appear if I give the user a particular URL, and I will only give that URL to customers who have coupon codes.
  • It always shows the ‘Buy with GoogleCheckout’ button – even if GoogleCheckout don’t do transactions in that currency. So a customer buying in US Dollars can click the ‘Buy with GoogleCheckout’ button, only to be told they can’t buy in dollars through GoogleCheckout. That is a very poor customer experience.

I investigated e-junkie ‘variants’, but these weren’t an adequate solution either. I was loathe to pay more for my payment processing. So I asked my good friend Paul Kossowski, an experienced Javascript programmer, to write me a payment form front-end to e-junkie. My basic requirements were:

  1. Handle multiple products, options and currencies.
  2. Show a running total depending on the product, number and options selected.
  3. Default to a sensible currency, based on the customer’s location from the free maxmind.com geolocation service.
  4. Mustn’t hang if the geolocation service is down.
  5. Make it easy to change prices and product descriptions.
  6. Make it easy to configure options, currencies etc (e.g. GoogleCheckout only allows me to charge in pounds sterling).
  7. Make it easy to change the ‘look and feel’ of the form.
  8. Only show a coupon field if passed an appropriate argument in the URL.
  9. Allow me access to the Javascript source so I can make it call the appropriate e-junkie URL, pass cookies and make other tweaks.

I am very pleased with the results. Here is a screenshot (click to enlarge):

payment form

click to enlarge

You can play with test versions that link through to PayPal, GoogleCheckout and 2Checkout via e-junkie by clicking on the links below (I prefer you didn’t play with my live payment pages, thanks):

Note that some links are broken on these test pages, but the link to the ecommerce providers are live. So don’t type in your credit card number, unless you are feeling generous.

The HTML on these pages includes some simple Javascript that sets up some arrays with the various products, prices, currencies etc. This then calls a separate (obfuscated) .js file which does the real work. An example of the set-up code is shown below:

form_javascript_example

click to enlarge

The look and feel of the form is controlled by a .css file. The resulting form looks fairly trivial on the page, but the .js file actually runs to several hundred lines of Javascript and took a few days for Paul to write and test, partly because of all the configuration options.

I think Paul’s form + e-junkie makes for a very professional looking and flexible payment solution at a very low cost. If you are interested in having Paul customize the Javascript for use on your site you can email him at: paul (at) dolphinfutures (dot) com . Expect to pay for a day or more of his time at UK rates, depending on your requirements.

Does 2Checkout have the ugliest payment page?

Over on the BOS forum Rensy commented on how ugly the 2Checkout payment page is. They appear to have beaten it with an ugly stick in a recent ‘makeover’. Below is the Perfect Table Plan 2Checkout payment page, click on the image to see it in it’s full glory:

2Checkout page 1

When (if) you finally work out where to click you are confronted with another equally ugly page:

2Checkout page 2

Presumably the icons down the left side are supposed to reassure me that the site is trustworthy. But all they do is distract and confuse me. When you emphasize everything, you emphasize nothing. The overlapping boxes, the choice of fonts and white space also look amateurish.

The PayPal and GoogleCheckout pages are models of taste and minimalism by comparison (apart from the huge and inexplicable white space at the bottom of the GoogleCheckout page):

PayPal

PayPal

GoogleCheckout

PayPal and GoogleCheckout also use a single page where 2Checkout uses two. This means one less click for your customer and, critically, one less chance to change their mind. I’m glad I only use 2Checkout as a back-up for customers who don’t want to use PayPal.

Does 2Checkout have the ugliest payment pages? Please add a comment below if you have seen worse (ideally with a link to a screenshot).