PayPal Instant Payment Notifications (IPN) Failing

[pmsupport]

Hi all,

I have contacted Pay Pal myself about this problem. They are going to take a look into this problem for us. They require some Pay Pal integration details in order to investigate this. (From settings | Business settings)

If anybody is happy to email me some details to give them as an example that would be great. pmsupport [@] actinic.co.uk

As soon as I have some feedback I will keep you posted.

Paul

[leej]

Same here

Hi everyone,
This is exactly what you need for a Monday morning! =)

I have a client who has emailed me with the same issue. I informed here of the situation thta everyone is having and tried the fix above. This is the response I got back from my client.

"I’ve spoken to a guy at Paypal because that didn’t work. He said that the notification url thing is irrelevant – it’s often blank, they take the details from somewhere else anyway.

Anyway he says when Paypal is contacting your server, it’s not replying with the right message – it’s a 502 message not a 200 message or something!

He’s sending an email with all the details in for me to forward to you. Can you have a look into it and see if we can sort it."

The client then forwarded me on this message form Paypal.

Thank you for contacting Merchant Services.

Following our conversation, I have opened a new ticket should you need further information.

As advised, there are two ways to trigger IPN notifications:

1) Specifying an IPN URL from your Profile.

2) Sending the variable notify_url during each payment.

Even thought your Profile IPN was blank, your website was still triggering notifications using the 2nd method. We can check this easily because even though you have changed your IPN URL to:

http://www.yourdomainname.co.uk

the notifications are being sent to longer URL (which is the one that your website is sending, and overrides your Profile IPN). Also, I have attached a picture that shows the variables that your website send to PayPal in the background, during each payment.

Explained that, let's focus on the actual problem.

PayPal will only set the Status of the notification to correctly "Sent" if our server receives an HTTP response of 200 OK from your server. This is the standard HTTP response and it means that your server has received our notification.

However, if you click on any message ID in your IPN History, you will see that our server is receiving an HTTP response of 502, which means:


"A server is acting as a gateway or proxy to fulfil the request by the client to access the requested URL. This server received an invalid response from an upstream server it accessed to fulfil the request.

This usually does not mean that the upstream server is down (no response to the gateway/proxy), but rather that the upstream server and the gateway/proxy do not agree on the protocol for exchanging data. Given that Internet protocols are quite clear, it often means that one or both machines have been incorrectly or incompletely programmed. "


From PayPal's perspective it will keep retrying the notification for 16 times and then it will go to Failed status.

We can't know from here why exactly is your server triggering that particular 502 response, instead of the standard 200 OK. My advice is to contact your server provider for advise, as they have access to the necessary tools to troubleshoot their IPN integration.

They can also contact us directly from www.paypal.com/mts

If you have any doubts, please reply to the email.

That's just great however I suppose the big question is WHY HAS IT JUST STARTED HAPPENING TO ALL OF ALL AT THE SAME TIME IF IT'S A SERVER ISSUE, UNLESS WE ARE ALL USING THE SAME HOSTING COMPANY.

[TraceyHand]

WHY HAS IT JUST STARTED HAPPENING TO ALL OF ALL AT THE SAME TIME IF IT'S A SERVER ISSUE, UNLESS WE ARE ALL USING THE SAME HOSTING COMPANY.

well, there's a thing.
ARE you?

[leej]

Let's see. We are using a hosting company called FirstServ based in London. The site is running on a Windows Plesk server. Anyone else?

[Redbull99]

I'm with Nublue, Linux VPS with Plesk.

Is anyone not having the problem?

Steve

[jmedinger]

It's happening on 2 of our sites too... not hosted with any company mentioned here either.

[Andy Warner]

you cant just put your web URL in the box if you use your account for multpile shops as we do - the data is in the payment sent from the catalog software, and until this weekend, it all worked as it should - this is a PayPal issue - they have changed something, not us!!!

from what i recall, the instructions tell you NOT to put any web address in the fields.

I trust Actinic support, not paypal!!!!!

[PhilB]

Hi Guys

I have been monitoring this thread as one of the posters is a new customer of ours and is having this issue.

To clarify Paypal's response; you do not have to have an IPN notification URL filled in in your paypal account because paypal supports a mechanism by which they are told on a per-transaction basis where to send payment notifications to in the background, which Actinic uses. The field in your paypal account is to specify a 'default' callback url to be used when notify_url is not specified by the merchant's website upon checkout - in my opinion it's best to leave this blank unless you know you have a specific use case for it, as it can cause problems with callbacks occurring unexpectedly to the wrong place if you use the same account for multiple sites/software installations etc.

The situation we have at the moment for our client is that the script the callback goes to is generating a 500 error and we're not able to see or get any troubleshooting information as nothing is being logged anywhere as to WHY this error is being thrown other than the fact that the script fails to complete execution correctly. This situation usually points towards a script error or configuration error on the server, but as the script itself works for OTHER processes (paypal callbacks are just one of the functions it seems to fulfill) it seems unlikely that the issue is with the server configuration; unless the paypal callback mechanism uses a specific perl module or similar that I have missed, but I can't see anything in the script that would indicate that.

My personal suspicion is that something subtle has changed at Paypal's side given the amount of people suddenly experiencing the issue and that it was merely coinicidental with our customer's move. Whatever they've changed is now causing the Actinic script to choke on the new input and throw the error, but it's not logging anything when it does so.

If Actinic want to get in touch with me then I welcome them to do so as I'm happy to work through the issue with them on behalf of our customer, and to the benefit of others here.

Phil

[Andy Warner]

yep, our default was IPN OFF as you don't need it turned on at all - the payment details actinic sends to paypal include an IPN value that over-rides the profile settings.

looking at ours, we get a 500 error on the last one (its 'retyring and has been since 4am - its on its 8th retry), but allegedly the rest sent OK.

the error log in acatalog folder shows the following errors occuring since the paypal issues arose:

Program = ORDERSCR, Program version = 20697 , HTTP Server = Apache/1.3.41 (Unix) PHP/5.2.9, Return code = 999 , Date and Time = 2010/09/24 11:22, Internal Errors = CallPlugInScript, execute: Modification of non-creatable array value attempted, subscript -15 at sc000001.pm line 616.


that error started occuring around mid september a few times, then tonnes of them sionce the 24th.

does that help?

[jmedinger]

That's exactly the same error message as we're receiving - ours started on the 17th and have ballooned since the 24th too

[leej]

First one for my client seems to have started on the 16th September and then continues to do so until present day.

[Andy Warner]

I guess thats about the end of my useful input then! seems like a PayPal change has knackered everone!

manual changes it is, for the moment at least.

[guccij]

Just to add this to the mix - we also use PayPal as one of our PSPs. We have had none of the problems described above. Yet ...
Hosted with 1and1.

[DiskDepot]

It's very unlikely that this is a problem with anyone's server settings having changed- we run our own server and have been having the same issue over the weekend.

I agree with the suspicion that PayPal have probably changed something subtle on their end that is causing problems for something in the Actinic scripts.

[PhilB]

Program = ORDERSCR, Program version = 20697 , HTTP Server = Apache/1.3.41 (Unix) PHP/5.2.9, Return code = 999 , Date and Time = 2010/09/24 11:22, Internal Errors = CallPlugInScript, execute: Modification of non-creatable array value attempted, subscript -15 at sc000001.pm line 616.

I'd seen those but the timestamps didn't seem to directly correlate to the paypal callbacks (I didn't think).

I just assumed that was some other goof.