What happens if you’re sure that four decimal places is the smallest, then suddenly a partner system starts sending you 6 decimal places?

Precision should be part of the spec for integrations. With the integer multiple of minimal unit, that makes it clear in the API what it is.

e.g. it doesn't make sense to support billing in sub-currency unit amounts just by allowing it in your API definition, as you're going to need to batch that until you get a billable amount which is larger than the fee for issuing a bill. Even for something like $100,000.1234, the bank doesn't let you do a transfer for 0.34c.

For cases where sub-currency unit billing is a thing, it should be agreed what the minimal unit is (e.g. advertising has largely standardised on millicents)

Implementation of fixed point decimals, using multiple integer representations encoded within a floating point system. Nice.

Well I mean, if your minimal unit is 1c, then a price like $22.56 should be encoded as 2256 cents.

If you're doing ads and going for millicents, something like $0.01234 should be encoded as 1234 millicents.

Obviously you have to agree on what you're measuring in the API, you can't have some values be millicents and others cents.

Yeah I am more laughing that once encoded in JSON as { "p": 2256, "dp": 2 } you are using 2 floating point numbers. But JSON, and indeed JS wasn't designed.

To be clear, I wasn't advocating for flexible decimal points. There is no "dp" parameter in the solution I was proposing. It's just documented in the API that "price" is denominated in cents (or satoshis or whatever you want)

Just a note that precision is a part of the standard if you’re using the ISO 4217 standard, which defines minor unit fractions.

https://en.wikipedia.org/wiki/ISO_4217

Or choose a different standard, I don’t know what else is out there, but you probably should choose an existing one.

Then you should store the time as well, because the number of decimals in a currency can change (see ISK). Also, some systems disagree on the number of decimals, so be careful. And of course prices can have more decimals. And then you have cryptocurrencies, so make sure you use bigints

You store it as an integer, but as we just saw in the OP, for general interop with any system that parses JSON you have to assume that it will be parsed as a double. So to avoid precision loss you are going to have to store it as a string anyway. At that point it's upto you whether you want to reinvent the wheel and implement all the required arithmetic operations for your new fixed-point type. Or you could just use the existing decimal type that ships on almost every mature platform: Java, C#, Python, Ruby, etc.

In dollars, what do you get up to with a double of cents without precision loss? It's in the trillions, I figure? So a very large space of applications where smallest-denomination-as-JSON-number is going to be fine.

Prices can certainly have more decimals that cents.

If you just store cents you can't represent them. You either have to guess at the beginning the smallest unit or store the precision along with it.

Just use strings, it's much simpler.