Answers.Body: <p>We had the same issue in CiviCRM 4.6.4 - our configuration inside our Authorize.Net portal was incomplete and we followed the steps outlined at</p>
  
  <p><a href="http://wiki.civicrm.org/confluence/display/CRMDOC/Authorize.net+Configuration" rel="nofollow">http://wiki.civicrm.org/confluence/display/CRMDOC/Authorize.net+Configuration</a></p>
  
  <p>under Automated Recurring Billing. After putting in the correct URL for authorize.net to post to, memberships started to update.</p>
  
  <p>Another thing to note is it's obnoxious to test because authorize.net processes their ARB transactions once every 24 hours at something like 2am so you won't know right away if it's working.</p>
  
  <p>Pulled out the relevant text here:</p>
  
  <p>"CiviCRM will need to be notified of the success of recurring contributions via a Silent Post URL.  Within Authorize.net, go to Account > Settings > Silent Post URL (within the Transaction Format Settings section).  On that page, enter the URL:</p>
  
  <p>Drupal: <a href="https://yoursite.org/sites/all/modules/civicrm/extern/authorizeIPN.php" rel="nofollow">https://yoursite.org/sites/all/modules/civicrm/extern/authorizeIPN.php</a></p>
  
  <p>Joomla: <a href="https://yoursite.org/administrator/components/com_civicrm/civicrm/extern/authorizeIPN.php" rel="nofollow">https://yoursite.org/administrator/components/com_civicrm/civicrm/extern/authorizeIPN.php</a></p>
  
  <p>WordPress: <a href="https://yoursite.org/wp-content/plugins/civicrm/civicrm/extern/authorizeIPN.php" rel="nofollow">https://yoursite.org/wp-content/plugins/civicrm/civicrm/extern/authorizeIPN.php</a></p>
  
  <p><em>If you fail to do this, one-time contributions will succeed normally, and recurring contributions will be processed successfully by Authorize.net, but the contribution status will be stuck at Pending.</em>"</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-08T21:07:42.267Z
Answers.LastActivityDate: 2015-12-08T21:07:42.267Z
Answers.UserDisplayName: Eli Lisseck
Answers.Body: <p>This is really more of a comment.</p>
  
  <p>We found recently that we were not getting the payments into the memberships.  The IPNs were there but they didn't go anywhere.  There was an error being logged after messages said everything worked.  Turned out that the civicrm_line_item table had been corrupted.  When the entity was civicrm_memberhip sometimes the entity id (which should have been the membership id) was the same as the contribution id.  Once that was corrected the payments were recorded in payment tab of the member.</p>
  
  <p>The creation of the contribution record wasn't happening.  The transaction to create them was being rolled back because of the line item issue.</p>
  
  <p>Not all members were affected and the cause of the corruption is still being investigated.</p>
  
  <p>From the log:</p>
  
  <p>Oct 01 08:24:41  [info] Contribution record updated successfully</p>
  
  <p>Oct 01 08:24:43  [info] Receipt sent</p>
  
  <p>Oct 01 08:24:43  [info] Success: Database updated</p>
  
  <p>Oct 01 08:25:27  [info] $backTrace = #0 /home/fshares/public_html/sites/all/modules/civicrm/CRM/Core/Error.php(897): CRM_Core_Error::backtrace("backTrace", TRUE)
  1 internal function: CRM_Core_Error::exceptionHandler(Object(DB_Error))</p>
  
  <p>/home/fshares/public_html/sites/all/modules/civicrm/packages/PEAR.php(931): call_user_func((Array:2), Object(DB_Error))</p>
  
  <p>/home/fshares/public_html/sites/all/modules/civicrm/packages/DB.php(976): PEAR_Error->PEAR_Error("DB Error: constraint violation", -3, 16, (Array:2), "INSERT INTO civicrm_membership_payment (membership_id , contribution_id ) VAL...")</p>
  
  <p>/home/fshares/public_html/sites/all/modules/civicrm/packages/PEAR.php(564): DB_Error->DB_Error(-3, 16, (Array:2), "INSERT INTO civicrm_membership_payment (membership_id , contribution_id ) VAL...")</p>
  
  <p>/home/fshares/public_html/sites/all/modules/civicrm/packages/DB/common.php(1905): PEAR->raiseError(NULL, -3, NULL, NULL, "INSERT INTO civicrm_membership_payment (membership_id , contribution_id ) VAL...", "DB_Error", TRUE)</p>
  
  <p>/home/fshares/public_html/sites/all/modules/civicrm/packages/DB/mysql.php(899): DB_common->raiseError(-3, NULL, NULL, NULL, "1452 ** Cannot add or update a child row: a foreign key constraint fails (`fs...")</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-23T14:39:13.740Z
