After working primarily in Django for the last while I had to do some WordPress work yesterday, implementing SEO improvements to one of our e-commerce client’s web site. I added a function to functions.php and got everything working nicely, but then I went to /wp-admin only to find a blank screen, with no error messages. Neither could I find anything in the server error logs. I could get to /wp-login.php and seemingly log in succesfilly, but then the same thing would happen – I couldn’t get in to the back end, even though the public site was working just fine.

Most of the proposed and unsurprisingly successful fixes I found in blogs and on the WordPress support forums involved re-installing WordPress, but one suggestion stood out: delete any blank lines at the end of your functions.php file. I’m in the habit of adding extra lines at the bottom of a file to give me more space to work in my text editor, so this looked promising. And it worked.

I don’t know why.

I think I’ve unearthed a conspiracy. In the wonderful world of the world-wide web (that’s WWWWW for short), with so much information available, and so many companies selling online, surely there must be a collection of standard procedures for implementing an online shop, and reliable sources of information covering them? Apparently not. How else to explain this except an evil conspiracy? In particular, an evil conspiracy against web designers and developers.

This post is drawn from an e-mail that I sent to a tech savvy client, a small business owner. The email summarized their options for e-commerce, in the specific context of the UK, and it was the result of some hours of research. Reading it over later I realized it could be useful to web developers, given the aforementioned global conspiracy. It is therefore my duty as a good web citizen to reveal this sacred, jealously guarded information – despite the dangers.

NOTE: I’ve called it a starting point, but really this post is just a record of my own starting point, and there’s a bias here towards WordPress.

Introduction

There is one way of selling online that I won’t really go into here, which is selling through your regular PayPal account or with Google Checkout. These are pretty good options, because they’re so easy, but most businesses don’t want customers being directed away to PayPal or Google when they check out. A more integrated solution is preferable because it gives customers confidence in the professionalism of the business; the business can have direct access to its product, order and customer data within a single system; and you – the developer – get more control all round. That’s what this post is really about, but the shopping cart software mentioned here can work nicely with the simpler PayPal set-up as well.

An online shop that accepts credit cards usually needs these four things:

• An Internet Merchant Account (IMA)
• A Payment Gateway
• Some shopping cart software (including product listings, product pages, a cart and a checkout page)
• (in some cases optional) Shop CMS (admin for shipping rates, product management, inventory, order management, etc.)

The shopping cart and CMS can normally be treated as separate and independent. For the payment gateway and IMA, I would normally recommend PayPal’s Website Payments Pro, which bundles these together. But if a substantial portion of your market is in the UK, there’s a problem:

Maestro and 3D Secure

This is where it gets complicated. In fact, it looks to me like the whole thing’s a bit of a mess.

Mastercard enforces the use of 3D secure to process Maestro payments (and this is becoming very common for payments with the other cards too). All Maestro transactions will be declined if this isn’t implemented. 3D Secure is an extra step in the checkout process, which allows real-time authentication with the customer’s bank. It commonly comes in the guise of “Verified by Visa” and “Mastercard SecureCode”. In some implementations it’s optional – the customer can skip it – because not all cards are required to be authenticated like this, but a Maestro payment just won’t complete successfully without a 3D secure authentication.

Before you go down this route it might be worth weighing up the pros and cons of 3D secure:

Pros

• Lets you take Maestro payments
• Can give customers more confidence in buying stuff online (in theory)
• Reduces chargebacks
• It could be that, as people in the UK have become more used to it, they have come to expect it

Cons

• Yet another step in the process of checking out – this is known to lead to a reduction of sales
• Restricts your options for e-commerce software and payment gateways
• From a development point of view, implementing 3D secure can be tricky, depending on the kind of solution you choose

With Website Payments Pro, it’s up to you to set up 3D Secure. Seemingly as an afterthought they recommend using some kind of product from a company called Cardinal, but I’ve no idea what Cardinal actually provide, and their web site is no help. I sent them an enquiry but received nothing in response. This didn’t give me much confidence, so I looked for some other solution, i.e., a payment gateway that had embraced 3D Secure and knew how to implement it.

Turns out there is one that’s popular in the UK: RBS Worldpay. They offer three account options, including one that – like Payments Pro – bundles together the IMA and the gateway. The crucial thing is that WorldPay implements 3D Secure.

RBS WorldPay

At the time of writing I haven’t implemented the gateway, so I can’t say too much about it now. I also won’t say anything about WorldPay’s interesting (in the loosest sense) recent history, but you should check it out because it puts things in perspective.

What I’ve discovered so far is that there are essentially two ways of implementing WorldPay: HTML redirect (or Hosted Payment Pages, which appears to be the newer name) and XML Direct.

HTML Redirect is the easier option. When the user checks out they’re redirected away to the WorldPay site, where all the hard stuff is taken care of. You may be familiar with HTML Redirect from seeing this beautiful interface:

Yes, I know: there’s no way you’re having this ugliness anywhere near your lovely design. But according to the WorldPay site, you can customize this page, in line with your own design. I don’t yet know just how customizable it is: looking at what documentation there is (not an easy task in itself), I’m sceptical how far you can go with it.

I must warn you that browsing the WorldPay site for good information is a painful experience. It has the feel of a collection of documents assembled from disparate sources by a robot with little sympathy for, or understanding of, the requirements of human beings. I suppose this is fairly common with such massive corporate organizations, but it’s a real shock when you’ve been used to dealing with small, focused companies with a dedication to openness on the web.

