Answers.Body: <p>We have a little trick for this situation.</p>
  
  <p>This extension</p>
  
  <p><a href="https://github.com/eileenmcnaughton/nz.co.fuzion.notificationlog" rel="nofollow">https://github.com/eileenmcnaughton/nz.co.fuzion.notificationlog</a></p>
  
  <p>allows you to replay processing IPNS from the system log - e.g after installing try</p>
  
  <p>drush cvapi NotificationLog.retry system_log_id=xxx</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-09T15:07:30.440Z
Answers.Text: Array
  (
      [error_code] => 0
      [entity] => NotificationLog
      [action] => retry
      [is_error] => 1
      [error_message] => unsupported processor
  )
Answers.UserDisplayName: jakew
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-09T15:17:01.607Z
Answers.Text: Wait - does the unsupported processor error mean that this version of the extension just does not support paypal? http://civicrm.stackexchange.com/questions/4458/what-should-drush-cvapi-notificationlog-retry-sequential-1-system-log-id-xxx-do
Answers.UserDisplayName: jakew
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-09T15:24:23.953Z
Answers.Text: Looked at the extension code.. apparently it only supports PayPal Pro and Authorize. For PayPal it's looking for log message "payment_notification processor_name=PayPal"; the ones I have are called "payment_notification PayPal_Standard"..
Answers.UserDisplayName: jakew
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-09T18:06:15.560Z
Answers.Text: Update: It's a 500 error. I duplicated it using poster. It seems that some of the parameters supplied by Paypal cause the server to return a 500 error. Ugh..
Answers.UserDisplayName: jakew
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T19:51:20.330Z
Answers.LastActivityDate: 2015-11-04T19:51:20.330Z
Answers.UserDisplayName: eileen
Answers.Body: <p>a 302 redirect doesn't redirect the POST data, which is what I suspect your issue is.</p>
  
  <p>The best solution is to use an IPN URL that doesn't need redirection.  If that's not an option, <a href="https://civicrm.stackexchange.com/a/4326/12">see here</a> for how to use a 307 redirect (which maintains the POST data) and see if that solves your problem.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T19:07:09.773Z
