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.

  • 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
    – eileen
    Oct 12, 2015 at 3:43

2 Answers 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


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."


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

  • Ellen, Have you had any luck with the corrupted table?
    – Tommy B
    Feb 23, 2016 at 14:39
  • 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.
    – EHendricks
    Feb 23, 2016 at 17:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.