Posted in GRC
Would you trust a financial application that occasionally calculates money incorrectly? 💰 Here is a question…
samuel watua Soita — Full Stack Software Engineer
Would you trust a financial application that occasionally calculates money incorrectly? 💰
Here is a question for developers:
Would you store a customer's payment amount using a floating-point type such as JavaScript's Number without thinking about precision?
Consider this familiar JavaScript expression:
0.1 + 0.2
The result is not represented as exactly 0.3 in standard binary floating-point arithmetic.
That might seem insignificant.
But financial calculations involve repeated additions, deductions, fees, discounts, taxes, commissions and refunds.
Small representation errors can accumulate or create unexpected rounding behaviour.
A safer approach is to define a consistent monetary representation.
For example:
- Store amounts in integer minor units where appropriate.
- Use decimal arithmetic when the calculation requires it.
- Associate every amount with an explicit ISO currency code.
- Define rounding rules centrally.
- Test fee calculations and partial refunds.
- Avoid mixing currencies in the same calculation.
And there is another important detail: not every currency has two decimal places.
Payment APIs can have currency-specific minor-unit rules. For example, Stripe documents different amount representations for zero-decimal currencies.
A payment system must understand the currency—not just the number.
Developers: how do you represent money in your applications: floating point, integer minor units, or decimal types?
#BackendEngineering #JavaScript #TypeScript #Fintech #FinancialSoftware #DatabaseDesign #PaymentSystems #SoftwareEngineering #PostgreSQL #SystemDesign #CleanCode #APIEngineering
2 reactions · 0 comments
Topics: #fintech, #javascript, #softwareengineering, #typescript, #cleancode, #apiengineering, #backendengineering, #postgresql, #paymentsystems, #databasedesign