Choose a numeric representation deliberately, and apply display rounding at the edge of your application.
Separate the value from its label
A quote displayed as 2,650.40 has both a numeric value and a formatting choice. The grouping separator and trailing zero help people read it, but they should not determine the value used for calculations. Keep formatted strings out of your arithmetic and sorting logic.
Our recommended pipeline is to validate the incoming value, preserve the required precision, calculate with an explicit numeric policy, and format only when presenting the result. Keep the source and unit alongside the price so that a correctly rounded number still has a clear meaning.
Understand the JSON boundary
RFC 8259 allows JSON implementations to limit numeric range and precision. It identifies binary64 as a common interoperability baseline and notes that integers from −9,007,199,254,740,991 through 9,007,199,254,740,991 can be agreed on exactly by such implementations. JSON itself does not guarantee arbitrary decimal precision.
A JSON number and a decimal string therefore need different handling. Follow the provider’s schema instead of coercing every value with the same conversion. Reject missing or malformed prices explicitly; turning an empty value into zero can make a broken response look like a real observation. [1]
Choose a calculation policy
For illustration, a bid of 2,650.40 and an ask of 2,650.65 produce a midpoint of 2,650.525. Showing two decimal places requires a rounding decision. Record that policy instead of letting individual widgets make different choices. These values are synthetic examples, not current quotes.
Where exact decimal arithmetic is required, consider a decimal arithmetic library or scaled integers with a documented scale. Check the supported range and how multiplication, division, and rescaling behave. Do not assume that a scale suitable for an incoming quote is also sufficient for a derived midpoint or percentage.
Test the round trip
Build fixtures that travel from response parsing through storage and back into the interface. Include trailing zeros, very small differences, values near a rounding boundary, and the largest value your contract accepts. Compare the stored measurement separately from the displayed label.
If you export data, document whether the export contains source values or rounded display values. Keep locale-specific grouping and decimal separators in the presentation layer. A price should not change because a user switches language, opens a CSV, or views the same observation in another widget.
References
Primary sources for the technical details in this article. Implementation suggestions are our own.