Answers.Body: <p>Answering in case this is helpful.  The problem was configuration (not informed of PayPal email change).  Would have been very quickly solved if <em>something</em> was logged vs just discarding the IPN.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-10-16T12:52:30.060Z
Answers.Text: It's not the IPN.   We receive them from PP and process them without error.  It's at the opposite end of the process -- namely, the inability to connect to their subscription service because of a firewall blockage.   
  
  Are others getting blocked?
Answers.UserDisplayName: ldgpangeo
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-17T21:12:18.087Z
Answers.LastActivityDate: 2017-02-17T21:12:18.087Z
Answers.UserDisplayName: EHendricks
Body: <p>Drupal - latest version
  CiviCRM - 4.7.13</p>
  
  <p>We have a client that uses PayPal standard with recurring payments that having an issue that I can't figure out.  The recurring payments seem to have quit working since the first of the year.  By quit I mean they are logged but after that nothing seems to happen.  No errors and no record of the payment.  I have used a test setup where I use curl to resend messages to my local environment while in debug mode but it doesn't work (it does work for authorize.net payments).  In this case it seems like the data isn't there when the message is to be processed.</p>
  
  <p>Another interesting thing is that some of the IPNs look like they are resent several times within a few mins.  They have the same transaction ID, etc.</p>
  
  <p>Any help or ideas are very much appreciated.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-14T18:30:34.583Z
Comments.Text: Can you describe more about "some of the IPNs look like they are resent several times within a few mins"? Are you seeing the IPNs coming in from Paypal in your web server log? What is the url that PayPal is posting to?
Comments.UserDisplayName: Alan Dixon
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-16T16:49:02.640Z
Comments.Text: I am seeing the retries in the system_log.  This is our first client using paypal subscriptions.  I looked into paypal IPNs and see that they expect a 200 response.  The site was upgraded to 4.7.13 on 12/11/16 and there was a bug with the IPN processing (CRM-19676).  This explains the retries (though there weren't 16 retries).  I patched the site with the fix on 1/30/17.  Since then there have only been 2 recurring IPNs and there is only one entry in the system_log for each.  However, there is no indication of the payment in the contact record and I haven't found any errors anywhere.
Comments.UserDisplayName: EHendricks
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-17T16:11:08.340Z
Comments.Text: I can confirm that I have paypal standard working 4.7.16. In reviewing, I can see that a January recurring contribution that should have arrived on the 13th was only recorded on the 18th, the Feb. one seems to have been effective. I also notice quite a lot of variations in the url that the IPN is posting to. The successful one on the 13th look like:
  
  POST /civicrm/payment/ipn/7
  
  But I've also got some older ones looking like:
  
  POST /sites/default/modules/civicrm/extern/ipn.php
  
  So I suspect there's quite a lot of places to go wrong.
Comments.UserDisplayName: Alan Dixon
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-17T21:09:04.993Z
Comments.Text: Thanks a lot for your response.  It turns out the client changed the email address and didn't inform us.  The IPN is just discarded when that happens.  There really should be something logged (heads to issue queue...).
Comments.UserDisplayName: EHendricks
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-04-18T06:37:30.097Z
Comments.Text: Could you be more clear re: 'paypal email change'?
  was this a contact email address that changed, or an official paypal email address? Thanks,
  Marsh
Comments.UserDisplayName: Marsh Circle
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-10-16T12:51:10.763Z
Comments.Text: The IPN's for existing recurring payments continue without a problem.  We receive them and Civi updates the contribution history correctly.   This is some form of PP firewall blocking access to their subscription (recurring payment) service in order to set up a NEW payment schedule.  
  
  Since CiviCRM composes the url to initiate the connection, I'm at a loss to figure out what needs modification -- particularly since we do nothing unusual in the payment form.
Comments.UserDisplayName: ldgpangeo
Tags: <payment-processor><paypal>
Title: Trouble with PayPal recurring payments
ThreadText: # Trouble with PayPal recurring payments
  
  (Asked by: username_0 on 2017-02-13)
  
  Drupal - latest version
  CiviCRM - 4.7.13
  
  We have a client that uses PayPal standard with recurring payments that having an issue that I can't figure out. The recurring payments seem to have quit working since the first of the year. By quit I mean they are logged but after that nothing seems to happen. No errors and no record of the payment. I have used a test setup where I use curl to resend messages to my local environment while in debug mode but it doesn't work (it does work for authorize.net payments). In this case it seems like the data isn't there when the message is to be processed.
  
  Another interesting thing is that some of the IPNs look like they are resent several times within a few mins. They have the same transaction ID, etc.
  
  Any help or ideas are very much appreciated.
  
  **Tags:** payment-processor, paypal
  
  > **Comments:**
  > **username_1**: Can you describe more about "some of the IPNs look like they are resent several times within a few mins"? Are you seeing the IPNs coming in from Paypal in your web server log? What is the url that PayPal is posting to?  
  > **username_0**: I am seeing the retries in the system_log.  This is our first client using paypal subscriptions.  I looked into paypal IPNs and see that they expect a 200 response.  The site was upgraded to 4.7.13 on 12/11/16 and there was a bug with the IPN processing (CRM-19676).  This explains the retries (though there weren't 16 retries).  I patched the site with the fix on 1/30/17.  Since then there have only been 2 recurring IPNs and there is only one entry in the system_log for each.  However, there is no indication of the payment in the contact record and I haven't found any errors anywhere.  
  > **username_1**: I can confirm that I have paypal standard working 4.7.16. In reviewing, I can see that a January recurring contribution that should have arrived on the 13th was only recorded on the 18th, the Feb. one seems to have been effective. I also notice quite a lot of variations in the url that the IPN is posting to. The successful one on the 13th look like:  POST /civicrm/payment/ipn/7  But I've also got some older ones looking like:  POST /sites/default/modules/civicrm/extern/ipn.php  So I suspect there's quite a lot of places to go wrong.  
  > **username_0**: Thanks a lot for your response.  It turns out the client changed the email address and didn't inform us.  The IPN is just discarded when that happens.  There really should be something logged (heads to issue queue...).  
  > **username_2**: Could you be more clear re: 'paypal email change'? was this a contact email address that changed, or an official paypal email address? Thanks, Marsh  
  > **username_3**: The IPN's for existing recurring payments continue without a problem.  We receive them and Civi updates the contribution history correctly.   This is some form of PP firewall blocking access to their subscription (recurring payment) service in order to set up a NEW payment schedule.    Since CiviCRM composes the url to initiate the connection, I'm at a loss to figure out what needs modification -- particularly since we do nothing unusual in the payment form.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-02-17. Score: 2 | Accepted answer
  
  Answering in case this is helpful. The problem was configuration (not informed of PayPal email change). Would have been very quickly solved if *something* was logged vs just discarding the IPN.
  
  > **Comments:**
  > **username_3**: It's not the IPN.   We receive them from PP and process them without error.  It's at the opposite end of the process -- namely, the inability to connect to their subscription service because of a firewall blockage.     Are others getting blocked?  
  
  ---
  
  