2
votes

I'm improving a PayPal IPN listener. I've read the specs and there are still a few open questions. As we all know, if you receive a notification, you have to connect to PayPal on a second channel, send them the received data, and PayPal will answer with either VERIFIED or INVALID. In certain cases, PayPal resends a notification until it receives an answer from us. And PayPal has a debugging page called "IPN History".

I had at least one occasion where I received INVALID, and the "IPN History" showed the normal status "sent".

Question 1: Is it correct that PayPal doesn't check whether I connect to them on the second channel to decide whether a message was correctly sent?

Q2: I assume that PayPal looks solely at the http status header (e.g. "200 OK") it receives from us to decide what status to show in the "IPN History". Is this correct?

Q3: I also assume that PayPal looks solely at the http status header to decide whether it has to resend a message. Is that correct?

That PayPal payment that I received INVALID now shows up in PayPal as a normal payment. But there was no additional notification at a later moment.

Q4: I assume this behavior was a internal PayPal problem, and the proper way to do this is to tell PayPal there was an error so that it sends another notification 5 minutes later. Is that correct?

Q5: If so, what http status header do I have to send back to PayPal if I receive INVALID to make sure that PayPal resends the notification later?

Thanks!

1
Some clarification: we do a lot of PayPal payments. Normally they work fine. We receive "INVALID" when it should be really "VERIFIED" maybe once in a thousand cases. I've written a test script that does this second channel-verification again, the exact same way as it did it before, and now PayPal is responding with "VERIFIED" for the cases that were "INVALID" previously. I presume that PayPal sends the wrong status because of some internal timing issues at their part. So this is about an edge case, and how to tell PayPal to resend their info again. Thanks!CruftyCraft

1 Answers

4
votes

A1) Correct. They simply POST the data to your script and if they get a 200 OK back from your server they consider it a done deal regardless of whether or not you POST back for verification or not.

A2) Correct.

A3) Correct. If the payment really was a legitimate PayPal payment then there must be something wrong with the way you POSTed it back to them for verification. It has to be formatted exactly the same as they originally sent it to you.

A4) As long as your POST back data is formatted the same way it won't be invalid. With a solid script put together you shouldn't have to send any specific non-200 message back to PayPal to try again. If you have everything configured correctly it will validate and your script will complete with a 200 OK. If something is wrong with your script it could either end up invalid (but still return a 200 OK so you wouldn't get another one) or it would return something besides 200 in which case it would re-post the data to you later.

A5) If you send anything other than 200 back it will re-try, but if you end up with a bunch of failures that are re-trying they'll place you on a delayed que and you won't get your IPN's as quickly as you normally would so I wouldn't recommend it. You want to avoid anything other than 200 results from your IPN script.