Shipping rates changing

[stewartm]

Hi,

I have recently started having a strange problem with shipping rates. Rates were working fine, however, are now randomly giving wrong amounts. For example minimum shipping is £3.50 however some customers get charged £3.00. Shipping should show up as:

mainland UK delivery: £3.50

in the checkout, the ones charged correctly show fine. Incorrect ones show with a number:

3:£3.00

This is the same with all rates and may not be confined to just the table rate as free shipping is also affected (but ony a cosmetic impact)

Free delivery: £0.00 sometimes shows as 0:£0.00

Have recently moved to the new Paypal IPN modules with a the rest of the site still to be updated. This may be the cause, butno idea how to fix.

I have been able to reproduce this in testing by going through checkout to confirmation and then going back to payment information (either via the back button or using the breadcrumb link) and back to confirmation. The shipping has then changed.

Any ideas or help would be most appreciated.

Thanks

Stewart

[pgmarshall]

Stewartm,


3:£3.00This looks like a 'case' statement output which might have failed ...

Which shipping module are you using?

Have you made any code changes?

Do you have a url and a way to replicate the issue?

Regards,

[stewartm]

Hi,

Thanks for your reply, I was just ignoring the last post rather than wasting my time.

I have 2 custom table rate v1.1 shipping modules and Free Shipping w/ Minimum Order Amount

I only started noticing this since moving to PayPal IPN v2.4

I will PM you details of the URL and steps to reproduce as this is on a live site.

Thanks

Stewart

[fourmat]

I have been having the exact same problem for quite some time now. I had thought it was because I had a highly modified version of OSM, but now I'm not so sure. For me it's happening when a customer places an order, then uses paypal (IPN).

If they hit the back button, or choose to return to the site to make a change without completing the payment, it takes them back to the order confirmation screen, where the shipping method now becomes the first digit of the original price of the shipping, and the price of shipping is an amount equal to the first digit of the original shipping amount.

For instance; If shipping was $7.68 Via UPSXML or USPS, then the shipping method and amount now becomes 7: $7.00. If the shipping amount was $11.68, the the method and amount become 1: $1.00.

I have put a patch on one part of the problem where I edited the return link to take the customer to the checkout_shipping page when they click the return button in paypal, but that doesn't address the root of the problem and it still doesn't do anything about the back button.

If they don't go back to the site, they and process the payment normally, everything goes through just fine and the amounts are good. But if they go back, then complete the order through paypal or another means, then the amount they get charged is the amount that shows when the back button is clicked.

I have been scratching my head for a long time on this issue. There is a transposition in the variables stored somewhere, but I can't seem to pinpoint where they are, or figure out how to view what variables get stored where.

Is there some method I can use to see what variables are stored by the browser that will be used by when the back button is clicked?

[stewartm]

Hi,

Thanks for your reply. This would seem to indicate that the problem is somewhere with Paypal IPN rather than shipping at all. It would make sense if this thread could be moved the the Paypal IPN board if possible.

I wonder if it is to do with the order being stored prematurely by this module?

Thanks

Stewart

[fourmat]

I am also using Paypal IPN v2.4

Yes I do believe it is the payment module not handling things right. I had gone to v2.4 to fix an issue with the coupon/gift voucher system. It could have something to do that that also. I'm not sure. Which version of OSCM are you using?

[fourmat]

Actually, I just realized that I was using the Paypal For CCGV module, which might have been named 2.4 at some point.

I've been able to narrow some things down.

When I set the module Transaction Type to Per Item, it will transfer information for a standard order fine (including hitting the back button), but it will not handle the discount coupon correctly when transferring the total to paypal (which is a known problem and in the instructions)

When I set the module Transaction Type to Aggregate, it will calculate the totals fine and transfer to paypal, including the proper coupon total, but chokes on the back button.

I will work on this more, but if anyone else might have some insight here, jump in.

[stewartm]

Thanks for your reply. I will try moving to per item as I have disabled coupons and vouchers anyway.

I am using oscMax v2.0 RC3.

Thanks

Stewart

[stewartm]

I can confirm that moving to per item within Paypal IPN resolves this issue.

Thanks

Stewart

[fourmat]

It has been a while since this last post, and I still haven't find an ultimate solution to the problem. But I did create a stopgap that will help reduce the number of bad Paypal orders with messed up shipping.

In the checkout_confirmation.tpl.php code I added a javascript popup alert box warning the customers not to hit the back button when they are in paypal. I know you can't fix stupid, but hopefully people will read the box and find the "cancel" link on the paypal page to return to the site.

in checkout_confirmation.tpl.php
FIND:

echo tep_image_submit('button_confirm_order.gif', IMAGE_BUTTON_CONFIRM_ORDER) . '</form>' . "n";CHANGE TO:

if ($order->info['payment_method'] == 'PayPal'){
echo tep_image_submit('button_confirm_order.gif', IMAGE_BUTTON_CONFIRM_ORDER, 'onclick=
"alert('You are about to be taken to Paypal to complete your order.n Do not press the back button.n If you must return to this checkout page, find the link that says Cancel and Return.nnClick OK To Continue to PayPal.')"') . '</form>' . "n";
}
else{
echo tep_image_submit('button_confirm_order.gif', IMAGE_BUTTON_CONFIRM_ORDER) . '</form>' . "n";
}

[stewartm]

Looks like there is now an "ultimate Solution" see 0000607: shipping costs mangled - osCmax Bug Tracking System (http://bugtrack.oscmax.com/view.php?id=607)