api-gateway payment validation tests don't cover decimal edge cases

[therealjhay]

Problempayment-validation.test.ts covers formats but not extreme decimals (e.g., 30-decimal amounts) that can overflow DB numeric columns.

1. No extreme-precision tests.
2. No max-decimal enforcement.
3. DB errors leak as 500.

Solution

• Enforce max decimals per asset.
• Test extreme inputs.
• Return 422 not 500.

Acceptance Criteria

• Extreme decimals rejected cleanly.
• 422 returned.
• pnpm --filter api-gateway build passes.

Note for Contributors: Write a clear PR description. Show an extreme-decimal rejection.

[nighshift-labs]

The public code makes this look like a real boundary mismatch: CreatePaymentBody accepts arbitrary decimal length, while prisma/schema.prisma stores Payment.amount as Decimal(18,6), and the route writes the caller string directly after Zod parsing. I would add a string-based precision/magnitude guard plus focused tests for 10.123456 vs 10.1234567 and a 30-decimal input, before payment.create runs. One contract choice is needed first: should precision come from the DB-wide 6 decimals or each supported asset’s declared decimals? Also should this remain the existing 400 VALIDATION_ERROR or introduce 422 for semantic precision rejection? With those choices, the patch is localized to the shared validator, error mapping, and payment-validation tests.

[Senorespecial]

I would love to work on this issue. please assign to me to work on it ASAP