Handle currency minor units correctly across payment providers to avoid 100x over- or under-charges

Steps

1. Maintain a lookup table of currency exponents: most currencies use 2 decimal places (USD, EUR, GBP → multiply by 100), some use 3 (KWD, BHD, OMR → multiply by 1000), and zero-decimal currencies use no multiplier (JPY, KRW, VND → pass the whole number).
2. Store canonical amounts in your system as integers in the smallest unit (e.g., cents) or as exact decimal types (not float) — floating-point arithmetic on monetary values causes rounding errors that compound across transactions.
3. Before calling any PSP API, convert from your stored representation to the PSP's expected format: Stripe, GoCardless, and Razorpay expect minor units as integers; some older APIs expect decimal strings (e.g., Mollie expects '10.00' for EUR 10).
4. When receiving amounts from webhooks, convert back to your internal representation using the same exponent table; never assume all webhooks use the same format even from the same provider across different endpoints.
5. Test explicitly with JPY, KWD, and at least one 2-decimal currency in your payment integration tests — a passing test with only USD does not validate currency handling.
6. Log the raw 'amount' and 'currency' fields from every API response alongside your expected values; discrepancies surface misconfiguration before they reach production.