PayPal App Standard on OSC 2.3.4 Errors (No Confirmation Email, No Inventory Reduction, Log Error for standard_ipn.php)

[beercityhooligan]

I have a client with OSC 2.3.4. I recently updated the install to include the latest version of the PayPal app, that I pulled down Saturday morning. The PayPal app zip shows version 4_039.

 

The general and PayPal standard app configuration has been completed for the PayPal app.

 

Sometimes things work fine, sometimes it doesn't. The symptoms when it doesn't are that after a customer makes a payment: emails aren't sent, and the inventory isn't reduced. The payments do still succeed in PayPal, and the status in OSC admin just sits at Processing and never updates.

 

I've been digging into this for days trying to figure it out, and am having little luck. Seems like these symptoms are common, but for a  variety of reasons.

 

Under the PayPal IPN listings, none of them show as failed.

 

One thing to note is that the PHP error_log shows the following error most times standard_ipn.php is accessed:

Fatal error: Call to a member function getCredentials() on a non-object in /home2/sitename/public_html/ext/modules/payment/paypal/standard_ipn.php on line 29

 

That line of code (line 29 from standard_ipn.php) is this:

  $seller_accounts = array($paypal_standard->_app->getCredentials('PS', 'email'));

 

After some debugging, the issue is that the _app member object of the paypal_standard object is null. Which is obvious from the error message in the log.

 

If you track it through, you see that when you create a new paypal_standard object in catalog/includes/modules/payment/paypal_standard.php via the class constructor,  it calls the constructor for OSCOM_PayPal(). If you go to catalog/includes/apps/paypal/OSCOM_PayPal.php you'll see that there is no explicit constructor function. None should be needed, as there's nothing requiring configuration/set up there. The call to new paypal_standard() in standard_ipn.php happens before the offending line 29 mentioned above, so _app should always have a value.

 

That led me to confirm that the OSCOM_PayPal file was in the correct spot, and accessible. Everything appears correct in that regard, and I don't get any kind of class not found exception being kicked out anywhere.

 

Any ideas, or things to investigate to discover the issue here would be extremely appreciated. This is driving me a bit crazy, and I'd love to have a solution (or at least a decent explanation and work around). 

[Wal]

Not helpful to you beercityhooligan, but I have the same problem. No answer for you, but will watch for any help reply from your post..

 

cheers Nev