4 ms·

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

by erikcw 12y ago

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.

emilepetrone 12y ago
Interesting - we have still gotten IPNs which is why we didn't suspect anything.
- cpncrunch 12y ago
  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
Tegran 12y ago
What about if it finds 301 or 302 codes (redirects)? I hope they don't count as a negative...
- aaronem 12y ago
  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.
- jcampbell1 12y ago
  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.
jewelia 12y ago
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.
jcoby 12y ago
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.
- yannk 12y ago
  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.
- yannk 12y ago
  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-with-flaskwerkzeug.html http://blog.cyberion.net/2014/08/parsing-paypal-ipn-requests...
  - jcoby 12y ago

by erikcw 12y ago

emilepetrone 12y ago

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

cpncrunch 12y ago
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

Tegran 12y ago

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

aaronem 12y ago
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.
jcampbell1 12y ago
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.

jewelia 12y ago

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.

jcoby 12y ago

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.

yannk 12y ago
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.
yannk 12y ago
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-with-flaskwerkzeug.html http://blog.cyberion.net/2014/08/parsing-paypal-ipn-requests...
- jcoby 12y ago