IPN listener getting status other than VERIFIED or INVALID

[paulatthehug]

According to the documention when our listener verifies an IPN PayPal should return either 'VERIFIED' or 'INVALID' however we've had a number of instances over the last few days where we've had gibberish back instead, although it's clear from the account that the IPN was valid (so we should have received 'VERIFIED' back).

It took me a while to add sufficient debug to catch it at it but on the two most recent occasions it returned this string each time:

  ‹        TŽK ‚0 „ïüŠ•», M <Œ$¨ÄÔ Çb›@‚ ûÐøïmáäe’Ùùvgɦ¸æ¬mJ8±s Í=«« â-bU²#bÁŠ5Ù')by‰iDzû )é% ÞØÁŽ’ Ò 2.à&_N Kp G  ŒtJ|ÃæŽþQÞGd¦­r :­>Fj0r²ÀA¯ Øž  Œ ôÛç åF “²à&!*±|  é4`¨›*,mþzø3ú   ÿÿ  Î[ óâ

(I've had to put a "*" in to replace a couple of symbols which the forum didn't like for some reason.)

This has only started happening over the last week and we've not touched the code in our IPN listener is quite a long time so it seems to be something on PayPal's side.

Any suggestions as to how to handle this? As it seems to be very intermittent I'm wondering about simply automatically re-submitting the API request until I get either 'VERIFIED' or 'INVALID' or invalid back (with a loop count to stop me sitting there forever banging my head against PayPal's brick wall) but that seemed like a horrible cludge.

[paulatthehug]

I too have had a message from them, although i disagree with their definition of "fixed". I quote:

Dear Oldham Paul,

Thank you for your waiting.

We have fixed this problem already. Now you can log into your PayPal account's IPN history page via link below, and then resend IPN message.

https://www.paypal.com/c2/cgi-bin/webscr?cmd=_display-ipns-history

After that you can receive IPN validate information.

Please let me know if you still have problem.

So their "fix" is that whenever this happens (so several times a day!) I should manually log in and get them to re-send the IPN.

[filipporonco]

Hi @paulatthehug,

are you sure!? 😞

I've interpreted the same identical answer as if the issue was solved and for the previous malformed IPNs we could resend them, if necessary, from the IPN history dashboard. In the previous messages they said that they were aknowledget about the 400 bad response problem so I don't think, logically, that they can consider as "fixed" the issue in the way you're reporting now. Well, I hope they don't think that! 😮

[paulatthehug]

Hmmm ... I think your interpretation is equally valid now I read it again.

OK, well I've replied saying:

So every time this happens (and it's happening several times a day bear 
in mind) you want me to *manually* log in and ask you to resend the IPN? 
Is that right?

You may regard this as a "fix" but I don't.

So their reply to that should determine which interpretation is correct.

[filipporonco · Accepted solution]

It's thrilling 😄
Keep waiting for an happy ending.

[paulatthehug]

Oh, you're going to love this (FSVO "love). They finally replied yesterday and then closed the ticket. This is what they said:

Dear Oldham Paul,

Thank you for your reply.

Such issue does not happened every time.

For the workaround and backup solution, you can also call GetTransactionDetails API and TransactionSearch API to obtain transaction details when IPN misfunction.

GetTransactionDetails API
https://developer.paypal.com/docs/classic/api/merchant/GetTransactionDetails_API_Operation_NVP/

TransactionSearch API
https://developer.paypal.com/docs/classic/api/merchant/TransactionSearch_API_Operation_NVP/

Or, you can download report from your PayPal account to see transaction details.

Sincerely,
Steven
PayPal Merchant Technical Support

So, in other words: it's intermittent (which we knew), they don't appear to be planning to fix it but instead propose a workaround, both of which are marked as "deprecated as of January 1, 2017"!

Anyway I replied, and they rejected my reply because "Your case is now closed."

[filipporonco]

This is the same person who’s answering us. Think that while I was asking about the correct ipn endpoint to use between the old PayPal.com and ipnpb he answered pointing us to completely other stuff as ipn listener configuration or PayPal IPs for each existing endpoint. Think this nightmare can’t find any solution since the answers are such this. Just to know - your direct feedback at this point might be better than their - what is the situation on your hand? Everything working or you got some malformed ipn again?

[Ballesteros]

If it's of any reassurance, my automated tests haven't seen any of the "400 Bad Request" responses since 15th July, so I am inclined to believe that they have fixed the underlying issue, even if the support responses do not appear competent enough to express this clearly or confidently!

I did see a response of 

<html> <body> Fatal Failure <br> </body> </html>

at 02:54 UTC  on Sunday 21st July 2019, but I've only ever seen that Fatal Failure response ~3 times in ~5 years so I'm tempted to ignore that one unless it happens again.

[Ballesteros]

Getting "Fatal Failure" from production IPN endpoint. Sandbox ok. Not seeing anything related on the PayPal Status page or scheduled maintenance. <html> <body> Fatal Failure <br> </body> </html>

[paulatthehug]

Yup, back here too.

And, as usual, PayPal say there's nothing wrong https://www.paypal-status.com/product/production

Sigh.

[filipporonco]

Just back for moment to give all of you a big hug, I’ve chosen the difficult way two years ago and I’ve completely rebuilt the whole platform with another gateway/solution. If you want to remain on PayPal (that I used, faced, hated and loved so much for 7 long years) please at least consider to leave any old deprecated integration and switch to rest api solutions. But the support, the long time waiting answers, the poor participation to this community and the frequent issues to the production and sandbox environment unfortunately we’ll be always part of your journey. Cheers! Fil