# Tuesday, 06 March 2012

In this series of articles we discuss the various methods of integrating with payment gateways; in particular how various payment gateways handle integration with hosted payment forms.

In this article we take a closer look at the most commonly employed integration method for payment gateways. Gateways like Authorize.Net, PayPal, WorldPay, Ing Bank (iDEAL), Payer, DIBS, and ePay all use this method for initiating payment using a hosted payment form.

If you’re interested in more background before proceeded please take a look at Intro to Payment Gateway Archetypes.

What Makes An "Outbound User Post"


The "Outbound User Post" is the most common archetype we've come across; indeed this is the model we originally designed our payment gateway integration framework to support.

The premise is the HTTP post with a twist: The gateway expects an HTML form to be generated on the store end, which in turn issues a HTTP post to the payment gateway accomplishing two goals in one go:

  1. Payment details such as currency, amount, etc. are sent to the gateway
  2. Customer is redirected to the payment gateway's hosted payment form

The upshot  is that it's pretty simple to work with as it relies solely on HTTP; as such it can readily be integrated using pretty much any technology. All you need to do is get the target URL for the post and the predefined form values right and you're good to go.

More Is Less


As it turns out combining the submission of information and the redirect as the sole integration point requires the form to be sent to the customer's browser and submitted from there by the customer herself.

The general purpose payment framework generally has two options for handling this type of integration:

A) Displayed Form, which displays actual information such as the final order confirmation to the customer, or

B) Transparent Form carrying only the required payment information without displaying any details to the customer, which is auto posted to the gateway.

Next up we’ll take a closer look the two options for handling integration.

Displayed Form


The displayed form is essentially embedded on a page displayed to the customer; generally speaking the last page displayed before handing over control to the payment gateway. The form contains predetermined values for amount, currency, and all the other required information to get the payment process going.

The issue obviously becomes one of dealing with ensuring that all the required values are present and named according to the specification and to avoid having to redo the same form over and over again.

In a scenario where a designer or developer control what is displayed to the customer this approach can become quite tricky to handle, i.e. the classic e-commerce "confirm order and proceed to payment" page.

Generally speaking getting this right is a huge part of getting the integration working. As it turns out this is cumbersome at best and downright daunting at worst unless you do this sort of integration work on regular intervals.

Building the form from scratch seems to be what the payment gateways requiring the "Outbound User Post" integration model had in mind when they designed it.

Transparent Form


The second option is an auto generated transparent form, which has no other purpose than to carry the payment information required by the payment gateway. It will never be displayed to the customer, but rather transparently be submitted to the payment gateway.

To achieve a transparent redirect JavaScript is required to auto submit the form on behalf of the customer. Most sites out there today require JavaScript to even function properly, which makes it a reasonable assumption to build a framework on.

The upside is very tight control over the payment information sent to the payment gateway and essentially allows a general purpose payment framework deal with the payment without concern for the actual store pages; as such it comes pretty close to being a "real" web service.

In turn designers and developers have an easier time building the store frontend as payment is handled almost as a pure web service although the intermediate form is still there albeit transparently so.

In Summary

The "Outbound User Post" archetype seems archaic in the assumptions made for the integration model. It's simple, yes, but either requires developers integrating using it to completely redo the integration form for each online store or introduce intermediate forms to achieve a transparent integration model.

The uCommerce e-cpmmerce platform handles the outbound user post via a standard transparent form, which is injected into the checkout flow, sent to the customer, and submitted transparently, seamlessly handing over control of the checkout flow to the payment gateway.

The observant customer will notice an intermediate page displayed for a fraction of a second before being handed over to the page gateway.

Surely there must be a better way. It is so happens there is. Read on a discover "Outbound Placeholder".

Comments are closed.