Design a payment system

Question 1

Who starts a payment?

Accepted Answer

A checkout page that will be refreshed, double-clicked and retried on a flaky connection. Every duplicate charge story starts here.

Question 2

What does checkout call?

Accepted Answer

A gateway terminates TLS, authenticates the merchant and rate limits — and is the last place a request is cheap to reject before it costs money.

Question 3

What owns the state machine of a payment?

Accepted Answer

A payment moves through pending, authorised, captured, failed and refunded, and exactly one component should be allowed to move it. Spread that across services and you get payments that are captured in one place and pending in another.

Question 4

Where is the record of what was charged?

Accepted Answer

An append-only ledger in a transactional store. Not a balance column somebody increments — money needs a history you can replay and audit, and "what is the balance" should be a question you answer from the entries rather than a number you hope is right.

Question 5

Who actually moves the money?

Accepted Answer

Not you. An external processor does, on its own latency and its own availability — and drawing it makes it obvious that the interesting failures in this system are calls to somebody else that time out without an answer.

Question 6

A payment succeeds. What else has to happen?

Accepted Answer

Receipts, order fulfilment, accounting and analytics all care, and none of them should be able to fail the charge. Emit an event and let them consume it — the payment is done the moment the ledger says so.

Question 7

The customer double-clicks Pay and the network retries. Where do you catch it?

Accepted Answer

On the idempotency key, looked up before anything expensive runs. It has to be a fast store with an atomic claim, checked on every attempt — and it is checked so often, and matters so much, that it belongs on the board rather than in the payment service’s head.

Question 8

Your client writes to the ledger directly. What could go wrong?

Accepted Answer

Everything. The ledger is the record of money; a browser must never be able to append to it, and there is no version of this where a client-side write is acceptable.

Question 9

How many payments a second?

Accepted Answer

50,000,000 / 86,400 is about 580 a second. Small — and worth saying out loud, because it tells the interviewer you know this problem is about correctness, not throughput.

Question 10

The provider call times out and you never learn whether it succeeded. Then what?

Accepted Answer

You cannot retry blindly and you cannot assume failure. The payment stays in-flight, the idempotency key protects the retry, and a reconciliation job compares your ledger against the provider’s report to reach a final answer. Every real payment system has this job, and candidates who have not built one rarely mention it.

Blueprint — system design