I tried finding an answer here but can not.
I've been using this code to process PayPal IPN for over a decade! Now, as of July 2018 it no longer works!
https://github.com/paypal/ipn-code-samples/blob/master/asp/paypal_ipn.asp
The only thing I know that is different recently is that PayPal required my domain to use TLS 1.2. I asked my hosting company to make sure that it now uses that, and they made some change to make sure. Ever since then, the listener I have set up does not process the IPN correctly. The code always falls into this IF:
if (objHttp.status <> 200 ) then
And never falls into this ELSEIF the way it used to when it was working fine:
elseif (objHttp.responseText = "VERIFIED") then
I'm not even sure how to troubleshoot this at this point. Is it something about the TLS 1.2? How can I make sure my hosting company set that up correctly?
Does my listener have to be located at an HTTPS url on my site? (Right now it is on HTTP).
Thanks.
In February, I got an email notice from Paypal that IPN would no longer validate successfully via an HTTP callback, and would further require HTTPS/SSL to validate. Update your script to connect this way, and it will probably fix it.
This PHP example should give a reasonable example.
Line 142:
" $fp = fsockopen("ssl://www.paypal.com",443,$err_num,$err_str,30);"
I had similar issues previously when connecting to Paypal on port 80.
Related
Since few days the adaptive payments (both preapprovals and chained) seems to be broken.
When we send the user to paypal to complete the order (chained) or to authorize the preapproval (preapprovals), they get a generic "invalid transaction" error. Tested the flow, we get the same error and looking to the console we can see this error on the checkout.js file in the paypal object directory:
Uncaught TypeError: PAYPAL.AP.Subflow is not a constructor
at checkout.js:11
(anonymous) # checkout.js:11
Seems something has broken on paypal side.
Anyone with the same issue? Workarounds?
Cheers, Fil
We've finally figured out what was wrong.
Trying the complete debugging of the call to the svcs endpoint we've discovered that since few days (first time from 2013), we started getting an odd response from the paypal server to our SOAP request as:
{"faultstring":"Unknown Content-Encoding","faultcode":"HTTP"}
We've then thought to some issue in the "transportation" of the call to paypal servers and we've tryed to add something in the headers.
First, we discovered that in our http header request some line that we've never used before was missing, for example:
"X-PAYPAL-DEVICE-IPADDRESS: " . $_SERVER['REMOTE_ADDR'] . "\r\n" ;
But this didn't solve the issue.
Then we've added a new line in the soap client array:
'compression' => SOAP_COMPRESSION_ACCEPT,
Adding this solved the issue but no one ever adviced us about the requirement of this part of the code. Probably, this is a linux issue, maybe paypal has changed some server with a newer one and while the older accepted the SOAP request even if it was not with this "compression" parameter, in the newer environment it seems required.
Anyway, everything is back to normality adding this line, we just still have an odd time response (long) for the Pay operation while everyting is smooth for the Preapproval operation but this might depend on different paypal servers managing one or the other operation.
According to this, paypal developers need to update their machine. My question is, how can we know that our application is ready for these changes?
Thank you.
You can check your SSL details using this tool. You just need to make sure it's showing SHA256 and TLS 1.2 for the enabled protocol. It will also give you details about any potential vulnerabilities you need to fix up in general.
For the IPN change that's really just up to you to make sure you've made the change. Within the IPN script you POST data back to PayPal. You need to make sure you're using https:// on the URL that you're POSTing back to. They will reject http://.
That's really all there is to it.
I have a Business Site and am using Sandbox to try to get PDT to work.
I set up return URL in selling preferences and turned PDT ON - but my Sandbox buyers do not get returned to the site.
There are warnings that if you do not format the return url properly then it will not work, but I cannot find any instruction as to what that format is. I am not sure if I specify the page I want to return to or just the root address which PayPal will something to.
I want to use it with an https, but I have also tried and failed with a different http site that I have.
Can you suggest what I might have forgotten to do?
It would be great if you could help me get started on this fairly fundamental point!
We have multiple sites that uses PayPal standard with PDT and IPN callbacks, when I switch this to sandbox mode things don't work but works outside of the sandbox. Try connecting to the live urls and see if that works, you can always refund payments if they go through.
In the posting url you can specify &return=XXX where XXX is the url encoded url back to your site
[This will override the setting within PayPal which is handy if you have multiple sites using the same PayPal account]
You can also specify the IPN (which should also be implemented) using ¬ify_url=
I got an auto-return to work in the sandbox!
Not quite sure what I did BUT it might have been that I set up PDT and IPN in the sandbox site, instead of just in the live site.
thanks for replies. I am not out of the woods yet, but I now live in hope.
I have a weird issue with Paypal IPN. Every alternate transaction is failing. So let's say if first transactions goes well then second one fails. Similarly if 3rd one goes well then 4th one fails.
HTTP status code I am getting for failed transactions in IPN history is 400.
I have implemented the new Paypal host header changes that were newly introduced by them.
Any idea why this is happening?
IPN History
http://i.imgur.com/NfqRsGi.png
IPN Detail
http://i.imgur.com/hcKdasw.png
EDIT
I am using PHP with curl to do IPN work (using same sample code as available on Paypal website)
ANOTHER EDIT
Ok I found another code sample for PHP 5.2 from Paypal site. This one is slightly different than the one I am currently using. I tested it on Paypal Sandbox twice and it worked. Later on I will test it on live to see if it is working fine or not.
Error 400 = bad request, this means that the get requests being made on the application layer (by your browser) may contain errors or the transport layer (syn, syn, ack, syn) 3 way hand shack is being interrupted. I would check your PC for Mallware to be on the safe side. Do a netstat -b in dos and see what's trying to get connections to the external network.
Also do a scan with malware bytes and a good virus scanner like Eset nod32.. Let us know how you get on^^
The new script I downloaded from Paypal website fixed the issue.
After paypal updated their interface (sandbox.paypal.com for example is not working, now you have to go to developer.paypal.com) many of the things are not working: 2 of them are particularly frustrating and I was hoping someone here knew how to get around them:
Am I the only one whose sandbox customer test accounts are not able to make purchases? The transaction page says they are not available.
IPN validation is not letting me send a https request. When I do it says there is something wrong with the server name. Yesterday however before the update I could get verified status. If I dont put https, now my handler gives me an invalid responde status, code: 400. What does it mean?
To fix the HTTP 400 error, follow the instructions in https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 and update your code to pass "Host" information. Ideally, things should work with just the recommended changes from the above link. Apparently, thats not the case. Here is a fix from one of the PayPal MTS person - PalPAL sandbox IPN processor rejecting all messages?
Remove the "cmd=notify-validate" option from the validation URL. I tried this and it worked. Though it doesn't return the right string, atleast it doesnt break with the 400 error.
While we wait for a fix from Paypal, I wonder how a company like PayPal can cause such a huge blunder and not post anything on their status page - https://www.x.com/developers/paypal/documentation-tools/site-status/pp-cri. It just makes you think that even smaller companies can do a better job than companies like PayPal.
For the code:400 issue, you have to update the post to version 1.1. That information is located here.
https://www.x.com/content/bulletin-ipn-and-pdt-scripts-and-http-1-1 in this bulletin.
However, as I posted before the asp.net example uses a call, that does not exist, so I was only able to get mine partly working. After fixing this, the servers appear to be rejecting calls to https, or the cert they have installed is invalid.
Action Required before February 1, 2013
Merchants need to update their IPN and/or PDT scripts to use HTTP 1.1, and include the “Host” header in the IPN postback script. In addition to this bulletin, these merchants will be notified via a direct email.
Alright, seems to be fixed!
If you are having trouble logging in, like suggested above, clear cache and cookies and try again.
Regarding the error 400, seems to have been solved by paypal!