Hmmm.. haven't changed the cart setup at ALL.. now users are reporting that when they click "Pay by Credit card" theyre getting this errer message from Authorize.net:
"The following errors have occured.
(53) Amount is missing or not valid."
Tried it myself.. added items.. all goes smoothly until the LAST page on our site.. click on "Pay by Credit card" - doesn't seem to be passing any/correct info to Authorize.net
Can be tried out at:
ANY help greatly appreciated!!
OK.. made ONE discovery.. it seems Authorize.net must have made some change and not told anyone.. arrgghh.
What's happening is that when the uShop tries to pass a fraction of a cent to A/N, the error 53 is generated.
Example: one of our 'products' is $29, but with shipping caluculated, uShop is trying to pass an amount of "32.005" in the hidden variable totals_total_with_shipping_tax to authorize.net and then it's rejected - Error 53.. although ordering TWO of this item results in a round number and is accepted.
This USED TO work ok.. (up to today). Is there anyway to fix this and have uShop round off and only pass only TWO significant decimal places to Authorize.net?
We're using the shipping method "Subtotal Formula" with the following variables: $0.065,$3.00
THANKS IN ADVANCE!
Anyone find a solution to this? The error is in the passing of more than 2 digits behind the decimal point.
Is there a quick fix to force rounding off?
Please help, we have many carts running with these same errors occuring since the AuthNet change.
I haven't found a solution yet.. and haven't rec'd a reply from either uBurst or Authorize.net (of course hoping for a cooperative reply from Authnet is probably dreaming) - I'm sure we'll hear from uBusrt as soon as they can develop some new code to correct this.
Anyway.. after what SHOULD have been a $3,000 - $5,000 weekened (but was ZERO.. arrgh) here's what I did-
I used excel to help me build a HUGE 'Subtotal Table' rather than using the Subtotal Formula (Which generates the totals in excess of 2 decimal places) and used that instead..
[An explanation of the Subtotal Table can be found at: http://www.uburst.com/uShop/reference/users_guide.html]
For economy's sake, I built it in $20 increments for purchases up to $1,500 like this:
$0=$3,$20=$4.95,$40=$6.25,$60=$7.55,$80=$8.85,$100=$10.15,$120=$11.45, ad infinitum..
Where usually we charge a subtotal formula of $3 + 6.5% of the total, for the workaround I had to do some averaging so my table didn't become too huge.. so in the example above, the $4.95 charge for anything from $20 to $40 is really the correct charge for $30
My excel formula (in cell B2) starting at the first increment looked like this:
Where cell A2 was my starting number of 20.. I then copied this for about 75 rows to get the 2 colums, pasted this stuff into a text editor, added the equal signs and commas and removed the returns.
(and for the $0=$3, I just picked something and put it in, the calc doesn't work on zero)
I then repeated the process for our higher priced RUSH delivery method.
Arduous work, and admittedly won't be an EXACT shipping amount because of the averaging, but should be within a few dollars, and at least got us up and running again... until we HOPEFULLY hear about a patch to uShop soon :)
Anyway.. HOPEFULLY it helps someone caught in this mess!
Yes, it would have been nice to have been warned of the Authorize.Net change. But, in any case:
STEP 1: Make a backup of your current ushop-lib.pl script ... just in case.
STEP 2: Open your ushop-lib.pl script with any text editor such as WordPad.
STEP 3: Do a search on the following text:
(You should see two lines that use "x_Amount".)
STEP 4: Immediately before the first "x_Amount" line, add this line:
$totals_total_with_shipping_tax = sprintf("%.2f",$totals_total_with_shipping_tax);
STEP 5: Immediately before the second "x_Amount" line, add this line:
$totals_total = sprintf("%.2f",$totals_total);
STEP 6: Save the script... as TEXT if your editor asks... and try it out!
We'll also try to get this work-around into the standard release sometime later this week.
Thank you, thank you!
BTW: I notice that ushop-lib.pl has (3) instances of x_Amount, one more than what you mentioned. I followed your proceedure on one of our carts and made the change to the first two instances in that order, disregarding the third. Was this correct?
There actually is a second set of "x_Amount" lines... (so I guess that makes 4 total)... but that second set is for interfaces to "Planet Payment". If you want to make the same change there you can, but if you're using Authorize.Net then only the first set of "x_Amount" lines are really being used.
Bill, the first set was all it took. It's working fine and has been since the fix. Thanks again ... pretty painless actually!