Answers.Text: Ellen, Have you had any luck with the corrupted table?
Answers.UserDisplayName: Tommy B
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-23T17:44:20.167Z
Answers.Text: I didn't ever figure out what caused the problem unfortunately.  It started working correctly on its own.  I did manually correct the table and also manually re-sent the IPN messages so the payments were recorded, though on the wrong date.
Answers.UserDisplayName: EHendricks
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-07T22:09:04.193Z
Answers.LastActivityDate: 2015-12-07T22:09:04.193Z
Answers.UserDisplayName: EHendricks
Body: <p>We're recently having trouble with auto-renewal memberships again. When a member's membership should renew, the members are getting charged through Authorize.net but it's not updating the membership status through Civi. Not sure what to check or how to fix this issue.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-10-12T03:43:53.417Z
Comments.Text: What version are you on? I have been seeing a few different issues on Authorize.net which appear to be due to the silent posts all coming in concurrently - but the memberships HAVE been renewing - on the latest 4.6.9 anyway
Comments.UserDisplayName: eileen
Tags: <civimember><authorize.net>
Title: How do I fix auto-renewal memberships? (Auth.net)
ThreadText: # How do I fix auto-renewal memberships? (Auth.net)
  
  (Asked by: username_0 on 2015-10-09)
  
  We're recently having trouble with auto-renewal memberships again. When a member's membership should renew, the members are getting charged through Authorize.net but it's not updating the membership status through Civi. Not sure what to check or how to fix this issue.
  
  **Tags:** civimember, authorize.net
  
  > **Comments:**
  > **username_1**: What version are you on? I have been seeing a few different issues on Authorize.net which appear to be due to the silent posts all coming in concurrently - but the memberships HAVE been renewing - on the latest 4.6.9 anyway  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-12-08. Score: 2
  
  We had the same issue in CiviCRM 4.6.4 - our configuration inside our Authorize.Net portal was incomplete and we followed the steps outlined at
  
  <http://wiki.civicrm.org/confluence/display/CRMDOC/Authorize.net+Configuration>
  
  under Automated Recurring Billing. After putting in the correct URL for authorize.net to post to, memberships started to update.
  
  Another thing to note is it's obnoxious to test because authorize.net processes their ARB transactions once every 24 hours at something like 2am so you won't know right away if it's working.
  
  Pulled out the relevant text here:
  
  "CiviCRM will need to be notified of the success of recurring contributions via a Silent Post URL. Within Authorize.net, go to Account > Settings > Silent Post URL (within the Transaction Format Settings section). On that page, enter the URL:
  
  Drupal: <https://yoursite.org/sites/all/modules/civicrm/extern/authorizeIPN.php>
  
  Joomla: <https://yoursite.org/administrator/components/com_civicrm/civicrm/extern/authorizeIPN.php>
  
  WordPress: <https://yoursite.org/wp-content/plugins/civicrm/civicrm/extern/authorizeIPN.php>
  
  *If you fail to do this, one-time contributions will succeed normally, and recurring contributions will be processed successfully by Authorize.net, but the contribution status will be stuck at Pending.*"
  
  
  ---
  
  ### Answer by username_3 on 2015-12-07. Score: 0
  
  This is really more of a comment.
  
  We found recently that we were not getting the payments into the memberships. The IPNs were there but they didn't go anywhere. There was an error being logged after messages said everything worked. Turned out that the civicrm\_line\_item table had been corrupted. When the entity was civicrm\_memberhip sometimes the entity id (which should have been the membership id) was the same as the contribution id. Once that was corrected the payments were recorded in payment tab of the member.
  
  The creation of the contribution record wasn't happening. The transaction to create them was being rolled back because of the line item issue.
  
  Not all members were affected and the cause of the corruption is still being investigated.
  
  From the log:
  
  Oct 01 08:24:41 [info] Contribution record updated successfully
  
  Oct 01 08:24:43 [info] Receipt sent
  
  Oct 01 08:24:43 [info] Success: Database updated
  
  Oct 01 08:25:27 [info] $backTrace = #0 /home/fshares/public\_html/sites/all/modules/civicrm/CRM/Core/Error.php(897): CRM\_Core\_Error::backtrace("backTrace", TRUE)
  1 internal function: CRM\_Core\_Error::exceptionHandler(Object(DB\_Error))
  
  /home/fshares/public\_html/sites/all/modules/civicrm/packages/PEAR.php(931): call\_user\_func((Array:2), Object(DB\_Error))
  
  /home/fshares/public\_html/sites/all/modules/civicrm/packages/DB.php(976): PEAR\_Error->PEAR\_Error("DB Error: constraint violation", -3, 16, (Array:2), "INSERT INTO civicrm\_membership\_payment (membership\_id , contribution\_id ) VAL...")
  
  /home/fshares/public\_html/sites/all/modules/civicrm/packages/PEAR.php(564): DB\_Error->DB\_Error(-3, 16, (Array:2), "INSERT INTO civicrm\_membership\_payment (membership\_id , contribution\_id ) VAL...")
  
  /home/fshares/public\_html/sites/all/modules/civicrm/packages/DB/common.php(1905): PEAR->raiseError(NULL, -3, NULL, NULL, "INSERT INTO civicrm\_membership\_payment (membership\_id , contribution\_id ) VAL...", "DB\_Error", TRUE)
  
  /home/fshares/public\_html/sites/all/modules/civicrm/packages/DB/mysql.php(899): DB\_common->raiseError(-3, NULL, NULL, NULL, "1452 \*\* Cannot add or update a child row: a foreign key constraint fails (`fs...")
  
  > **Comments:**
  > **username_4**: Ellen, Have you had any luck with the corrupted table?  
  > **username_3**: I didn't ever figure out what caused the problem unfortunately.  It started working correctly on its own.  I did manually correct the table and also manually re-sent the IPN messages so the payments were recorded, though on the wrong date.  
  
  ---
  
  