Lots of PayPal pending memberships - even some that cleared

I have about a 25% "pending" proportion on memberships. We only accept PayPal. I have received a bunch of complaints from paid members that they can't access their site. Checking PayPal, payment has indeed cleared. Checking the membership, it's listed as "pending" with payments as "never."

Yet the payment did clear. Any idea what's going on?

Thanks

Rick Drew

Hi!

I am also investigating into this matter. I smell there is something very small but irritating in this area. Due to time problem I have not been able to investigate in depth.

In my case, the members have confirmed their email addresses. So they should be getting a subscription, called as first subscription "Registered members".

Even when they confirmed their email address, which I am really not sure, they are not being added into the plugin database.

Further, the funny part is that some members who did not yet verified their email addresses are able to obtain multiple subscriptions. Now when they did NOT CONFIRM their email address, how the hell they became so intellegent to register multiple products?

This is not enough. I deleted and rebuild the entire database. They DID NOT get added into the plugin database, even if their status is Active and a product_id exists.

I sincerly beleive that member[data][status] field and all other binary fields needs to be bombarded as it does create a lot of nightmares, more of problems that help saving calculation time.

if you are hosting your site on GoDaddy servers, that might be a problem... cuz apparently they are blocking usage of some curl process or something that is required to update amember database, paid members and subscriptions and all that...

but hey, what do I know? I only found that out the hard way...

Hi!

I respectfully DISAGREE with you for following reasons:

1. If an User has completed a subscription, paid or unpaid, then he has or MUST HAVE those respective entries in the payment table. If the programming of aMember does not recognise for any reasons, then it is wrong to blame the provider for it.

2. There are several information in this regards that are currently tored in the member[data][status]. This field has created a nightmare in my case and I have seen it how the programming interface interacts with this field.

This field is a binary field. There is no reason to use a binary field in todays date. A Binary field cannot be cached in mysql. So each and every calculation will have to be used in a different way.

3. I personally find it not necessary to repeat the same data and insert in anathor field i.e. member-status. One can make on-the-fly such calculation and it does not make the script slow as compared to the following nightmares of this field.

4. For each and every logical reason, I see only this field to be responsible. If a payment is complete, then aMember scripts MUST take the payment and the programming MUST be in compliance to the liability arising out of it. This should be done in a manner that aMember immediately changes the status to paid status for payment or completed status for free subscriptions.

This aspect cannot be compromised with anything else and cannot be provider specific. There are legal responsibilities arising out of it.

IN my case the number of pending rises too. I am not with godaddy.

Hi I think this was answered before. I'll try finding the post. If you notice you receive payment but amember is still on pending then its because your webhost is blocking a certain port with there firewall. Alex said submit a ticket for the fix and he'll show you how to dissable verification.

OK I just found the link. Maybe its not the same thing but might be.
http://www.amember.com/forum/showthread.php?t=5732&highlight=firewall

Having a very similar problem. About 15% "pending" proportion on memberships but payment already cleared on PayPal side. No pattern to it whatsoever, other than about 15% "randomly" aren't activated even though they paid. Similar to yourself, complaints are streaming in from the paid members that cannot access the site.

As a temporary fix, I can manually activate each account. But this is not very practical. Furthermore, not all paid members have "complained"... yet... this could develop into a nightmare down the road.

I've opened a ticket for help, but I thought I would reply to this thread to let you know my similar circumstances. Anyone get this resolved?

(I'm not a server guru, but it would appear that if it was a firewall setting, 100% of the paid transcations wouldn't be activated rather than only a portion of them not being activated).

Note the "PAID" transaction in the above. We get a ton of folks that just sign up and don't follow through. Very common. That is not the problem here. The problem here is that on the PayPal side I can see user accounts that have paid with cleared payments, yet on the aMember side their accounts are not activated... but again, only happens for about 15% of the cases for us.... previous user above noted it occuring for about 25% of the cases.

Thanks to all for comments.

I am also having tremendous problems with Paypal and IPN verification. One problem was that the fopen call to paypal would not work -- helpdesk fixed that somehow, but that created a new problem that has not been resolved. I now get this error:

paypal_r ERROR: Payment receiver email [{}] is unknown, payment ignored.
If it is wrong, please add email address {} at aMember CP -> Setup -> PayPal

My paypal email address is setup correctly as per the instructions, but somehow the script is not seeing or using the email address in its call to paypal ipn -- this seems to be a side effect of the fix for the first problem, but I have no clue as to how I can fix this.

Also, it seems like code is being changed in order to fix these problems -- when (if) I upgrade to the next version of the script will the code modifications be overwritten and break the paypal IPN calls again?

This is very frustrating -- seems like the code simply doesn't work at all -- I havent been able to do even one correct transaction yet...

Help

I am getting upset customers because of this fopen error. Why don't you post the files that fix this errors so we can do it?

I disabled my firewall on my server and it did not resolve the problem. Can someone please get back to me or send me the files I need to resolve the problem.

I use a host that resells godaddy. Is this fixed in the latest release? Or is it a patch I need to request individually?

I have been using aMember for many years with no Pay Pal issues, now, right after I installed the PHPBB and Coppermine plugins, I am having Pay Pal transactions that do complete, but never update the subscription. My debug indicates the following error:

paypal_r ERROR: finish_waiting_payment error: Payment is already completed

I noticed that once I added the two plugins, my db rebuild time went WAY up!

I'm thinking that now the response to Pay Pal has slowed so bad that transactions are not being completed.

Any ideas?