A decade of software production makes me wonder why so many payment gateways are so dreadful to implement. However, a decade of end user testing makes it all too apparent! Understanding how people use your software is incredibly difficult.
Developers are the end users for payment gateways, and I’ve had the chance to be that end user many times. I take no particular credit for this list — these requirements are a result of me having used some absolutely superb payment providers. No names though; this isn’t a review!
For payment providers, this list is a cheat sheet for business and software development. For managers, it’s a guide to spotting the best of what’s available. For developers, it’s a way to vocalise what’s wrong with a gateway that’s not sitting well with you.
- Clear cost structure and automated sign up — Some providers want you to begin a relationship before they give you access and tell you their prices. There are no prices on their website, you contact them, they get back to you, you negotiate. It’s slow, not everybody gets the same deal, and it’s a sign several of the points below also won’t be met.
- Public API docs — what have you got to hide!? A programmer can’t fully evaluate a payment provider if they cannot view their docs. These need to be available without commitment.
- Recurring payment support (if you need it) — This is getting common, but it’s still not universal. Without out it, you need to store payment details on your own servers. That’s a big security consideration you shouldn’t have to deal with. Which brings me to…
- Payment details stored by provider — Going through PCI compliance is an unnecessary expense. Most payment providers store these details, so use one of those.
- Support for all major cards — This is pretty much guaranteed now, but still check. There’s no point settling for just Visa and Mastercard. If those are the only options, there’s going to be someone else out there offering a similar package with more cards provided. Same goes for mobile networks if you’re dealing with payment by SMS.
- Sandbox/debug mode — it makes dev easier. Easy dev is cheap, low risk dev. Do not introduce risk to your payment functionality! Devs and QA should be able to test fully with little cost or consequence.
- Dev payment cards — You begin testing in sandbox mode. You end dev testing with a specific array of test cases. You need cards for every provider, and you need cards which produce every type of error — no funds, expired, various validation fails…
- Few errors states — related to the above, you’ll get through your testing much more quickly if there are as few conditions to test as possible. This largely comes down to different ways a payment can fail. It shouldn’t be any more granular than necessary for functionality. Ten or fifteen unique errors is fine. Twenty-five or more is a hassle.
- Not having to go through a person to complete your testing — This seems obvious, but I’ve had to do it before now! You test a transaction, it involves a confirmation message which goes to the payment provider, you speak to a person to get them to read a code or click a link. It’s slow. Slow is expensive, and likely to introduce mistakes.
- Competitive fees — Take a look at Paypal (or Google. They’re very similar) and Amazon. This is your benchmark. If they charge more than that, what are you getting? If they charge less, what have you lost? Remember to check for hidden fees. There’s no definitive list, but some providers charge extra for failed transactions, transactions from certain locations, transactions from certain people, or have an unusual pricing model which makes particular size transactions unpalatable.
- Customisable payment screens — That’s those which don’t have to show a logo. Or, fully usable through services, so you can make your own screens. Or both.
- Support for callbacks, with customisable end points — Sometimes payments take time. Recurring payments may take a month or more! You can’t always rely on a successful HTTP response code, so the gateway will need to provide callback support if the implementation is to be robust. They would normally be customisable too, so you can easily work within your own conventions.
- Sandbox users — Typically this means sandbox email addresses to log in with. This can be a way to identify a QA technician which needs many of the items on this list, but a specific feature available to these people should be that they can buy things without being charged. In many cases this can be largely covered by your software alone, but it’s better if the payment gateway plays along.
- Sped up subscriptions for debug users — A month ending in five minutes makes testing recurring billing much easier!
- And, sometimes, an existing credit card database — Adding Amazon or Google (or, to a lesser degree, PayPal) can increase payment conversion for people who already have their credit card details stored with them.