Recoverable Equipment Checkout
The IT team collects an equipment request through a three-step checkout. People often go back to correct an address, and the payment service can be temporarily unavailable. Implement the existing flow so users never lose a valid draft and can recover from a failed submission.
Requirements
- Preserve a single checkout object across all steps.
- Validate only the fields required by the current step.
- Prevent navigation outside the valid step range.
- Allow users to return and edit earlier information.
- Render a review summary before confirmation.
- Submit asynchronously, show a pending state, and keep the review visible after failure.
- Allow a failed submission to be retried without clearing the draft.
The provided payment stub rejects the test card 0000 and accepts 1234. This is a deterministic way to exercise the same failure-and-retry behavior a real payment boundary would have.
What to explain in your review
- Why is one checkout object safer than separate state per step?
- Which validation belongs at a step boundary versus at final submission?
- How does the UI prevent duplicate submissions while preserving retry value?
Reference solution notes
The reference keeps the draft independent from the current step, validates only the fields needed to advance, and treats submission as a separate async state machine (idle, pending, error, complete). A valid alternative is a reducer for the workflow; the important behavior is that Back preserves data, a failed request leaves the Review screen intact, and a retry does not duplicate or clear the request. Common mistakes include validating only on the first step, resetting the draft on Back, enabling Place order while pending, and navigating away on a failed request.