4

As per the title, here's how it happens:

  1. Create a payment processor instance (i.e. add payment processor here /civicrm/admin/paymentProcessor?reset=1)
  2. Create a second one of the same type, different credentials. Leave the first one as default.

When trying to use the second payment processor on a 'backend/admin' contribution form (ie. /civicrm/contact/view/contribution?action=add&cid=etc.), we get an error at /CRM/Contribute/Form/Contribution.php, line 1165 (this is using civicrm 5.6.1, we had the same issue on 5.3.1). As far as we know this behaviour was introduced sometime shortly before 5.3.1 (that was the security update in the summer), i.e. this is new behaviour on several upgraded, existing installs.

I can see that the payment_processor_id value is getting to the server (I can see it in the submit values in the stacktrace).

To make matters a bit more confusing, we can't reproduce it reliably (but do have it reproduced on three separate sites, but not a fourth, new install), so there is some additional aspect going on here.

These tests are all using the iATS payment processor (of course ...), but I don't think that actually comes into play, since the code breaks before it can identify which payment processor is responsible for the payment.

Improve this question
4
  • Issue posted here: lab.civicrm.org/dev/core/issues/579
    – Alan Dixon
    Dec 7, 2018 at 16:27
  • I tested this on the demo site (using a dummy processor for both) and couldn't replicate... have you by chance tested switching one or both processors to dummy or some other processor type?
    – Lesley Carter - BackOffice
    Dec 8, 2018 at 17:56
  • So far, it appears the issue we were running into was specific to: 1. The presence of a iATS ACH/EFT payment processor. 2. The presence of two iATS CC payment processors. The non-default iATS CC payment processor was generating the error. It wouldn't surprise me if there are other ways to trigger the error, but the code is sufficiently opaque that it'll be hard to figure out ...
    – Alan Dixon
    Dec 11, 2018 at 16:50
  • We are also facing same issue with IATS , but disabling those will not allow to do payment form other payment processor form recent commit github.com/iATSPayments/com.iatspayments.civicrm/commit/…. I am not sure why we are removing/disabling those , but as per comment in function description For now, this form doesn't refresh when you change payment processors, so I can't use swipe if it's not the default, so i have to remove it. If we remove that code of disabling and change payment processor in select it shows related fields. can we remove t
    – Sushant
    Dec 14, 2018 at 15:11

1 Answer 1

Reset to default
2

Okay, first remind me to never exclude my iATS extension from being part of the problem ...

Karin tracked this down to the point in the (core) code where the list of available payment processors are reloaded a second time.

It occurred to me that the iATS extension interferes with this form for two reasons:

  1. in order to remove the iATS ACH/EFT processor if any,
  2. (or) to remove all but the swipe processor if it's the default

i.e., it's having to do some non-supported changes to core.

But ... it looks like the way it does this, by removing entries from various parts of the form, no longer works.

I think the best solution would be that instead of removing the payment processors from the option lists, the code will just disable them, (assuming that's possible).

And it turns out that this is easy, and you can try it out with the next iATS extension release or this commit/patch:

https://github.com/iATSPayments/com.iatspayments.civicrm/commit/2bf9dcdb1537fb75649aa6304cdab991a8a9d1eb

Improve this answer
2
  • We are also facing same issue with IATS but disabling those will not allow to do payment form other payment processor form recent commit github.com/iATSPayments/com.iatspayments.civicrm/commit/…. I am not sure why we are removing/disabling those , but as per comment in function description For now, this form doesn't refresh when you change payment processors, so I can't use swipe if it's not the default, so i have to remove it. If we remove that code of disabling and change payment processor in select it shows related fields. using CiviCRM 5.3.2
    – Sushant
    Dec 15, 2018 at 5:07
  • If you have a different issue, please post it on the iATS payments issue queue, I'm not understanding your comment here. The reason the extension needs to disable payment processors in the backend form is not part of this issue.
    – Alan Dixon
    Dec 17, 2018 at 17:25

Your Answer

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

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