Design a Refund Workflow with Explicit State and Recovery

Design a refund system or workflow. Clarify the business rules and external payment integration before defining the implementation. ### Constraints and Clarifying Questions The report names a refund workflow in an AI-enabled coding round but supplies no refund eligibility formula, data model, or provider API. Do not infer that the product itself is AI-powered. For a worked design, choose a validated refund request against an existing payment, an approval step where required by supplied policy, and an idempotent provider execution path. These are explicit practice choices. ### What a Strong Answer Covers State transitions, refund-amount validation, concurrent requests, stable request identity, ambiguous provider outcomes, and an auditable result. Keep business policy separate from orchestration. ### Follow-up Questions - What happens when two partial refunds are requested concurrently? - How do you distinguish a rejected request from a provider outcome that is still unknown?