Knowledge BasePayment Methods and PSP Gateway

Payment Methods and PSP Gateway

Sana Commerce 8.3
Your provider

Introduction

What is a Payment Service Provider?

The most important part of a commerce website is that the customer can order and pay for the products added to his basket. On most e-Commerce sites the customer has an option to pay in multiple ways. In order to support this you could implement each of these payment methods yourself.

The obvious downside of this will cost a lot of effort implement and will be high maintenance. In most cases the store will also have to keep payment information like credit card number. To store this information the site would have to be PCI DSS Compliant; bottom line is that it will cost a lot of money for implementation.

One solution for this is using a Payment Service Provider (PSP for short). A PSP will handle most payments done from a Sana Commerce site; most PSP will also help the store owner with the handling of the payment. This will save a lot of effort, time and money.

There are many PSP's, examples include but are not limited to:

PayPal
Ogone
Docdata
Bibit
Buckaroo

How Can We Add a PSP to Sana Commerce Site?

The details of how a PSP is implemented will differ for each PSP but the general structure is often mostly the same for each PSP. Most PSP's offer two ways to do communicate with them. First is calling the PSP directly from code using things like web services. Second is by redirecting the user to pages on the PSP site. For Sana Commerce stores we always use the second option. This is because for the first option the site still needs to be PCI DSS Compliant, which is not always recommended for each store because of the cost.

The flow between the PSP payment site and a Sana Commerce site can be represented in the following way:

The user starts the payment on the order confirmation page. After preprocessing the user is redirected to the PSP loading page. The external PSP page will be loaded in an iframe here. The user can then finish the payment at the PSP site.

If the payment is completed the user is redirected back to the Sana Commerce site and will receive a success message. The confirmation page will not update the order status. Updating the order status is done by a separate call to the payment confirm page. This page will update the status of the order. It is possible that this page will be called multiple times during the payment process.

Most PSP will have an in-build price limit. In this case it will not be possible to order above a (certain) large amount. Keep this into account when testing the PSP flow

Differences Between PSP's

While the general flow of the PSP's is often the same, there will always be small differences between providers. Some common examples include:

Different payment status and names for payment methods for each PSP;
The way the user is redirected and information is send to the PSP payment page;
The way the confirm page is handled, at which point it is called;
The freedom to change the layout/presentation of the payment page;
Common configuration like the URL of the payment page.

To create a generic framework to build PSP implementation or other payment methods, Sana Commerce contains the 'Sana.Commerce.Payment' library.

This library greatly simplifies the creation of custom PSP implementations and other payment methods. An implementation of a payment method is called a 'payment module' in the Sana Commerce framework. Sometimes a payment module is referred to as a payment gateway.

The following techniques make it easier to create payment modules:

Configuration, payment modules can be adapted by simply changing the configuration;
The existence of base will make it easy to create Custom implementations of payment modules;
The use of pipelines. Pipelines allow payment code to be re-used and injected at different places in the payment process.

Knowledge BasePayment Methods and PSP Gateway

Sitemap

Installation

Product Versions

Links

Sana Commerce does not accept any liability for the content of this website, or for the consequences of any actions taken on the basis of the information provided. The information below should be interpreted as an example. No rights can be derived from this information.

Sana Commerce – the integrated e-Commerce solution for Microsoft Dynamics NAV & AX

Updated: January 2014