Get an unfamiliar codebase explained top-down before touching a single line

You are onboarding a new engineer onto this codebase who can read code fluently but has zero context on this specific project's decisions. Do not describe syntax anywhere in this response. Describe intent, architecture, and the traps a competent engineer would still fall into.

SCOPE
the checkout and payment flow specifically, not the whole repository

WHAT THIS PERSON ALREADY KNOWS, SO YOU DO NOT RE-EXPLAIN IT
This engineer has shipped production TypeScript and React before, just not on this specific codebase — no need to explain what a React hook is.

THIS PERSON'S BACKGROUND
Backend-leaning, comfortable with API design, less experienced with frontend state management specifically.

EXPLAIN IN THIS EXACT ORDER
1. What this codebase, or the scoped area above, actually does — two sentences, written for someone who has genuinely never seen it.
2. Entry point or points — where execution actually starts, and the first meaningful thing that happens after that, named by real file and function.
3. Architecture — the four to six major modules or layers, and for each, its one job and, just as importantly, what it explicitly does not do, since the boundary of a module's responsibility is usually the more useful fact.
4. Data flow — trace one realistic request or user action end to end through those layers, naming real files and functions at each step, not a generic description of 'the flow.'
5. State and side effects — what is stateful, where it lives, and specifically what would break if two instances of that state-touching code ran concurrently.
6. The traps — three to five things that look obvious but are not: a misleading name, a module that appears unused but is not, a place where the intuitive fix is actually the wrong one and why.

CONSTRAINTS
- Cite real file paths, function names, and class names throughout, never a generic description standing in for a specific reference.
- Where you are inferring rather than certain, because no comment, test, or commit message confirms it, say 'likely' or 'appears to' explicitly rather than presenting an inference as settled fact.
- Stop after item six. Do not propose changes, improvements, or a refactor plan unless it is explicitly asked for separately — this is an explanation, not a review.
- Calibrate depth per section against Backend-leaning, comfortable with API design, less experienced with frontend state management specifically. rather than treating every layer as equally unfamiliar — spend fewer words on the part of the stack this person already has real experience with, and more on the part where their background gives them the least to draw on.

Given This will be read once, in one sitting, before their first real ticket — it needs to be complete enough to act on, not a reference document to revisit., prioritize completeness over polish, and if the checkout and payment flow specifically, not the whole repository scopes this to one subsystem, still name in one sentence how that subsystem's boundary connects to the rest of the codebase, so the walkthrough does not read as though this area exists in isolation.