What is the standard for formatting currency values in JSON?

json schema currency format
json number format
how to pass integer value in json
javascript currency format
json format
country currency code json
json numeric values quotes
currency json data

Bearing in mind various quirks of the data types, and localization, what is the best way for a web service to communicate monetary values to and from applications? Is there a standard somewhere?

My first thought was to simply use the number type. For example

"amount": 1234.56

I have seen many arguments about issues with a lack of precision and rounding errors when using floating point data types for monetary calculations--however, we are just transmitting the value, not calculating, so that shouldn't matter.

EventBrite's JSON currency specifications specify something like this:

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

Bravo for avoiding floating point values, but now we run into another issue: what's the largest number we can hold?

One comment (I don’t know if it’s true, but seems reasonable) claims that, since number implementations vary in JSON, the best you can expect is a 32-bit signed integer. The largest value a 32-bit signed integer can hold is 2147483647. If we represent values in the minor unit, that’s $21,474,836.47. $21 million seems like a huge number, but it’s not inconceivable that some application may need to work with a value larger than that. The problem gets worse with currencies where 1,000 of the minor unit make a major unit, or where the currency is worth less than the US dollar. For example, a Tunisian Dinar is divided into 1,000 milim. 2147483647 milim, or 2147483.647 TND is $1,124,492.04. It's even more likely values over $1 million may be worked with in some cases. Another example: the subunits of the Vietnamese dong have been rendered useless by inflation, so let’s just use major units. 2147483647 VND is $98,526.55. I’m sure many use cases (bank balances, real estate values, etc.) are substantially higher than that. (EventBrite probably doesn’t have to worry about ticket prices being that high, though!)

If we avoid that problem by communicating the value as a string, how should the string be formatted? Different countries/locales have drastically different formats—different currency symbols, whether the symbol occurs before or after the amount, whether or not there is a space between the symbol and amount, if a comma or period is used to separate the decimal, if commas are used as a thousands separator, parentheses or a minus sign to indicate negative values, and possibly more that I’m not aware of.

Should the app know what locale/currency it's working with, communicate values like

"amount": "1234.56"

back and forth, and trust the app to correctly format the amount? (Also: should the decimal value be avoided, and the value specified in terms of the smallest monetary unit? Or should the major and minor unit be listed in different properties?)

Or should the server provide the raw value and the formatted value?

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

Or should the server provide the raw value and the currency code, and let the app format it? "amount": "1234.56" "currencyCode": "USD" I assume whichever method is used should be used in both directions, transmitting to and from the server.

I have been unable to find the standard--do you have an answer, or can point me to a resource that defines this? It seems like a common issue.

I don't know if it's the best solution, but what I'm trying now is to just pass values as strings unformatted except for a decimal point, like so:

"amount": "1234.56"

The app could easily parse that (and convert it to double, BigDecimal, int, or whatever method the app developer feels best for floating-point arithmetic). The app would be responsible for formatting the value for display according to locale and currency.

This format could accommodate other currency values, whether highly inflated large numbers, numbers with three digits after the decimal point, numbers with no fractional values at all, etc.

Of course, this would assume the app already knows the locale and currency used (from another call, an app setting, or local device values). If those need to be specified per call, another option would be:

"amount": "1234.56",
"currency": "USD",
"locale": "en_US"

I'm tempted to roll these into one JSON object, but a JSON feed may have multiple amounts for different purposes, and then would only need to specify currency settings once. Of course, if it could vary for each amount listed, then it would be best to encapsulate them together, like so:

{
"amount": "1234.56",
"currency": "USD",
"locale": "en_US"
}

Another debatable approach is for the server to provide the raw amount and the formatted amount. (If so, I would suggest encapsulating it as an object, instead of having multiple properties in a feed that all define the same concept):

{
"displayAmount":"$1,234.56",
"calculationAmount":"1234.56"
}

Here, more of the work is offloaded to the server. It also ensures consistency across different platforms and apps in how the numbers are displayed, while still providing an easily parseable value for conditional testing and the like.

However, it does leave a problem--what if the app needs to perform calculations and then show the results to the user? It will still need to format the number for display. Might as well go with the first example at the top of this answer and give the app control over the formatting.

Those are my thoughts, at least. I've been unable to find any solid best practices or research in this area, so I welcome better solutions or potential pitfalls I haven't pointed out.

