Design a Payment Gateway

A hiring manager says "design a payment gateway" and the fast way to fail is to draw a ledger. The gateway is the layer at the front door; settlement happens behind it. A merchant hands it a charge. It validates that charge, protects the card number, and picks a processor. It gets an authorization decision back across a network that drops responses, and tells the merchant yes or no. Everything about settlement, the batched movement of funds and the double-entry books, lives downstream and is a separate design. Confuse the two and you spend your time on accounting while the interviewer waits to hear how a retry does not charge the card twice.

So draw the boundary first and say it out loud. On one side is the merchant, who wants a simple call: charge this card this amount, tell me if it worked. On the other side are the processors and card networks, which are slow, occasionally down, and reachable only over a link that can lose your request or lose their reply. The gateway is the thing in the middle that makes an unreliable, multi-party integration look like one dependable call. That framing is the whole lesson. Get it, and idempotency, tokenization, timeouts, and webhooks stop being a checklist and become the obvious answers to a boundary you have already named.

The American Express angle

Amex runs a closed-loop network, so for its own cards it is the gateway, the network, and the issuer at once. That is not trivia. The person across the table has watched authorization requests time out and seen a processor go dark mid-peak. They have answered a chargeback that hinged on whether a retry was the same logical charge or a new one. They are not grading a diagram. They want to hear you name the one hazard that defines this layer, that the network can lose a response and the merchant will resend, and then build so the resend is harmless. Say "idempotency key" early, tie it to a concrete retry story, and keep authorization separate from the settlement that happens later.