PayPal Instant Payment Notifications (IPN) Failing

[Andy Warner]

first paypal order completed via ipn today - yay!!

[jmedinger]

Seriously?

After the previous posts saying that neither Paypal nor Actinic had changed anything?

This smacks of someone at Paypal looking deeper into their processing methods and altering something then...

God I hate misinformation from the PSP's

[Nigelb]

Andy
what did you do? Have been having the same problem and also got a reply from Paypal saying it was nothing to do with them.

It's still not working for us, so if there's anything you did to fix it can you let us know?

Thanks!

[Stuart J Sykes]

IPN's still failing for me - looking at the PAYPAL IPN history all my transactions are set on 11 retries (then go to SENT)
Does that mean that PAYPAL actually got through to the script? Is 11 retries the maximum?
It looks like PAYPAL are "passing the buck" to Actinic saying its a script fault...
So....whats the betting that Actinic are gonna say its a user server fault?

[blademail]

PayPal IPN timing out

We have the same problem, we are using Actinic Business V9. PayPal pointed us to the IPN log - from My account/History/IPN History What is evident is that the normal amount of retries is 1 but from 25/09 this jumped to 11.

Is this a common theme? Please check

PayPal say the retry interval increases after each failure and that 11 retries represents a time of several hours. The technician also said "I tried to paste the IPN URL that Actinic provided you and I got a message saying that "orders must be completed within 3 hours or they will be automatically cancelled.", which is normal as I suppose Actinic will have some kind of security timeout. After 11 retries for the IPN, it's well more that 3 hours between the actual transaction and the IPN so I think Actinic is giving up before thinking the transaction was never paid."

I sent this comment and a sample of the IPN message to Actinic support and i understand that they and PayPal are looking to see if there has been a change to the format of the PayPal IPN message which could cause the message to fail in the Actinic cgi script. Otherwise its hard to think why so many of us, with separately hosted scripts have had the same problem at the same time.

Actinic support have asked me to reset the shopping cart expiry period to 48 hours which I will do today, but I am not enthusiastic about having to wait 48 hours for a transaction payment to be notified!

Peter R
Blademail

[pmsupport]

Hi all,

Just to give you an update, our development team are still looking into this issue. As soon as I have an update I will keep you posted.

Paul

[gabrielcrowe]

Theory:

Assuming paypal have not changed anything (which i doubt btw) and some people are still working well. Could it be an update applied to perl itself that has caused the issue?

Some auto-patch may not have been applied to certain servers, and this might be why they are still working.

Of course, if paypal have changed something, im surprised someone here has not picked up on the subtle difference between the working IPN and the broken IPN.

help me actinic ben kenobi, you're our only hope.

[brucet]

We are still trying to communicate with PayPal about this. If they have made a change that we need to respond to, then we will do so as promptly as we can. But ATM we cannot establish whether this is the case, or if so, what the nature of the change might be.

[dalydesign]

Just to add to the numbers...

We're experiencing the same. Hosted on Fasthosts server running Linux/Plesk

Our server's had a few tweaks for PCI-DSS compliance about 6 months ago, but it's had no tweaks since - I'm not sure if this is a factor worth mentioning.

Our Paypal is showing that all callbacks have been sent successfully after 11 tries, but prior to this week, all callbacks were not requiring resending.

However all payments this week are ending up in Pending PSP but paypal history is showing as successful with a 200 code.

We'll await hang fire until one of you genius Actinic warriors discover's what changes Paypal have done.!

[brucet]

It's hard to see how anything we have done could have broken scripts generated from two or three year old software versions sitting on other people's desktops... However we're not going to see our customers fall between ourselves and PayPal. We are pursuing this as vigorously as we can in order to track down the cause and find a solution.

[DiskDepot]

Theory: Assuming paypal have not changed anything (which i doubt btw) and some people are still working well. Could it be an update applied to perl itself that has caused the issue?

Some auto-patch may not have been applied to certain servers, and this might be why they are still working.

As I mentioned earlier, we run our own server and have not (to the best of my knowledge) updated anything like that recently, yet we have still experienced this issue. Therefore it's unlikely that that's causing the problem.

[gabrielcrowe]

As I mentioned earlier, we run our own server and have not (to the best of my knowledge) updated anything like that recently, yet we have still experienced this issue. Therefore it's unlikely that that's causing the problem.

fair point.

Silly paypal, causing themselves such a support headache. lol.

[Andy Warner]

our one that went through was hosted in the US on a rackspace cloud server.... not looked at any outstanding UK served sites yet today - too busy setting up my new Samsung LCD tv......

[Stuart J Sykes]

our one that went through was hosted in the US on a rackspace cloud server.... not looked at any outstanding UK served sites yet today - too busy setting up my new Samsung LCD tv......

MMmmmmmmmm.....this sounds like a PAYPAL UK server thing then..

[Andy Warner]

well, ive not had any paypal orders today on uk sites - all worldpay.