Paypal Express has stopped working. Paypal IPN working fine. Linkpoint working fine. Results from curltester.php are fine.

root@s307 [~]# php -m | grep curl
curl
curl
cURL Information => libcurl/7.24.0 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5

Any help would be greatly appreciated.

1. URL to curltester.php script?
2. What do your PayPal_CURL_xxxxx.log files contain? http://www.zen-cart.com/showthread.php?61199-Debug-Logging-PayPal

The command-line CURL test you quoted isn't the same as running CURL via PHP statements which call the CURL extension compiled into PHP. They can potentially operate very differently.

The (7) Could Not Connect To Host message always means exactly what it said. Couldn't connect. And probably because the connection was refused, or because name lookups failed.

I got the command line results after running the test here
http://rastaheadwraps.com/extras/curltester.php?paypal=1 and ?ssl=1
the first test failed, the second test came up good

Here is what I find in logs

PHP Warning: mktime() expects parameter 6 to be long, string given in /home/nilajah/public_html/[custom_admin]/includes/functions/general.php on line 3162

PHP Catchable fatal error: Object of class shoppingCart could not be converted to string in /home/nilajah/public_html/[custom_admin]/view_stuck_paypal_orders.php on line 71

I have had debug mode turned on, but Express had been disabled. I turned it on just to test it once, but I am not seeing a log with Paypal in its subject.

Right. Now you're getting

