Pay Pal IPN is not carring over my orders

Dr. Byte,
Just ran a purchase test on my STAMP site using PayPal Express. It ran PERFECTLY!:clap: . This means that the database MUST be working correctly. Another point before I forget. Changing the code for DESCRIPTION by removing that ONE PERIOD did the trick! No more duplication of the item descriptions in the ORDER CONFIRMATION emails!:smartalec: . This completes the mod! I will PM you a notepad file with the complete instructions for your approval and maybe we can post it for others to use. Let me work on it a while more to be sure everything is in order.

I seriously think that there must be something in the update patches somewhere that has changed how PayPal IPN module is working with the MySQL 5.0 version. Effecting the database security some how as the 5.0 version is more security oriented. Reading other posts this does not seem to effect 4.xx versions. I will run an IPN test on my STAMP site tommorrow and I do have a feeling that the same bug effect will happen there too. Will post results ASAP. We are close to perfection I think.:lamo:

Hello again Dr. Byte,
It does appear that this is an update patch problem:huh: . At least with the MySQL 5.0 database. I just ran the IPN test on my STAMP website and the results are exactly the same as what happened on Wildercraft. Right down to the error on the return URL. Am adding the code posted previously here to correct the return URL error so at least the customer will be returned to the website. Am wondering if that bit of code can be utilized somewhere else in the update patch to force the database to store the new_orders info?
I guess the next step is in your court now Dr. Byte:lookaroun . I hope that I have given enough info to help. Other than this I say the cart is a perfect program!:smartalec:

golowenow:

down to the error on the return URL. Am adding the code posted previously here to correct the return URL error so at least the customer will be returned to the website. Am wondering if that bit of code can be utilized somewhere else in the update patch to force the database to store the new_orders info?What do you mean by an error on the "return URL" ?

When the customer pays they are supposed to be redirected back to the payment success page on the website. It does not do that without the code you added:

Hmmm .... lovely MySQL 5 strict mode ...

Try editing /includes/functions/whos_online.php
line 47 says this:
Code:
$wo_last_page_url = (zen_not_null($uri) ? $uri : 'Unknown');try changing it to this:
Code:
$wo_last_page_url = (zen_not_null($uri) ? substr($uri, 0, 254) : 'Unknown');__________________

After adding that it works fine. That is what I was meaning by the return URL. Sorry for throwing ya:unsure:

Okay ... that's not a "returnURL" (as in the PayPal RETURNURL parameter) bug ... that's a whos-online bug which manifests when attempting to store the referrer URL for purposes of tracking whos-online activity.
It's fixed in the next Zen Cart release.

golowenow:

I seriously think that there must be something in the update patches somewhere that has changed how PayPal IPN module is working with the MySQL 5.0 version.did you have any PayPal patches installed before this happened ?
I'm trying to figure out which patch introduced the problem ...

I'd be interested in knowing if your server is showing any errors in the apache errorlog when the IPN attempts to process but aborts.

Also, try running this in phpMyAdmin and then do another test transaction:

ALTER TABLE paypal CHANGE reason_code reason_code varchar(40) default NULL;

Also, please either "Install" or "Edit" the PayPal Express Checkout module so that it touches up several other database table fixes. If you don't want it installed, you can "Remove" it again after installing. (Install or Edit forces the database-table fixes to run, and affects both modules.) This is a step that should be run whenever the patch gets applied.

Back from work. OK, cannot say which patch introduced the problem because I do not think I have had any customers on the STAMP side use it. Either they paid with the Express module or by money order. The wifes site which only uses the IPN module had her first and only sale when I discovered the problem. The server (which is called Abyss webserver) shows no errors in the fast CGI log. I will try to run the SQL query on the stamp sites database and run another test to see if it changes will put the IPN module in debug mode and post the results. Will post within the hour.:unsure:

OK ran the SQL query on my Stamp sites database and ran test. No luck.:huh: . I noticed that when I was directed to the PayPal payment page that it only shows in the item area Golowes Collector Stamps Purchase Item #1 and shows only a total for item does not separate the shipping ie; the shipping is 0.00 and then the grand total.Here are exampe images from running IPN on my wifes site.

This is what is in the checkout page on step 3.

This is what is on the PayPal site.

Here is the IPN debug log from the Stamp purchase.

Apr 09 2007 18:39 -- IPN PROCESSING INITIATED.
*** Originating IP: 216.113.188.202 notify.paypal.com

Apr 09 2007 18:39 -- IPN NOTICE :: ipn_application_top -> language files okay

