Bug: Payment amount validation accepts malformed numeric strings

[mssystem1]

Describe the bug

Payment amount validation accepts malformed numeric strings because validateStringAmount() uses parseFloat(). For example, parseFloat("1abc") returns 1, so the value can pass validation even though it is not a valid decimal amount.

Steps

1. Open packages/account-sdk/src/interface/payment/utils/validation.ts
2. Check validateStringAmount()
3. Notice that it validates the amount using parseFloat(amount)
4. Try values like:
   • "1abc"
   • "1.2.3"
   • "1foo"
5. These values can pass the initial numeric validation because parseFloat() accepts partial numeric strings
6. Later, the same value is passed toward payment encoding, where parseUnits() expects a valid decimal string

Expected behavior

validateStringAmount() should reject malformed decimal strings immediately.

Valid examples should include:

• "1"
• "1.0"
• "1.000001"
• "10.50"

Invalid examples should include:

• "1abc"
• "1.2.3"
• "1foo"
• "abc"
• ""
• "."
• "1."
• "0"
• "-1"

Version

2.5.6 / latest master

Additional info

Suggested fix: replace parseFloat-based validation with strict decimal string validation.

Example:

export function validateStringAmount(amount: string, maxDecimals: number): void {
  if (typeof amount !== 'string') {
    throw new Error('Invalid amount: must be a string');
  }

  const pattern = new RegExp(`^(?:0|[1-9]\\d*)(?:\\.\\d{1,${maxDecimals}})?$`);

  if (!pattern.test(amount)) {
    throw new Error(
      `Invalid amount: must be a positive decimal string with up to ${maxDecimals} decimal places`
    );
  }

  if (Number(amount) <= 0) {
    throw new Error('Invalid amount: must be greater than 0');
  }
}

This would make SDK validation stricter and fail earlier with a clear error.

Desktop

• OS: N/A
• Browser: N/A
• Version: N/A

Smartphone

• Device: N/A
• OS: N/A
• Browser: N/A
• Version: N/A

[osr21]

Confirmed — parseFloat-based validation is a real footgun. A related edge case worth including in the fix: scientific notation strings like "1e6" are accepted by parseFloat (returns 1000000) but will throw in parseUnits since it expects a plain decimal string. Silent truncation with no user-facing error.

We hit this exact category of bug building a USDC bridge dApp and ended up with a strict validation function that covers all the edge cases. Sharing it as a reference:

function validateStringAmount(amount: string): bigint {
  const trimmed = amount.trim();
  if (!trimmed) throw new Error("Amount is required.");

  // Reject scientific notation — parseFloat accepts it ("1e6" → 1000000), parseUnits does not
  if (/e/i.test(trimmed)) {
    throw new Error("Enter a plain decimal number (e.g. 1.50), not scientific notation.");
  }

  // Strict decimal — digits, at most one dot, more digits; rejects "1abc", "1.2.3", "1.", "-1"
  if (!/^\d+(\.\d+)?$/.test(trimmed)) {
    throw new Error("Invalid amount — must be a valid decimal number.");
  }

  // Reject too many decimal places (token-specific; 6 for USDC)
  const [, frac] = trimmed.split(".");
  if (frac && frac.length > 6) {
    throw new Error("Amount cannot have more than 6 decimal places.");
  }

  const parsed = parseUnits(trimmed, 6);
  if (parsed <= 0n) throw new Error("Amount must be greater than zero.");
  return parsed;
}

The strict regex catches "1abc", "1.2.3", "1.", ".", "", and "-1". The scientific notation check is kept separate so it surfaces a friendlier error message. The decimal-places check prevents a confusing parseUnits throw when a user pastes a value with too much precision.