Answers.Body: <p>I found the problem.  The permissions were not set correctly for recurring contributions on authorizeIPN.php. So when the silent post was running it was getting a 404. I did not see this in the log. For others out there make sure authorizeIPN.php is retrievable.  </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-25T22:14:32.897Z
Answers.Text: Mind sharing what "correct" is?  How about the URL you used to verify this?  (Edit, so we can add points to this answer!)
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-27T19:40:08.910Z
Answers.Text: In my case it was the user for the file. The file was owned by root but needed to be owned by the user. It is just a matter of remembering to do things as the user in the server rather than as root. It could also be a permissions issue for you.
Answers.UserDisplayName: Josh
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-01T21:35:24.057Z
Answers.Text: So, you have an ownership by the web user.  Does that user have write privileges on the file?  I've got the file owned by root, but group owner is the web user.  The owner has rw rights, but group just has r.  I'm getting 404 256 status errors in the web logs.  Giving write privileges on that file feels wrong.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-02T18:09:20.677Z
Answers.Text: Nevermind.  Finally found an error with the Silent Post URL.   To test for 404 errors, just visit the Silent Post URL and you should see a transaction failure message, rather than a 404.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-05T16:56:42.923Z
Answers.LastActivityDate: 2016-02-05T16:56:42.923Z
Answers.UserDisplayName: Josh
Body: <p>I have several recurring contributions for a CiviCRM 4.6.10 site.  These contributions were made through CiviCRM and into Authorize.net.  They worked multiple times in 2015 but none of the transactions have been recorded in CiviCRM in 2016. We have verified our record with Authorize.net and all of these transactions have been successful.  </p>
  
  <p>Thanks in advance.  </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-28T16:11:58.220Z
Comments.Text: Josh - you did not mention your version of Civi, but in general, I would start by checking your Civi log on the days when those contributions should have posted.  Are any errors recorded?  Also, check the recurring contribution records themselves - have their statuses changed to canceled or failed, for example?  Does the transaction information on the recurring contribution record match what is on the recurring billing record in Authorize?  Finally, have you confirmed that the Silent Post URL recorded in Authorize still is correct?
Comments.UserDisplayName: Lesley Carter - BackOffice
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-29T04:33:00.800Z
Comments.Text: We are using CiviCRM 4.6.10.  I checked with Authorize.net and we are using the correct URL. The failed donations say _in progress_ and checked the database and that matches the status in the database. -- I also checked and I do not see any errors related to this in the logs.
Comments.UserDisplayName: Josh
Tags: <civicontribute><recurring-contributions><authorize.net>
Title: Recurring Contributions Stopped in 2016
ThreadText: # Recurring Contributions Stopped in 2016
  
  (Asked by: username_0 on 2016-01-27)
  
  I have several recurring contributions for a CiviCRM 4.6.10 site. These contributions were made through CiviCRM and into Authorize.net. They worked multiple times in 2015 but none of the transactions have been recorded in CiviCRM in 2016. We have verified our record with Authorize.net and all of these transactions have been successful.
  
  Thanks in advance.
  
  **Tags:** civicontribute, recurring-contributions, authorize.net
  
  > **Comments:**
  > **username_1**: username_0 - you did not mention your version of Civi, but in general, I would start by checking your Civi log on the days when those contributions should have posted.  Are any errors recorded?  Also, check the recurring contribution records themselves - have their statuses changed to canceled or failed, for example?  Does the transaction information on the recurring contribution record match what is on the recurring billing record in Authorize?  Finally, have you confirmed that the Silent Post URL recorded in Authorize still is correct?  
  > **username_0**: We are using CiviCRM 4.6.10.  I checked with Authorize.net and we are using the correct URL. The failed donations say _in progress_ and checked the database and that matches the status in the database. -- I also checked and I do not see any errors related to this in the logs.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2016-02-05. Score: 2
  
  I found the problem. The permissions were not set correctly for recurring contributions on authorizeIPN.php. So when the silent post was running it was getting a 404. I did not see this in the log. For others out there make sure authorizeIPN.php is retrievable.
  
  > **Comments:**
  > **username_2**: Mind sharing what "correct" is?  How about the URL you used to verify this?  (Edit, so we can add points to this answer!)  
  > **username_0**: In my case it was the user for the file. The file was owned by root but needed to be owned by the user. It is just a matter of remembering to do things as the user in the server rather than as root. It could also be a permissions issue for you.  
  > **username_2**: So, you have an ownership by the web user.  Does that user have write privileges on the file?  I've got the file owned by root, but group owner is the web user.  The owner has rw rights, but group just has r.  I'm getting 404 256 status errors in the web logs.  Giving write privileges on that file feels wrong.  
  > **username_2**: Nevermind.  Finally found an error with the Silent Post URL.   To test for 404 errors, just visit the Silent Post URL and you should see a transaction failure message, rather than a 404.  
  
  ---
  
  