Answers.Body: <p>Solved.  During our migration from Drupal to Wordpress, both with Civi databases, there were a few days when the Drupal server was still live and 5 recurring donations were added.  On the new Wordpress site, the first 5 new recurring contributions used the same primary key in the civicrm_contribution_recur table. This didn't cause the new recurring transaction to fail on the AuthorizeNet side.  But we now had two sets of 5 users sharing a recur_id in the AuthorizeNet account.</p>
  <p>I copied the 5 Civi records (from both contribution and contribution_recur tables) from Civi on the Drupal side to the Wordpress Civi database starting at the next available primary key value.  So I effectively left 5 new Civi users overloading the original recur_id of the five old contributions that were new in new positions in the table.  I failed to realize that this did not consider how the AuthorizeNet future transactions were going to notify Civi when the next recurring transaction occurs.  So when AuthorizeNet sent a notification back to Civi for the new Wordpress user donation, it somehow mapped the transaction info sent through the API to an older contribution from a different user and it wasn't even recurring.</p>
  <p>But Civi happily created a new record in civicrm_contribution for that legacy user's name and sent a receipt to his email which indicated that he was charged again for a recurring transaction that he never created.  It belonged to the new user who unknowingly created a recurring transaction with the same recur_id as a contribution_recur record on the old site.  He was not actually charged.  On the payment gateway, the recurring transaction was charged to the user who created it on the new Wordpress site.  But the circuits got crossed when the API notification went to Civi and someone else got the receipt.  This continued for several months until we identified the issue.  Fortunately, there were no actual charges to the people who mistakenly received receipts and this only affected 5 users.</p>
  <p>For anyone reading this who's planning a migration, the lesson learned was make sure you disable contributions on the old site (put it in maintenance mode and disable the payment gateway) right before you bring up the new site with the migrated Civi database.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-06-20T10:22:17.220Z
Answers.LastActivityDate: 2024-06-20T10:22:17.220Z
Answers.UserDisplayName: NormK
Body: <p>We have around 50 people set up with a monthly recurring contribution to our non-profit.  Lately, when the next payment date is reached, CiviCRM creates a record in civicrm_contribution table with a different contact_id than the one associated with the record in civicrm_contribution_recur table.  The payment still gets charged to the user in the civicrm_contribution_recur table based on the payment_method that they originally set up.  But the (wrong) user in the new civicrm_contribution record gets sent the receipt.</p>
  <p>If there is data corruption, I can't figure out where in the schema to find the table &amp; column that CiviContribute module is using to select the contact_id that gets used in the new contribution record.  If you know the tables associated with the recurring contribution logic, can you point me in the right direction?</p>
  <p>Thanks!!</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-06-16T03:40:31.133Z
