Min transaction amount enforced with clear error
Why it matters
Accepting zero-amount or sub-minimum transactions creates two concrete problems: payment processors (Stripe, Adyen) reject amounts below their floor and return errors that must be handled; and zero-amount transactions that do commit pollute the ledger with noise records that complicate reconciliation. OWASP A03 covers this as inadequate input validation. The error message matters too — WCAG 2.2 SC 3.3.1 and 3.3.3 require error messages to identify the constraint, not just report failure, so users know what to correct.
Severity rationale
Medium because zero and sub-minimum amounts cause payment processor rejections that surface as user-visible errors and create invalid ledger records.
Remediation
Enforce a minimum of 1 cent server-side and return a message that states the actual threshold, not a generic failure string.
// src/app/api/transfers/route.ts
const schema = z.object({
amountCents: z.number().int().min(1, 'Minimum transaction amount is $0.01'),
});
const parsed = schema.safeParse(await req.json());
if (!parsed.success) {
return Response.json(
{ error: parsed.error.issues[0]?.message },
{ status: 422 }
);
}
Mirror the constraint in src/components/TransferForm.tsx with min="0.01" on the amount input and a visible hint below the field.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Financial Form Validation Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-20 — Improper Input Validation
- owasp:2021 · A03
- wcag:2.2 · 3.3.1 — Error Identification
Taxons
History
- 2026-04-18·v1.0.0·Initial import from finserv-form-validation·automated