Send monetary amounts as decimal strings with a decimal point, no grouping separator and no currency symbol. Keep the currency code alongside each value. Use decimal arithmetic; do not convert money to binary floating-point values before calculating or serializing it.
Amount precision belongs to the currency. For example, USD allows two decimal places, KWD three and KRW none. Extra non-zero fractional digits are rejected, not silently rounded. IDR accepts two amount decimals even where its usual display has none; display precision and payment-provider minor-unit precision are separate. Preserve a settled amount exactly on receipts and refunds.
COD and checkout amount maps follow the same rule: a map can contain KWD as "1.234", KRW as "1234" and USD as "12.34". This applies to fees, order minimums and maximums, and fee-waiver thresholds. Their webhook values remain decimal strings and never contain the merchant's display separators or currency symbols.
Store Admin and mobile management displays follow Settings > General. Storefront and customer-email displays follow the applicable language and currency. API, CSV and webhook amount strings do not change with General. Treat formatted values as display text, isolate the complete amount in mixed left-to-right/right-to-left interfaces, and never parse them back into financial values.
For fields explicitly returned in minor units, use the contract's exponent. Do not assume every currency has 100 minor units or derive its multiplier from the number of displayed decimals. For plan-catalog responses, amount_decimal is the exact major amount, amount is the same price as a whole number with amount_exponent implied decimal places, and formatted_amount is the display value. A formatted_monthly_equivalent on a yearly price is a comparison; the yearly price remains the billed amount.
Partner directory budgets use min_budget_amount as a currency-validated decimal string and formatted_min_budget for display.