Comments.Text: The payment processor might be relevant info, e.g. paypal, stripe, other? Also version info.
Comments.UserDisplayName: Demerit
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-06-17T07:52:33.420Z
Comments.Text: @Demerit.  Thanks for the tip.  Our processor is AuthorizeNet with Credit Card Type.  Can you tell me the order of operations of when the recurring payment is charged to the processor and when the new Contribution record is created in the database?  Assuming AuthorizeNet automatically charges the card each month before the record is created in Civi, then are you suggesting that the contact_id sent back to Civi on our server, via the CiviCRM API might be different than the contact_id in the original civicrim_contribution_recur record?
Comments.UserDisplayName: NormK
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-06-17T12:40:53.480Z
Comments.Text: No by version I meant version of civi/authnet. I believe the order is https://lab.civicrm.org/extensions/authnet/-/blob/a5bc85cb43eb665e002dfdeeedbd8d4b93b52587/CRM/Core/Payment/AuthNetIPN.php#L309 then https://lab.civicrm.org/extensions/mjwshared/-/blob/4f07025a9892e416df7864f1cc663675d12fee0f/CRM/Core/Payment/MJWIPNTrait.php#L347 then https://github.com/civicrm/civicrm-core/blob/594e7ecebf936683ab995072c97a0d979927791b/api/v3/Contribution.php#L672. You could try to debug what params it ends up using.
Comments.UserDisplayName: Demerit
Tags: <civicontribute><recurring-contributions>
Title: Recurring CiviContribution generating new contributions assigned to the wrong contact
ThreadText: # Recurring CiviContribution generating new contributions assigned to the wrong contact
  
  (Asked by: username_0 on 2024-06-16)
  
  We have around 50 people set up with a monthly recurring contribution to our non-profit. Lately, when the next payment date is reached, CiviCRM creates a record in civicrm\_contribution table with a different contact\_id than the one associated with the record in civicrm\_contribution\_recur table. The payment still gets charged to the user in the civicrm\_contribution\_recur table based on the payment\_method that they originally set up. But the (wrong) user in the new civicrm\_contribution record gets sent the receipt.
  
  If there is data corruption, I can't figure out where in the schema to find the table & column that CiviContribute module is using to select the contact\_id that gets used in the new contribution record. If you know the tables associated with the recurring contribution logic, can you point me in the right direction?
  
  Thanks!!
  
  **Tags:** civicontribute, recurring-contributions
  
  > **Comments:**
  > **username_1**: The payment processor might be relevant info, e.g. paypal, stripe, other? Also version info.  
  > **username_0**: @username_1.  Thanks for the tip.  Our processor is AuthorizeNet with Credit Card Type.  Can you tell me the order of operations of when the recurring payment is charged to the processor and when the new Contribution record is created in the database?  Assuming AuthorizeNet automatically charges the card each month before the record is created in Civi, then are you suggesting that the contact_id sent back to Civi on our server, via the CiviCRM API might be different than the contact_id in the original civicrim_contribution_recur record?  
  > **username_1**: No by version I meant version of civi/authnet. I believe the order is https://lab.civicrm.org/extensions/authnet/-/blob/a5bc85cb43eb665e002dfdeeedbd8d4b93b52587/CRM/Core/Payment/AuthNetIPN.php#L309 then https://lab.civicrm.org/extensions/mjwshared/-/blob/4f07025a9892e416df7864f1cc663675d12fee0f/CRM/Core/Payment/MJWIPNTrait.php#L347 then https://github.com/civicrm/civicrm-core/blob/594e7ecebf936683ab995072c97a0d979927791b/api/v3/Contribution.php#L672. You could try to debug what params it ends up using.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2024-06-20. Score: 2
  
  Solved. During our migration from Drupal to Wordpress, both with Civi databases, there were a few days when the Drupal server was still live and 5 recurring donations were added. On the new Wordpress site, the first 5 new recurring contributions used the same primary key in the civicrm\_contribution\_recur table. This didn't cause the new recurring transaction to fail on the AuthorizeNet side. But we now had two sets of 5 users sharing a recur\_id in the AuthorizeNet account.
  
  I copied the 5 Civi records (from both contribution and contribution\_recur tables) from Civi on the Drupal side to the Wordpress Civi database starting at the next available primary key value. So I effectively left 5 new Civi users overloading the original recur\_id of the five old contributions that were new in new positions in the table. I failed to realize that this did not consider how the AuthorizeNet future transactions were going to notify Civi when the next recurring transaction occurs. So when AuthorizeNet sent a notification back to Civi for the new Wordpress user donation, it somehow mapped the transaction info sent through the API to an older contribution from a different user and it wasn't even recurring.
  
  But Civi happily created a new record in civicrm\_contribution for that legacy user's name and sent a receipt to his email which indicated that he was charged again for a recurring transaction that he never created. It belonged to the new user who unknowingly created a recurring transaction with the same recur\_id as a contribution\_recur record on the old site. He was not actually charged. On the payment gateway, the recurring transaction was charged to the user who created it on the new Wordpress site. But the circuits got crossed when the API notification went to Civi and someone else got the receipt. This continued for several months until we identified the issue. Fortunately, there were no actual charges to the people who mistakenly received receipts and this only affected 5 users.
  
  For anyone reading this who's planning a migration, the lesson learned was make sure you disable contributions on the old site (put it in maintenance mode and disable the payment gateway) right before you bring up the new site with the migrated Civi database.
  
  
  ---
  
  