️ What is the standard for formatting currency values ​​in JSON?, I don't know if this is the best solution, but now I'm trying to just pass the values ​​​as strings not formatted except for the decimal point, for example: "amount":  AFAIK, there is no "currency" standard in JSON - it is a standard based on rudimentary types. Things you might want to consider is that some currencies do not have a decimal part (Guinean Franc, Indonesian Rupiah) and some can be divided into thousandths (Bahraini Dinar)- hence you don't want to assume two decimal places.

AFAIK, there is no "currency" standard in JSON - it is a standard based on rudimentary types. Things you might want to consider is that some currencies do not have a decimal part (Guinean Franc, Indonesian Rupiah) and some can be divided into thousandths (Bahraini Dinar)- hence you don't want to assume two decimal places. For Iranian Real $2million is not going to get you far so I would expect you need to deal with doubles not integers. If you are looking for a general international model then you will need a currency code as countries with hyperinflation often change currencies every year of two to divide the value by 1,000,000 (or 100 mill). Historically Brazil and Iran have both done this, I think.

If you need a reference for currency codes (and a bit of other good information) then take a look here: https://gist.github.com/Fluidbyte/2973986

Formatting Numbers, Example: Using a JSON Object to Format Numbers. The following request against the GGSALES data source formats the y-axis labels as currency, grouped by  Currency Format JSON JSON with information about currencies: codes (ISO 4217), the names, grapheme (symbols), fraction and formatting.

Amount of money should be represented as string.

The idea of using string is that any client that consumes the json should parse it into decimal type such as BigDecimal to avoid floating point imprecision.

However it would only be meaningful if any part of the system avoids floating point too. Even if the backend is only passing data and not doing any calculation, using floating point would eventually result in what you see (in the program) is not what you get (on the json).

And assuming that the source is a database, it is important to have the data stored with right type. If the data is already stored as floating point then any subsequent conversion or casting would be meaningless as it would technically be passing imprecision around.

Numeric types, JSON has no standard way to represent complex numbers, so there is no way to test for them in JSON Schema. integer¶. The integer type is used for integral  In general, using floating point to store monetary values is a bug farm, so you're better off moving toward "integers" even if technically they are still floating point values in JSON. Some systems use an ISO currency code with the third letter in lower case to denote such currencies. For example GBp for British pence, or USd for US pennies.

ON Dev Portal - API Guidelines - Currencies you may find interesting suggestions :

"price" : {
 "amount": 40,
 "currency": "EUR"
}

It's a bit harder to produce & format than just a string, but I feel this is the cleanest and meaningful way to achieve it :

  1. uncouple amount and currency
  2. use number JSON type

Here the JSON format suggested: https://pattern.yaas.io/v2/schema-monetary-amount.json

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "type": "object",
    "title": "Monetary Amount",
    "description":"Schema defining monetary amount in given currency.",
    "properties": {
        "amount": {
            "type": "number",
            "description": "The amount in the specified currency"
        },
        "currency": {
            "type": "string",
            "pattern": "^[a-zA-Z]{3}$",
            "description": "ISO 4217 currency code, e.g.: USD, EUR, CHF"
        }
    },
    "required": [
        "amount",
        "currency"
    ]
}

Another questions related to currency format pointed out right or wrongly, that the practice is much more like a string with base units :

{
    "price": "40.0"
}

JSON - DataTypes, JSON - DataTypes - JSON format supports the following data types − Array. an ordered sequence of values. 5. Value. it can be a string, a number, true or false,  Number display format settings For numeric data, the display format metadata includes whether the number is a currency or percentage, the decimal places, and the grouping separator. Table 1.

Java Programming: 24-Hour Trainer, DATA. JSON format is based on the syntax of the JavaScript object literals. JSON became a de facto standard way of data formatting on the web, replacing  If a negative value is rounded and becomes zero, it is formatted as a zero value. The following are valid within a format string: Zero placholder. Zero (0) or double zero (00) If the value being formatted has a digit in the position where the 0 appears in the format string, then that digit is copied to the result string.

Delphi Cookbook, Click button 1 (the memo fills with the serialized data as a JSON object). 3. The average Delphi user is very skilled with some kinds of TDataset machine without problems with decimal separators, date format, currency formatting, and so  JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses

Formatting Numbers – amCharts 4 Documentation, JavaScript. JSON // Round all numbers to integer chart.numberFormatter. Number formatting in amCharts is loosely based on Unicode standard. Please  JSON Data - A Name and a Value. JSON data is written as name/value pairs. A name/value pair consists of a field name (in double quotes), followed by a colon, followed by a value:

Comments
  • Related question: stackoverflow.com/questions/45222706/…
  • Thank you for your thoughts. I've already pointed out a number of problems with some approaches. What I'm looking for is something that DOES work.