Adyen uses integers [2]
Square uses integers [3]
So not sure that the industry would agree with you
[1] https://stripe.com/docs/api/prices/create#create_price-unit_...
[2] https://docs.adyen.com/api-explorer/Checkout/70/post/payment...
[3] https://developer.squareup.com/reference/square/objects/Mone...
a) On web api, so this is by definition data interchange, not "in a language".
b) with a currency code to cross check it.
c) implicitly "in cents" which needs further documentation - does this mean "pence" when the currency is GBP? How does this work for for JPY? BHD?
d) cannot represent fractions of a cent or penny.
So: this int plus currency code plus docs is OK but not great, a lowest common denominator format for interchange, requires further documentation and cross-checking as "100 USD" does not mean 100 bucks and the conversion is currency-specific, and cannot represent all values.
I wouldn't refuse to convert _to and from_ this format at the edges of my application, for data interchange, but the conversion to something clearer and richer IMHO should remain there.
Payment APIs are far from the only use case in fintech, for interest calculations you do have to care about fractions of a cent or penny.
In fact, if your case is "I call the stripe api" ... are you sure you're a fintech and not an online store? Get back to me when you have to interop with FiServ, MasterCard or SAP.
Point missed, they use that format _on their client apis_, which tells you nothing about what they do in the code that handles it. Now it could be the same internally, in which case the reason is "there's crap code everywhere"
Erm, did you see the quotation marks around "in cents" ? It's a _quote_ from the docs at the link. The link _that you gave_.
The issue is not "do you or I understand the difference", it's "does stripe" and "do stripe users, after reading that?"
It is not making the point that this is great.
Three additional 'mistakes' to prevent when dealing with money representations:
1. The definition of a currency might change. For example, some years ago Iceland decided to change the exponent of ISK from 2 to 0. Currencies have different versions.
2. As a FinTech you probably have integrations with many third parties, they don't change their exponents for a currency at the same time. Keep track of what third parties think the correct exponent is at any point in time, and convert between your representation and their representation. Otherwise, you'll have interesting incidents (e.g. transferring 100x the intended amount of ISK).
3. At first you think that counting minor units as an integer is enough, and then you need to start accounting for fractions of cents because sales people sold something for a fee of $0.0042 per transaction. If your code rounds all these fees to $0.00 you don't make any money.
3 - Indeed, the currency type that I referenced "is appropriate for financial calculations that require large numbers of significant integral and fractional digits and no round-off errors"
If your language has a dedicated type for monetary amounts, use that. (1)
If it does not, but you can make a value object to represent, e.g. amount and currency code, then do that.
If however, your language does not have a dedicated type for monetary amounts, or one cannot be trivially built or retrieved as a package (2), then you should ask yourself if it is really a suitable language for financial tasks.
1) https://learn.microsoft.com/en-us/dotnet/api/system.decimal
2) https://github.com/shopspring/decimal https://www.npmjs.com/package/ts-money