What are the downsides to storing money values as cents / minor units?

Question

I have noticed that some financial api\'s like stripe api for credit card processing require that amounts be passed in as cents, this seems like a good simplification and it is

Answer 1

1. What are the downsides of storing money as cents.

Not that many. Storing money as cents simplifies calculations and makes it precise. As mentioned quite a few times, never represent your money as floats in calculations.

2. Are there specific operations that are hard to do with money as cents?

You would need eventually present the amount to users. And the values then need to be formatted according to the formatting for a specific currency.

3. Does money stored as cents work with all world wide currencies or does accounting for different currencies become a gigantic mess of if else special cases?

Working with real currencies and supporting multiple currencies in an application might require you to store money in 100th of cents to support currencies like CLF with 4 decimal places or BHD with 3 decimal places. See ISO-4217.

4. Is there a good java library for working with money as cents?

Not that I'm aware of. What kind of support are you looking for in such library?

Answer 2

Trade is usually computed by dollar (1 Australian Dollar = 0.94 US Dollars at time of posting). It is trivial to say that 100 Australian cents = 94 US cents, however there are many currencies where cents do not exist. The primary advantage of cents is that you can store values as integers, whereas dollars must be stored as floating- or fixed-point decimal values.

A downside of storing monetary values in cents (as integers), is that rounding errors can occur. For example 20 Australian Cents = 18.8 US Cents.

For currencies that have cents, it will probably often be simple to do computations, but a lot of the time you will have to convert to dollars (or primary currency, for non-dollar currencies), as that is what the exchange rates are based off.

Personally, I'd always use the primary currency over a subdivision, they're easier to work with, less prone to rounding errors, and easier to read ($150.50 is easier to read than 15050¢.)

Answer 3

The downside is that you can't represent fractional units. This is a problem if you are performing interest calculations or the like. However, if you are making a "real money" transaction, this issue goes away.

It doesn't matter if the currency is non-decimal - as long as there is a smallest unit, you can use that to represent any other amount. You may need to be a little more clever in how you display in human readable format, if that is relevant, but that's a separate issue.

In fact, using the smallest unit is likely to simplify performing conversions, as you can work out the conversion rate between the smallest unit of each currency pair. Of course, once you're into conversion rates, you'll end up needing to use BigDecimal (or the like) again.

So, in summary, it may well be best to use both smallest unit as your denomination, AND to use BigDecimal to handle fractional parts if they can arise. Don't use IEEE floats, because they can't represent all decimal numbers correctly. This will lead to the kinds of errors that will upset someone.