Paypal orders not showing up?

I am using the current version of zen 1.3.5 and when someone purchasing something off my site and chooses "cash on delivery", the order will show up as a "new order" and I will receive an email, but when the customer chooses the only payment method" paypal" it will take them to the paypal page for payment and redirect them back to the checkout success page ( but it wont give them an order number), but I dont get an order confirmation or see it under new orders or even under "customers, paypal ipn".

I have changed the settings in paypal to reflect my domain:
http://mydomain.com/ipn_main_handler.php

in Website Payments Preferences set your Automatic Return URL to:
http://mydomain.com/index.php?main_page=checkout_process

but I still dont get any notifications. I have installed the paypal ipn module in zen and using the same email, but I dont know what can be wrong.... please help!

do I need to do anything else to make this work? I have read the wiki docs on this and everything looks ok....

I would figure if someone is purchasing something and it takes them to the paypal page and back to my site, shouldnt it be working properly then?

What am I missing? Thanks in advance!

bfwdesigns:

I would figure if someone is purchasing something and it takes them to the paypal page and back to my site, shouldnt it be working properly then?

What am I missing?

That would be great in a perfect world if all webhosts were configured identical and PayPal always worked flawlessly.

As it stands, if there is any sort of communication blockage between the two, then the release-instruction from PayPal won't trigger your server to complete the insertion of the order into your list of received orders.

More details on how that works and how to troubleshoot are here:
http://www.zen-cart.com/wiki/index.php/PayPal

i checked the this step:

Try accessing http://yoursite.com/ipn_main_handler.php with your browser. If you see PHP errors, those will need to be resolved. If you get a white screen, then the first phase of PayPal™ contacting your site isn't encountering errors. This doesn't mean there aren't any, it just means the initial most obvious steps are working.

and i get the white page...
does the paypal account have to be verified??

how do i check my logs? I went here and did not see anything in the folder besides the .index.html file which nothing comes up when i try to view it...

bfwdesigns:

does the paypal account have to be verified?? it helps if it is. Sometimes that's the only remaining key.

how do i check my logs? I went here and did not see anything in the folder besides the .index.html file which nothing comes up when i try to view it...

There are 2 kinds of logs:

1. server errorlogs, accessible in your server's control-panel. These tell you errors that are occurring when PHP pages are processing.
2. paypal handshaking logs. You can turn on PayPal debug logging by activating the setting in the PayPal module in Admin->Modules->Payment. You'll need to check to be sure that your /includes/modules/payment/paypal/logs folder is marked read/write (chmod 777). Then use your FTP program to access/view those logs to see what the cause of errors may be.

I'm having exactly the same problem and with the same version of ZC. Have tried checking my error logs but nothing obvious showed up. will do so again tonight. My problem is clearly at the stage of PP communicating back to ZC after taking the payment. no order shows and no confirmation follows.

have even changed the cmod permissions on the main_ipn_handler to 755 as recommened in another post.

I have checked with my host re the two recommended ports described in the ZC wiki and this is what they said:

Ports 80 and 443 are not open for outbound connections from the server for security reasons. The suggested IP addresses from Paypal have been added to our firewall configuration.

Am i likely to be able to use Paypal with ZC at all in light of that? Can i point Paypal to another file instead or some other kind of workaround? We're only a startup so Paypal is about all we can afford at this stage.

Cheers

Sam

If they've added the PayPal IP addresses to the firewall, then that may or may not indicate overriding their normal restrictions against outbound traffic. If it is blocked, then PayPal may reach you via inbound communications, but the outbound acknowledgement and authentication to collect official details ... won't be able to happen.

DrByte:

If they've added the PayPal IP addresses to the firewall, then that may or may not indicate overriding their normal restrictions against outbound traffic. If it is blocked, then PayPal may reach you via inbound communications, but the outbound acknowledgement and authentication to collect official details ... won't be able to happen.

damn. i was hoping you wouldn't say that! :( even the paypal module debugging thing isn't recording anything. i had this batch of errors come back via email (the only batch to come back from several test transactions, and it was from 2 days ago!). I've copied and pasted them from separate emails. Any ideas?

IPN FATAL ERROR::Transaction did not validate

IPN WARNING::Transaction was not marked as VERIFIED. IPN Info = HTTP/1.1 200 OK
,Date: Sun, 08 Oct 2006 11:34:48 GMT
,Server: Apache/1.3.33 (Unix) mod_gzip/1.3.26.1a mod_ssl/2.8.22 OpenSSL/0.9.7e
,Set-Cookie: cookie_check=yes; expires=Wed, 05-Oct-2016 11:34:49 GMT; path=/; domain=.paypal.com
,Set-Cookie: Apache=203.209.195.202.20861160307288998; path=/; expires=Tue, 30-Sep-36 11:34:48 GMT
,Connection: close
,Transfer-Encoding: chunked
,Content-Type: text/html; charset=UTF-8
,
,7
,INVALID
,0
,

IPN INFO - POST VARS
cmd=_notify-validate

IPN INFO - CURL INFO
HTTP/1.1 200 OK
,Date: Sun, 08 Oct 2006 11:34:48 GMT
,Server: Apache/1.3.33 (Unix) mod_gzip/1.3.26.1a mod_ssl/2.8.22 OpenSSL/0.9.7e
,Set-Cookie: cookie_check=yes; expires=Wed, 05-Oct-2016 11:34:49 GMT; path=/; domain=.paypal.com
,Set-Cookie: Apache=203.209.195.202.20861160307288998; path=/; expires=Tue, 30-Sep-36 11:34:48 GMT
,Connection: close
,Transfer-Encoding: chunked
,Content-Type: text/html; charset=UTF-8
,
,7
,INVALID
,0
,

