Error message when testing memberships: "Expected one PaymentProcessor but found 0"

Question

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

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

Answer 1

I had the same error. It appeared that we had removed a payment processor that we had used before, but don’t use any more (never do that. Just disable the payment processor).

When searching for memberships, also attached payments are displayed. Some of these payments het the removed payment processor. The was causing the error.

We restored the payment processor. In the database we changed the ID’s of the live and the test payment processor to the original ID’s. That solved the issue.

Answer 2

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.

Answer 3

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: