CiviCRM Community Forums (archive)

I would patch your codebase like this & then check your civicrm log for debug output.

(note the first line of this patch is just a fix that *should* be done in Payjunction - I submitted the same change for eWay yesterday - but I doubt it is significant)

diff --git a/CRM/Core/Payment/PayJunction.php b/CRM/Core/Payment/PayJunction.php
index 7080288..219d8ea 100644
--- a/CRM/Core/Payment/PayJunction.php
+++ b/CRM/Core/Payment/PayJunction.php
@@ -53,7 +53,7 @@
    * @static
    *
    */
-  static function &singleton($mode, &$paymentProcessor) {
+  static function &singleton($mode, &$paymentProcessor, &$paymentForm = NULL, $force = false) {
     $processorName = $paymentProcessor['name'];
     if (self::$_singleton[$processorName] === NULL) {
       self::$_singleton[$processorName] = new CRM_Core_Payment_PayJunction($mode, $paymentProcessor);
@@ -160,7 +160,9 @@
 
     // get an pjpgResponse object
     $pjpgResponse = $pjpgHttpPost->getPJpgResponse();
-
+    CRM_Core_Error::debug('txnarray', $txnArray, TRUE);
+    CRM_Core_Error::debug('pjpgRequest', $pjpgRequest, TRUE);
+    CRM_Core_Error::debug('pjpgResponse', $pjpgResponse, TRUE);
     if (self::isError($pjpgResponse)) {
       return self::error($pjpgResponse);
     }

so, in fact the trxn_id should be correctly populated at this point from what you say...

diff --git a/CRM/Core/Payment/PayJunction.php b/CRM/Core/Payment/PayJunction.php
index 7080288..e534bd3 100644
--- a/CRM/Core/Payment/PayJunction.php
+++ b/CRM/Core/Payment/PayJunction.php
@@ -53,7 +53,7 @@
    * @static
    *
    */
-  static function &singleton($mode, &$paymentProcessor) {
+  static function &singleton($mode, &$paymentProcessor, &$paymentForm = NULL, $force = false) {
     $processorName = $paymentProcessor['name'];
     if (self::$_singleton[$processorName] === NULL) {
       self::$_singleton[$processorName] = new CRM_Core_Payment_PayJunction($mode, $paymentProcessor);
@@ -160,7 +160,9 @@
 
     // get an pjpgResponse object
     $pjpgResponse = $pjpgHttpPost->getPJpgResponse();
-
     if (self::isError($pjpgResponse)) {
       return self::error($pjpgResponse);
     }
@@ -176,7 +178,7 @@
     $params['trxn_result_code'] = $pjpgResponse['dc_response_code'];
     $params['trxn_id'] = $pjpgResponse['dc_transaction_id'];
     $params['gross_amount'] = $params['amount'];
-
+    CRM_Core_Error::debug('params', $params, TRUE);
     return $params;
   }
   // end function doDirectPayment

Do you have 'separate payment' configured on your contribution page - ie

"
x
Separate Payment

Check this box if you are including both Membership Signup/Renewal AND a Contribution Amount section, AND you want the membership fee to be handled as a separate transaction.

With this configuration, the membership fee is automatically charged, and users have an option to make an additional contribution (two separate payment transactions will be generated).

The contribution amount covering the membership fee will use the financial type configured with the selected membership type (see the membership types configuration tool to review those settings). Any additional contribution will use the financial type configured for this online contribution page.

If this option is NOT checked and you include a Contribution Amount section, then a single transaction is processed for their contribution amount which must at least cover the selected membership fee.

NOTE: This option is NOT available for PayPal Website Payments Standard and Google Checkout."

I believe separate payment may work for ? Paypal Pro? but would not expect it to work for PayJunction

Greetings Eileen,

Odd, no debug output to the web browser this time. The new test transaction still got stuck in pending state.

I got the dreaded green box stating:

Your contribution has been submitted to PayJunction Test Gateway for processing. Please print this page for your records.
An email receipt will be sent to emailaddywashere once the transaction is processed successfully.

patch gripped about the end of your diff, so I had to manually patch it myself. I will attach it below to be sure the patch was what you intended. It made sense to me.

I am thankful,

Greetings Eileen,

No worries... I began fresh on it this morning and was able to get it to go all of the way through the module. Sanitized output attached.

And yes, in the Civi Contribution Dashboard, this test transactions is stuck at "Pending (Incomplete Transaction)" state.

I would think this to indicate it not a PJ specific file is where the transaction goes wrong... like I started this post it seemed to me to go wrong in file: ./CRM/Contribute/BAO/Contribution/Utils.php

I am thankful,

OK - you are going to need to add a

CRM_Core_Error::debug('backtrace', debug_backtrace()));

& then go through adding your debug all the way along until you figure out when it stopped being there :-(

So,

I think you are saying that it gets to here & calls this function

https://github.com/civicrm/civicrm-core/blob/4.4/CRM/Contribute/BAO/Contribution/Utils.php#L287


At the point when the function is called is $result['trxn_id'] correctly populated or not?

Greetings Eileen,

I sprinkled your suggested LOC around the Util.php file, sent a test membership join transaction, and captured over 14M worth of trace data.

I suspect, however, it did not dump the $contribution array as the trxn_id and trxn_result_code fields I had been keeping an eye on in my sleuthing are always populated.

I have attached my diff to the Utils.php file as compared to v4.4.4 from CiviCRM official. Could you please double check what I attempted and comment as to if the $contribution array should have been enumerated or not?

I am thankful,