I submitted a ticket 8 hours ago but didn't get a response back during business hours. Apparently I should have put it in Troubleshooting instead of Support. We integrate our subscriptions, with recurring payments, with Pay Pal. We are seeing some strange things happening in the last day or so with all transactions showing up in the Error/Debugg Log as having IPN validation error messages that state Paypal claims it is not valid IPN transaction. There have been dozens of aMember transactions with Pay Pal in a row starting in the middle of July 7 (yesterday) that came back with the same error message: "paypal_r ERROR: IPN validation error: Paypal claims it is not-valid IPN transaction: [8 ]" Does anyone have any idea what this might be? I am reaching out to Pay Pal right now and will update this thread with any info they provide. Right now, new orders with Pay Pal are not registering with aMember and new recurring payments made by Pay Pal are not showing up in aMember, either. It's a mess.
This is the exact top line of the error message on the Error/Debug Log: 07/08/2013 05:26:39 /amember/plugins/payment/paypal_r/ipn.php paypal_r ERROR: IPN validation error: Paypal claims it is not-valid IPN transaction: [8 ]
Also, we already had amde these changes as noted on this Pay Pal Fix post by cgi-central posted on January 30: http://www.amember.com/p/2013/ But my hunch is there is something else that happened with Pay Pal changing their validation scripts for those of us still using 3.x, but I don't know and need to find out quickly before this is a total disaster for us.
We also started getting these errors yesterday. We made the code changes mentioned here http://www.amember.com/p/2013/ on January 16, 2013. Everything was working fine until yesterday.
The amember code doesn't handle "chunked" responses - it assumes the word "VERIFIED" to be the very first thing in the response. However, if we get a chunked response, the first thing is "8" (=number of bytes in the word "VERIFIED") - so it fails. We modified the code in paypal_r.inc.php. Now we have this: PHP: if(!preg_match('/\bVERIFIED\b/', $res)) // $res not $ret return sprintf(_PLUG_PAY_PAYPALR_ERROR2, $ret);
That's above my head what you just said. Are you saying you fixed this and I should try to mirror your changes? If so, can you explain a little bit more to someone less tech savvy like me. PayPal told me minutes ago that they are getting the correct 200 response and they think it's a script error with aMember. They said they haven't made any changes in requirements like they had at the start of this year. Pay Pal's tech person believes the "chucked" response problem is a good place to start when finding the error.
I'm really not the right person to give support for your software. However, all we did was change this: PHP: if ($ret != 'VERIFIED') return sprintf(_PLUG_PAY_PAYPALR_ERROR2, $ret); To this: PHP: if(!preg_match('/\bVERIFIED\b/', $res)) // $res not $ret return sprintf(_PLUG_PAY_PAYPALR_ERROR2, $ret); Here: ~/amember/plugins/payment/paypal_r/paypal_r.inc.php Maybe Amember support can chime in and offer their advice. USE THAT CODE AT YOUR OWN RISK!
Let me just make sure I have the facts right about how similar our situations really are... So you got this error starting yesterday after not getting any similar errors before that in the Error/Debug Log: "paypal_r ERROR: IPN validation error: Paypal claims it is not-valid IPN transaction: [8 ] This is happening now on EVERY transaction for us (new orders, recurring subs, cancellation attempts by user/customer). And you changed the code you mentioned above and now you are no longer getting the error and now Pay Pal and aMember are communicating and processing orders just fine since? After reading him your email about the "chunked responses," Pay Pal's tech person said this sounds like a script error of some kind. He suggested I post this in the Forum and send it to aMember's tech team: "There's a trim function that's recommended to be used with the new HTTP 1.1 standards. It's a trim function, and every script is a little different, but the developer should know where it should go. It's hard to understand why it all of a sudden started working."
Code change: PHP: $rr = explode("\r\n\r\n", $res); if(!preg_match('/\bVERIFIED\b/', $rr[1])) return sprintf(_PLUG_PAY_PAYPALR_ERROR2, $ret);
Thanks again! So the post you just made with the "explode" in the opening line is one change, and then earlier (pasted below by me) you made another change. That means you made two code changes to fix things, or is one of these not needed? And where did you place the code change in the post right above this one? On what line? I'm not likely to change anything until I hear from aMember, but I remain a little confused about whether you initiated two codes change to fix the problem we both encountered yesterday or just one. Thanks. PHP: if ($ret != 'VERIFIED') return sprintf(_PLUG_PAY_PAYPALR_ERROR2, $ret);To this: PHP: if(!preg_match('/\bVERIFIED\b/', $res)) // $res not $ret return sprintf(_PLUG_PAY_PAYPALR_ERROR2, $ret);
It's best to wait and hear back from Amember. We've made 1 code change. We changed this: PHP: if ($ret != 'VERIFIED') return sprintf(_PLUG_PAY_PAYPALR_ERROR2, $ret); To this: PHP: $rr = explode("\r\n\r\n", $res); if(!preg_match('/\bVERIFIED\b/', $rr[1])) return sprintf(_PLUG_PAY_PAYPALR_ERROR2, $ret);
I will wait to hear back from aMember. We are able to manually watch (although it's labor intensive) new orders and active them with a manual comp month/year since new orders aren't triggering anything with aMember other than the error, plus we are tracking cancellations via Pay Pal and will manually cancel subs. I just wanted to clarify what you did, since it might expedite aMember's tech team recommending a solution if you were able to convey what you did and confirm it solved the issue for you. Of course, it makes sense to hear from them in case they think there is a better solution or if your solution might have unexpected negative side effects. I suspect if this worked for you they will recommend I also make that change, but they may recommend different precise code changes that they think will work better or be more stable or safe or whatever. I really appreciate your posts as I don't feel totally alone in dealing with this "out of nowhere" issue. Do you (or anyone) have any idea or theory on why a code that worked fine on July 6 stopped working properly suddenly on July 7? That still is strange, since the high-level Pay Pal tech person I talked to said they hadn't been notified of any changes in how they handle things.