Body: <p>I've got an interesting puzzle on my hands. </p>
  
  <p>A client's site (CiviCRM 4.7.x; Drupal 7.x) has stopped recording some recurring transactions. </p>
  
  <p>The transactions show as settled successfully in AuthorizeNet but it seems that when AuthorizeNet sends that info back to civi, it's hitting an error. </p>
  
  <p>This only happens with a small subset of recurring donations, the one thing they all share in common is that the donor, after making the initial donation, decided to change how much they want to give monthly. </p>
  
  <p>If I look in Authorizenet, I see that in one case the initial payment was made for $20, then it was changed to $25. All payments have the right invoice id; contact id; and everything else necessary for civi to match them up correctly. </p>
  
  <p>SELECT c.id, c.receive_date, c.financial_type_id, r.amount, c.total_amount FROM civicrm_contribution c RIGHT JOIN civicrm_contribution_recur r on r.id = c.contribution_recur_id where r.amount != c.total_amount;</p>
  
  <p>shows all the records having this problem. </p>
  
  <p>In those cases, I believe because the Amount in the expected recurrence is not the same as the amount in the data from Authorizenet they are not getting recorded. </p>
  
  <p>Does anyone have any ideas for:</p>
  
  <p>1: how to edit the existing data (either in the UI, or via SQL or the civi API) so it will work moving forward?</p>
  
  <p>2: where I might start digging to find where this is happening and how I might fix it? </p>
  
  <p>Thanks </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-06T23:54:21.857Z
Comments.Text: I found where this is happening, as I thought it's a number mismatch. 
  
  line 121 of AuthorizeNetIPN.php 
  
  `    // At this point $object has first contribution loaded.
      // Lets do a check to make sure this payment has the amount same as that of first contribution.
      if ($objects['contribution']->total_amount != $input['amount']) {
        CRM_Core_Error::debug_log_message("Subscription amount mismatch.");
        echo "Failure: Subscription amount mismatch<p>";
        return FALSE;
      }`
  
  adding in a way of allowing this seems simple but the big question is **is it a stupid idea**
Comments.UserDisplayName: ericG
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-07T00:47:13.713Z
Comments.Text: [`CRM/Core/Payment/AuthorizeNetIPN.php`](https://github.com/civicrm/civicrm-core/blob/c7dd4aed68b60ea3133cb4461b9ff9abf287fdff/CRM/Core/Payment/AuthorizeNetIPN.php#L121) for easy reading :)
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-07T04:53:09.797Z
Comments.Text: thanks Chris. Still getting the hang of how stack exchange works/formats comments
Comments.UserDisplayName: ericG
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-08T05:51:56.017Z
Comments.Text: No problem! Looks like that code has been around a long time! Generally I think the plan is to get processors out of core.
Comments.UserDisplayName: Chris Burgess
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-11-28T21:11:17.000Z
Comments.Text: I opened a JIRA issue and will submit a patch for review to see "is it a stupid idea" :) https://issues.civicrm.org/jira/browse/CRM-21492
Comments.UserDisplayName: Jon G - Megaphone Tech
Tags: <recurring-contributions><authorize.net>
Title: changing amount of CiviCRM recurring payments with AuthorizeNet breaks Civi's recording of the transactions after the amount change
ThreadText: # changing amount of CiviCRM recurring payments with AuthorizeNet breaks Civi's recording of the transactions after the amount change
  
  (Asked by: username_0 on 2017-11-06)
  
  I've got an interesting puzzle on my hands.
  
  A client's site (CiviCRM 4.7.x; Drupal 7.x) has stopped recording some recurring transactions.
  
  The transactions show as settled successfully in AuthorizeNet but it seems that when AuthorizeNet sends that info back to civi, it's hitting an error.
  
  This only happens with a small subset of recurring donations, the one thing they all share in common is that the donor, after making the initial donation, decided to change how much they want to give monthly.
  
  If I look in Authorizenet, I see that in one case the initial payment was made for $20, then it was changed to $25. All payments have the right invoice id; contact id; and everything else necessary for civi to match them up correctly.
  
  SELECT c.id, c.receive\_date, c.financial\_type\_id, r.amount, c.total\_amount FROM civicrm\_contribution c RIGHT JOIN civicrm\_contribution\_recur r on r.id = c.contribution\_recur\_id where r.amount != c.total\_amount;
  
  shows all the records having this problem.
  
  In those cases, I believe because the Amount in the expected recurrence is not the same as the amount in the data from Authorizenet they are not getting recorded.
  
  Does anyone have any ideas for:
  
  1: how to edit the existing data (either in the UI, or via SQL or the civi API) so it will work moving forward?
  
  2: where I might start digging to find where this is happening and how I might fix it?
  
  Thanks
  
  **Tags:** recurring-contributions, authorize.net
  
  > **Comments:**
  > **username_0**: I found where this is happening, as I thought it's a number mismatch.   line 121 of AuthorizeNetIPN.php   `    // At this point $object has first contribution loaded.     // Lets do a check to make sure this payment has the amount same as that of first contribution.     if ($objects['contribution']->total_amount != $input['amount']) {       CRM_Core_Error::debug_log_message("Subscription amount mismatch.");       echo "Failure: Subscription amount mismatch<p>";       return FALSE;     }`  adding in a way of allowing this seems simple but the big question is **is it a stupid idea**  
  > **username_1**: [`CRM/Core/Payment/AuthorizeNetIPN.php`](https://github.com/civicrm/civicrm-core/blob/c7dd4aed68b60ea3133cb4461b9ff9abf287fdff/CRM/Core/Payment/AuthorizeNetIPN.php#L121) for easy reading :)  
  > **username_0**: thanks username_1. Still getting the hang of how stack exchange works/formats comments  
  > **username_1**: No problem! Looks like that code has been around a long time! Generally I think the plan is to get processors out of core.  
  > **username_2**: I opened a JIRA issue and will submit a patch for review to see "is it a stupid idea" :) https://issues.civicrm.org/jira/browse/CRM-21492  
  
  ---
  
  ## 0 answers
  
  