Req for CiviCRM assistance from PayJunction

[mdlueck]

Greetings,

Continuing dialog after a long laps, I decided to start a brand new thread.

With the upgrade to CiviCRM 3.4.x, now PayPal transactions are not completing in addition to CC payments via the PayJunction (PJ) gateway. PayPal transactions were completing when we were on CivicCRM 3.3.x.

Long long ago, CC / PJ transactions were completing momentarily, just the recurring transaction flag was not getting set in PJ. We changed nothing, suddenly transactions were getting marked "recurring" in PJ, and precisely at the same time the same transaction in CiviCRM was getting stuck in "Pending" state. That is where the situation has remained.

Anyway, following is a message from CiviCRM support hoping to obtain information from CiviCRM:

Hi,

Thank you for the reminder, that brings everything back to light. This is where we're at on that...

We looked into this and it seems that the only payment option that can automatically update a status is the PayPal IPN (Instant Payment Notification). We attempted to mimic the configuration that the PayPal module uses in order to update the status after a payment has been issued, but we have not been successful in doing this.

PayJunction does not insist that an IPN is not needed. However, we do confirm that we do not return an IPN. Therefore, if CiviCRM is configured to look for that in order to update the status, then this is why PayPal is the only option that allows for the status to be updated from Pending to Completed, since they do return an IPN.

Previously, Lobo indicated that we could look at the PayPal module as an example of how this is handled. We did review the PayPal module, but it is not as straight-forward as it sounds. Since PayJunction does not return an IPN, we attempted to update the module so that it simply bypasses the Pending state and instead sets the status to Completed immediately after a payment was made. We were not able to do this since we could not decipher where this task is handled and how it is updated.

As of now, we have reached the limits of our ability to configure the PayJunction module for CiviCRM to function in the particular manner that you are asking for. If Lobo can create the process that I mentioned above (skip Pending, set it to Completed), then it seems that it would solve the problem. However, we are not aware if CiviCRM has intricacies that require the state to "touch" the Pending state, or not.

With Kindest Regards,
Alex Estrada

Senior Tech Support Rep
PayJunction, Inc.

[mdlueck]

As a followup question to this original request... is CiviCRM even capable of hand shaking with a gateway which does not use a return call path / IPN, rather gives its final reply in return to the call that CiviCRM originally makes? That is how PayJunction prefers to work.

Does CiviCRM insist on a return call path / IPN pushing the transaction from Pending to Completed, or is there another way to not require an IPN with CiviCRM? If so, Pay Junction would be interested in an example.

[Donald Lobo]

yes, check paypal pro or authorize.net or moneris

the function call to implement is: doDirectPayment

lobo

[mdlueck]

Thanks lobo. I have forwarded your reply back to PJ.

I thought of one additional point to this puzzle:

Straight up / plain donation transactions CONSISTENTLY complete properly - CiviCRM + PayJunction.

Only if it is a organization membership which is the summation of a Civi Membership with a Civi Profile attached which in turn creates a Drupal CMS account does the train wreck happen.

The PayPal gateway was working successfully up through CiviCRM versions 3.3.x, however upgrading to 3.4.x has now PayPal join transactions not completing, same as PJ.

So, please explain where the payment call comes from differently between straight up donation transactions and the more complicated membership transactions. TIA!

Is there some database table that gets accessed when doing the more complicated transaction that is not for simple donations that might have ended up with some crud in it? I recall such a case with accessing the "database of organizations" profile type, and you found proper error handling had been disabled to allow the Civi test harness to run without error.

I seem to recall us testing the profile separately and that did complete properly, emails were sent, the Drupal account provisioned. We have since locked down the profile so that it may not be run independently.

We have had a test copy of the site for several months now which I would be happy to toss debug code on if that would help track down the source of these troubles.

Thank you! 

[Donald Lobo]

I dont have answers to the below. A couple of things:

1. I do think there are quite a few orgs out there that are using membership + profile + collecting payment quite successfully from various payment processors

2. I suspect someone will need to spend some time on your install trying to figure out whats happening and why. I dont think we can debug and figure this out via the forums easily. The Civi Developer manuals are a good place to get started.

lobo

[mdlueck]

Thank you, Lobo... ESPECIALLY for point #1. Previously I was of the impression that we were going beyond what was supportable with CiviCRM, which I found puzzling since it is clearly documented in the CiviCRM "book" website.