Design a Fixed-Position Payment Command State Machine

Design the parser and object-oriented state-machine core for a payment command interface. The reported commands use a fixed number of argument positions; unused positions contain empty strings. ```text CREATE id payer payee amount APPROVE id "" "" amount CAPTURE id "" "" amount CANCEL id "" "" "" ``` Both `APPROVE` and `CAPTURE` carry an amount. The remembered transition sketch is: ```text CREATED → APPROVED APPROVED → PARTIALLY_CAPTURED or SUCCEEDED PARTIALLY_CAPTURED → SUCCEEDED ``` The report also says cancellation applies to payments that have not yet been approved. It warns that the recalled rules may be incomplete or inaccurate. ### Constraints & Assumptions - Treat this as an engineering design exercise over the supplied partial specification, not a fully specified payment-processing console. - Each command has one operation token and four argument positions. Preserve empty-string placeholders during parsing. - Do not infer whether the approval amount must equal the creation amount, whether capture amounts are increments or totals, or whether repeated partial captures are allowed. - Cancellation has an ID position, but the description also refers to canceling all unapproved payments. Keep targeted-versus-bulk cancellation unresolved until clarified. - No external money movement, balances, concurrency model, currency format, or required output format is supplied. Define the boundaries around these policies rather than inventing observed behavior. ### Clarifying Questions to Ask - What are the valid amount representation, range, currency units, and relationship between created, approved, and captured amounts? - Does `CAPTURE` add an amount or set a cumulative total, and can a partially captured payment remain partially captured after another command? - Is `CANCEL id` targeted, or is there a bulk cancellation operation? How are terminal payments handled? - What happens on duplicate creation, repeated approval, an unknown ID, malformed input, or an invalid transition? ### Part 1 — Parse Fixed-Position Commands Describe a parser that preserves all argument positions and produces a typed command. Explain where syntax validation stops and payment-rule validation begins. #### What This Part Should Cover - Recognition of empty quoted values, command arity, and required versus placeholder fields. - Explicit amount conversion and malformed-input errors. - No state mutation while parsing or validating basic syntax. ### Part 2 — Model States and Policy Boundaries Design payment objects and the command handler using the supplied transition sketch. Identify the missing rules that must be clarified before implementing a complete monetary state machine. #### What This Part Should Cover - Centralized transition validation and separation of operation identity from current state. - Atomic application of a validated command to a payment record. - Conditional treatment of capture arithmetic and cancellation scope, without claiming an invented rule came from the source. ```hint Keep empty fields positional Removing an unused payer field should not shift the payee or amount into a different argument position. ``` ### What a Strong Answer Covers - A reliable fixed-position parser and maintainable command/state separation. - Preservation of the supplied transitions and explicit identification of gaps in the remembered specification. - Validation before mutation, stable error handling, and no unsupported assumptions about actual financial effects. ### Follow-up Questions - How would the transition table change if repeated partial captures were explicitly allowed? - How would you prevent a failed amount validation from leaving a payment half-updated? - What additional identity would be needed to distinguish a retried capture request from a second intentional capture of the same amount?