Payment processing hasn't been a major focus of the systems I've developed over the years, but I have had occasion to integrate with a couple of third party services including WorldPay's card payment gateway.

I can't say that experience was particularly enjoyable.

Old school and complex

Payment systems clearly need to be secure, and security requires a certain level of complexity. Also the more options the service provides, the more complex the underlying processes will tend to be. As developers we expect this.

If we're to work with it, though, we need to be able to understand that complexity with as little effort as possible. Good documentation is key.

I've found WorldPay's documentation to be rather poor. There's far too much of it for a start and it's dotted all over their disjointed website in different formats. Sometimes there's a specific PDF you need to find and plough through. At other times the docs take the form of a poorly designed micro-site. Long-winded, inconsistent and producer-centric: it has a very 1990s/early 2000s feel about it.

From a client's perspective things aren't much better. I was unable to find out what the service actually costs from their own site. I had to visit a third-party for a clear indication.

The charging structure itself is complicated. There's a fee for setting up an account, an ongoing monthly service charge, a settlement charge each time they pay over your funds... and that's in addition to the per-transaction fees. For credit card transactions they take a percentage commission plus a fixed fee per transaction.

And before you can start selling, there are approval and activation processes to go through.

GoCardless: a modern "FinTech" company

What a relief then to discover GoCardless not long ago, a UK Direct Debit provider who seem to offer a far simpler, cheaper and more "21st Century" means of accepting payments via your website.

Their pricing structure? If you're processing fewer than 500 transactions a month you'll just pay 1% of the transaction value up to a maxiumum of £2. That's it. Simple for clients/businesses to understand, and extremely competitive to boot.

And you can start taking payments immediately.

I've found them to be highly developer-friendly too with a simply designed site documenting their REST API. The API can be accessed directly or using one of their pre-built libraries for the most popular languages. The source of each is available on GitHub, as indeed are the docs themselves.

They're also very responsive over email should you need additional support. In fact as soon as I'd registered I got a personal message asking if I needed any help as a developer.

GoCardless CFML library

Of course, as a no-longer-popular language, CFML doesn't feature among the official GoCardless clients. I made a half-hearted stab with the Java library, but didn't get far with my weak knowledge of that language, and so set about building my own CFML wrapper for the REST API.

The result is a new community CFML library for GoCardless which is now available on GitHub. It's been tested and used on ColdFusion 9.0.1 (the minimum version required) and the test suite runs successfully on Railo 4.2 (with which I'm just getting my feet wet). It should work with some earlier versions of Railo too.

Not for everyone

GoCardless are a breath of fresh air and I'd encourage developers and businesses to check them out. However there are some shortcomings to consider.

The clue to the first is in the name. They don't support card payments of any description. Direct Debit is what they do. This is exactly what many businesses want of course, especially where the product or service lends itself to automatic recurring payments, such as a subscription. One-off payments are also supported though, as are pre-authorised variable amount debits.

Secondly, their offering is UK/Sterling-only at the moment, although a Europe-wide service is apparently coming soon.

Finally, although nicely designed in other respects, be warned that their checkout process suffers from some apparently unncecessary complexity.