3

All of my contribution pages, when tested, return you back to the page with this message at the top:

Payment Processor Error Message: 9003: MD5 Verification Failed

I have reset the MD5 code from both sides, even going so far as to delete the entire payment processor and recreate it. Whatever the issue is, it is definitely not the MD5 code.

Authorize.net says that they have no record of having been reached by our website at all, and that something must be going wrong with the call/connection.

Here are the only error codes I found in the log. They both seem to be email related, but perhaps they are related to this somehow?

    $Fatal Error Details = Array ( 
[message] => Could not connect to MailStore for postmaster@mail.makomcommunity.org<p>
Error message: <pre>An error occured while sending or receiving mail. Could not read from the stream. 
It was probably terminated by the host.</pre><p> [code] => 
) 

    $backTrace = #0 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/Error.php(322): CRM_Core_Error::backtrace("backTrace", TRUE
#1 /home/makom/www/www/sites/all/modules/civicrm/CRM/Utils/Mail/EmailProcessor.php(185): CRM_Core_Error::fatal("Could not connect to MailStore for postmaster@mail.makomcommunity.org<p>Error...")
#2 /home/makom/www/www/sites/all/modules/civicrm/CRM/Utils/Mail/EmailProcessor.php(60): CRM_Utils_Mail_EmailProcessor::_process(TRUE, Object(CRM_Core_DAO_MailSettings)) 
#3 /home/makom/www/www/sites/all/modules/civicrm/api/v3/Job.php(361): CRM_Utils_Mail_EmailProcessor::processBounces() 
#4 /home/makom/www/www/sites/all/modules/civicrm/Civi/API/Provider/MagicFunctionProvider.php(89): civicrm_api3_job_fetch_bounces((Array:1)) 
#5 /home/makom/www/www/sites/all/modules/civicrm/Civi/API/Kernel.php(96): Civi\API\Provider\MagicFunctionProvider->invoke((Array:9)) 
#6 /home/makom/www/www/sites/all/modules/civicrm/api/api.php(23): Civi\API\Kernel->run("job", "fetch_bounces", (Array:1), NULL) 
#7 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/JobManager.php(131): civicrm_api("job", "fetch_bounces", (Array:1)) 
#8 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/JobManager.php(83): CRM_Core_JobManager->executeJob(Object(CRM_Core_ScheduledJob)) 
#9 /home/makom/www/www/sites/all/modules/civicrm/bin/cron.php(42): CRM_Core_JobManager->execute() #10 {main} 

I guess my question here is this: What do you think is wrong, and how would you go about fixing it?

Update: I got the error log to cough up a related error! So as of right now, this is my issue. It is also worth noting that I am now having this error with PayPal as well, so I think it's something in the payment processor portion of civi, rather than an authorize.net issue.

Please help me decode these errors!

    $backTrace = 
#0 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/Error.php(364): CRM_Core_Error::backtrace("backTrace", TRUE)     
#1 /home/makom/www/www/sites/all/modules/civicrm/CRM/Financial/BAO/PaymentProcessor.php(188): CRM_Core_Error::fatal("Invalid value passed to getPayment function") 
#2 /home/makom/www/www/sites/all/modules/civicrm/CRM/Contribute/Form/ContributionBase.php(349): CRM_Financial_BAO_PaymentProcessor::getPayment("", "live") 
#3 /home/makom/www/www/sites/all/modules/civicrm/CRM/Contribute/Form/Contribution/Main.php(73): CRM_Contribute_Form_ContributionBase->preProcess()
#4 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/Form.php(455): CRM_Contribute_Form_Contribution_Main->preProcess() 
#5 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/QuickForm/Action/Display.php(94): CRM_Core_Form->buildForm() 
#6 /home/makom/www/www/sites/all/modules/civicrm/packages/HTML/QuickForm/Controller.php(203): CRM_Core_QuickForm_Action_Display->perform(Object(CRM_Contribute_Form_Contribution_Main), "display") 
#7 /home/makom/www/www/sites/all/modules/civicrm/packages/HTML/QuickForm/Page.php(103): HTML_QuickForm_Controller->handle(Object(CRM_Contribute_Form_Contribution_Main), "display") 
#8 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/Controller.php(353): HTML_QuickForm_Page->handle("display") 
#9 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/Invoke.php(312): CRM_Core_Controller->run((Array:3), NULL) 
#10 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/Invoke.php(86): CRM_Core_Invoke::runItem((Array:15)) 
#11 /home/makom/www/www/sites/all/modules/civicrm/CRM/Core/Invoke.php(54): CRM_Core_Invoke::_invoke((Array:3)) 
#12 /home/makom/www/www/sites/all/modules/civicrm/drupal/civicrm.module(489): CRM_Core_Invoke::invoke((Array:3))
#13 [internal function](): civicrm_invoke("contribute", "transact?reset=1&id=13")
#14 /home/makom/www/www/includes/menu.inc(527): call_user_func_array("civicrm_invoke", (Array:2)) 
#15 /home/makom/www/www/index.php(21): menu_execute_active_handler()
#16 {main}

