We use Plug n Pay at $work to conduct our financial transactions. It’s a great service, but the example code that they provide for PHP and Perl developers leaves something to be desired.

I spoke with a tech support guy there, and, while he was helpful, and clearly very knowledgeable, I found that we differed significantly on a particular point of philosophy. He seemed to be somewhat perplexed as to why I would want a full OO interface to their API, because, as he said, any PHP programmer worth their salt can take the API documentation and write code that sends arguments via Curl, or PHP sockets, or whatever, and get useful results from it.

To this end, they offer one PHP file, containing a partial implementation of one of the API methods, as an example of how one might do this. The example manually builds a query string, rather than using http_build_query, and manually splits the return value, rather than using parse_str – not crimes in themselves, but it seems that ecommerce code should be held to higher standards than this.

While I don’t disagree that a good programmer could indeed do this, I disagree that any would *want* to. Good code is reusable code. Having thousands of programmers writing exactly the same code, and having many of them, no doubt, doing it really badly and insecurely, is not in the best interests of anyone – the programmers themselves, the companies they work for, or even Plug n Pay (or any other financial vendor). They are wasting thousands of hours, and they are very probably writing code that is insecure, confusing, poorly documented, and, in many cases, just plain wrong.

Having a complete API implementation, and providing that to customers, is a service to everyone. It saves my time as a programmer, it saves time and resources on tech support, and it results in more secure code that is guaranteed to do the right thing every time.

Now, the folks at PnP offered to audit my code and possibly offer it for download on their site, given certain licensing requirements, and I may take them up on that. I haven’t decided yet. But, to be honest, I find their attitude about the whole thing to be quite at odds with my view of how software development should work. Encouraging every individual programmer to find their own way is not the way to improve the overall security stance of ecommerce websites. In fact, I would say that the huge daily number of compromised ecommerce websites is a direct result of this stance.

So, anyways, to this end, I offer my starter implementation of a full PHP API for PnP. So far, it’s incomplete, but exposes the most frequently used methods, and does it in such a way that it’s pretty difficult to get it wrong. Of course, you need a PlugNPay account to use this, but one hopes that if you found this article by a Google search, this is the solution you’re looking for.

Now, it’s possible that I’m the only person that cares about this kind of thing, but if you’re interested in receiving updates of this code, or possibly in participating in the ongoing development of this code, please let me know, and we’ll work something out. Collaborative development of reusable code seems like the only sane way to implement a financial transaction codebase.