IPN is not being sent to our server since yesterday, but IPN history claims lots of retries

[Webtail]

(Sorry if this is the wrong board.)

We have following problem with our integration with PayPal (a business account with working integration for several years).

On Sat 2021-03-20, around 10 am CEST, we stopped getting IPNs from PayPal. Every transaction get struck in "Retrying" with response code 500.

We were making changes in our site the night before. After the changes, we got 6 IPNs that worked as they should, and after that that we stopped getting any IPNs.

Today we made several tests. Final one was:

• We made order in our system.
• We paid it via PayPal.
• We found it on IPNs list (in PayPal admin account) with status "Retrying" and status 500.
• We took the IPN message and sent it ourselves to our system (from one of our developer's machine, so also from outside the Azure cloud which hosts our site).
• The IPN handling service sent it back to PayPal and received answer "VERIFIED".

Conclusions:

• We ARE able to receive IPNs and handle them properly.
• We ARE able to simulate PayPal sending us IPN and whole further flow is ok, including PayPal confirming the IPN.
• We DON'T get IPNs from PayPal.

Please help. 

[TS5101]

We have absolute the same problem! Since March 22 at about 12 CEST we don't get  IPNs anymore.

Nothing has changed on our site, and we checked everything.

Best regards

Jens <removed>

[TS5101]

Sorry, I Meant March 20th

[TS5101]

Status Update,

we are receiving the IPNs again, since yesterday at about 7pm CET. 

Best regards

J.<removed>

[Webtail]

Could you figure out what it could have been?

We are still stuck.

The funny thing is that there have been a few SHORT periods of time when it seemed to work again but then it went back to retrying.

Btw, we are using custom ports. We found out yesterday that non-standard ports might not work. We have changed our nitofical URL to something new, without custom ports. But all NEW orders keep retrying the OLD url.

[Gunsuka]

We are seeing much the same as you, we are getting the IPN notices and the data in them in fine.  However PayPal is reporting the retrying and 500 error.

Made a post about it here:

https://www.paypal-community.com/t5/PayPal-Reporting/IPN-Retrying-All-of-a-sudden/m-p/2649194#M4928

[TS5101]

Update,

we received IPNs irregular for a few nights. Since 25.3 we no longer receive IPNs at all. We can check with our server logs that Paypal is not sending any IPN calls at all !

But, we ourselves can generate calls and responses with test forms and also with the IPN simulator.

[Gunsuka]

We have been getting email notices from PayPal that our IPN system is failing.  In that email they indicate that they may suspect the IPN feature for our domain, so perhaps that is what has happened to you?   They suspended your IPN notices because they think it is not working?

I contacted PayPal support, got one reply where they asked to see the screenshots of what we see and any other information.  Once we sent that info back we have heard nothing else.

Our IPN notices still say retrying (or failed after a few days).

[kfchu]

We have similar issue starting from 25/3

IPN message is keep retrying and the history shows our response code is 500

We also got the email warning from PayPal about our IPN script.

But the ipn script in our server is processed without problem and it is triggered to update our product database.

We put the script into IPN simulator to test and the simulator replied it is verified.

[Gunsuka]

I resolved my issue today.  After looking at the code, I realized it had to be something with the verification of the data.  After you get the data from PayPal, you have to send it back to them to verify it.

I figured it out by using Google and finding others who had the same problem.

Once I knew what the problem is, I found this page from PayPal that documents the issue:  https://www.paypal.com/us/smarthelp/article/how-do-i-modify-my-ipn-php-listener-to-support-http1.1-t...

It says it has been required since 2013, but was still working for us until it just broke!

The part we were missing was:

$header .= "Connection: close\r\n\r\n";