Removing decimals charges the change?

I'm having a problem after removing the decimals from my prices to make them nice round numbers. Everything looks good all the way through until I receive my merchant email receipt from Authorize.net.

To set it up I did this:

1. I went into: admin panel/ localization / currencies
2. I selected USD then clicked Edit. In Decimal Places field I changed 2 to 0.

Everything displays without the decimal to give me nice and clean numbers, even on the Zen Cart order receipts... But when I get my merchant receipt I see that the actual amount with change has been charged. For example, instead of $32, I see $32.40 in the actual charge amount.

Any idea why this would be happening?

All you changed was the display price. The actual price is still whatever you put when you entered the product.

I see... Ok so I would need to change all of the product pricing and attributes... Man I wish there was an easier way!

If you surf through all the similar threads you might find someone who has found a solution. I'm guessing that it would take some code to go into that table in the db and truncate every entry somehow - a solution that is way over my head.

So what's the business logic behind all of this?
It's rare, especially for a North American store, for purchases to be rounded to the nearest dollar. Hence the questions. Can you explain why you're wanting to do this?

It's more of a style and brand thing than anything else... Currently all our prices are .05 short of a dollar like 39.95. I did it for marketing reasons, to make it sound cheaper than $40, but I think that logic may be old school... At least in my opinion it is. If you take off the change it makes it a much more simple number, 3 digits as opposed to 5. Plus it makes it easy on everybody from a mathematics perspective.

I see more and more stores doing this nowadays, it's attractive imo.

So I've noticed a problem when doing this... Even if I take out the decimals, what happens when we have a 15% sale on an item that costs $110?

This would make the product price $93.50... Which would also show on the customer email receipt and in Authorize.net. It seems there is no way around this?

Is there???

swamyg1:

I did it for marketing reasons, to make it sound cheaper than $40, but I think that logic may be old school...

Although it may be old school logic, it STILL WORKS (which is why you still see it almost everywhere).

Please don't ask me why it works (I've never really understood it myself because I always mentally round up anyway), but my wife is a classic example where it does work. Time and time again she'll see a product advertised for (say) $39.95, yet when she tells me about it the price is 'a bit over $30' (rather than just under $40). Seriously, that 5cents difference in actual cost can amount to ~$10 in perceived cost.

People are weird.

Cheers
Rod

And people will still cross the street to buy gasoline from a station which advertises a price of $3.98.9 rather than buy it at $3.99.

I've decided to go with prices like $39, $49, etc. I think this does what I'm trying to do while still using old fashioned marketing tactics.

Now the problem I'm running into is that If I change the decimal to 0 in currencies, I still have the authorize.net problem when we have sales on our site.

For example, a 15% sale on a $39 makes the product $33.15 which authorize.net will charge even if the price displays $33 on my site. I cannot have it show one thing on my site, and charge customers another... Is there any way around this?

The only thing I can think of is hiding the decimals if .00 on product pages and listing pages.... But not on the checkout page. This thread shows how to do it on attributes, but does anybody know how to do it on the product and listing pages?

What happens if tax is gonna be charged on the order?
Are you planning to insulate the customer from all their tax liability, and pay the differences yourself?

It's funny how opposed some people are to this concept, I find it frustrating! It's not not like there aren't other sites doing this. It shouldn't be overly complicated.

I said ONLY on product pages and listing pages, not the checkout page. Maybe you should reread my post instead of getting so defensive? Geez

swamyg1:

It's funny how opposed some people are to this concept,

I think 'opposed' is the wrong word. We are merely giving you the benefit of our own experience. One could ask why you are so opposed to taking our advice?

swamyg1:

I find it frustrating!

As do we. Look at it from our POV. You have asked us how you can do something that we know (from experience) isn't going to be of any real benefit to you, and in fact is almost certainly going to be detrimental. In spite of this it appears that it is still something you plan to do, and you somehow expect us to go out of our way to help you go down the path that we are advising against.

How, in good consciousness can we help you do something that we know is bad for you?

swamyg1:

It's not not like there aren't other sites doing this.

Agreed, but that doesn't mean it is a good idea.

swamyg1:

It shouldn't be overly complicated.

Ergo, you shouldn't be having a problem implementing it.

However, even this short thread is indicative of the fact that it isn't that simple either.

I suppose it could be that simple if zencart were 'brain dead' and didn't deal with mundane things such as sales tax or discounts, then everything could be a nice round number, but when these things are factored into the equation you simply don't end up with nice round numbers, which means that they need to modified by additional code.

swamyg1:

I said ONLY on product pages and listing pages, not the checkout page. Maybe you should reread my post instead of getting so defensive? Geez

In other words, you will be quite happy for your customers to see one set of figures on the product and listing pages, but have slightly different figures presented on checkout? I suppose as long as the checkout amounts total less than the product/list prices you'll not get any complaints, but doing it the other way will have people screaming at you left, right and center.

DrByte has already asked about the tax issue, so I'm going to ask you about postage costs. Will you be wanting to have nice round figures for these too? Wouldn't it be counter productive to sell a product at $40 (because you don't want $39.95) and then charge (say) $2.65 for postage? Unless you round these up too, the customer is still going be be charged an odd amount on checkout.

The point I'm getting to here is that the final cost involves more than just the product cost (usually), which means you need to apply the same 'rules' to all costs, else you will be defeating your aim anyway.

swamyg1:

For example, a 15% sale on a $39 makes the product $33.15 which authorize.net will charge even if the price displays $33 on my site. I cannot have it show one thing on my site, and charge customers another...
Is there any way around this?

It's code, therefore it is possible.

The problem is that, zencart, like every other store, is designed for accuracy, and what you are wanting to do is make it inaccurate. How can this ever be a good thing?

Cheers
Rod

swamyg1:

If I change the decimal to 0 in currencies, I still have the authorize.net problem when we have sales on our site.

swamyg1:

I said ONLY on product pages and listing pages, not the checkout page. Maybe you should reread my post instead of getting so defensive? GeezUm .... now you're contradicting yourself.
You SPECIFICALLY said "I still have the authorize.net problem" ... so, that's payment (ie: checkout), and NOT merely "product pages and listing pages".

My last post was specifically responding to your authorize.net comment.

I'm not opposed to your choice of rounding to the nearest dollar. But I'm absolutely not going to knowingly give you any code suggestions that would shoot you in the foot.