Why this matters: this is the machine-coding problem where a wrong assumption costs real money. The system you're asked to design wraps a gateway you don't control — slow, occasionally down, and moving actual funds — and the entire round pivots on one question about it: what does a timeout mean? Candidates who hear the answer and keep designing as before have already double-charged a customer. Candidates who let it reshape their design are the ones this problem exists to find.

The prompt, as given

Design the payment-processing core of a platform.

When a customer pays, your system charges them through an external payment gateway — one you don't control, that is sometimes slow, occasionally down, and always moving real money. Your job is everything around that call: deciding when to make it, recording what happened, and being right about the money even when the gateway leaves you guessing.

Read the last clause again: right about the money even when the gateway leaves you guessing. That's the interviewer telling you, in plain sight, that some gateway calls will end without an answer. Most candidates skim past it. Don't.

The questions, and why each one matters

"What happens when a call to the gateway times out — do I know whether the charge went through?" This is the round's defining question, and the representative answer is brutal: you don't know. The charge may have gone through, or not. Sit with what that does to your design. Retry blindly and you may charge twice; assume failure and mark it failed while the customer's card was actually billed, and you've lied about money. The only honest response is a design where "I don't know yet" is a first-class state, resolved later by asking the gateway what actually happened — never by guessing. Everything else in the chapter flows from taking this answer seriously.

"What operations do I expose?" Create a payment intent for an amount, confirm it (this triggers the charge), query status, refund it — full or partial. The intent/confirm split matters: it gives you a stable identity for the payment before any money moves, which turns out to be exactly the anchor idempotency needs.

"What do duplicate requests look like?" Users double-click; client apps retry on their own timeouts. Both must be safe — meaning the system must guarantee that repeating a request cannot repeat a charge. Ask whether the gateway helps: the representative answer is that it accepts an idempotency key on charge calls. That one fact is your safety mechanism; the design question becomes where keys come from and what they're attached to.

"What are the record-keeping rules?" Finance's answer: money history is never edited. A correction is a new entry, never a changed one. That sentence rules out a design where you overwrite a payment row's amount, and rules in an append-only ledger alongside mutable status.

"Can I retry a charge whose outcome I don't know?" Allowed — but only if provably safe. "Provably" is doing the work in that sentence: safe because the same idempotency key rides the retry, not safe because you waited a while and hoped.

"What's the volume, and what dominates?" Thousands of payments a day, and correctness dominates throughput everywhere. That frees you from cleverness: no caching, no sharding talk. The hard part of this problem is being right, not being fast.

The requirement set this chapter builds against

Gateway      external, one in v1, network calls can take 30+ s,
             occasionally down; accepts an idempotency key
Timeout      outcome UNKNOWN — charge may or may not have happened
Interface    createIntent(amount) / confirm / status / refund
             (full or partial); several currencies, handled fine
Duplicates   double-clicks and client retries both must be safe
Records      money history never edited — corrections are
             new entries, never changed ones
Retries      allowed only when provably safe (idempotency key)
Volume       thousands/day; correctness dominates throughput

The design consequences are all seeded here: the unknown outcome forces a state machine with UNKNOWN in it and a reconciliation path out of it; the duplicate rule forces idempotency keys anchored to the intent; the never-edit rule forces an append-only ledger separate from mutable state.

As always in this course: a live interviewer's answers may differ from this set — maybe their gateway gives no idempotency support and you must build dedup yourself, and the conversation is the skill. Ask, absorb, and let the answers steer.