- Ya
- 7 Agosti 2026, 04:05 UTC
- Mwandishi
- kamo
- Ahadi ya
- bf35f85
The API stores money as NUMERIC(19,4) and serialises it with toPlainString(), so the shipped $50.00 minimum withdrawal arrived as "50.0000". Both money inputs accept at most cents, so the default lit up the invalid-amount error on a form nobody had touched. Editing an existing commission line had the same problem — 100.0000 in the amount box. toAmountInput() normalises for display. Trailing zeros past the cent are dropped because they carry no value; anything SIGNIFICANT past the cent is returned untouched, so a real sub-cent figure surfaces as the validation problem it is rather than being silently rounded away. String-only — rounding through Number is the class of bug that made money a string here in the first place. Normalising the displayed value alone would have introduced a second bug: both panels compare the edited value against a baseline to decide whether anything is unsaved, and comparing a normalised field to a raw stored value reports a pristine form as dirty forever. So the processor normalises inside toDraft, which produces both the draft and its comparison baseline, and the Stripe panel normalises both sides of its check. Tests cover the pairs that actually reach these fields plus the ones where rounding would change someone's money, and assert the output satisfies the field pattern that started this.