What is the standard for formatting currency values in JSON? -

bearing in mind various quirks of data types, , localization, best way web service communicate monetary values , applications? there standard somewhere?

my first thought use number type. example

"amount": 1234.56 

i have seen many arguments issues lack of precision , rounding errors when using floating point data types monetary calculations--however, transmitting value, not calculating, shouldn't matter.

eventbrite's json currency specifications specify this:

{ "currency": "usd",  "value": 432,  "display": "$4.32" } 

bravo avoiding floating point values, run issue: what's largest number can hold?

one comment (i don’t know if it’s true, seems reasonable) claims that, since number implementations vary in json, best can expect 32-bit signed integer. largest value 32-bit signed integer can hold 2147483647. if represent values in minor unit, that’s $21,474,836.47. $21 million seems huge number, it’s not inconceivable application may need work value larger that. problem gets worse currencies 1,000 of minor unit make major unit, or currency worth less dollar. example, tunisian dinar divided 1,000 milim. 2147483647 milim, or 2147483.647 tnd $1,124,492.04. it's more values on $1 million may worked in cases. example: subunits of vietnamese dong have been rendered useless inflation, let’s use major units. 2147483647 vnd $98,526.55. i’m sure many use cases (bank balances, real estate values, etc.) substantially higher that. (eventbrite doesn’t have worry ticket prices being high, though!)

if avoid problem communicating value string, how should string formatted? different countries/locales have drastically different formats—different currency symbols, whether symbol occurs before or after amount, whether or not there space between symbol , amount, if comma or period used separate decimal, if commas used thousands separator, parentheses or minus sign indicate negative values, , possibly more i’m not aware of.

should app know locale/currency it's working with, communicate values like

"amount": "1234.56" 

back , forth, , trust app correctly format amount? (also: should decimal value avoided, , value specified in terms of smallest monetary unit? or should major , minor unit listed in different properties?)

or should server provide raw value , formatted value?

"amount": "1234.56" "displayamount": "$1,234.56" 

or should server provide raw value , currency code, , let app format it? "amount": "1234.56" "currencycode": "usd" assume whichever method used should used in both directions, transmitting , server.

i have been unable find standard--do have answer, or can point me resource defines this? seems common issue.

i don't know if it's best solution, i'm trying pass values strings unformatted except decimal point, so:

"amount": "1234.56" 

the app parse (and convert double, bigdecimal, int, or whatever method app developer feels best floating-point arithmetic). app responsible formatting value display according locale , currency.

this format accommodate other currency values, whether highly inflated large numbers, numbers 3 digits after decimal point, numbers no fractional values @ all, etc.

of course, assume app knows locale , currency used (from call, app setting, or local device values). if need specified per call, option be:

"amount": "1234.56", "currency": "usd", "locale": "en_us" 

i'm tempted roll these 1 json object, json feed may have multiple amounts different purposes, , need specify currency settings once. of course, if vary each amount listed, best encapsulate them together, so:

{ "amount": "1234.56", "currency": "usd", "locale": "en_us" } 

another debatable approach server provide raw amount , formatted amount. (if so, suggest encapsulating object, instead of having multiple properties in feed define same concept):

{ "displayamount":"$1,234.56", "calculationamount":"1234.56" } 

here, more of work offloaded server. ensures consistency across different platforms , apps in how numbers displayed, while still providing parseable value conditional testing , like.

however, leave problem--what if app needs perform calculations , show results user? still need format number display. might go first example @ top of answer , give app control on formatting.

those thoughts, @ least. i've been unable find solid best practices or research in area, welcome better solutions or potential pitfalls haven't pointed out.