Apr 09 2007 18:39 -- IPN INFO - POST VARS received (sorted):
Array
(
[address_city] => ???????
[address_country] => United States
[address_country_code] => US
[address_name] => Brenda ????
[address_state] => WA
[address_status] => confirmed
[address_street] => ??????????
[address_zip] => ??????
[business] => [email protected]
[charset] => windows-1252
[custom] => zenid=0hbp4v4lmmhepn09e8qtql9pm5
[first_name] => Brenda
[item_name] => Golowe's Collector Stamps Purchase
[item_number] => 1
[last_name] => ????
[mc_currency] => USD
[mc_fee] => 0.40
[mc_gross] => 3.50
[notify_version] => 2.1
[payer_email] => [email protected]
[payer_id] => ANKECA9KZT4V2
[payer_status] => unverified
[payment_date] => 18:39:14 Apr 09, 2007 PDT
[payment_fee] => 0.40
[payment_gross] => 3.50
[payment_status] => Completed
[payment_type] => instant
[quantity] => 1
[receiver_email] => [email protected]
[receiver_id] => NF2U526WE9V4Q
[residence_country] => US
[shipping] => 0.00
[tax] => 0.00
[txn_id] => 0TT528704A975920F
[txn_type] => web_accept
[verify_sign] => An5ns1Kso7MWUdW4ErQKJJJ4qi4-ADyFFb4dqerXFKlrykaeyytMaKio
)

Apr 09 2007 18:39 -- IPN INFO - POST VARS to be sent back for validation:
To: www.paypal.com:80
POST /cgi-bin/webscr HTTP/1.1
Host: https://www.paypal.com
Content-type: application/x-www-form-urlencoded
Content-length: 919
Connection: close

Array
(
[mc_gross] => 3.50
[address_status] => confirmed
[payer_id] => ANKECA9KZT4V2
[tax] => 0.00
[address_street] => ?????????
[payment_date] => 18:39:14 Apr 09, 2007 PDT
[payment_status] => Completed
[charset] => windows-1252
[address_zip] => 98584
[first_name] => Brenda
[mc_fee] => 0.40
[address_country_code] => US
[address_name] => Brenda ????
[notify_version] => 2.1
[custom] => zenid=0hbp4v4lmmhepn09e8qtql9pm5
[payer_status] => unverified
[business] => [email protected]
[address_country] => United States
[address_city] => ????????
[quantity] => 1
[verify_sign] => An5ns1Kso7MWUdW4ErQKJJJ4qi4-ADyFFb4dqerXFKlrykaeyytMaKio
[payer_email] => [email protected]
[txn_id] => 0TT528704A975920F
[payment_type] => instant
[last_name] => ????
[address_state] => WA
[receiver_email] => [email protected]
[payment_fee] => 0.40
[receiver_id] => NF2U526WE9V4Q
[txn_type] => web_accept
[item_name] => Golowe's Collector Stamps Purchase
[mc_currency] => USD
[item_number] => 1
[residence_country] => US
[payment_gross] => 3.50
[shipping] => 0.00
[cmd] => _notify-validate
)

Apr 09 2007 18:39 -- IPN INFO - Confirmation/Validation response
HTTP/1.1 200 OK
,Date: Tue, 10 Apr 2007 01:39:18 GMT
,Server: Apache/1.3.33 (Unix) mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a mod_ssl/2.8.22 OpenSSL/0.9.7e
,Set-Cookie: cookie_check=yes; expires=Fri, 07-Apr-2017 01:39:18 GMT; path=/; domain=.paypal.com
,Set-Cookie: Apache=71.227.227.54.47571176169158559; path=/; expires=Thu, 02-Apr-37 01:39:18 GMT
,Connection: close
,Transfer-Encoding: chunked
,Content-Type: text/html; charset=UTF-8
,
,8
,VERIFIED
,0
,

Apr 09 2007 18:39 -- Breakpoint: 1 - Collected data from PayPal notification

Apr 09 2007 18:39 -- IPN INFO :: Transaction email details.
From IPN = [email protected] | [email protected]
From CONFIG = [email protected]

Apr 09 2007 18:39 -- Breakpoint: 2 - Validated transaction components

Apr 09 2007 18:39 -- Breakpoint: 3 - Communication method verified

Apr 09 2007 18:39 -- IPN NOTICE :: Could not find matched txn_id record in DB. Therefore is new to us.

