CiviCRM Community Forums (archive)

Hi all, I've set up some new membership types for our nonprofit and they all have auto renew required. I've been testing them with the 'test-drive' pages just like I do for any contribution page I make (usually events). The transaction goes through from the users perspective but in the back end, it just sits there as pending and no confirmation/receipt email gets sent.  Civi gives this message to the user:

Your contribution has been submitted to PayPal Pro for processing. Please print this page for your records.
An email receipt will be sent to 1234@567890.com once the transaction is processed successfully.

I tested these yesterday evening and waited 24 hours in case PayPal just took a while, but nothing has happened still. As far as I understand it, the transaction gets sent to PP, PP processes it then talks back to Civi which completes it. That would happen for each instance of auto renewal as well. I've turned on IPN as per the documentation and all other non auto renew transactions work just fine.

I have not tested this live yet, so I'm wondering if it's not working because it just won't in test-drive mode. Does anyone know if that is the case? I figured I would ask before I start testing live. Thanks for anything thoughts and help!

Edit: Took me a little bit but I got finally got into the sandbox test site and I do see all the tests I did the other night in both the history and recurring payments and when I checked, IPN wasn't even turned on for the test account. I'm guessing that's why it's not working and they're just pending. I'm going turn IPN on for the test account and try again. Will update soon. Thanks.

can u resend the IPN manually and see how the web server responds? check your apache logs and see if the IPN is recorded there

lobo

So I don't have SSH access and don't see any var folder for an apache log. I did find the logs folder at the root and it does have www logs but there's not anything that I can see that corresponds to a PayPal IPN message.

Would that be the notification URL? I used just our main page like the documentation says. I looked at our live IPN history and found a recent transaction that went through and is completed and then looked for anything related to it in the www-log.gz for that day and there was nothing so it seems pretty sure that PayPal IPN just isn't really getting back to Civi.

A few notes:

• IPN had never been turned on (live or sandbox) until just recently when I started trying to get the auto-renew memberships working. Live payments, including recurring in the past worked fine, and there seems to be no interruptions (though we don't offer recurring anymore).
• This was all with a real credit card test-driving the page and paying on the actual page.
• When I just tried clicking on the PayPal button and paying with a test PayPal account, it gave this error: Payment Processor Error message: 11502: Invalid Token The token is invalid and wouldn't even go through.

Do I need to create a listener on our side somewhere to get the IPN messages to be actually received?

I'm still quite the novice with both PayPal and Civi so I apologize for being out of the loop on some things and appreciate the help found in the community!

That IP is indeed paypal's sandbox ipn machine

the url seems wrong in both cases, the url needs to be:

/sites/all/modules/civicrm/extern/ipn.php

You'll need to investigate and find out why civi is sending the wrong url to paypal. most of the paypal code is in CRM/Core/Payment/PayPal*

lobo

So I waited and the payments went through to PayPal and I checked the IPN history and it says they sent back the IPN messages. But still nothing happened in Civi. In the log file, the hits from PayPal don't line up time wise correctly but the last few hits from PayPal were all:

173.0.82.126 - - [07/Jan/2013:16:44:50 -0500] "POST / HTTP/1.0" 200 37871 "-" "-"

All the 404's were from earlier I think. So I'm not sure why Civi still isn't actually getting anything. Do changes need to be made to the actual ipn.php file perhaps?

So after taking a day or two off from thinking about this, I've now made some more progress:

I've learned that the pending membership (which has gone through paypal without issue) has no member since, start or end dates. My thought is that maybe having no dates means it can't trigger the new or current rule and is somehow defaulting to the pending status? When I edit one of these pending auto renewal memberships, the member since dates gets filled in with the current date and when I save it, it changes to current status and fills in the start and end date. However, the recurring contribution associated with it is still pending.

I then tested to see if running the membership status processor job (which has not been set to run automatically at this point) would update the pending memberships, but it doesn't; which make sense since there are no dates in the pending membership for the job to go off of.

I think there are going to be more issues to overcome still but it seems like a major one is that there are no dates when these auto renewal memberships come in.

Any thoughts? Thanks.