Validation checks incoming data, generated files, and displayed values against rules the application accepts. In payment software, it protects the system from malformed ACH data, mismatched bank routing numbers, and incorrectly formatted UI values. Treat validation as a backend responsibility as well as a user-interface concern: another system or screen cannot be trusted to enforce the rules for you. section 4.9.3 section 8.8.4 section 10.2.4
Start by making each rule explicit. A file identifier can require one or more lowercase letters, digits, or underscores; a file-ID modifier can require exactly one uppercase letter or digit. Regular-expression and length constraints keep these structural rules close to a field definition, reducing custom boilerplate. section 4.9.3 section 8.5.3
Listing 4.26 Validation in Pydantic
from fastapi import FastAPI, Request, status, HTTPException
from fastapi.responses import JSONResponse
…
@app.exception_handler(ValidationError) #1
async def validation_exception_handler(request: Request, exc: ValidationError): #2
return JSONResponse( #2
status_code=status.HTTP_400_BAD_REQUEST, #2
content={"detail": exc.errors()} #2
) #2
A FastAPI exception handler turns a Pydantic validation failure into a 400 response with error details. Detailed development errors are useful, but production responses should avoid exposing sensitive information. section 4.9.3
Some rules depend on live business data rather than syntax alone. An immediate destination may look like a routing number yet still be unacceptable unless it appears in the current allowed-bank list. A Pydantic field validator can query that list, accept a known value, and raise a controlled error for an invalid or uncheckable value. Consider query costs when validating many records or fields. section 8.5.3
Validate behavior at several points in the workflow:
- Reject malformed API fields and return a handled error response rather than relying on callers to prevent bad input. section 4.9.3
- Test both acceptance and rejection cases, such as a lowercase file ID that succeeds and an uppercase value that fails its pattern. section 4.9.3
- Inspect generated ACH files by counting type-6 entry records and comparing the result with the expected entry count. section 7.6
- Validate display-specific formats before rendering them; an invalid Base64 image string can safely produce an empty source. section 10.2.4
From rule to tested API response
Define a lowercase file_id pattern, attach a validation-error handler that returns status 400, then test a valid identifier for a 200 response and an invalid uppercase identifier for the expected pattern message. This verifies the rule and the client-visible failure path together. section 4.9.3
Validation grows with the application. Early work can focus on detecting bad files rather than recovering from them; later rules may require reversing posted transactions, logging exceptions, changing test data, or separating increasingly complex record validation from parsing code. section 2.6 section 8.5.3
