Choosing a Payment Gateway

Next Post

When you have an ecommerce website taking credit-card orders directly online is a must. Shoppers get their purchases confirmed quickly and you get a definite sale. When it comes to card transactions there are of course many protections and compliances you need to adhere to in order to be considered trustworthy enough to carry logos and take those payments including secure storage and transmission. This is why many (even large and midsized stores) opt for 3rd party processing with a recognised name.

Firstly there are no wholly right or wrong answers with choosing a gateway but here are some general tips.

Why go third party?
Firstly storage and transmission of card data must be handled securely so your site will need a secure certificate that is renewed yearly with a registrar. You have to prove your PCI compliance yearly with a series of tests and questionnaire(at your expense) to ensure you know and adhere to legal practices. You have to pay for enhanced security (PCI compliant) servers. Should anything go wrong your customers will blame you and lose confidence in your serivce.

Why not let the 3rd party processor handle all that for you (some still require you to complete a yearly PCI form at your expense) and get the added kudos of having their logo on your site.

Go for merchant name recognition: 
SagePay, WorldPay & PayPal are huge names and people know and trust them, having their names on your site gives customers confidence in your site as they've used them before, maybe even have their own accounts with them, and know that those gateways find you trustworthy.

Many major banks supply online payment systems however it can be more economical to still work with a 3rd party site and transfer money to your bank than to let them be your processor by default.

There are a lot of gimmicky merchants too. Ones that off cash-back, points and incentives for their use but in our experience that is a mask for them being unknown and trying to establish themselves in the face of established and proven merchants.

What makes sense to your business model:
Paypal have something of a cheap n cheerful image by letting you setup and only pay on transactions (ideal for small, new sites when you are testing the waters) however they are massively well known and used. While WorldPay & SagePay are more in the realms of monthly flat rates so you pay them whether you make a sale or not.

All of them have different flavours and types of account so pick the one that works for you whether it be pay monthly and/or per-transaction.

Onsite / Offsite Integration:
When you integrate you can go:

  • Offsite which means after the customer checks-out they temporarily go to the merchant site, make the payment and return to your site for confirmation. This is easy to develop and preferable for smaller sites and lets the merchant site deal with all the security issues.
  • Onsite is a little more tricky as the developer has to embed the payment system into your site so it appears as if the customer never leaves your site while also being equally secure. This entails you purchasing, and yearly renewing, a secure certificate (£40-£50 approx) for your site, all of which takes extra time and money for you and the developer.

Whatever the case the developer will need some details of the gateway. Firstly you should sign up with the merchant of your choice and get a login.

  • Your master login is used to control the payments and money flowing in and out to your bank accounts.
  • You should also setup a developer account for your developer to work on the integration without affecting your security.
  • You should provide your developer with two sets of integration information: the live and development credentials.

Live credentials are used to make live payments with real customers while development credentials are used during development to allow the developer to make lots of payments and interactions to simulate both good and bad payment scenarios without incurring costs.

You can also ask your merchant to allow your developer to speak on your behalf while development is in progress. This typically takes the form of a password the merchant provides you which your developer can use in communications.

You should supply any integration documentation you receive so your developer is up to date on any changes with the gateway since their previous developments.


These typically take the format of a username, password and security key. They are securely hidden within your site so when a payment is desired they are transmitted and authenticated by the merchant to know that you are the person to whom payment should be credited.


That concludes this post but follow-up entries will expand on the topic and we always welcome comments, suggestions and visitor input to help us improve these blogs and give us ideas for future posts.

By Alanna at 11 Aug 2014, 12:52 PM