Refund engine with lifecycle awareness
Design a refund engine that does the right thing depending on where the original payment is in its lifecycle: if the payment is authorized-but-not-captured, you must VOID (release the hold), not refund; if captured-but-not-yet-settled, you may be able to reverse before settlement; if settled, you issue a true refund that moves money back days later. ~1M refunds/day. Each path has different timing, fees, and reversibility, and the user just clicks 'refund'. How do you model this so the system always picks the correct, cheapest, fastest reversal and never refunds more than was captured?
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.