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:


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.

4 thoughts on “A new front-end for e-junkie

  1. Romain

    Yes, thanks for commenting on coupons. Great insight.

    >> 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.

    Just thinking: In that use case wouldn’t it be easier to have the coupon code embedded in the URL? In that case, no need for a coupon field at all, the discount could appear automatically.

  2. Andy Brice Post author

    >Just thinking: In that use case wouldn’t it be easier to have the coupon code embedded in the URL?

    Yes. Ideally the coupon field should be populated from an argument in the URL so the user gets some visual feedback. I haven’t actually tried this yet, but it should hopefully be quite easy to set up in the form.

  3. Robin

    Hey Andy,

    Paul did a great job! We did use to only show coupons in case coupons were setup for whole cart or if the cart contained items and then that had to be changed to work with new discount code changes. We are however working on a fix today to get it like the way it should be.

    As for Google Checkout issue, it’s a great point. We are only going to start showing up for GBP and USD carts for not and later on even make that more specific so that USD carts show Google Checkout only for merchants in US and GBP only for merchants in UK.

    Thanks for helping us improve and also for coming up with a workaround already so there’s no pressure ;)

Comments are closed.