Update 2:

This is what I see in lines 324-349. I think this means that the issue is somewhere in CRM_Utils_Array? But I"m not at all sure where to find that. There doesn't seem to be a table in the civicrm database by that name.

//FIXME: to support multiple payment processors
      if ($isMonetary &&
        (!$isPayLater || !empty($this->_values['payment_processor']))
      ) {
        $ppID = CRM_Utils_Array::value('payment_processor', $this->_values);
        if (!$ppID) {
          CRM_Core_Error::fatal(ts('A payment processor must be selected for this contribution page (contact the site administrator for assistance).'));
        }

        $ppIds = explode(CRM_Core_DAO::VALUE_SEPARATOR, $ppID);
        $this->_paymentProcessors = CRM_Financial_BAO_PaymentProcessor::getPayments($ppIds, $this->_mode);

        $this->set('paymentProcessors', $this->_paymentProcessors);

        //set default payment processor
        if (!empty($this->_paymentProcessors) && empty($this->_paymentProcessor)) {
          foreach ($this->_paymentProcessors as $ppId => $values) {
            if ($values['is_default'] == 1 || (count($this->_paymentProcessors) == 1)) {
              $defaultProcessorId = $ppId;
              break;
            }
          }
        }

        if (isset($defaultProcessorId)) {
          $this->_paymentProcessor = CRM_Financial_BAO_PaymentProcessor::getPayment($defaultProcessorId, $this->_mode);
          $this->assign_by_ref('paymentProcessor', $this->_paymentProcessor);
        }
2
+100

The stacktrace error "Invalid value passed to getPayment function" can be caused by not choosing a payment processor on the individual contribution page. Verify that the payment processor on that page(s) is checked; it should then operate correctly.

The message "Payment Processor Error Message: 9003: MD5 Verification Failed" is a separate issue. This is a message from the payment processor, not from CiviCRM. You should investigate it further with your payment processor.

5

In CRM/Contribute/Form/ContributionBase.php(349) the system is not able to determine the name of your payment processor. Please check:

  • that you at least one payment processors configured
  • that all payment configured processors have a 'name' defined and not empty
  • that at least one of your payment processors is set as 'default'
  • since the chosen payment processor depends on the mode the contribution form is used, check that you have 'test' credentials defined for at least one of your configured payment processors
  • finally, that the contribution form leading to this error has a payment processor defined in the Amounts tab

If all of this is correct, I would start debugging this by looking at lines 324 to 349 of the above file and investigating why the $defaultProcessorId variable is set to "" (rather than a numeric value) when reaching line 349.

  • Thanks. This is really helpful! I just crashed Civi trying to upgrade it, so I can't even try this. Do you do consulting? I'd love to hire you to help straighten this out, if you're open to it. naomi at socher-lerner.com – naomisl Jun 26 '16 at 15:12
  • I've restored to backup and un-crashed! Now I've checked your suggested list, and am on to looking through the file you suggested. Wish me luck! (And I'm still interested in your consulting services, definitely. This is frustrating!) – naomisl Jun 26 '16 at 15:57
  • Added those lines in the question. Do you see anything I can change? – naomisl Jun 26 '16 at 19:50
3

I had a similar issue that ultimately turned out to be a problem between the .htaccess and settings.civicrm.php files. Basically, the contribution page was https:// but the response from authorize.net was being pushed back to http://.

Not sure if this is your problem, but it's an easy thing to check.

  • Interesting! How do you check for that? – naomisl Jun 22 '16 at 21:11
2

Just an intuitive answer. I see two errors. May be they are related or one is influencing the other. May be the first inhibits or is needed for the payment process? Don't leave loose ends!

First error is a fatal error and would block further processing. I see it relates to email. I would try to solve that error first, then concentrate on the other. May be the first will solve the second or it will lead you to the solution of the second.

2

Try changing

if (isset($defaultProcessorId)) {

to

if (!empty($defaultProcessorId)) {

In those code lines above - it seems to be set but empty

1

Had this exact same error but it was specific to the test credentials - production credentials were working fine - if this is the case with you Naomi, then the issue might not be in the code at all (@twomice and @Eileen are both much more experienced than I, so if it is in the code, I will bow out to them). If production credentials ARE working, then try updating the test credentials with those of an authnet sandbox account (this is the only way testing will work). Also, just a tip, the MD5 Hash needs to be relatively short (I've used MD5 Hash generators that spit out really long strings that tend to cause issues).

Hope this helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.