Answers.Text: I'm not using redirects at all - this is stock civi paypal standard processor, and the ipn url is sites/all/modules/civicrm/extern/ipn.php - an actual file on the server.
Answers.UserDisplayName: jakew
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T20:10:13.100Z
Answers.Text: Check the URL and protocol that PayPal is hitting - if your CiviCRM or webserver is configured to use a given URL (`https://example.org`) and PayPal is hitting a URL that doesn't match (`http://www.example.org`) then you might see redirects happen. Consider canonical URLs in webserver, canonical URLs in CMS, and CiviCRM config.
Answers.UserDisplayName: Chris Burgess
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-06T03:53:28.653Z
Answers.Text: Using curl with the www. in front of the domain name returns the same result - "302 found"..
Answers.UserDisplayName: jakew
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-04T18:41:11.963Z
Answers.LastActivityDate: 2015-11-04T18:41:11.963Z
Answers.LastEditDate: 2017-04-13T12:53:13.017Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>As referenced here and other places in the forum:</p>
  
  <p><a href="https://forum.civicrm.org/index.php?topic=29753.15" rel="nofollow">https://forum.civicrm.org/index.php?topic=29753.15</a></p>
  
  <p>IPN's from paypal are apparently not passing muster with CiviCRM. The errors in the log are somewhere along the lines of "Could not find an entry for contactID in GET". This log is generated by testing using curl, like so:</p>
  
  <p>curl -k -X POST -d "[paste in IPN params from Paypal IPN log]" <a href="https://oursite.org/sites/all/modules/civicrm/extern/ipn.php?reset=1&amp;contactID=[contact_id]&amp;contributionID=[contribution_id]&amp;module=contribute" rel="nofollow">https://oursite.org/sites/all/modules/civicrm/extern/ipn.php?reset=1&amp;contactID=[contact_id]&amp;contributionID=[contribution_id]&amp;module=contribute</a></p>
  
  <p>The words in brackets are my substitutions; clearly there is an integer contactID in the GET request; what's going on here?</p>
  
  <p>UPDATE: More perplexing is that the civicrm_system_log table varies depnding on how the IPN is sent. From Paypal, it shows all the info from the IPN as it's logged in Paypal - with the GET parameters first, followed by the POST parameters, all within the same JSON-looking structure, in the log table's 'context' field. If I simulate a re-send of the same IPN using curl as described above, the parameters from the GET part of the request are missing from the context field. I'm not sure if they're supposed to show up in the log or not, as it seems the POST variables are what show up in the log, so it's a little tricky to know how to debug this.</p>
  
  <p>In any event, the actual IPN's that came through from Paypal, and which Paypal says were met with 500 errors, are logged in the database, and there are no corresponding entries in Civicrm.[hash].log from those times indicating any errors, so presumably the IPN should have processed correctly. This is rather complicated and confusing.. could someone please help?</p>
  
  <p>Update: Including the GET data in the curl request with -X GET -d "reset=1&amp;contactID=[contact_id]&amp;contributionID=[contribution_id]&amp;module=contribute" results in a "302 found" response, but no more information than that, and I cannot find any evidence in the database log of the request, and there is no mention at all in Civicrm.[..].log.</p>
  
  <p>Addendum: The PayPal IPN simulator reports that it cannot successfully handshake with either the dev or live sites. That is strange considering that IPN logs are appearing in the live site's civicrm_system_log table..</p>
  
  <p>UPDATE: Apparently here's what was happening. I have a Civi extension where I call a function defined in a Drupal module, and the 500 error was about calling an undefined function. I fixed that in the extension code, but the function in question called the Drupal watchdog(..) function, which is also undefined in the context of being called from ipn.php. So here's a better question: What's the solution to this problem? Do I edit ipn.php and bootstrap Drupal before doing anything else? It seems odd that, just for IPN's, something would break because it is not running under the same assumptions that the rest of Civi runs under.. of course, I could also switch from Drupal watchdog in my extension to whatever the Civi equivalent is.. any suggestions?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-04-28T01:01:50.333Z
