North East Blog Directory

May 13, 2015

Jason Judge

OmniPay Authorize.Net DPM Gateway

Note: this article is a work-in-progress. I’ll be updating it between refreshing the whole site and doing a tonne of other tasks. If you have any questions, just fire them at me and I’ll aim to answer in this article, along with worked examples.

In this article 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 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:

  • AIMAdvanced 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.
  • SIMServer 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.
  • DPMDirect 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.


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.

To be continued over the next few weeks.

The post OmniPay Authorize.Net DPM Gateway appeared first on Academe Computing.

by Jason Judge at May 13, 2015 10:02 AM

May 12, 2015


Britse Lagerhuisverkiezingen 2015

Sinds ik in Engeland woon heb ik de politiek matig gevolgd. Zowel de politiek in Nederland als die in het Verenigd Koninkrijk. Aangezien ik van de Nederlandse politiek weinig mee krijg en het stemmen vanuit het buitenland nogal een gedoe is, heb ik stemmen met de Tweede Kamerverkiezingen sinds de laatste keer opgegeven. Hier in het Verenigd Koninkrijk mag ik niet stemmen in het equivalent, de verkiezingen voor het Lagerhuis, omdat ik niet Brits ben.

Om hier te mogen stemmen zou ik me tot Brit moeten laten naturaliseren, met de kans dat ik dan mijn Nederlandse paspoort kwijt raak, en met op dit moment als enige voordeel dat ik mijn stem mag uitbrengen in deze verkiezing.

Dit zou me meer dan £1000 kosten en dat is het dankzij het gebruikte kiesstelsel niet waard. Stemmen is belangrijk en ik ben altijd van mening geweest dat als je niet stemt, dat je dan niet mag klagen. En stemmen vind ik nog steeds belangrijk, maar het blijkt in het Verenigd Koninkrijk niet altijd veel uit te maken. Het kiessysteem werkt hier heel anders dan in Nederland en er valt veel over te klagen.

Gedurende de jaren dat ik het kiesstelsel hier in actie heb gezien heb ik het altijd al vreemd gevonden, maar het is pas tijdens de verkiezingen van mei 2015 dat ik echt opgelet heb en zie dat het systeem knotsgek is.

Hoe het werkt

De verkiezingen voor het Lagerhuis in het Verenigd Koninkrijk worden gevoerd middels een districtenstelsel in combinatie met een meerderheidsstelsel. Er zijn 650 zetels in het Lagerhuis en het land is opgedeeld in 650 kiesdistricten. Een zetel hoort bij een kiesdistrict. Stemmers die in een kiesdistrict geregistreerd zijn kunnen alleen stemmen op kandidaten voor dat kiesdistrict. In ieder kiesdistrict is maximaal 1 kandidaat per partij, maar lang niet alle partijen hebben kandidaten in alle kiesdistricten.

Voor de verkiezingen van mei 2015 waren er meer dan 60 partijen, maar in het kiesdistrict waar ik woon waren er maar kandidaten van 6 van die partijen.

Veel districten worden gezien als "safe seats" wat betekent dat het onwaarschijnlijk is dat de zetel naar een andere partij gaat. Dit komt er op neer dat als je in zo'n district stemt, dat je stem eigenlijk nutteloos is. De winnaar van die zetel had ook gewonnen als je niet op hem/haar had gestemd, en de verliezer had ook verloren als je wel op hem/haar had gestemd (aannemende dat genoeg andere mensen nog wel stemmen).

Ik heb schattingen gezien dat van de 46 miljoen kiezers, de stemmen van slechts 100 duizend kiezers er toe doen.

Om een zetel te winnen hoef je alleen meer stemmen te krijgen dan de andere kandidaten. Als er bijvoorbeeld 1000 kiezers zijn en 5 kandidaten en 4 van die kandidaten krijgen 199 stemmen en 1 krijgt er 204 dan wint die laatste de zetel.

Op deze manier is het mogelijk om een meerderheid van de zetels in handen te krijgen met ruim minder dan de meerderheid van alle stemmen.

En dat is precies wat er nu is gebeurd. De Conservatives (Tories) hebben een "overgrote meerderheid" van 331 van de 650 zetels gewonnen met minder dan 37% van de stemmen. Dit verdient het om het nog een keer anders te zeggen: ze hebben 51% van de zetels gekregen voor 37% van de stemmen.

De resultaten

De resultaten van de verkiezingen zijn met veel detail beschikbaar, maar ik wil er een paar uitlichten om mijn punt duidelijker te maken.

