2

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.

Improve this question
6
  • 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?
    – Alan Dixon
    Feb 14, 2017 at 18:30
  • 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.
    – EHendricks
    Feb 16, 2017 at 16:49
  • 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.
    – Alan Dixon
    Feb 17, 2017 at 16:11
  • 1
    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...).
    – EHendricks
    Feb 17, 2017 at 21:09
  • 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
    – Marsh Circle
    Apr 18, 2018 at 6:37

1 Answer 1

Reset to default
2

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.

Improve this answer
1
  • 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?
    – ldgpangeo
    Oct 16, 2020 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.