As referenced here and other places in the forum:


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?

  • 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. Apr 28, 2016 at 1:01

2 Answers 2


We have a little trick for this situation.

This extension


allows you to replay processing IPNS from the system log - e.g after installing try

drush cvapi NotificationLog.retry system_log_id=xxx

  • Array ( [error_code] => 0 [entity] => NotificationLog [action] => retry [is_error] => 1 [error_message] => unsupported processor )
    – jakew
    Nov 9, 2015 at 15:07
  • Wait - does the unsupported processor error mean that this version of the extension just does not support paypal? civicrm.stackexchange.com/questions/4458/…
    – jakew
    Nov 9, 2015 at 15:17
  • 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"..
    – jakew
    Nov 9, 2015 at 15:24
  • 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..
    – jakew
    Nov 9, 2015 at 18:06

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 for how to use a 307 redirect (which maintains the POST data) and see if that solves your problem.

  • 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.
    – jakew
    Nov 4, 2015 at 19:07
  • 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. Nov 4, 2015 at 20:10
  • Using curl with the www. in front of the domain name returns the same result - "302 found"..
    – jakew
    Nov 6, 2015 at 3:53

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.