I was recently contacted by somebody through my website complaining that PayPal must have changed something in their system because all sorts of customers are having issues using their application, but nothing has changed…the usual story.
This particular merchant was using PayPal’s Recurring Payments system to manage subscription profiles. Each time a user of the application would log in to the system, the app would use PayPal’s GetRecurringPaymentsProfileDetails API to obtain the current status of the profile and proceed accordingly. For some reason, though, this portion of his application was failing and not letting people with active profiles in.
The first step to troubleshoot something like this is to see what exactly is happening with that communication to and from PayPal. Log files provided us the raw HTTP request and response bodies to take a look at, and that’s where we noticed the following:
- The ACK (result) of the API call came back as SuccessWithWarning
- The “warnings” that PayPal return are included as “errors” within the response.
- The specific warning/error we were getting was 11587 – Billing Address is Partial
Now, what’s interesting here is that this does indeed look like something new PayPal just started doing. I’ve worked with Recurring Payments for years and I’ve never seen this warning about a partial billing address. Further investigation reveals that I was finding the same thing happening in all the apps that I manage myself, so I’d have to agree that PayPal did indeed make a change here.
So why didn’t my stuff break like my new friend here? That’s exactly what he asked me. My immediate theory was that he must not be handling the ACK correctly, which I see happen all the time. For example, the following code logic would have been treated as a failure in the scenario outlined above.
if($ack == "Success")
{
// It worked!
}
else
{
// It failed!
}
Because $ack actually had a value of SuccessWithWarning, it would be treated as a failure with that particular logic. This is the cause of many headaches for developers I’ve seen over the years. This guy swore, though, that he had made that mistake before so he always makes sure to check for both.
We started digging deeper into his code where this particular API call was being made, and what we found made him red-faced pretty quickly. He actually wasn’t checking the ACK value at all. He was simply checking for errors…any errors at all…and if there were errors, he treated it as a failure.
if(count($errors) > 0)
{
// Failure
}
else
{
// Success
}
This was causing all of these app users that had partial billing addresses to get locked out of their system. Once we adjusted the logic to check the value of ACK properly everything worked as expected.
if(strtoupper($Ack) != ‘SUCCESS’ && strtoupper($Ack) != ‘SUCCESSWITHWARNING’)
{
// Failure
}
else
{
// Success
}
As a bonus, he decided he’d like to go ahead and send himself email notifications when warnings like this occur. He was thrilled to see such a feature once he understood what was going on.
To summarize, it seems that PayPal did make a change, and stuff like that can be frustrating. The true source of the problem here, though, was a flaw in programming logic and error handling. Don’t get careless with that stuff during development!