IPN listener getting status other than VERIFIED or INVALID

paulatthehug
Contributor
Contributor

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.

Login to Me Too
41 REPLIES 41

AustinS1
Contributor
Contributor

Anyone get an update? We are still having this problem, terrible customer experience and tons of manual labor being spent on our end 😞

Login to Me Too

paulatthehug
Contributor
Contributor

I did, finally, get the same response that Fil posted here on Jul-10-2019 08:04 AM but it's still ongoing and is worse than ever today. The cludge we've put in, which is working, although it's dubious from a security viewpoint, is that we are treated any reply other than "INVALID" as valid. So no manual labour and the customers are happy as they're getting the normal instant delivery.

 

I am slightly worried that someone might manage to fake an IPN and, if so, how PayPal will respond when we verify it (I hope it will come back invalid). But as we're taking micropayments we simply cannot afford to process payments by hand as it would wipe out our whole profit margin so we have little choice but to risk it. This seems valid given that our potential losses are similarly small (and we are manually auditing a random selection of transactions and especially any larger ones).

Login to Me Too

Ballesteros
Contributor
Contributor

I went with the suggestion from another thread, which was to amend our code to loop up to three retries from our server to the IPN URL if the response from IPN is not "VERIFIED". We shouldn't have to, but it has been working so far.

 

On the other hand, my endpoint monitor which hits IPN with a blank GET request every 61 minutes has still received the 400 Bad Request response around once per day on average, so I'd hate to think how often people with a busy integration are seeing this error if I'm still seeing it daily when hitting it that seldomly.

Login to Me Too

filipporonco
Contributor
Contributor

15 days has passed from the first episode and the issue is still ongoing.

The list of the affected accounts and businesses grows everyday here and on stackoverflow where other people is asking for help:
https://stackoverflow.com/questions/56938887/malformed-response-from-paypal-ipn-instead-of-verified-...

Paypal team has offered some workaround via merchant technical support ticket system and said that the issue has been escalated to the relevant team In the meanwhile if some workaround might fit for small number of transactions manually manageable, a lot of us, especially for those operations (as preapprovals, for example) that are not covered from the suggested worarounds because ther're not transactions for preapprovals, just loose orders and moneys.

IPN are vital for every automated environment based on Paypal APIs and I think this should be fair and helpful showing this issue on the paypal-status webiste too (they answered us that it is not because this isn't affecting ALL users).

Two weeks and no fixes, that's it.

Login to Me Too

filipporonco
Contributor
Contributor

Someone moved this post in the sandbox environment channel.
But the issue reported is actually in the LIVE PRODUCTION website.

Login to Me Too

paulatthehug
Contributor
Contributor

WTF! Well, I started this thread and it wasn't me. Must be the site admins who are presumably PayPal staff. 😣

Login to Me Too

IgorFrolov
Contributor
Contributor

After implementing of 3 attempt of verification request we changed IPN postback URL to https://ipnpb.paypal.com/cgi-bin/webscr on 15th of July. Since that changes we have no issue with IPN verification at all (all IPN are verified after first attempt)

Login to Me Too

filipporonco
Contributor
Contributor

Hi @IgorFrolov , can you please clarify if, as endpoint, you are using the complete link:
https://ipnpb.paypal.com/cgi-bin/webscr or https://ipnpb.paypal.com  ?

This is not clear in the documentation and in one thread here one of the paypal team said that we should not add the /cgi-bin/webscr part because it is intended for web checkout that worked with the old endpoint but not with the newer that is only server to server.

Login to Me Too

IgorFrolov
Contributor
Contributor

filipporonco
Contributor
Contributor

Received today, July 18th, a message from the MTS saying that the issue has been fixed now.

Login to Me Too

Haven't Found your Answer?

It happens. Hit the "Login to Ask the community" button to create a question for the PayPal community.