CiviCRM Community Forums (archive)

Greetings,

Since our configuration is connecting multiple sub-components of Civi together, it was hard for me to decide which forum group to post to.

Our organization is an on-line community. CiviContribute charges keep their Drupal / CiviMember ID active which we include the creation of a Profile to gather contact information for the member.

Several weeks ago, I believe while we had v3.3.5 code on the server, CiviContribute transactions were making it all of the way to "Completed" state. Our CC gateway is PayJunction (PJ), and when the charges were making it all of the way to "Completed" in Civi, the one thing which was missing was the recurring attribute on the charge per PJ. We were having to manually turn that on via the PJ website. Ever since we began with CiviCRM / PJ, yes the "Enabling the PayJunction processor to handle recurring contributions" has been in our configuration, per the instructions here: http://wiki.civicrm.org/confluence/display/CRMDOC33/PayJunction+Configuration#PayJunctionConfiguration-RecurringContributions

For the past couple of weeks (Since 03/21/2011 per my sent email...), however, behavior has suddenly changed! Currently CiviContribute transactions get stuck / do not move past "Pending (Incomplete Transaction)" and magically transactions appear correctly in recurring mode at the PJ website! (When transactions actually show up at PJ that is!) A fair number of transactions get stuck at "Pending (Incomplete Transaction)" and appear NO WHERE at the PJ website!

Since the CiviContribute transactions do not get to completed state, then obviously we do not get receipts emailed.

Additionally no email is generated when a person completes the Profile attached to this configuration.

<><><><>

Straight up CiviContribute donation transactions appear to work FAR MORE SMOOTHLY! We see those go through to "Completed", and the receipt with PDF attachment is delivered.

So it seems to us that Civi is able to handle small tasks, but when Drupal user account creation + Profile + CiviContribute + CiviMember + LoginToboggon + EIEIO are all strung together, the process does not work properly.

I have been thus interested in the logging aspects of Civi, and default logging is silent as to what is happening in Civi internals.

PJ said months ago they were going to set up a CiviCRM test environment to help us work through such issues. We are yet to see them complete the task.

As members (both new and existing) are getting ticked off at the troubles and some are leaving, I am turning here to seek assistance with these troubles.

Sincerely,
Michael Lueck

Thanks lobo.

About #2, with the Civi / PJ handshake there is no return path comparable to Authroize.net. According to PJ, all PJ is going to communicate back about a charge is returned at the time Civi sends the charge to PJ.

There is some voo-doo Rx to modify the Authorize.net return path program file to have it receive Authorize.net format chatter from PJ's Authorize.net return path simulator. I thought we needed to do that in order to get transactions to reach "Completed" state. Since the straight-up donations work consistently and only the more complicated memberships are having trouble, apparently configuring the return path via the Rx is not really necessary.

I will work on your #1 request.

Via IRC: According to Lobo:
dlobo>   mdlueck: there are too many combination that are used in your setup that we don't have experience with

OK, so:

1) Shall we drop certain parts of our member join process to simplify it? If so, please specify.

2) Should we migrate to beta releases of 3.4 and assist with testing at this point? Will documenting such problems be easier to address with a beta release rather than fixing the current stable release?

Frankly I am at a loss...

3) The LoginToboggan module has been disabled for about a week now. No improvement to these new member join problems has been seen. Exactly the same results. So I would think LoginToboggan is now in the clear for not being involved. (Now that I think of it, I do not think I cleared the /files/civicrm/templates_c/ directory after disabling LoginToboggan, so I will try that now.)

Well possibly clearing the /templates_c/ directory shook problems out. This morning we had someone update their membership using monthly recurring PayPal. The transaction made it through to "Completed" state, the email was sent as result of filling in the profile. The only think lacking on the CiviCRM side was Civi does not think the transaction is a recurring one.

However on the PayPal side, they show the transaction correctly as recurring. So better to have PP thinking in terms of recurring than neither side.

I hope the next CC site membership goes as smoothly!!! 

P.S. Perhaps since PayPal has this charge as a recurring charge, can Civi NOT show the charge as recurring as that would result in both systems charging / aka double charges? Perhaps Civi can not show recurring since PayPal is in recurring mode.

goto a url like:

http://drupal.demo.civicrm.org/civicrm/admin/uf/group/update?action=update&id=1&context=group

(which u can get from administe civicrm >> civicrm profile >> settings (for thtat profile)

and uncheck the "Profile" in the used for box

lobo

you'll have to be a lot more specific on what is erratic and not working
.
lobo