PayPal SDK for the loss

I recently had occasion to attempt to integrate PayPal Payments Pro into a web site. Now, theoretically, that shouldn’t be a big problem. However, I was skeptical from the start since my previous experience with integrating anything PayPal was less than pleasant.

First off, I started out by trolling through the developer documentation at PayPal’s site. It quickly became clear that organization is not their strong point. There is much discussion of various APIs and SDKs which mostly serves to confuse the issue if you don’t already know the answer. Since I know what an SDK is, I thought, perhaps, such a thing would make my life easier, as is often the case. I figured it would prevent me from having to bother with all the low level communication details. Alas, that was not to be the case.

I downloaded the SDK I apparently needed though determining that was something of a chore on its own. Then I attempted to use it. I discovered that I need something called “composer” to “install” the SDK. That was the first WTF. SDKs usually do not require “installation” of any sort. You should be able to just download them, shove them somewhere convenient, and use them. Nope, not this one. Instead, you have to run this “composer” thing to fetch dependencies and construct the environment properly. And this requires command line access on the server, which is a no-go for the vast majority of hosting providers.

Well, as it turns out, I have command line access so I attempted to follow the instructions for installing this “composer” thing. First, it barfed about some obscure PHP setting not being set correctly but it provided some helpful advice for fixing that. Once I got past that, it gave me reams of cryptic errors about SSL problems and no clues what might be the cause. Fun. Eventually, I got thie installer thing to run using a command line switch which is not mentioned anywhere except in the help output from the installer itself.

Okay, great. I got the “composer” thing installed. Then I ran it (after some difficulties working out how to do that successfully) and it seemed to finish without problems. Then I followed the basic instructions on using the SDK itself.

This all seemed good until I actually tried to make a call into the SDK. Nothing worked and there was no documentation or any guidance on what might have gone wrong to cause the error. Much searching around on the interwebs revealed many people having similar problems with no useful answers from PayPal except “you didn’t install it correctly”. Basically, this left me with a completely useless SDK which apparently works fine for PayPal employees.

I did some digging into the SDK itself. What I discovered was horrifying. Inside the SDK are dozens, if not hundreds, of little PHP files defining classes all over the place and using namespaces all over the place. The whole thing is apparently glued together by an autoloader provided by this “composer” thing. Leaving aside the very heavy, obscure, and complicated dependency on “composer”, which apparently is there because it is more “convenient” for something like 0.0001% of all developers, it became abundandly clear why there was such a problem. Here’s a hint: if your system falls over dead without a class autoloader, you either have a very large complex problem or you have an overly complex rube goldberg scheme going on. Here’s a hint on the hint: you almost never have a very large complex problem.

After some quick studying of a few of the files, I realized that a piece of academia had escaped into a production system. The SDK design is textbook “object oriented” design in a source structure that would be more at home in a Java jar file.

Next I wondered if there was any particular reason for the complexity. After all, there might have been. I dug around for a while until I found the documentation for the underlying API. Much to my surprise, I discovered that it was a simple collection of remote procedure calls accessed through one a couple of interface formats (SOAP or Name/Value Pairs, namely). In other words, they took a fairly simple set of function calls and wrapped them up in a rube goldbergian class hierarchy, exceptions, and some sort of framework.

Now armed with the API documentation, I cranked up my PHP skillz and started banging away on the keyboard. In under an hour, I had a single function that could package up a request and send it to the PayPal server. It even managed to obtain a proper response from the server (“you are not authorized” in this case because, well, I didn’t use proper credentials, but it did prove the concept).

Now, the API has a large number of calls available. I can see a class structure for such an API having a class per API call and even an underlying structure for making API calls.  But why does an API based around essentially simple remote procedure calls need a massive library and framework system with a fragile class autoloader to work? Why can’t it just define the basic API level stuff in a single file and then, possibly, each actual call in its own file and be done with it? And better yet, why can’t that simply be in a single directory structure that can simply be dropped in, a single file included, and access to the whole shebang just works?

In summary, SDKs are supposed to make the developer’s life easier, not harder. PayPal completely missed this point with their SDKs. When it is orders of magnitude easier to work with the raw API (I’m not kidding about orders of magnitude), the SDK is horribly broken.

If you have occasion to integrate PayPal services, ignore the SDK entirely and deal with the low level API directly. Your sanity and budget will thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *