Answers.Body: <p>Okay, first remind me to never exclude my iATS extension from being part of the problem ...</p>
  
  <p>Karin tracked this down to the point in the (core) code where the list of available payment processors are reloaded a second time.</p>
  
  <p>It occurred to me that the iATS extension interferes with this form for two reasons:</p>
  
  <ol>
  <li>in order to remove the iATS ACH/EFT processor if any, </li>
  <li>(or) to remove all but the swipe processor if it's the default</li>
  </ol>
  
  <p>i.e., it's having to do some non-supported changes to core.</p>
  
  <p>But ... it looks like the way it does this, by removing entries from various parts of the form, no longer works.</p>
  
  <p>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).</p>
  
  <p>And it turns out that this is easy, and you can try it out with the next iATS extension release or this commit/patch:</p>
  
  <p><a href="https://github.com/iATSPayments/com.iatspayments.civicrm/commit/2bf9dcdb1537fb75649aa6304cdab991a8a9d1eb" rel="nofollow noreferrer">https://github.com/iATSPayments/com.iatspayments.civicrm/commit/2bf9dcdb1537fb75649aa6304cdab991a8a9d1eb</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-15T05:07:07.163Z
Answers.Text: We are also facing same issue with IATS but disabling those will not allow to do payment form other payment processor form recent commit https://github.com/iATSPayments/com.iatspayments.civicrm/commit/2bf9dcdb1537fb75649aa6304cdab991a8a9d1eb. 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
Answers.UserDisplayName: Sushant
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-17T17:25:51.900Z
Answers.Text: 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.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-12-11T16:49:44.580Z
Answers.LastActivityDate: 2018-12-13T19:03:41.473Z
Answers.LastEditDate: 2018-12-13T19:03:41.473Z
Answers.UserDisplayName: Alan Dixon
Body: <p>As per the title, here's how it happens:</p>
  
  <ol>
  <li>Create a payment processor instance (i.e. add payment processor here
  /civicrm/admin/paymentProcessor?reset=1)</li>
  <li>Create a second one of the same type, different credentials. Leave the first one as default.</li>
  </ol>
  
  <p>When trying to use the second payment processor on a 'backend/admin' contribution form (ie. /civicrm/contact/view/contribution?action=add&amp;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.</p>
  
  <p>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).</p>
  
  <p>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. </p>
  
  <p>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.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-12-07T16:27:56.447Z
Comments.Text: Issue posted here: https://lab.civicrm.org/dev/core/issues/579
Comments.UserDisplayName: Alan Dixon
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-12-08T17:56:59.447Z
Comments.Text: 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?
Comments.UserDisplayName: Lesley Carter - BackOffice
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-12-11T16:50:23.367Z
Comments.Text: 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 ...
Comments.UserDisplayName: Alan Dixon
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-12-14T15:11:58.613Z
Comments.Text: We are also facing same issue with IATS , but disabling those will not allow to do payment form other payment processor form recent commit https://github.com/iATSPayments/com.iatspayments.civicrm/commit/2bf9dcdb1537fb75649aa6304cdab991a8a9d1eb. 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
Comments.UserDisplayName: Sushant
Tags: <civicontribute><payment-processor><admin>
Title: Unable to make backend contributions with non-default payment processor (sometimes) "no class provided" error
ThreadText: # Unable to make backend contributions with non-default payment processor (sometimes) "no class provided" error
  
  (Asked by: username_0 on 2018-12-07)
  
  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.
  
  **Tags:** civicontribute, payment-processor, admin
  
  > **Comments:**
  > **username_0**: Issue posted here: https://lab.civicrm.org/dev/core/issues/579  
  > **username_1**: 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?  
  > **username_0**: 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 ...  
  > **username_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 https://github.com/iATSPayments/com.iatspayments.civicrm/commit/2bf9dcdb1537fb75649aa6304cdab991a8a9d1eb. 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  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2018-12-11. Score: 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>
  
  > **Comments:**
  > **username_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 https://github.com/iATSPayments/com.iatspayments.civicrm/commit/2bf9dcdb1537fb75649aa6304cdab991a8a9d1eb. 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  
  > **username_0**: 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.  
  
  ---
  
  