0

we are now trying to test the membership signups which includes recurring payments. I've gone through all the steps on the contribution pages and have not seen any errors there (except that no thank you email was sent, but this may be a separate issue from this one)

However once I go to "Memberships" -> "Find Memberships", choosing "Yes" for "Membership is a test", and clicking on "Search" I get this error:

Sorry but we are not able to provide this at the moment. Expected one PaymentProcessor but found 0

enter image description here

Output from /sites/default/files/civicrm/ConfigAndLog:

Mar 02 18:51:27  [info] $backTrace = #0 /home/peoplesfund/www/www/sites/all/modules/civicrm/CRM/Core/Error.php(451): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 /home/peoplesfund/www/www/sites/all/modules/civicrm/CRM/Core/Invoke.php(55): CRM_Core_Error::handleUnhandledException(Object(CiviCRM_API3_Exception))
#2 /home/peoplesfund/www/www/sites/all/modules/civicrm/drupal/civicrm.module(448): CRM_Core_Invoke::invoke((Array:3))
#3 [internal function](): civicrm_invoke("member", "search")
#4 /home/peoplesfund/www/www/includes/menu.inc(527): call_user_func_array("civicrm_invoke", (Array:2))
#5 /home/peoplesfund/www/www/index.php(21): menu_execute_active_handler()
#6 {main}

(Entire output is not shown because a huge code mass is printed. I can provide this if needed though in a file)

I've also tried enabling debugging but the same error screen is shown

There is no problem when searching if we have chosen "No" for "Membership is a test", this will (instead of the error message) produce a list of real members that we have

Does anyone know what we can do to solve this problem? Is it likely that this will cause problems for the live contribution pages in the future (even if that is not the case right now?)

Grateful for help and with kind regards, Tord

1

I always look for ways to TEST in LIVE mode - because the is_test pathway in CiviCRM is not what you want to test - you want your tests to be as close to your is_live as possible.

Create a new payment processor "iATS - TEST88" or "Authorize - TEST" and put the test credentials into the "live" section. Then run real live tests.

Only downside is you'll have some clean up to do as people have purchased real Memberships and have credit real Contributions and real Recurring Series with fake credit cards - but the huge upside is that if you get things working - you'll know for sure it will work when you plug in your own Store credentials and processing URL into your Payment Processor's config.

Here's an example for test credentials under Live section for Authorize.net:

enter image description here

0

I think I had this problem when there was an erroneous test payment processor set up. I fixed it by removing this payment processor from the civicrm_payment_processor table. Every entry should be duplicated - one with is_test = 1, and one with is_test = 0. You could try removing any entries where only one of these exists.

  • Thank you for taking time to help out, i appreciate it. I've looked at our db using phpMyAdmin and can see that we have two payment processors (paypal standard and paypal express) and for these there are one row with is_test = 0 and anohter with is_test=1, so a total of four rows. I think though that there may have been a problem with the setup because previously we were experimenting with using Stripe, so maybe some left-over settings from the Stripe plugin is causing our problem – sunyata Mar 3 '17 at 17:42
  • Update: Thank you for putting me on the right track, we have now removed one of the payment processors (which we no longer use) and the problem went away completely! Strange though since we didn't use that payment processor (PayPal Express), neither for the tests we were running or for anything else – sunyata Mar 13 '17 at 17:23

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.