Skip to main content
Every monetary value in the API is an integer in the smallest unit of the store’s currency. There are no decimal points and no human-formatted strings like "$12.34" or "Rp 5.000".
Integers avoid floating-point rounding errors and keep every amount exact. The catch: an integer alone is ambiguous — you must know how many decimal places the currency has to turn it into a human amount. That number varies by currency, and there is no universal standard, which is the most common source of confusion.
Always read an amount together with its currency. Amounts live on resources next to a currency code: a store has store.currency, an order has order.currency. Products and inventory items inherit the store currency.

Minor units per currency

The “smallest unit” is the currency’s minor unit. Most currencies split into 100 (cents, pence, sen), but many do not. Zero-decimal currencies (the integer is the amount — do not multiply by 100): BIF, CLP, DJF, GNF, IDR, IQD, JPY, KMF, KRW, MGA, PYG, RWF, UGX, VND, VUV, XAF, XOF, XPF. Three-decimal currencies: BHD, JOD, KWD, OMR, TND. Every other currency uses 2 decimals.
For a store using IDR (Indonesian Rupiah), a price of 5000 means Rp 5,000 — not Rp 50. Rupiah has no minor unit, so the integer is the whole-rupiah amount. Sending 500000 when you mean Rp 5,000 overcharges the customer 100×.

Converting to and from human amounts

Let d be the number of decimals for the currency (from the table above):
For display, Intl.NumberFormat reads the correct decimals from the currency for you:

Amount fields in the API

Every field below is an integer in the store currency’s minor units.

Products & inventory items

Product variants carry the same three fields.

Orders

Nested amounts: each discounts[].amount, each line item’s price and total_amount, line-item option prices[], and the selected service.price.

Store