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), 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.