Unable to make backend contributions with non-default payment processor (sometimes) "no class provided" error

Question

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.

Answer 1

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