table tr td { text-align: right; padding-left: 10px; } table tr td.text { text-align: left; background-color: #ccc; padding-right: 10px; } table thead { background-color: #ccc; }

Zetels 2015Verschil met 2010Aantal stemmenStemmen percentageVerschil met 2010
Green Party101.157.6133,8%+2,8

Om een overgrote meerderheid te behalen zijn minstens 326 zetels nodig. Dat is meer dan de helft van het Lagerhuis. De Conservatives hebben dat bereikt met slechts 36.9% van de stemmen.

Verder zijn er nog meer zetelverdelingen die duidelijk niet alleen op het aantal stemmen gebaseerd zijn:

  • SNP heeft minder stemmen dan de Liberal Democrats, maar 7 keer zoveel zetels;
  • Het verschil in aantal stemmen voor de SNP en de Green Party is niet erg groot, maar het verschil in de zetels wel - SNP heeft er 56 keer meer;
  • SNP en Liberal Democrats hebben samen minder stemmen dan UKIP, maar veel meer zetels;
  • UKIP en Green Party hebben evenveel zetels, maar UKIP kreeg ruim drie keer zoveel stemmen;
  • En nog duidelijker: Liberal Democrats en DUP hebben ook evenveel zetels, maar de Liberal Democrats hebben ruim 13 keer zoveel stemmen gekregen;
  • Tevens heeft Labour deze keer een groter percentage van de stemmen gekregen, maar minder zetels!

De stemmen voor de Green Party, UKIP en de Liberal Democrats zijn verspreid over het hele land, terwijl de stemmen voor de SNP en DUP in een beperkt geografisch gebied plaats vinden. Een partij heeft meer kans op een zetel als de stemmen geografisch dicht bij elkaar zijn.

Er gaan geruchten dat de Conservatives waarschijnlijk het aantal zetels naar beneden willen bijstellen door zetels van andere partijen samen te voegen, zodat ze er voor de volgende verkiezingen beter voor staan. Dit klinkt als een valse methode om aan de macht te blijven, en dat het een probleem met dit kiesstelsel is, blijkt wel uit het feit dat er een woord voor bestaat: gerrymandering.

Evenredige vertegenwoordiging

Er is weinig kans dat dit systeem zal veranderen, aangezien de grootste partijen geen belang bij verandering hebben - hun aandeel in het Lagerhuis zou waarschijnlijk omlaag gaan.

Lang niet iedereen is blij met het huidige systeem en er wordt uitgebreid geroepen dat het systeem moet veranderen. Het systeem is verouderd en werkt niet meer.

4 jaar geleden was er een referendum over Alternative Vote, een systeem dat voorgesteld werd omdat het niet een erg grote verandering zou zijn - en er vermoed werd dat echte evenredige vertegenwoordiging door het electoraat afgewezen zou worden omdat het te anders was.

Evenredige vertegenwoordiging wordt voor sommige verkiezingen wel gebruikt in het Verenigd Koninkrijk, maar niet voor die van het Lagerhuis - want dat zou de grote partijen geen goed doen.

Zetels 2015Zetels gebaseerd op stemmen percentage
Green Party125

Ik heb hier de simpele methode gebruikt om de stemmenpercentages te gebruiken, in werkelijkheid zou er waarschijnlijk een ingewikkeldere methode gebruikt worden die ongeveer op hetzelfde neer komt.

Aangezien veel mensen nu taktisch stemmen om te zorgen dat de partij die ze zeker niet in de regering wil ook werkelijk niet in de regering komt, is het waarschijnlijk dat minder mensen voor de twee grote partijen zouden stemmen. Ook is het waarschijnlijk dat meer mensen die nu niet stemmen, omdat hun stem er niet toe doet, alsnog zouden gaan stemmen wat de resultaten ook weer zou veranderen.

by Mario ( at May 12, 2015 09:31 PM

May 03, 2015

Alistair's Blog

Arduino Pro Mini / Lilypad pinouts

I have been using the Arduino Pro Mini and the Arduino Lilypad recently with an external programmer. As I normally use a generic USB programmer and need to connect each pin manually I am continually looking up what needs to be connected where. This is a table of connections to make this easer.

Name Arduino
Pro Mini
FTDI Cable FTDI Cable
Budget Cable
Ground B GND GND Black n/c n/c
Ground GND CTS Brown GND Black
Receive RXI TXD Orange TXD Green
Transmit TXO RXD Yellow RXD White
Reset G Reset RTS Green n/c n/c

by Alistair MacDonald at May 03, 2015 01:40 PM

# This site is managed by the team at SuperMondays, is hosted by the team at Consilience and is maintained on github.