Unable to make backend contributions with non-default payment processor (sometimes) "no class provided" error
This isn't a full error report, but we've been chasing it down long enough I wanted to get something in here.
As per the title, here's how it happens:
- Create a payment processor instance (i.e. add payment processor here /civicrm/admin/paymentProcessor?reset=1)
- 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), and I suspect it might be related to this commit: https://github.com/civicrm/civicrm-core/commit/8461467c33a8e35f67b1d9938cdbc3d5ba5fd4b9 The commit in general is good, but the code it's touching is sufficiently scary that lots of hidden things might happen. Or maybe that's unrelated ...
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), 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.
Clues welcome ...