Jon G, for Authorize, the answer is Yes, using Eileen's extension - see:
What should drush cvapi NotificationLog.retry sequential=1 system_log_id=XXX do?
and get the extension at:
Issue had been filed https://issues.civicrm.org/jira/browse/CRM-18483 and this is my fix https://github.com/civicrm/civicrm-core/pull/8270/files
As earlier in case of drupal site, CRM_Utils_System::loadBootStrap() eventually calls CRM_Utils_System_Drupal::loadBootStrap() and fails at https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/System/...
Your IPN path is configured in paypal - the best path to point it to is yoursite/civicrm/payment/ipn/x where x is the number of the processor. Once you have updated it in paypal it is possible to re-send missed ipns from the paypal console
A complete sidestep would be to use a standalone Profile for submitting the membership 'application' and then when approved fire them an email with checksum to the Contribution page which has the membership optionsn on it, which uses the paypal payment processor so you get paid and creates the membership. just a thought.
I found and fixed the problem. In this case the root cause was the site was moved at go-live. Interesting to note the CiviCRM Admin panels and CiviCRM frontend pages all worked fine.
I found IPN listeners in here: /administrator/components/com_civicrm/civicrm/extern/
I pinged the listeners URLs like:
I kept pulling my hair out until we migrated to paypal pro (with it's own set of issues :)) but a couple of things to look at:
Check apache error log,
Paypal has a log that shows details of all IPN calls to server.
Make sure you have correct URL for http vs. https
Check civicrm log files in files/civicrm/ConfigandLog
Make sure firewall rules (and especially ...
We have a little trick for this situation.
allows you to replay processing IPNS from the system log - e.g after installing try
drush cvapi NotificationLog.retry system_log_id=xxx
We had identical symptoms, after lots of cursing CiviCRM, finally found it was nothing to do with CiviCRM.
PayPal IPN requires a valid email address. Our mailbox was full with someones vast supply of Spam. Cleared the mailbox and it worked fine.
Hope this does it for you.
Why is IPN failing on Pantheon?
Check out CRM-17212: IPN and other scripts break on Pantheon due to session handler although it does look like you have a similar patch in effect. Compare your changes with those merged into the 4.7 branch, or consider trying 4.7.
How do I debug on Pantheon?
On Pantheon hosting, you can inspect your application's error logs ...
My answer above is generic to this issue; this answer is specifically addressing Zachary. Thanks for posting the backtrace, it's got the details we need.
When you create an ARB (recurring payment) subscription with PayPal, Civi sends some details to PayPal. In return, PayPal embeds those details in every IPN. That's how Civi can match an IPN with the ...
When troubleshooting IPNs, the most important first step is to see if CiviCRM received them correctly. You can do this by checking the civicrm_system_log database table for the IPNs.
If you are NOT receiving the IPNs in Civi, there is most likely a web server configuration error, or they're being sent to the wrong URL.
If Civi IS receiving the IPNs, you ...
Thank you for the confirmation others are seeing this issue. In the end, this solved it for us - add lines 4-6 from the following code (lines 1-3 and 7-9 included for reference) to file /CRM/Core/Payment/PayPalProIPN.php
CRM_Core_Error::debug_var('GET', $_GET, TRUE, TRUE);
CRM_Core_Error::debug_var('POST', $_POST, TRUE, TRUE);
You don't say what CiviCRM version you have but this was fixed in 5.27.0
https://lab.civicrm.org/dev/core/-/issues/1608 & sounds similar
This patch - https://github.com/civicrm/civicrm-core/pull/18062 should improve the quality of your error logging
I've been seeing this in various versions of CiviCRM starting in roughly Sep of this year. Note in the original post that actually 500=error vs. 200=success, but other than that, the description of the symptom I'm seeing is accurate. I think that (just guessing) something has changed in the way that Paypal is using the IPN URL - and sending it things it ...
Which IPN file is used depends on what payment processor extension you use.
So it might be a different file, not necessarily extern/ipn.php
The webhook URL that your payment processor tries to contact is sent along with the payment information.
So for the old payments, your payment processor probably has the old URL stored and it's probably not possible to ...
The "payment processor ID" is an integer, not a string - this may be your issue. Go to Administer menu » System Settings » Payment Processor. Next to the PayPal Standard processor you're working on, click the Edit link. You should get a new page with a URL that looks like this:
I'm not using this system, but I may have an explanation. We use a custom coded donation system that expects PayPal to report back to us when there is a transaction. On 7/26/17, 7/27, and 7/29 so far there have been no such transactions, on 7/28 we only received too. The problem is confirmed to be a PayPal issue, and after fighting with them for 2 hours ...
Is this paypal pro or standard? For paypal pro all IPNS except for recurring are actually ignored, the outcome is resolved in realtime (ideally the IP would be a backup but Civi code doesn't implement that)
The guys on the core team have done a tremendous job in resolving this issue in v 4.7.13 - you can refer to the following JIRA ticket for details: https://issues.civicrm.org/jira/browse/CRM-18483
Hope this helps!
I believe what's being described here is a particular case of CiviCRM issue financial/27 - PayPal Standard doesn't handle IPNs. The issue mentions recurring payments, but any payment involving an IPN is likely affected.
You can help solve this by testing the proposed fix and reporting on whether it solves your problem, creates new problems, etc.
Note also ...
If PayPal is saying the IPN went through correctly, it's worth checking to see what the URL PayPal is using for the IPN. Does it match what you're expecting? Can you find your Apache (or nginx) web server logs and correlate them with PayPal? Are they also showing a 200? Or perhaps a redirect of some sort?
This is a really common error incidentally.
I suspect that that error you're seeing is unrelated to the PayPal issue.
Check the CiviCRM Error Logs for errors that happened around the time of the last transaction.
Check your htaccess logs for blocked requests from PayPal.
The error being thrown is in libraries/civicrm/CRM/Utils/System/Drupal.php line 545 in ...