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.

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:

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.