Currency Minor Unit Lint for Payment API Amounts

Six of the money lines below send an amount the payment API reads differently from what the backend engineer in Sofia, Tokyo or Kuwait City meant - and nothing fails, because every one of them is valid code.

line  3  [error]  Math.round(x * 100) charges 100x in the 16 zero-decimal currencies (JPY, KRW, VND...)
line  5  [info]   Zero-decimal currency: 500 JPY is amount 500 - the * 100 above charges 100x here
line  6  [error]  BGN stopped being legal tender on 2026-02-01. Charge EUR (1 EUR = 1.95583 BGN)
line  7  [error]  amount is a decimal literal - 10.99 is read as 10 or rejected outright
line  7  [warn]   KWD is a 3-decimal currency: 1.5 is 1500, not 150, and the last digit must be 0
line  8  [warn]   ISK needs a two-decimal value ending in 00 - 5 ISK is amount 500
line 10  [warn]   Math.round on a float tax rounds 1.005 down to 1 (it is stored as 1.00499999999999989)
line 11  [error]  toFixed(2) prints 1200.00 for JPY and truncates KWD 1.234 to 1.23
--- 15 findings over 8 lines, from 24 rules ---

The line every assistant writes

const amount = Math.round(price * 100);

This is correct for the dollar, the euro and the pound. It is wrong for the sixteen currencies that have no minor unit at all - BIF, CLP, DJF, GNF, JPY, KMF, KRW, MGA, PYG, RWF, UGX, VND, VUV, XAF, XOF and XPF. In those currencies the amount is the charge: 500 JPY is the integer 500. Multiply by a hundred and a 5,000 yen order bills 500,000 yen.

It is wrong in the other direction for the currencies with three decimals - BHD, IQD, JOD, KWD, LYD, OMR and TND. Those amounts are in thousandths, and processors additionally require the last digit to be zero. Sending 150 for KWD 1.5 undercharges by a factor of ten on every invoice.

The code that stopped being true on a date

Bulgaria adopted the euro on 1 January 2026 at the fixed rate of 1 EUR = 1.95583 BGN. The lev and the euro circulated together through January, and since 1 February 2026 the euro has been the sole legal currency. currency: "bgn" is not a style choice any more; it is a code that a processor will refuse.

Croatia did the same on 1 January 2023 at 1 EUR = 7.53450 HRK. VEF became VES, MRO became MRU, STD became STN, SLL became SLE, ZWL became ZWG. Every one of those is still sitting in somebody's config file, because a retired currency code is a perfectly valid three-character string until the API answers.

Why the assistant cannot catch this

Ask a coding assistant whether Math.round(price * 100) is right and it will say yes, because for the currency it was shown most often it is. Ask it whether BGN is a live currency code and it will say yes, because it learned a world in which it was. The blind spot is not carelessness - it is the training date, and it is exactly the same date the code was written on.

Nor does the test suite help. Math.round(19.99 * 100) returns 1999 whatever currency you attach to it. The number is only wrong once it reaches the processor, and by then it is a refund, a dispute and a support thread.

What the rules check

Twenty-four rules, each one checkable:

• the scaling rules - * 100, / 100, toFixed(2), decimal literals in an amount field
• the float rules - parseFloat on money, equality comparisons, parseInt(x.toFixed()), Math.round on a tax line
• the currency rules - zero-decimal, three-decimal, the ISK and UGX trailing zeros, the HUF and TWD payout divisibility
• the dated rules - BGN, HRK and the six other retired ISO 4217 codes, each with its replacement and the day it changed
• the formatting rules - "$" + concatenation, Intl.NumberFormat with style: 'currency' and no currency option, bare toLocaleString()

Checking the file you have open is free: all twenty-four rules, every finding, nothing hidden and no watermark. The licence key covers the other job - every file in the repository, a CI gate that fails the build before a wrong amount can merge, a CSV, JSON or HTML report, and rewriting the retired codes in place. $29 once, 7-day full refund.