Which payment integration is right for me?

Dan

Dan
Writes on 19th July 2016

PayPal, SagePay, WorldPay, Stripe, EPDQ, etc... all fundamentally offer the same thing, a means for your customers to pay you for your products and/or services.

Most of the time you'll only ever have one payment provider running on your site, but we've had clients in the past that have implemented multiple systems for redundancy or to provide their customers with alternative options. They each have various integration types and I've listed these below to provide you with a good understanding of which may be right for you.

1. Form

This system is fairly common amongst payment gateways. It offers reasonable security to your users but isn't particularly flexible and can (in some instances) be manipulated by your end users if they have some basic HTML knowledge. This process literally POSTs information regarding the order/payment to your payment provider through a HTML form and directs your user to a page on your payment providers system where they enter their payment details. Upon completion the customer may or may not be pushed back to your site, where the order will be completed.

Pros

  • Generally quick and easy to implement on any site
  • Security of the payment process is not a concern of yours
  • Your site/system never actually handles or "sees" any of the end users sensitive payment details.
  • Requires the basic level of PCI compliance – self assessed

Cons

  • Very little flexibility
  • Can be exploited with a little knowledge of HTML
  • Generally information is not provided back to your system
  • Customer is redirected for payment outside of your site

2. Server

Similar to Form integration, this approach works by sending information about the required transaction to the payment provider. They essentially set up a payment instance and return a unique URL which you display to your customer. These requests are generally sent either Server-Side (by the code underlying your site) or through a simple client-side request (usually a POST). In some instances you'll send your customer to the URL you have been provided or you'll display the URL in an iframe. The iframe approach allows you to maintain the appearance that the payment is being taken directly on your site.

Pros

  • Still relatively simple to integrate though may require more server-side work than form integration
  • Security of the actual payment process is not a concern
  • Your site/system never actually handles or "sees" any of the end users sensitive payment details
  • Often provides some flexibility
  • Can send transactional information back to your site after integration
  • Requires the basic level of PCI compliance – self assessed

Cons

  • There are still limitations to the flexibility to the system, some styles cannot be changed.
  • If an iframe type integration is not available the customer "is not kept on your site" for payment.

3. Direct

Most if not all of the payment gateways we've had experience with offer some way for you to completely customise the payment process. Direct integration allows you to completely control how you ask your users for their credentials, providing complete flexibility. Usually the payment provider offers an API for this system.

Pros

  • You have complete flexibility of what the payment process looks like, what information you collect and how your users actually interact with it.
  • Can integrate flawlessly with your website design
  • You have access to ALL payment and transactional information

Cons

  • You are responsible for the security throughout the entire payment process
  • You actually handle and transmit payment details, even if you don't save those details you are required to be PCI compliant at a high level.
  • Security requirements of your entire site are greater.
  • Can be costly to implement properly.

4. Recommendations

Webnetism strongly advise the use of a Server type system and usually suggest avoiding direct integrations. This avoids you having to get any high level of PCI compliance and means that your payment provider are responsible for the safety of your user's payment details through the payment process. With integrations that offer an iframe system we can generally produce a payment page that integrates seamlessly with the rest of your site, giving the appearance that the customer remains on your site through the entirety of their order. It's very secure and offers enough flexibility to give your customers a pleasant user experience through the order process.

5. PCI Compliance

PCI DSS is a security standard for how a company must handle payment details, specifically credit and debit cards. The Payment Card Industry Data Security Standard (PCI DSS) describes various different levels of security and verification that must be achieved in order to handle and/or store card details. These requirements may include a variety of physical and non-physical security ranging from hardware related requirements such as firewall use to physically restricting access to the room where the server storing details is located. Being able to offload these requirements to another party like your payment system can be a huge benefit when taking payment details online as PCI compliance is not particularly easy or cheap to achieve at the often required higher levels.

The contents in this article describe our experience integrating payment systems and does not necessarily consider your individual circumstances and requirements.

Join the conversation

      

0 comments

Let's contribute!

How about you help us a little and share this page with your friends? It’s just a click, we promise!

Want to get in touch?

Then why don't you? Just click the button bellow and secure your place in our office chair (before you ask... yes, spinning is allowed)!

Get in touch