# Sunday, 26 February 2012

payment-gateway-flow

At uCommerce we come into regular contact with payment gateways of all shapes and sizes. At the time of writing this post we're up to fifteen separate payment gateway integrations.

With so many integrations under our belt I realized that we inadvertently developed ad-hoc archetypes to describe the various types of gateways.

When dealing with a new payment gateway the archetypes let us quickly determine which type of gateway we're dealing with and what the requirements will be for integration with it.

This is the first in a series of article describing the various archetypes we've found so far.

A Little Background

Print

Back in the day there was just one way of integrating with a payment gateway: Good old direct API call. The premise was simple; call a remote API with credit card details  entered on your website and get a "yay" or "nay" response back from the gateway with some transaction details. Forms were easy to design, integration was straightforward. All was good in the land of online payments.

Along comes the Payment Card Industry Data Security Standard (PCI DSS), a combined effort between VISA, Mastercard, American Express, Discover, JCB aimed at increasing security around online payments. All good, right?

It did in fact manage to increase security, but increased the complexity integrating with payment gateways as well. “But how?”, you might ask.

Online stores would no longer be able to store or even have customers enter credit card information on their websites without a costly certification of the operating environment.

As a result the payment form found a new home away from home: Payment gateways started offering hosted payment forms to overcome the requirement for the PCI certification. Thus the hosted payment forms were born.

What Sets the Gateways Apart

stand-out

The authorization process and more specifically authorization using a hosted payment form is really what sets payment gateways apart today. It turns out that APIs for acquiring, voiding, and refunding are pretty much all based on the same principle: Direct API integration based on tokens issued during authorization.

It seems that payment gateways all came up with their own variation over the  same theme for dealing with hosted payment forms. No standard exists for handling the process although archetypes have emerged over time as we discovered.

Before we dive into the archetypes let's take a look at why the hosted payment form exists and why so many online stores are using it today.

The Hosted Payment Form

Hosted Payment Form

The primary reason for introducing the hosted payment form was, as we discussed previously, to avoid handling credit card information locally on the online store's own servers. The responsibility is handed over to the gateway.

This makes hosted payment forms great for avoiding security issues with credit card information and generally speaking is the way to go for online stores large and small. Depending on the gateway the hosted payment form allows for the same flexibility as the direct integration combined with a local payment form method so it's really a win-win situation.

What's the Downside

some-assembly-required

Integrating a hosted payment form is generally more tricky. There are more concerns in the way payment information such as amount due is transmitted as many of the available solutions require that information to be submitted by the customer herself to the gateway.

Commonly the process works like this: The online store sends payment information to the customer's browsers, which in turn submits that information to the gateway.

When information is passed to the customer and then on to the gateway a huge can of worms concerning tampering with the payment information is opened up. What's to stop the customer from changing the amount to a big fat zero and getting their order for free?

Thus the total sum of required moving parts to make hosted payment work is increased making for a more complex integration model, e.g. redirects between multiple servers, encryption of payment information, and secure processing of payment gateway responses; more commonly known as callbacks.

Outbound vs. Inbound

in-out-arrowsWhen figuring out which archetype a payment gateway we're dealing with we need to consider two aspects: The outbound call and the inbound callback.

It's important to note that when using outbound/inbound we're looking at the process from the point of view of the online store, i.e. the customer is outbound from the store to gateway and vice versa.

The outbound call deals with passing the customer and relevant payment information from the store to the payment gateway.

The inbound call deals with passing the customer back from the payment gateway along with the all important "yay" or "nay" for the status of the transaction.

In Summary

Hosted payment forms offer tangible benefits over direct API integrations when it comes to security and in some cases flexibility like when dealing with additional security features like 3D Secure.

The benefits come at the price of a more complex integration model, which seems to have as many variations as there are payment gateways.

Despite this we decided to make hosted payment forms the default for built-in payment providers in uCommerce to minimize requirements for online stores running our software.

Hence archetypes evolved because we have a very real need for terminology to enable us to easily talk about the gateways.

Comments are closed.