It took a couple of messages to WorldPay technical support to find out that there was another way: XML Direct. This allows a more complete integration with your site, because all the processing is done in the background, rather than with a redirection. The implications are that you’ll need to make damn sure you’ve got a secure system. RBS have a process for assessing your set-up, and further procedures for testing and activation.

For an alternative to RBS WorldPay that also supports 3D secure, check out SagePay

PCI Compliance

Aside from any particular requirements of your gateway, generally a secure setup is one that is PCI compliant.

With HTML Redirect and the hosted solutions (option 1 below), you don’t need to be PCI Compliant at all, because you’re not actually storing credit card numbers on file or in a database. It’s your payment gateway (eg. WorldPay or Website Payments Pro) or shopping cart service that has to be PCI compliant. However, your gateway may still require you to pass some level of security-checking.

With XML Direct, you do need to pass some PCI Compliance tests, and that’s a whole other can of worms I’m not going to open right now, because I’m still not sure exactly what’s inside. Worms, yes, but what kind? And do they bite?

SSL/HTTPS/Encryption

You might not be storing credit card numbers, but you may need to transmit them securely, in which case you will need to buy an SSL certificate and have it installed on your web server. Basically, if your checkout page resides on your web server, as part of the site, you will need SSL. But if it’s hosted, as it is with WorldPay HTML Redirect or one of the complete hosted shopping cart solutions (option 1 below), you’re not transmitting anything sensitive so SSL is not required.

Software Option 1: Hosted

Examples: Ecwid, Foxycart, Shopify

With hosted e-commerce, you sign up to a service that provides a cart and checkout process, all hosted on their servers. General shop settings – shipping, taxes, coupons and product types – are all administered on their site.

The big advantage is that they they’re the ones who need to have the SSL encryption and security, and they wrap up the whole checkout process very nicely, so there’s not much in that area you have to worry about.

I’ve set up a shop with FoxyCart and MODx, and while there’s a lot of work to be done if you need product management built into your CMS, setting up the customized cart and checkout pages is a breeze.

• They handle SSL and PCI compliance
• No 3D secure/Maestro (because they’re responsible for implementing it and Ecwid, Foxycart and Shopify haven’t done so yet, although they’re working on it)
• Your data is on their servers
• Separate place to manage shop (ie. separate from the rest of the website)

Ecwid (Free)

• Very fast, very easy, and very tempting
• But no API and not very configurable
• Depends on JavaScript

Foxycart ($19/month)

• Very configurable
• Total control over the design of the hosted pages
• API and XML feed to get data from their servers to yours (allowing you to integrate this data with your database and CMS)
• Cart depends on JavaScript

Shopify (From $29 to $699/month)
Look at that price-range. That indicates a pretty mature kind of product, and I get the feeling this might be one of the best hosted solutions out there, but I don’t know much about it. But it’s built with Ruby on Rails so it must be super cool, right?

Software Option 2. Self-hosted / Integrated

Examples: WordPress plugins WP e-commerce and Shopp

I recently split off a WordPress site into two development branches, one with Wp e-commerce and the other with Shopp. I’m very impressed with this type of software solution. I don’t see any reason why you couldn’t implement any size of shop, and there’s loads of CMS features covering just about everything. I went with Shopp in the end, but they’re pretty similar in functionality.

• You have their software installed on your server (ie. the server I’m hosting the site on)
• You keep all the data on your server
• You don’t have to log in to another site to manage your shop
• Shop CMS for product, order and customer management etc., integrated into your site CMS
• Configurable
• Often requires an SSL certificate
• Could require PCI Compliance, depending on how you implement it
• Maestro support is possible (if using RBS WorldPay or something similar like SagePay)
• But no WorldPay gateway option out-of-the-box

WP e-commerce (free, or $195 for the business gold cart)

• Open source
• Configurable, customizable
• Ability to create a custom gateway integration
• The free version withholds some functionality that in most cases is a necessity, such as multiple images per product. You could probably code this in yourself if you wanted to avoid the cost.

Shopp (One-off $55)

• Open source
• Configurable, customizable
• Ability to create a custom gateway integration

Software Option 3: Self-hosted Standalone CMS

Example: Magento

• You have their software installed on your server, alongside your web site CMS
• All-in-one shopping cart, product and order management package
• You keep the data on your server
• Open source
• Separate dedicated CMS for your shop (not integrated into your site CMS)
• Tonnes of features
• Potentially difficult to configure and integrate
• Requires an SSL certificate
• Could require PCI Compliance, depending on how you implement it
• Maestro support possible (if using RBS WorldPay or SagePay)
• But no WorldPay gateway option out-of-the-box

Something like Magento should be seriously considered. It’s very featureful, and I hear they recently implemented 3D secure. However, setting up and configuration could be time-consuming, and systems like these can be pretty bloated, slow and clunky.

Conclusion

If you need to take Maestro payments – and there are still a lot of those cards around – you can’t really go with option 1. The other options all have built-in support for several gateways, but unfortunately not WorldPay. This means some unavoidable work on your part to hook things up. Whether you go with option 2 or 3 depends solely on the needs of the client and your own development decisions.

In the forthcoming weeks I’ll be implementing the gateway – perhaps developing a WorldPay module for Shopp in the process – so I’ll be posting about that. If the Guardians of the Sacred Secrets of E-commerce haven’t tracked me down, that is.