The problem with middleware is that your software is always caught in the middle. In the case of Seamless Donations, the plugin is fundamentally a piece of software that lives between WordPress and a payment gateway, which today is only the standard PayPal interface. That means that if either of those two endpoint products change, Seamless Donations has to be modified to keep up.

Such was the case today, with an emergency upgrade to Seamless Donations to accommodate a security change in PayPal. Back in June, PayPal announced some changes to how it was going to handle its APIs, specifically moving from TLS to TLS 1.2. But because Seamless Donations uses the standard PayPal gateway, that wasn’t supposed to impact Seamless Donations users.

Ah, but it did.

As it turns out, on January 12, PayPal started to block all transmissions that used TLS. In Seamless Donations, the IPN (Instant Payment Notification) responder uses TLS to communicate back to PayPal to verify the success of a transaction. Those “chat backs” were suddenly being blocked, but only for sandbox users. Those using the production PayPal interface were not experiencing this new blockage.

Unfortunately, due to a family member’s severe illness and then death, I had to step away from supporting Seamless Donations for a few weeks. I returned to it yesterday, facing a number of users who were no longer able to do sandbox testing. At first, I blamed their hosts. But when one user pointed out an article about a similar problem for Java API users, a light dawned. It wasn’t a host-related problem. The whole API had changed.

What made all this worse was that, at least as of the time of this writing, the IPN documentation page hadn’t been updated. My code was exactly the code in the docs, but my code (and, apparently PayPal’s) didn’t work any longer. What was truly special (in a “darn you, PayPal” fist-shake kind of way) is there was no documentation replacing the erroneous documentation. For this situation, I had to trial-and-error it until I found something that worked.

In any case, here’s what’s been done. The dgx-donate-paypalstd-ipn.php file has been updated and now when it’s time to initiate a chat back, I first try to connect using TLS, and if that fails, I again try, using the generic SSL transport protocol. I’ve also coded this try/failback mechanism into the production side of the Seamless Donations gateway, so if PayPal should decide to make the change on the non-sandbox side, the code should absorb the hit.

One item of note: I did find a number of references to using a different mechanism to accomplish that chat back, using the cURL library. But I didn’t want to worry about breaking everyone’s installation in case cURL wasn’t installed by given hosts. I don’t have too much of a problem using a specialized library for an add-on, but I have worked very hard to make sure the core Seamless Donations plugin works with the basic requirements provided by WordPress. This solution, in Seamless Donations v4.0.14 does just that — at least until PayPal breaks something new.

And so it goes.