v0.5.1

Bug fixes

• X402\Support\PriceParser rejects negative amounts, decimal-overflow, and non-strict-shape inputs by default. Surfaced from a downstream adapter cutover that pinned three silent-conversion vectors:

  1. Negative amounts used to produce a negative atomic string ('-0.5' → '-500000'). The wire format accepts it; adopters notice on the facilitator side, or never. Now throws by default.
  2. More fractional digits than the asset supports used to silently truncate ('0.0001' with decimals=2 → '0'). A buyer signing this authorization gets debited for zero atomic units while the seller serves the request. Now throws by default.
  3. is_numeric() shape used to accept scientific notation ('1e5' silently accelerates to 100000), thousands separators ('1,000'), leading +, hex/oct prefixes, and whitespace. Now uses strict regex ^-?\d+(\.\d+)?$ and rejects the lot.

  Opt into the looser behaviour explicitly when you have a deliberate reason:

  // Refund / credit math
  PriceParser::toAtomic('-0.5', 6, allowNegative: true);  // → '-500000'
  
  // "Round to the nearest cent" pricing
  PriceParser::toAtomic('0.0000019', 6, truncate: true);  // → '1' (drops the 9)

  PaymentRequiredBuilder (test helper) passes truncate: true internally — fixture amounts like '0.0123456789' keep working there. Production callers reach for PriceParser::toAtomic() directly and get the strict defaults.

Full Changelog: 0.5.0...0.5.1