Design a Payment Service
Work from the brief alone. Write what you would produce — actors, requirements, data, a first slice, your unknowns — before opening anything below it; the exercise stops working if you read the reality first.
Ticket: "Design a payment service for the online store. It should take a card and charge it." That is the entire ticket. List the requirements that are missing before you design anything.
Your attempt
Nothing here is checked. It exists so that the reveal below is a comparison rather than a reading.
Designing the happy path well. A clean interface — charge(card, amount) — with a clean implementation, reviewed and merged, and every missing requirement discovered by a customer: the first EU order with the wrong currency, the first partial refund with nowhere to attach, the first double-click that charges twice. Each is then a migration on a live payments table, which is the most expensive place a requirement can arrive.
Read this even if you are confident. It is here rather than behind a button because it is the move most people actually make, it produces things that look like a project, and its cost arrives when the first hard requirement has nowhere to go.