2

We have a support website that we use to create custom orders for our customers. This website runs ASP.NET 1.1 and connects to PayPal using the PayFlow Pro API.

We also have a customer-facing website that runs ASP.NET 4.0 and also uses PayFlow Pro for connectivity to PayPal.

The customer-facing website is communicating fine with PayPal, but we're getting a "Failed to Connect to Host Uri" error from the support site.

Furthermore, we have a test server set up to run the support site, and it is communicating with PayPal with no issues. The only difference that I can tell between the test site and the production support sites is that test is running IIS 7.0 while production is running IIS 7.5. All DLLs and configuration files appear to be identical.

All of this started happening about a week ago, just after PayPal discontinued use of SSL. I would think it has something to do with the SSL switchover, but we have disabled SSL in IIS so I'm not sure where else to look. And why would the customer-facing site continue to work while the support site can't connect? They use the same infrastructure.

JoshE
  • 21
  • 3

3 Answers3

2

This isn't really the answer you're looking for but We've been facing the same issues since Jan 12th. We've taken the same steps you have and are seeing the same result. Interestingly, if we do an IIS reset it will start working again, at least for a while.

We did a Wireshark trace the last time the issue occurred and all we really found out is that the connection is being reset on the PayPal side. We suspect that the issue lies within the PayPal network, likely due to their recent SSL changes. I suggest you do a Wireshark trace when you're seeing the error and submit that to PayPal. That's basically what we're doing to try and resolve this issue.

Update: After some testing, this does appear to be an issue with the recent SSL changes. We were ultimately able to reproduce this issue. What we believe we've discovered that if your .Net app calls any other web services which still allow SSL 3 (such as Youtube's API) then IIS will always try to use SSL3, at least until you do an IIS reset. Since PayPal no longer allows SSL3, the connection to PayPal fails. If you do an IIS reset, then try PayPal it will work, unless your app hits another SSL3 endpoint at which time your PayPal will start to fail once again.

Like you we have a admin application which does not live on the outside at all. Also like you, our eCom site is still working fine. We think this is because our eCom's do not make any SSL3 calls to any services, therefore the server that our eCom's are on never gets "stuck" on SSL3. Our internal app however, does interact with the YouTube API. It appears if we hit the YouTube API, which allows SSL3 then our PayFlow transactions start to error out. If we do an IIS reset, PayFlow will work, until we hit the YouTube API then PayFlow breaks again.

I know this is a bit circumstantial, but it may give you a somthing to go on.

Good luck!

btw, we also had SSL "disabled" in IIS but that did not appear to fix the issue.

Corey Behrends
  • 71
  • 3
  • Thanks for your response. We aren't calling any other apis from our support site, and I don't see any other SSL calls being made. Do you mean "restart the website" when you say "IIS reset"? – JoshE Feb 02 '15 at 16:57
  • Yes, an IIS reset appears to fix the issue, at least for a while. – Corey Behrends Feb 03 '15 at 17:04
  • I had a similar issue, IIS reset didn't seem to fix it but PayPal got back to me and said their engineers will do something within 48 hours. – Aligma Apr 10 '15 at 05:15
2

This is also not the answer you have been looking for, but we too have been experiencing the same problem and despite several days working at it and numerous communications with PayPal we have not been able to resolve it.

This is the only post we have been able to find that matches our issue so I am going to point PayPal at it, perhaps if anyone else has a PayPal ticket raised, they can post their ticket number so we can prove to them that there is a wider issue than they are acknowledging. Ours is 150113-000138.

We are not in a position to reset IIS right this minute, but we will do so overnight to see if it allows a successful payment. I'll post an update later.

Update:

After a lot of research, trial and error we came to the conclusion that this is indeed a Microsoft issue and that an IIS Reset does indeed fix the issue until another connection is made from the server, knocking the connection back to SSL.

Our approach was to move the 1.1 site into a .Net 4.0 CLR. This was not plain sailing as there were several knock-on issues but with patience and careful debugging we ironed those out and now have a working website.

Tony
  • 79
  • 1
  • 1
  • 9
0

I had the same issue under Framework 4.6.1, my problem was caused by the web.config setting <httpRuntime targetFramework="4.5" />. When I changed the targetFramework to 4.6 it fixed the error for me. Hope this helps anyone with the same issue.

Necromancer
  • 390
  • 5
  • 15