28 connect() timed out!
``` ... which almost always means you've got a server nslookup/nameserver/resolv.cnf problem, which your hosting company will need to fix.

Many months ago PayPal changed some of their IP addresses, and sent out about 20 mailings over about 10 months leading up to the change, telling people to make sure their hosting companies aren't over-caching old IP addresses or blocking the new IP addresses in their server firewalls.

Some hosts (I recall a discussion on the forum about a month ago, I think it was about Fasthosts) have had to fix their servers because their name lookups were using outdated cached data, or had some other system failure when handling traffic to PayPal.

You'll need to get your hosting company to fix this problem. It's not a Zen Cart issue.  Zen Cart has always used the "name", and never any hard-coded IP address, for this exact reason: it's the right way to make sure all the normal internet-webserver-routing operations work properly. The weak link here is your hosting company who is doing something they ought not to.

Give them the link to your curltester.php script as the testing tool they need to use to finally confirm it's fixed. Of course, make sure they use the ?paypal=1 parameter or they'll say it's fixed and close the ticket prematurely.
Additionally, you might try reporting your host to PayPal to hopefully get PayPal to reach out to them and fix the problem. <https://www.paypal.com/mts>

I am still getting this

7 couldn't connect to host
Array
(
[url] => "https://api-3t.paypal.com/nvp"
[content_type] =>
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 19.996362
[namelookup_time] => 0.157639
[connect_time] => 0
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => -1
[upload_content_length] => -1
[starttransfer_time] => 0
[redirect_time] => 0
)

I was also quite sure it is not a Zen cart issue because no config had been changed at all, no new plugins added when the problem cropped up. But you have just proved the value of placing the issue here anyway. Thanks for the reply. I am going to re-open the ticket with what you just suggested.

May or may not be related... But your website appears to be on a blacklist with Vipre. In my experience Vipre is a little slower at removing people from a blacklist (compared to other companies). You may want to make a manually request.

Typically you get on one of these lists when someone running protection software finds something suspicious about your website (or another site on the same shared hosting).. Or either your site or another site on the same shared hosting was part of a known or suspected malware campaign.

I did not look too deeply into the potential of being on other blacklists - just wanted to give you a heads up.

Wow! incredible stuff, thanks for the heads up, lhungil. I do know there was a hack from Brazil, almost exactly a year ago, so whatever the guy did before we were onto him may have triggered it. But Paypal has been working fine all this time till Dec '12. Can you tell me how I can view the same details you found out? I am especially interested in the date of their block.

I hadn't realized the paypal folder had a separate set of logs from the logs in cache - this seems to be the first one of this type, about the date the Express stopped working

2012-12-11 10:11:18

(live transaction) --> https://api-3t.paypal.com/nvp
Request Headers:
Array
(
[0] => Content-Type: text/namevalue
[1] => X-VPS-Timeout: 45
[2] => X-VPS-VIT-Client-Type: PHP/cURL
[3] => X-VPS-VIT-Integration-Product: PHP::Zen Cart(tm) - PayPal/NVP
[4] => X-VPS-VIT-Integration-Version: 1.3.9h
)

Request Parameters: {SetExpressCheckout}
Array
(
[AMT] => 27.99
[ITEMAMT] => 27.99
[L_NUMBER0] =>
[L_NAME0] => Side Sac Lion Of Judah Bag
[L_DESC0] => Color: Army Green with Rasta Colors
[L_AMT0] => 27.99
[L_QTY0] => 1
[LOCALECODE] => US
[PAYMENTACTION] => Sale
[ALLOWNOTE] => 1
[LANDINGPAGE] => Billing
[RETURNURL] => https://rastaheadwraps.com/ipn_main_handler.php?type=ec
[CANCELURL] => https://rastaheadwraps.com/index.php?main_page=shopping_cart&ec_cancel=1
[PAGESTYLE] => ATR
[METHOD] => SetExpressCheckout
[CURRENCYCODE] => USD
[USER] => xxxxxxxxxxxxxx_api1.yahoo.com
[PWD] => ****************
[VERSION] => 60.0
[SIGNATURE] => ****************************************************We7c
)

Response:
Array
(
[] =>
[CURL_ERRORS] => (7) couldn't connect to host
)

(7) couldn't connect to host
Array
(
[url] => https://api-3t.paypal.com/nvp
[content_type] =>
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 59.992658
[namelookup_time] => 0.00264
[connect_time] => 0
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => -1
[upload_content_length] => -1
[starttransfer_time] => 0
[redirect_time] => 0
)

SetExpressCheckout, Elapsed: 59994ms -- Failed
(7) couldn't connect to host
Array
(
[url] => https://api-3t.paypal.com/nvp
[content_type] =>
[http_code] => 0
[header_size] => 0
[request_size] => 0
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 59.992658
[namelookup_time] => 0.00264
[connect_time] => 0
[pretransfer_time] => 0
[size_upload] => 0
[size_download] => 0
[speed_download] => 0
[speed_upload] => 0
[download_content_length] => -1
[upload_content_length] => -1
[starttransfer_time] => 0
[redirect_time] => 0
)

Hosting support says the Paypal IPs are reachable, no blocks on the firewall

root@s307 [/home/nilajah/public_html]# csf -g 216.113.188.10

Chain num pkts bytes target prot opt in out source destination
No matches found for 216.113.188.10 in iptables
root@s307 [/home/nilajah/public_html]# csf -g 66.211.168.126

Chain num pkts bytes target prot opt in out source destination
No matches found for 66.211.168.126 in iptables

Where they are resolving the name

paypal.com. 300 IN A 66.211.169.66
paypal.com. 300 IN A 66.211.169.3

I checked the dedicated IP of the site here

http://whatismyipaddress.com/blacklist-check

and here

http://www.mxtoolbox.com/blacklists.aspx

came up clean both places

Norton says the site is safe

http://safeweb.norton.com/report/show?url=http%3A%2F%2Frastaheadwraps.com

and also AVG

http://www.avgthreatlabs.com/sitereports/domain/rastaheadwraps.com

nothing else for me to do except wait for the client to get an answer from Paypal.

isaiah36:

Hosting support says the Paypal IPs are reachable, no blocks on the firewall

root@s307 [/home/nilajah/public_html]# csf -g 216.113.188.10

Chain num pkts bytes target prot opt in out source destination
No matches found for 216.113.188.10 in iptables
root@s307 [/home/nilajah/public_html]# csf -g 66.211.168.126

Chain num pkts bytes target prot opt in out source destination
No matches found for 66.211.168.126 in iptables

Where they are resolving the name

paypal.com. 300 IN A 66.211.169.66
paypal.com. 300 IN A 66.211.169.3

It's too bad they aren't looking at the error details you've been posting, which clearly states that the URL your store needs to connect to is https://api-3t.paypal.com/nvp ... which won't the same address as the generic paypal.com

The csf / iptables check is only the firewall. It's nothing about name lookups.

isaiah36:

Hosting support says the Paypal IPs are reachable, no blocks on the firewall

Where they are resolving the name

paypal.com. 300 IN A 66.211.169.66
paypal.com. 300 IN A 66.211.169.3

That's fine if you were using a webbrowser to go to the PayPal website. The thing is, that's not where your problem is.

(live transaction) --> https://api-3t.paypal.com/nvp

api-3t.paypal.com has address 173.0.88.69
api-3t.paypal.com has address 173.0.88.101
api-3t.paypal.com has address 173.0.84.69
api-3t.paypal.com has address 173.0.84.101

Go back and get 'em to check again.

There are even more possible addresses than what RodG mentioned:
https://ppmts.custhelp.com/app/answers/detail/a_id/92

From http://www.zen-cart.com/wiki/index.php/PayPal

It's important to note that a properly configured host wouldn't normally need ANY entries for PayPal as far as outbound communication is concerned.
And, for incoming, well, your site is a webserver, so you probably want incoming traffic from pretty much everywhere, except addresses which have proven themselves untrustworthy.

That is to say, if your host truly has no firewall addresses (in or out) for PayPal, then it starts suggesting what I mentioned before: that it's a namelookup / resolv problem, where the server's own ability to properly resolve names to addresses is broken or outdated because caching is foobar'd.

DrByte:

There are even more possible addresses than what RodG mentioned:

True, but api-3t.paypal.com only uses the 4 listed.... At least according to the DNS :)

I thought I'd give the OP's host a fighting chance... <g>

Curiously (not important for the OP or his host to know) the following two IP's
66.211.168.126
66.211.168.194
are listed by PayPal as also being used by api-3t.paypal.com, but they don't (or no longer) have a DNS entry for them.

DrByte:

That is to say, if your host truly has no firewall addresses (in or out) for PayPal, then it starts suggesting what I mentioned before: that it's a namelookup / resolv problem, where the server's own ability to properly resolve names to addresses is broken or outdated because caching is foobar'd.

I tend to agree...... Hmmm, depending on when the 66.211.x.x addresses got dropped by the DNS it is possible that this is when the OP's problems started (just thinking out loud).

Cheers
Rod.

ping -c5 173.0.88.69

PING 173.0.88.69 (173.0.88.69) 56(84) bytes of data.

--- 173.0.88.69 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

root@s307 [~]# ping -c5 173.0.88.101
PING 173.0.88.101 (173.0.88.101) 56(84) bytes of data.

--- 173.0.88.101 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

root@s307 [~]# ping -c5 173.0.84.69
PING 173.0.84.69 (173.0.84.69) 56(84) bytes of data.

--- 173.0.84.69 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

root@s307 [~]# ping -c5 173.0.84.101
PING 173.0.84.101 (173.0.84.101) 56(84) bytes of data.

--- 173.0.84.101 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms

isaiah36:

ping -c5 173.0.88.69

PING 173.0.88.69 (173.0.88.69) 56(84) bytes of data.

--- 173.0.88.69 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

This doesn't really tell us anything useful.

Cheers
Rod

isaiah36

Q. Under your configuration->My_store settings, do you have an entry that reads: "cURL Proxy Status"? If so, make sure it is set to "False".

If this entry** doesn't exist,** try running the following SQL command
UPDATE configuration SET configuration_value= 'FALSE' WHERE configuration_key = 'CURL_PROXY_REQUIRED' ;

It has been a long time since ZenCart needed to use the proxy option (and then only for one particular host).
Current versions of zencart have removed this as an option because the host that shall be nameless removed the need for it. However, it has been noted that some auto-install scripts incorrectly set this value to 'true' and the only way to to set it back to false is via the SQL update command.

I make no guarantee that this will work, and I'm pretty much clutching at straws. It has been about a year since I've seen this 'fix' actually work, but it is a possibility that is pretty easy to eliminate.

Cheers
Rod