payments-and-moneylisted

# Payments and money Payment bugs lose real money, cannot always be undone, and bring regulators. Every payment operation must be **correct, idempotent, auditable and reconcilable**. Prefer boring, proven designs and the provider's official SDK. ## Amounts - **Never use binary floating point for money.** Use integer minor units (`amountMinor: 1999`) together with the currency, or a decimal type (`BigDecimal`, `decimal`, `Decimal`, `NUMERIC`). - The currency always travels with the amount. The minor-unit exponent comes from ISO 4217 (JPY 0, USD 2, KWD 3), never an assumed 2. - Round once, at a defined point, with an explicit mode: half-up, or banker's rounding, as the business, tax or fiscal rule requires. When splitting (instalments, tax lines, split payments), allocate the remainder so the parts sum exactly to the total. - In JSON and APIs, send amounts as integers in minor units or as decimal strings, never as floats. - Tax, fee and FX rates are **effective-dated configuration**, not constants. Laws change them. ## Operations - **Idempotency on every mutating call.** The client generates an idempotency key per business operation. The server stores the key with the result and returns the same result on retry. Pass the key through to the provider. - **Explicit state machine** per payment, for example `created → authorized → captured → refunded(partial|full)`, plus `failed`, `canceled`, `expired`. Transitions are validated. States are never overwritten backwards. - **Time