So I have a PHP service that\'s only job is to accept PayPal IPN connections. I\'m using PSR7 $request->getBody()->getContents()
to get the following from
For the record, I have been having this issue with Paypals IPN Simulator, and found that the solution is typical of Paypal:
The Issue: A correctly formatted IPN test run on the Paypal IPN Simulator returns INVALID when all checks show it should be correct.
Solution:
1) The simulator ALWAYS runs on the "sandbox" environment. I was using it to check on a "LIVE" payment sites feedback and took hours to discover that your IPN needs to be set to sandbox mode. This is not mentioned on the Paypal Simulator and appears to be hardcoded and "assumed" by Paypal.
2) the Payment_Date
field in the IPN Simulator is invalid and not accepted when returned to Paypal, so clear this field or set this field to null
when submitting IPN Simulator runs.
3) Sometimes, strangely, Paypal IPN Simulator will tell you
IPN was not sent, and the handshake was not verified. Please review your information.
Even Though the simulated transaction is fully processed by my IPN listener script and returns VERIFIED
. Always Check your own feedback script rather than the crap Paypal decides to tell you.
A combination of the above issues has lost several hours of my life. Stripe is far, far better to code with.
We have been using the IPN simulator for the last few days, and are getting intermittent INVALID
messages returned on the validation request.
Waiting a few minutes, or just pressing the "Send IPN" message a few times seems to work.
We have seen a request return an INVALID
, and moments later the same request returns VERIFIED
. Quite annoying.
The PayPal transaction validation always returns INVALID if the IPN comes from the IPN simulator, but I found a workaround. If the IPN will come from a real transaction, it works fine. Here is how I did.
It would seem the new IPN Simulator interface is using javascript Dates in the payment_date field. If you set this manually to something like today it works OK. Whether this is an encoding/decoding issue on the IPN Simulator side, or in your IPN listener, I am not sure.