Hacker News Reader

Comment by erikcw | Hacker News Reader

Not sure if this is related to this particular case. From previous experience, PayPal will silently stop delivering IPNs if your webhook URL ever returns a non-200 status code for an extended period of time.

It took us a fair amount of time to figure out that this was the cause of our issue -- the PayPal UI didn't indicate any problems and PayPal business customer support was unable to see the source of the problem either.

View on HN

IPNs are annoyingly difficult to use.

Some accounts simply will not send them until an IPN URL is set, even for transactions that include the notify_url in the request. You cannot even see the IPN history until you enter an IPN URL, even if it was used through the notify_url param.

IPNs that include UTF8 characters will not validate by default in most PayPal accounts. PayPal defaults to Win1252, translates the UTF8 content to Win1252, tells you it's Win1252 and then seems to validate the IPN against the original UTF8 data. I have never been able to validate a Win1252 IPN that had UTF8 content. I've tried iconv, stripping bits, and plain substitutions (ü -> u). Nothing seems to work. This seems to be getting better though.

For about 2 months last year they forgot to include a field that had to be added in order to verify the IPN. And you had to iterate through a few different values to see which one was correct. So we got a rash of support tickets asking why our customers were suddenly getting notifications of issues verifying PayPal purchases and were having to manually approve orders. I submitted a ticket after a day of dealing with the issue and got a response about 2 weeks after they fixed the issue. There was no indication of the problem on their status site.

The IPN verification service randomly returns INVALID for valid data or simply doesn't work. Sometimes IPNs are delayed.

Dealing with the PayPal APIs are far, far harder than their sales sites would have you believe.

I banged my head pretty hard on this recently, but afaict I have a working solution. I wish this had been better documented. One problem I faced is that I had to fiddle with Flask to make it work (Python user here). I'll post my setup somewhere tomorrow and comment back here.

Here is my solution to the encoding issues, let me know if it works for you (assuming your environment let you access the body of the request without parsing it, or already knows how to parse it correctly).

http://blog.cyberion.net/2014/08/parsing-paypal-ipn-requests...

Thanks, but that's a wholly separate issue from what I was talking about.

When you have UTF8 data in the IPN, PayPal translates it to win1252 in the IPN. But it verifies the IPN against the original UTF8 data. The only way to fix it is to go into the profile and change the IPN format to use UTF8. There is no programmatic way to set the encoding for IPNs to be sent in and there are no workarounds that I am aware of.

If you never see international names or addresses with accents and diacritics you won't run into the problem.

That's not my experience, validating the data has always worked by just spitting it back out to them without any alterations to the data.

Yea; we always, always return a 200. I have no idea about redirects but you can test that using the (very, very painful) sandbox. FYI, another lesson we learned the hard way: if you are testing your IPNs in the sandbox and you include a port number in the URL, the IPNs will silently fail. You also can't use IP addresses for IPN testing (again, they will silently fail) so I setup an A record in our DNS pointing to my local machine for testing.

Interesting - we have still gotten IPNs which is why we didn't suspect anything.

Have you checked your web server logs? We had a problem a year ago where we were getting 403 errors (forbidden). It turns out that paypal's DNS was a bit screwy, so apache wasn't able to do a reverse dns lookup on the ip address, and it was therefore getting rejected by our server. I simply added the ip addresses of all of paypal's IPN servers to our Allow list, and we haven't missed any IPNs in the last year:

Allow from .paypal.com

Allow from 173.0.81.1

Allow from 173.0.81.33

Allow from 66.211.170.66

What about if it finds 301 or 302 codes (redirects)? I hope they don't count as a negative...

I wouldn't chance it; the first time I implemented IPNs, I had to spend almost a week on R&D aimed purely at discovering and working around all the undocumented fuckups.

Webhooks are not hard. That Paypal fails at them this badly makes me think their infrastructure is a (much larger) disaster waiting to happen; if I still did freelance work, I would be moving all of my clients to Stripe right now, before the next inevitable mishap.

They actually do the right thing with a 301 redirect, and re-post to the new URL. I did a site wide http->https redirect, and surprisingly the IPN script continued to work.

Reply on news.ycombinator.com