Batch Transaction Processor

The problem

Bulk imports rarely fail in one clean way. Headers drift, dates are malformed, amounts cross edge conditions, and a single invalid row can make an otherwise useful file difficult to reason about. The interface needed to expose those problems before confirmation without turning a large file into an unreadable wall of errors.

The approach

I structured the experience as a three-step flow: capture the batch details, parse and review the file, then summarize only the records that are valid for submission. Zod keeps row validation explicit, while the review UI makes errors visible at the point where they can be corrected.

The CSV header strategy is deliberate. Strict mode accepts only the canonical schema; an optional permissive mode normalizes a small, documented set of synonyms. That keeps the default auditable instead of silently guessing what a column means.

Engineering decisions

• Parsing and validation are separated so normalization rules remain testable without rendering the interface.
• Back navigation preserves the selected file and parsed records rather than forcing the user to repeat an expensive step.
• Pagination state is synchronized to the URL and browser storage, making a long review easier to resume.
• The review table switches to virtualization above 300 rows to keep large synthetic imports responsive.
• Confirmation is intentionally in-memory: this project demonstrates the browser workflow and does not claim to process real payments or persist transactions to a backend.

Verification

The repository includes unit, component, and Playwright coverage for valid and invalid files, header mismatches, back-navigation persistence, pagination, mixed-validity batches, and synthetic 10,000-row scenarios. The fixtures use generated names, account numbers, dates, and amounts.

Result

The final flow makes the state of a batch legible at each step: what was uploaded, which rows are actionable, why others failed, and what will be included in the summary. It is a focused example of treating validation and recovery as product design rather than as an error message added at the end.