How do I fix auto-renewal memberships? (Auth.net)

Question

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.

Answer 1

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 2

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