IPN NOTICE::Got past language loads

IPN FATAL ERROR::No saved session data available

IPN FATAL ERROR::Could not find stored session in DB, cannot re-create session

IPN FATAL ERROR::No POST data available

Oh and I should add I've also tried the 1 cent refund thing and deleting the meta..php from mytemplate directory and neither of those worked.

Those IPN errors indicate that the order information it was trying to validate doesn't exist in your shop. So, either communications is failing somewhere, or those notices may be related to non-purchase activity on your PayPal account.

As Dr Byte kindly pointed out - my test site was password protected and this stops Paypal from communicating with the site and posting the order information back.

We're up and running now...

The Zen Cart team ROCK!!! Donation coming after we actually sell some stuff...

:D

I am having this same issue, but it is only a problem for about 3 customers. I have had my cart up and running for a year now (I paid to have someone install and set up my entire site, I am just trying to trouble shoot to see if is something I can fix before I have to pay my designer/host so any help is greatly appreciated) The thing that is really weird is that all of the customers that the orders are successful go to e-mail that I have set up in Admin/Modules/Payment/PayPal IPN now for these 3 customers that the order never appears go to a different e-mail account that I have set up in PayPay.

So in my Cart I have [email protected] and in PayPal I have [email protected] as my primary and [email protected].

But like I say even though the [email protected] is the one set up in my Admin Module but is not my primary account in PayPal... all those order work perfectly.

Can anyone tell me why just these 3 people's accounts refer to the [email protected]

I mean I understand that since they are getting sent to the other account that's why the orders don't appear but what I don't get is why are they even going to that other account???

stuffedpretzel:

I mean I understand that since they are getting sent to the other account that's why the orders don't appear but what I don't get is why are they even going to that other account???

I don't understand why that would be happening either, as Zen Cart code doesn't use a secondary email address.

What version of Zen Cart are you using? (Admin->Tools->Server Info)

Your gonna laugh but I am using 1.2.3... since I posted I updated my ZenCart e-mail to match the primary account in PayPal and did a few tests and it seems to be working. But I am still concerned about these 3 customers I have (1 of them is a weekly repeat customer, not sure how long she will put up with this, LOL).

Oh I was going to ask and forgot... was there a recent change with the interface with PayPal? Meaning did the requirement of it being the primary account? Cause seriously I have had this cart up and running for a year now and didn't change anything until today (changed the e-mail to match PayPal).

Just curious.

It's the same to me, lol
As I mentioned in another thread.

I also have been using a second email for more than one year.
And yesterday I have to replace it by primary email.

I suppose paypal was and is still updating its system.

After I corrected the email setting, orders shew up correctly as before.
But a few hours later some orders missed again, no information posted on my site. No ordre numbers.

My paypal IPN was off.

I think I will turn it on to see if it make sense.

BTW, are you also using your zen-cart with your paypal IPN off?

Nope my PayPal IPN is on.

Well I guess it makes me feel better knowing that I am not the only person with this issue and that I am not going crazy, LOL! I think I will still have one of my customers with this problem though simply because she was having issue long before this whole mess with the primary account came up. Going to keep digging for the answer.

Thanks for the help with this everyone.

This time it differs.

I got an order at my zen-cart admin place.
But there is no payment to my paypal from that guy.

Then I review my order history,
I find a payment that made yesterday, which had no order information at my zen-cart that time.

Then I checked the transaction ID of the previous payment and the current order, they matches.

So I think this order comes 10+ hours later than the payment. lol

Anyone know what paypal is doing around these days?

I'm having similar issues, I've examined my log files after throwing a couple of test IPNs at the system from the Paypal sandbox (now bearing in mind I left my Paypal credentials the same (didn't load new ones from the Sandbox! So this maybe an issue? But I wasn't sure and Paypal's sandbox kept giving me errors) Here is a portion of the log:

IPN FATAL ERROR :: Could not establish fsockopen.
Host Details = http://proxy.shr.secureserver.net:3128 (0) Unable to find the socket transport "http" - did you forget to enable it when you configured PHP?

http://www.sandbox.paypal.com/cgi-bin/webscr
Trying again without SSL ...

Apr 20 2010 23:44 -- IPN FATAL ERROR :: Could not establish fsockopen.
Host Details = http://proxy.shr.secureserver.net:80 (0) Unable to find the socket transport "http" - did you forget to enable it when you configured PHP?

http://www.sandbox.paypal.com/cgi-bin/webscr
Trying again without specified protocol ...

Apr 20 2010 23:44 -- IPN FATAL ERROR :: Could not establish fsockopen.
Host Details = proxy.shr.secureserver.net:80 (110) Connection timed out

https://www.sandbox.paypal.com/cgi-bin/webscr

Any tags I should edit in my Php.ini file? Or should I try again with the credentials changed? In the past however, even with the credentials setup and real IPNs flow their have been issues.

Two options:

a) RECOMMENDED: upgrade to v1.3.9
or
b) at least patch your site to work on GoDaddy or to avoid errors occurring as a result of old requirements built-in because of GoDaddy's odd configuration: http://www.zen-cart.com/forum/showthread.php?p=612520#post612520 (and all other posted fixes which you find relevant ... noting that they're already included in v1.3.9)