paypal ipn v2.4 issue with shipping costs disappearing

[eriknuds]

Hi,

I experience an issue with shipping costs disappearing when using the paypal ipn v2.4 module on oscmax v2.0.25, and here are the steps to reproduce:

First:
* Make sure you have the paypal ipn 2.4 credit card payment module enabled
* Make sure you have some some shipping method with an associated cost enabled (such as the flat rate module)

Then:
* Log in as customer, buy something, go to register, click checkout
* Select some shipping method that has an associated cost, click to continue
* Select the paypal ipn credit card payment method, click to continue
* Then at the confirmation page click the link back to "payment info" at the bottom
* Now the shipping costs have been mangled, the line is there but the name and the value is the first digit of the original shipping cost.

This is a serious error, as any customer can avoid shipping costs by doing this and then proceed to pay with their credit card!

I believe it is the paypal ipn module that is at fault because this doesn't happen when other payment modules are selected, and it happen regardless of shipping method selected. However I can't seem to locate the erroneous code, as the paypal ipn v2.4 module is a little complex and I don't know the internal workings of oscmax very well yet either.

Any ideas how to fix it?

Any ideas where in the code the error is happening?

I see that the paypal ipn module also have a php file in the ext\modules\payment\paypal_ipn-directory of oscmax - what is the ext directory structure meant for, and when is this php file used and what is its purpose?

Both the ext module and the regular module php files seem to reset a lot of variables and states and it looks kind of hairy...

[eriknuds]

Not much help on this forum...the problem can be reproduced even easier than described above - you don't have to go back to the payment info page, you can just refresh the confirmation page to see that the shipping costs are mangled (and thus can be avoided!) in any osc store using the paypal_ipn module. A pretty serious error if you ask me...

I've tracked down the problem to this line:

$shipping = number_format($order_total['ot_shipping'] * $currencies->get_value($my_currency), $currencies->get_decimal_places($my_currency));

...in process_button() in paypal_ipn.php - when I comment out that line, everything works. However I'm not sure what the purpose of the line is, and worry that commenting it out might break something else in another setting or situation. Also, not understanding all aspects of the problem, I worry that there might be more similar issues in the code as well. The line had this comment:

///CCGV extras by Alexander Dimelow - better to calculate separate otherwise the shipping Free vaucher/code never will work

...but I don't use any shipping Free vaucher/code so hopefully it will not be a problem for me anyway. My testing indicates everything I use now works as it should.

Hopefully someone can shed more light on this issue, and hopefully fix it properly as well, as this is clearly a serious bug in the paypal_ipn module.

Does anybody know where a bug like this should be reported to get the proper attention?

[ridexbuilder]

Michael is really the only person here that seems to have any deep knowledge on the PayPal stuff.
Have a look at the bugtracker My View - osCmax Bug Tracking System and SVN commits oscmax2 - Project Hosting on Google Code, for updates to PayPal. 2.0.25 has been around for quite a while now and there may be a couple of updates pertaining to IPN

[eriknuds]

I checked out the trunk with svn, the relevant code seems identical, so I submitted a bug report: 0000607: shipping costs mangled - osCmax Bug Tracking System

[eriknuds]

The issue is bugtracked here: 0000607: shipping costs mangled - osCmax Bug Tracking System

If you can't reproduce the issue it might be because of differences in currency decimal point settings. After some more research into php stuff (I'm new to php) I pinpointed and found a proper fix for the issue:

replace the line:

$shipping = number_format($order_total['ot_shipping'] * $currencies->get_value($my_currency), $currencies->get_decimal_places($my_currency));

...with the line:
$shipping = number_format($order_total['ot_shipping'] * $currencies->get_value($my_currency), $currencies->get_decimal_places($my_currency), $currencies->get_decimal_point($my_currency), '');

...that is, give the decimal point character and no thousand separator character to make the number_format() function call safe to run several times on any number and regardless of osc currency decimal point settings vs php defaults.

[eriknuds]

Arg, there was an error with the fix I proposed just above (commenting out the line still fixes the issue as well, but creates an issue with vauchers of course).

After some more research I believe I finally got the proper fix:

Replace: $shipping = number_format(...
with: $shipping['cost'] = number_format(...

How easy is that...thanks to the print_r() function which I didn't know before. Learning more php and osc every minute

[pgmarshall]

If you think you have found a bug or even better a "fix" please make sure you post it in the bugtracker so we can incorporate it into the core code.

Glad to see people hacking around with the source to fix stuff ...

Regards,

[eriknuds]

Yes:

> The issue is bugtracked here: 0000607: shipping costs mangled - osCmax Bug Tracking System


Regards,
Erik Knudsen

[wkdwich]

just wanted to double check.. is it necessary to uninstall and reinstall the module when applying this fix?? If this solves the problem I will be forever in your debt! I was just pinning the issue down to a paypal problem when another one came in:

Sub-Total: $50.00
9: $9.00
Total: $59.00

The shipping should have been $9.95 and there should have been some text there not 9:

[eriknuds]

Hi,

you don't have to uninstall/install - just correct the buggy line as described

Your example indicates you are experiencing the same problem as I did.

Replace: $shipping = number_format(...
with: $shipping['cost'] = number_format(...

Regards,
Erik Knudsen