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.
Hey Rich,
Interestingly, we were just talking about PHP based payment libraries here at my $work, also. We're not considering PlugNPay currently, but it's good to see open source implementations of such regardless.
-Chris D
This is exactly why we decided to go with Authorize.net. I made an attempt last year at writing our own API for another payment gateway, and we wasted so much development time in the process that we've since moved on. It's really disappointing, too, because some of the features of Plug N Pay are really interesting. They just didn't follow through with it. If they're going to market ease-of-use with member management, they need to make it a little easier to access that information. Your API is giving us another chance to look at taking advantage of Plug N Pay's features, though, so thanks for your work!
Plug'n'Play obviously has lousy developers. Not wanting to write a beautiful API for your service just because what you currently have "works" (for some definitions of the word) just underscores how lousy they are. If you're content with providing crap, you are by definition a crappy developer. Not having time or money to do something with it is completely different; it's not the same as to be content. You can not have the time nor money to do something better and still feel lousy about it. Infact, you should feel lousy about it.
The new API you're providing through Google Code looks good. But there's a spelling error on the very front page. "$php" should be "$pnp", no? :-) And the best place to have the documentation is not within the source code repository but on the Wiki, don't you agree?
Asbjørn Ulsberg,
As it happens, I disagree with you on two points.
While I disagree with the philosophy that "what we have is good enough", I don't think that this necessarily makes them crappy developers. A little misled, perhaps, but I think that the main thing that it means is that nobody there is a php developer. Their API is not written in php. I'm providing a php interface to it. They're not php coders, and so they simply don't care about the php interface.
Secondly, no, I don't agree that the best place for documentation is in the wiki. Wikis are, in my opinion, good for scratch pads, but not much good as the authoritative source of documentation, particularly for an API. The place for API documentation is inline, using phpdoc. This is, of course, a matter of opinion, but it's my opinion, and it's my code, at least for the moment, until someone else comes along and joins the project.