Requested by: Michael Letellier
Moved from Strategy11/formidable-pro#6678 — the affected code only exists in this repo (Lite), not Pro.
Repro: On a currency where thousand_separator and decimal_separator are swapped from US convention (e.g. EUR: thousand=., decimal=,), enter an amount using US-style separators, e.g. 1,030.21.
Root cause: stripe/controllers/FrmTransLiteActionsController.php
get_amount_from_string() (:354) passes the raw string through unchanged: 1,030.21.maybe_use_decimal() (:367) sees thousand_separator === '.', finds one . in the string with a 2-digit tail, assumes it's being used as a decimal point, and swaps it: str_replace('.', ',', ...) → 1,030,21.normalize_number() (:392) strips the currency's thousand_separator (., none left to strip) then swaps decimal_separator , → ., producing 1.030.21, then casts to float.- PHP's
(float) cast on 1.030.21 stops parsing at the second ., silently returning 1.03.
Incorrect: 1,030.21 → amount sent to Stripe: 1.03 (or equivalent tiny-fraction result for any input with two separators in the "wrong" order for the currency).
Expected: either correctly parsed as 1030.21, or rejected/flagged — not silently mangled by ~1000x.
No validation catches this anywhere in the chain; it fails silently with a wrong charge amount, not an error.
Reported via: Help Scout #234168 (closed as customer education — told to remove separators entirely, which avoids the bug but does not fix the underlying parser).
Fix should make maybe_use_decimal/normalize_number either detect an ambiguous/contradictory separator pattern and reject it, or parse more defensively so a malformed amount never silently shrinks by orders of magnitude.
Once fixed, close/reference formidable-pro#6678.
Requested by: Michael Letellier
Moved from
Strategy11/formidable-pro#6678— the affected code only exists in this repo (Lite), not Pro.Repro: On a currency where
thousand_separatoranddecimal_separatorare swapped from US convention (e.g. EUR: thousand=., decimal=,), enter an amount using US-style separators, e.g.1,030.21.Root cause:
stripe/controllers/FrmTransLiteActionsController.phpget_amount_from_string()(:354) passes the raw string through unchanged:1,030.21.maybe_use_decimal()(:367) seesthousand_separator === '.', finds one.in the string with a 2-digit tail, assumes it's being used as a decimal point, and swaps it:str_replace('.', ',', ...)→1,030,21.normalize_number()(:392) strips the currency's thousand_separator (., none left to strip) then swaps decimal_separator,→., producing1.030.21, then casts to float.(float)cast on1.030.21stops parsing at the second., silently returning1.03.Incorrect:
1,030.21→ amount sent to Stripe:1.03(or equivalent tiny-fraction result for any input with two separators in the "wrong" order for the currency).Expected: either correctly parsed as
1030.21, or rejected/flagged — not silently mangled by ~1000x.No validation catches this anywhere in the chain; it fails silently with a wrong charge amount, not an error.
Reported via: Help Scout #234168 (closed as customer education — told to remove separators entirely, which avoids the bug but does not fix the underlying parser).
Fix should make
maybe_use_decimal/normalize_numbereither detect an ambiguous/contradictory separator pattern and reject it, or parse more defensively so a malformed amount never silently shrinks by orders of magnitude.Once fixed, close/reference
formidable-pro#6678.