OmniPay Authorize.Net DPM Gateway

In this short series I hope to provide some practical worked examples showing how to use the DPM extension of the OmniPay Authorize.Net gateway. I’ll run through what all those terms mean first.

Authorize.Net

Authorize.Net is a payment processor that can be used to take payments on websites. It does a lot more than simply take payments, such as scheduled payments and refunds, but we are just looking at payments here.

There are a few broad modes in which Authorize.Net can be used. They are:

• AIM – Advanced Integration Method. This is a machine-to-machine API. Your site collects all the details from the user (where needed), including credit card details and sends it on to the AIM interface. It gets a response, then processes that response as appropriate. This mode provides access to most of the facilities within Authorize.Net. It does, however, have strict PCI ramifications. Because the end user’s credit card details pass through your server, there are very strict rules and accreditation that must be followed and applied for. Most small shops and businesses would want to avoid this on their own websites.
• SIM – Server Integration Method. With this method you send the end user off to the Authorize.Net website to enter their credit card details. Your site never sees these details. You can send what contact details you already know about the user along to the SIM interface with the user, so they don’t have to fill out their details afresh. Some people don’t like this, because the branding on the SIM payment screen belongs to Authorize.Net Personally I don’t find going to a trusted payment gateway site to fill out my credit card details is a problem at all, but apparently many people perceive it to be a bad thing. PCI compliance is still relevant, but it is not as onerous as for AIM. Credit card details do not go through your site, but if your site has been hacked, then all bets are off – you really don’t know what is being captured when malware is installed.
• DPM – Direct Post Method. This method works in a very similar way to SIM, but with the payment form on your own site instead of a an Authorize.Net site. This payment form can be branded entirely to your liking. The form is not posted back to your site, but instead posts to the the Authorize.Net DPM site. The DPM site then posts back to your site the result of the credit card authorisation, and your site handles that and informs the end user. If there are mistakes in the form that the user submitted, then Authorize.Net DPM will inform your site, pass it the current submitted form details and give your site the opportunity to re-present the form to the user so they can make corrections.

SIM is by far the easiest to implement, and is much safer for you than AIM. DPM is very similar to SIM, but requires more to be implemented on your site. The benefit of that is that you have full control of the style and branding across all the payment pages.

This article will focus on the DPM method of using Authorize.Net, as it is a fairly recent additional to OmniPay – the PHP library that attempts to normalise a multitude of different payment gateways. The Authorize.Net gateway, containing support for AIM, SIM and DPM, can be found here. There are at present few examples of how the DPM gateway can be used through OmniPay.

OmniPay

The OmniPay package from The PHP League, originally developed by Adrian Macneil, is a pluggable library that provides access to a wide range of payment gateways. It focuses on common requirements: authorisation, capturing payments, voiding authorisation, and a few other services. It’s aim is to provide a common and consistent way to handle the different payment gateways, so it is simple easier to switch between them.

OmniPay is a composer package, and support for each gateway is provided through a separate composer package.

OmniPay largely meets its objectives, but suffers a little from a lack of worked examples in the documentation. Even though the library aims to make the gateway use consistent, each gateway does tend to have its own foibles – they all do something that requires some special handling in the merchant application, and that requires additional plumbing around the gateway.

We are dealing here with version 2 of the OmniPay library. My hope is that version 3 (proposed for later in 2015) will look a little deeper into these exceptions to find some patterns that perhaps have not been recognised previously, and they could be handled within OmniPay to reduce the amount of exceptional plumbing required in the application.

Authorize.Net DPM

The Direct Post Method (DPM) was likely introduced in response to the rapid rise and popularity of Stripe. This gateway popularised the method of POSTing card and address details direct from the merchant site – the shop taking payment – to the payment gateway. This means the users stay on the merchant site when completing their credit car details, but the details are never posted back to your site.

While Stripe and some similar gateways use JavaScript to POST the form details to the gateway, making them AJAX, and never taking the user away from the site, Authorize.Net DPM is different. It works like this:

1. The merchant site presents a payment form to the user, including fields for the payee name, address and credit card details. Any number of details can be pre-filled, and the merchant site can decide which fields are shown, which can be changed, and which are hidden.
2. The payment form is completed by the user. When the user submits the form, it POSTs direct to Authorize.Net not the merchant site.
3. The user is handed over to Authorize.Net, but they don’t hang around for long. The supplied credit card details are checked and a decision is made on whether the payment or authorisation is approved.
4. Authorize.Net will perform a callback. It will directly POST the results of the authorisation to the merchant site. The POST will include the status, any errors, and the details of the form as submitted (minus the credit card details – the idea is never to send them to the merchant site).
5. The merchant site validates, stores and processes those results in the callback.
6. The merchant site callback handler then generates a HTML page, usually based on the results, and returns it to Authorize.Net. That page will then be sent by Authorize.Net to the user’s browser. The main purpose of that page will be to redirect the user back to the merchant site. So while most payment gateways will expect the callback to return a URL, which the gateway will send the user to, this gateway asks for a HTML page containing a meta refresh and/or a JavaScript redirect to send the user to the correct page of the merchant site.
7. When the user returns to the merchant site, they are informed of the result. If the result is an error, then the merchant site can re-present the user with the form they completed and display the error message, so the user can try again. If the payment was declined, then they are told so.

All processing of the transaction should hopefully have happened in the callback, and not left for when the user returns to the merchant site, because sometimes the user may not have made it back for one reason or another. Many Authorize.Net gateways do not do that – they send the user to a “success” or “fail” page, where the transaction is processed or not from there. Don’t fall into that trap, because it is not secure.

The next part in this series will introduce the sequence chart that an implementation needs to follow.