How to choose an online payments provider
We have recently been around the houses with our experiences with online payment solutions recently and thought we’d share some of our heartache so you don’t have to go through the same things.
Reputation Monitor is an online service we provide that is paid for monthly by credit card. When we were building it, we went through a few options trying to decide who we should use to help us take and process those payments and ended up settling on Barclays’ ePDQ system. We bank with Barclays and have had a fantastic experience with them generally (our local business manager is very good - if you’re in London and bank with anyone else, or don’t know the name of your bank manager, let me know and I’ll put you in touch).
The reasons for going with Barclays, beyond already banking with them, were that they claimed they could handle all of our requirements, including:
- accepting payments in more than one currency (we wanted to offer GBP and USD)
- setting up and managing recurring monthly payments
The first chink in the armour came when we tried to download a spreadsheet of payments received. We wanted this in order to:
- reconcile our accounting software
- automatically mark accounts as paid when users’ recurring payments went through (we’d already resigned ourselves to the fact that they wouldn’t update us electronically via an API when each month’s payment was received)
It never crossed my mind that an online payments provider wouldn’t offer this service, yet apparently it is only available on their packages for bigger businesses. All they could offer us was a monthly paper statement (not particularly good for either purpose, especially as it only told us amounts received, not who they came from) and an online area where we could log in and create online reports. Without scraping these reports, we couldn’t come up with any good way of getting our payments in electronic form.
It turned out that they weren’t very good at meeting our direct requirements either. Our first USD transaction failed. When we called support to find out why, we were told that our USD ’store’ wasn’t set up. This was a bit strange as (a) it was part of our core requirements and (b) why should we need a whole other store? Surely all it needed was to allow USD payments?
Noooo. Apparently we had to integrate with an entirely new store to accept the USD payments. We started going down this route, but as more and more hurdles were put in our way, we ended up re-thinking and re-visiting our options.
Should you use Google Checkout for accepting credit cards online?
One of the first options we went back to was Google Checkout - we have used it successfully for accepting payments for our recent seminar as well as for a number of clients and other projects so we knew it worked well. We were also pretty confident it would handle multi-currency requirements smoothly - Google’s usually pretty good on the international aspect of its services. Finally, it had an additional benefit over Paypal that the money is deposited into your bank account quickly and automatically without requiring you to login and transfer to your bank.
The hurdle that prevented us being able to offer our users this option was that Google checkout does not allow you to set up recurring payments! This was a pretty big flaw in that plan and led us to reject checkout (reluctantly).
It appears that Paypal is the best provider for accepting recurring payments
We have used Paypal for a few things in the past - both for clients and internal projects. We had felt that it could appear slightly less professional than some of the other solutions (especially for business to business transactions) but they have greatly improved their service recently and, in particular, they are the only provider I have found that offers:
- recurring payment handling and management
- sensible multi-currency support
- statement download in many formats
- automatic notification to our software of successful recurring payments
- automatic notification of cancellation of a subscription
Given that it is also free to set up and charge a comparable percentage of credit card transactions to the big merchant account providers, it seems to be far and away the best solution at the moment.
If you have enjoyed this post you can subscribe to the rss feed to read more about how you can monitor and protect your brand online








Comment link
Duncan Morris on Fri (13 Jul) @ 4:29 pm
Just to put a further nail in the Barclay’s epdq coffin the process you go through to test the account is quite frankly the most ridiculous process I have ever heard of.
Unless I have got the wrong end of a massive stick, they don’t have a test or sandbox area (unlike Google Checkout or Paypal). So you have to ‘test’ your application in live.
I couldn’t believe it when I read the documentation.. Here is my favourite snippet
“We do not recommend you attempt this” - You don’t recommend we test our applications… Am I the target of a very elaborate joke. Barclaycard, that is the biggest load of balls I have ever read.
Comment link
Will Critchlow on Fri (13 Jul) @ 4:30 pm
Wait, we test stuff?
Comment link
Will Critchlow on Fri (13 Jul) @ 4:31 pm
Seriously though. How can they expect you to test by putting through a transaction for a defined amount? What about if your product has a price already? How do you test that? Clowns.
Comment link
Bill Hilton on Sun (15 Jul) @ 11:39 pm
I have to be a touch careful here, because Barclays (or, at least, BarCap) is a client of mine. Lovely, lovely people, all of them - good-looking, charming, brilliant, etc. etc.
[rant]
However, it always beats the hell out of me why people bother using merchant accounts at all. OK, PayPal may (in some instances) cost more and may rely on customers clicking through to another domain to make the payment, but it’s ultra-reliable and the payment can land in your bank within a week of arriving in your PayPal account - as against a 60-day delay with some merchant accounts. I’ve been taking credit card payment from clients for ages by using a simple shopping cart or invoice email.
[/rant]