Using CiviCRM 5.7.6 w/ Drupal, I'm getting an issue with my backoffice contribution forms. Specifically, even though the configuration says not to require CVV, and the form itself does not have a (*) to indicate it's required, I'm still getting an error if I submit the form without a CVV, and the error tells me that I require the CVV.

When I look at the code, the key seems to this piece of code, around line 278 in CRM/Core/Payment/Form.php:

  public static function validatePaymentInstrument($payment_processor_id, $values, &$errors, $billing_profile_id) {
$payment = Civi\Payment\System::singleton()->getById($payment_processor_id);
$payment->validatePaymentInstrument($values, $errors);


Specifically, the validatePaymentInstrument call of the payment object triggers the error because the payment object itself doesn't have the isBackOffice property set. It's not clear to me why it should have that isBackOffice property set unless that object had been created earlier in the code flow and the backoffice property set there.

It also seems to me that this form is the backoffice form, so we could put in a setBackOffice call just before the validate call, but I'm curious why this code seems to have worked in the past.

I'll note also that the error is relatively recent, and it's not clear to me whether it might be code version and/or php version dependent.

enter image description here

  • There were JIRA issues way back about this but expect you have found them eg issues.civicrm.org/jira/browse/CRM-20166, issues.civicrm.org/jira/browse/CRM-10366, github.com/civicrm/civicrm-core/pull/11205
    – petednz - fuzion
    May 23, 2019 at 0:56
  • Yes, it's not clear to me if those are related or not - the code included in those issues seems correct and not a cause of what I'm experiencing, which I suspect is a bit subtle.
    – Alan Dixon
    May 23, 2019 at 15:51
  • We have exactly the same issue, and I'd got pretty much exactly as far as you in debugging it. It kicked in for us sometime in early May, and doesn't seem to be related to an upgrade or a PHP version. We're on WordPress and Civi 5.11. I'll report back when I have a change to dig into it some more. May 23, 2019 at 16:41
  • Thanks Andrew, that makes me happy! FWIW, I was still able to reproduce the bug after switching my php back to 7.0.
    – Alan Dixon
    May 23, 2019 at 19:06

1 Answer 1


This isn't a full answer, but we (Karin actually) discovered that by removing the redis caching configuration from the civicrm settings file, the problem went away.

This is a bit weird, since the problem I was looking at was the static code cache, but it sort of makes sense if the api call that pulls in the payment object could potentially be reading from the more permanent (usually mysql table) cache.

So, my best guess to this issue is that there is some code somewhere that is accessing the CiviCRM cache without using or knowing about the use of Redis.

On it's own, this just means we can't use the Redis cache for CiviCRM, but it suggests that there might be a bigger problem hiding in here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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