Ubercart erroneously warning that payment for order did not equal total in log when using Paypal WPS

I'm sure it's a rounding error. Does this patch help?

testing the patch & awaiting a PayPal order that might require rounding, but previous orders that would have required rounding do appear as the OP's so i'll confirm soon

the first and only PayPal order after the patch was applied, resulted in a "IPN attempted with invalid order ID."

Message Receiving IPN at URL for order *. (didn't pass an order#?)

never had this before, don't believe that any rounding would have been necessary.The PayPal order from ½ hour before applying the patch went through fine

I had to undo the patch as the rounding error is less severe than a lost sale at the moment

Hi
I am also getting this warning on all PayPal orders, only using PayPal Standard. It looks like this check and warning was just add in version 2.4.

The problem here is of course rounding.
In my case it was California(8.25% or 9.5%) taxes applied to the order that caused the value stored in order->order_total to be a non-rounded value, as opposed to the payment amount coming in from paypal.
THe database(and order->order_total) contained non-rounded value, where as payment amount coming in from paypal was rounder.
Its a problem with Ubercart Taxes modules as IRS does say that you need to round to the nearest dollar. There is absolutely no reason to store non-rounded value in the database

@vladgur: So does the patch in #1 fix it for you, or not?

I'm also getting this error, and there is no rounding involved with my orders as there is no tax applied.

@checkmark: Did you actually apply the patch and test it?

@TR: no, because of comment #3 I'm waiting for the patch developer to update it.

I'm having this same problem as well. Rather than losing transactions per comment #3 i'm waiting for an update as well. Thanks for the great work everyone.

on a side note, I'm showing stock being decremented twice in conjunction with this- even though only 1 item was ordered:

Order Admin Comments:
10/27/2010
3:17:30 PM - The stock level for HD-DC-Lanyard-Drop has been decreased to 9.

10/27/2010
3:17:31 PM - PayPal IPN reported a payment of 11.28 USD.

10/27/2010
3:18:21 PM - The stock level for HD-DC-Lanyard-Drop has been decreased to 8.

10/27/2010
3:18:23 PM - Order created through website.

Log Info:
Date Wednesday, October 27, 2010 - 15:17
User Anonymous
Location http://www.quackerequipment.com/uc_paypal/ipn/5
Referrer
Message Payment for order 5 did not equal the order total.

------------------------------------
Using:
Drupal core 6.19
Ubercart 6.x-2.4
Ubercart Ajax Attribute Calculations 6.x-2.0
Ubercart Custom Price 6.x-1.x-dev (2010-Jul-11)
Ubercart Dependent Attributes 6.x-1.0
Ubercart Discount Coupons 6.x-1.3
Ubercart Discounts (Alternative) 6.x-2.x-dev (2010-Aug-24)
Ubercart Fee 6.x-1.0-beta2
Ubercart Out of stock Notification 6.x-1.4
UC Upsell 6.x-1.21
FedEx Shipping Quotes for Ubercart 6.x-2.0
Token 6.x-1.14
Rules 6.x-1.3

Is it possible this could have anything to do with updates on PayPal's end? I noticed the user interface when submitting payment via paypal WPS has recently (not sure how recently) been updated.

This happens for me too using PayPal WPS (and uc_vat if that matters).

Any ideas for a fix yet?

@demm: Did you try out the patch?

hi,
I tested the patch above and it works. That's a rounding issue in my case.
Thank you to TR.
Ksin

Yes, it seems the patch has fixed the error messages in the log.

In my case I followed a wrong advice to bulk update all prices. In the MySQL query they forgot to include rounding (see my post). Now the database is full with prices of 3 or more digits behind the comma, while my currency only allows 2. There is no tax calculation in my case. The order total that was sent had more then 2 digits. Apparently Paypal applies a rounding before they process the payment and the rounded value is confirmed through IPN. That's why the check in the Paypal module fails.

I don't think this patch is the right way to solve this. It is trying to fix the symptom, not the cause. Better would be when an order is stored in database with rounded values. Then the total amounts will match exactly and there would be no need for this patch.

I therefore changed this as a bug in the order system, but there might be rounding bugs elsewhere (cart? conditional actions?) . The bug is that Ubercart is not obeying the settings in admin/store/settings/store/edit/format where you can set the number of digits.

When somebody adds an item to cart, and that item in database would have a price with more then the set digits, then it should round to the set number of digits before it is added to cart and the order. The same should happen with tax and any other calculation that can have results of more then the set number of digits. All calculation results should be rounded to the set number of digits. As a logical consequence the order total will have right number of digits and there will be no need for a fix in Paypal module. It is not a bug, it is rather a test that made us discovered the underlying problem.

bump.

Still having this issue after rounding all my prices. Would appreciate some activity or at least some comments.

This one crept up on me when I upgraded from 2.2 to 2.4 yesterday when I tested out a order in live. Does this error mess up any of the worklflow? Would I be better to downgrade to 2.2 or 2.3 , the site is not live and I only have a test product so not a big deal to downgrade.

@future assassin: try the patch in #1 and report if it works for you.

ñull changed this from RTBC, and is probably right in that there should be a better fix somewhere else in Ubercart, but this patch is better than nothing (if it works).

I applied the changes and no error after wards on a live test. Now the item is only $.05 and no taxes are configure but does have shipping charges. I'll do a couple more tests with a higher priced item and with taxes Canadian taxes configured later today.

Subscribe

Subscribe

As a work-around this patch is doing the job.

The question remains why we make the test a few cents weaker with this patch? It was there to check that there is any difference and now we allow small differences. Accumulated small differences lead to large differences. Most likely the test was put there originally to prevent some form of fraud, but with this patch you allow accumulated "small fraud".

Committed #1. Probably needs porting to 7.x as well.

@ñull: The test ensures the difference is less than 1 cent. Because shipping and tax modules may calculate things to a greater precision than 1 cent, but PayPal rounds to 1 cent, the values may not be exactly equal, but are close enough for us to consider them the same. This is still a bit of a hack, and the real fix is being discussed in #479784: Order rounding

Actually, the reason for this is because we're trying to compare two floats, which doesn't work very well even in the best of circumstances. Since PayPal sends payment amounts to the nearest cent, the comparison should probably check for a difference greater than half a cent. Not that it matters a whole lot since all that happens is a watchdog() message.

Committed to 7.x-3.x.