Comments.Text: When you execute `curl http://example.com/?a=1&b=2` without quoting the URL, your shell may intercept the ampersand and following characters. This may be the source of your replays not including the (latter) GET params. Compare output of `echo foo&bar` versus `echo "foo&bar"` to see this demonstrated.
Comments.UserDisplayName: Chris Burgess
Tags: <civicontribute><paypal><ipn>
Title: Paypal IPN failure -
ThreadText: # Paypal IPN failure -
  
  (Asked by: username_0 on 2015-11-04)
  
  As referenced here and other places in the forum:
  
  <https://forum.civicrm.org/index.php?topic=29753.15>
  
  IPN's from paypal are apparently not passing muster with CiviCRM. The errors in the log are somewhere along the lines of "Could not find an entry for contactID in GET". This log is generated by testing using curl, like so:
  
  curl -k -X POST -d "[paste in IPN params from Paypal IPN log]" <https://oursite.org/sites/all/modules/civicrm/extern/ipn.php?reset=1&contactID=[contact_id]&contributionID=[contribution_id]&module=contribute>
  
  The words in brackets are my substitutions; clearly there is an integer contactID in the GET request; what's going on here?
  
  UPDATE: More perplexing is that the civicrm\_system\_log table varies depnding on how the IPN is sent. From Paypal, it shows all the info from the IPN as it's logged in Paypal - with the GET parameters first, followed by the POST parameters, all within the same JSON-looking structure, in the log table's 'context' field. If I simulate a re-send of the same IPN using curl as described above, the parameters from the GET part of the request are missing from the context field. I'm not sure if they're supposed to show up in the log or not, as it seems the POST variables are what show up in the log, so it's a little tricky to know how to debug this.
  
  In any event, the actual IPN's that came through from Paypal, and which Paypal says were met with 500 errors, are logged in the database, and there are no corresponding entries in Civicrm.[hash].log from those times indicating any errors, so presumably the IPN should have processed correctly. This is rather complicated and confusing.. could someone please help?
  
  Update: Including the GET data in the curl request with -X GET -d "reset=1&contactID=[contact\_id]&contributionID=[contribution\_id]&module=contribute" results in a "302 found" response, but no more information than that, and I cannot find any evidence in the database log of the request, and there is no mention at all in Civicrm.[..].log.
  
  Addendum: The PayPal IPN simulator reports that it cannot successfully handshake with either the dev or live sites. That is strange considering that IPN logs are appearing in the live site's civicrm\_system\_log table..
  
  UPDATE: Apparently here's what was happening. I have a Civi extension where I call a function defined in a Drupal module, and the 500 error was about calling an undefined function. I fixed that in the extension code, but the function in question called the Drupal watchdog(..) function, which is also undefined in the context of being called from ipn.php. So here's a better question: What's the solution to this problem? Do I edit ipn.php and bootstrap Drupal before doing anything else? It seems odd that, just for IPN's, something would break because it is not running under the same assumptions that the rest of Civi runs under.. of course, I could also switch from Drupal watchdog in my extension to whatever the Civi equivalent is.. any suggestions?
  
  **Tags:** civicontribute, paypal, ipn
  
  > **Comments:**
  > **username_1**: When you execute `curl http://example.com/?a=1&b=2` without quoting the URL, your shell may intercept the ampersand and following characters. This may be the source of your replays not including the (latter) GET params. Compare output of `echo foo&bar` versus `echo "foo&bar"` to see this demonstrated.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-11-04. Score: 2
  
  We have a little trick for this situation.
  
  This extension
  
  <https://github.com/eileenmcnaughton/nz.co.fuzion.notificationlog>
  
  allows you to replay processing IPNS from the system log - e.g after installing try
  
  drush cvapi NotificationLog.retry system\_log\_id=xxx
  
  > **Comments:**
  > **username_0**: Array (     [error_code] => 0     [entity] => NotificationLog     [action] => retry     [is_error] => 1     [error_message] => unsupported processor )  
  > **username_0**: Wait - does the unsupported processor error mean that this version of the extension just does not support paypal? http://civicrm.stackexchange.com/questions/4458/what-should-drush-cvapi-notificationlog-retry-sequential-1-system-log-id-xxx-do  
  > **username_0**: Looked at the extension code.. apparently it only supports PayPal Pro and Authorize. For PayPal it's looking for log message "payment_notification processor_name=PayPal"; the ones I have are called "payment_notification PayPal_Standard"..  
  > **username_0**: Update: It's a 500 error. I duplicated it using poster. It seems that some of the parameters supplied by Paypal cause the server to return a 500 error. Ugh..  
  
  ---
  
  ### Answer by username_3 on 2015-11-04. Score: 1
  
  a 302 redirect doesn't redirect the POST data, which is what I suspect your issue is.
  
  The best solution is to use an IPN URL that doesn't need redirection. If that's not an option, [see here](https://civicrm.stackexchange.com/a/4326/12) for how to use a 307 redirect (which maintains the POST data) and see if that solves your problem.
  
  > **Comments:**
  > **username_0**: I'm not using redirects at all - this is stock civi paypal standard processor, and the ipn url is sites/all/modules/civicrm/extern/ipn.php - an actual file on the server.  
  > **username_1**: Check the URL and protocol that PayPal is hitting - if your CiviCRM or webserver is configured to use a given URL (`https://example.org`) and PayPal is hitting a URL that doesn't match (`http://www.example.org`) then you might see redirects happen. Consider canonical URLs in webserver, canonical URLs in CMS, and CiviCRM config.  
  > **username_0**: Using curl with the www. in front of the domain name returns the same result - "302 found"..  
  
  ---
  
  