Apr 09 2007 18:39 -- Breakpoint: 4 - Details: txn_type=unique ordersID = 0 IPN_id=0

Relevant data from POST:
txn_type = unique
parent_txn_id = None
txn_id = 0TT528704A975920F

Apr 09 2007 18:39 -- Breakpoint: 5 - Transaction type (txn_type) = unique

Apr 09 2007 18:39 -- IPN INFO :: Currency/Amount Details:
PayPal email address = [email protected]
| mc_currency = USD
| submitted_currency = USD
| order_currency = USD
| mc_gross = 3.50
| converted_amount = 3.50
| order_amount = 3.5

I uninstalled before applying the March 21 patch and reinstalled both IPN and Express modules after applying the last patch issued (March 21).
Hopefully this will give a clue?
Best!
John:lamo:

I'm having the same problem, orders won't post in ZC. I have not had ANY post for me, ever, so it's not intermittent for me like some folks have said for theirs. New install of 1.3.7, patch applied from the 21st with no improvement. DrByte, I PM'd you my log. I note that my log stops at Breakpoint 1. Other people here have more info after that. Clue?

RCWalter? Please post your system stats. Are you running MySQL 5.0? Is your webserver based on your PC? ie; Abyss or Apache? ect; ect;. Dr. Byte needs this info.
Thank you. John

Sorry, I should have included that.

** Server OS: ** Linux 2.6.19-1_3.BHsmp
** Database: ** MySQL 4.1.21-standard
** PHP Version: ** 4.4.6 (Zend: 1.3.0)
** HTTP Server: ** Apache/1.3.37 (Unix) mod_fastcgi/2.4.2 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a PHP-CGI/0.1b

Hosted by bluehost.com

I found this in my php error_log:
[10-Apr-2007 16:25:13] PHP Fatal error: Call to a member function on a non-object in /home/me/public_html/zencart/includes/functions/functions_email.php on line 226

Might that be calling the email to me or the customer, and when it fails, it dies right out of the php before completing the next step...which may then be posting the order?

Well, now that I'm looking back above at the debug log posted by golowenow, I see that the next thing after Breakpoint 1 is
IPN INFO :: Transaction email details.
My log ends at Breakpoint 1, and I have that Fatal Error in functions_email.php

I'm starting to suspect there's something wrong. :)

But, it works fine if I use check/money order instead of PayPal. What's the difference, I would think it would fire off the email call either way?

Whooooo! It's working!
No idea now what did it. As a result of searching all through the modules/payment/paypal.php files looking for email calls, I got the bright idea to turn off the "email" portion of the "log and email" debug in the paypal module. So now it works.

Looks like something I did between turning on debug and turning it off must have fixed it, but at the same time the email portion double-broke it!

I did things such as installing the patch, and installing then removing express checkout. So, I don't know which of those (or something else I did) was the trick. So I just won't use the email portion of the debug. I still don't get it though, I was getting the emails just fine.

RCWalters? Are you saying that the IPN module is working correctly now? Is it listing items in your invoices that were purchased? Or does the invoice look like mine above?
Thank you for info:smartalec:

A question for Dr. Byte. I was recently having a problem with the sessions table crashing. I changed the sessions cache from

define('STORE_SESSIONS', 'db');

to

define('STORE_SESSIONS', '');

in my config files. The sessions files are now being stored in the CACHE folder of Zencart. It appears that all is working correctly there. PHP is adding and removing them as it is supposed too. Would this effect IPN?:unsure:

STORE_SESSIONS settings should have no impact on IPN handling.

You could always try changing it back for a test ....

The rcwalters problem, while their first post said "I'm having the same problem", was apparently related to the original poster's discussion for this thread ... which has long since been lost with golowenow's specific problem. For them, no orders were being stored to Zen Cart due to a PHP error.

The golowenow problem is failing mid-stream of storing the order details ... a PHP or MySQL error is the likely cause, but the failure is happening in a very different place for different reasons.

OK Dr. Byte.
Changed the setting from '' to 'db' in both config files on Wildercraft and ran test. Same results. No items listed in invoices and items not changing to "SOLD".:( Guess that is not the problem. Was looking back at version 1.3.0 Zencart IPN_main_handler.php. With the new Express module that sure has changed! When I was running that cart IPN was working ok. But then too I was running MySQL 4.xx and an older version of PHP. Looking forward to more info and tests:yuck: . Each test is costing me on PayPal as I have Premier accounts and thus have to pay fees LOL. Good luck on researching this. Wow! a lot of views on this thread aye??:smartalec: