If you interview at a fintech, a marketplace, or anywhere that takes money online, there is a good chance a payments question is coming. Until last week, Sensei had exactly one card on the topic.
That is fixed. Sensei now has 14 payments questions, each built from what interviewers actually ask, with 70 quiz questions to go with them.
What is covered
- Authorization, capture, and settlement. What happens between "Pay" and the money arriving, and why those are three different steps.
- Idempotency and double charges. The classic: a customer taps Pay twice, or a retry fires after a timeout. How do you make sure they are charged once?
- "The request timed out. Did it go through?" One of the best questions in the set, because the honest answer is "you don't know yet," and the interesting part is what you do next.
- Designing a double-entry ledger. Why every serious payments system ends up with debits and credits that always balance.
- Floats versus minor units. A short screener question that still catches people.
- And the rest: reconciliation, webhooks, 3DS2 and SCA, PCI scope, tokenization, declines and retries, interchange, chargebacks, and unattended terminals like parking machines.
Every card follows the Sensei format: a plain concept overview with tables and diagrams, a step-by-step walkthrough, tradeoffs, common mistakes, a spoken sample answer, follow-up questions, whiteboard tips, and the red flags that make an interviewer nervous.
A taste: why money is never a float
Floating-point numbers cannot represent most decimal fractions exactly. Add 0.1 and 0.2 in most languages and you get 0.30000000000000004. That error is tiny once. Across millions of transactions, rounding drift becomes a reconciliation problem nobody can explain.
The standard answer is to store amounts as integers in the currency's minor unit, so $12.34 becomes 1234 cents, and to keep the currency next to every amount. Then comes the follow-up interviewers love: not every currency has two decimal places. The Japanese yen has none, and a few currencies use three. Your design has to know the difference.
A taste: the idempotency key
When a client sends a payment request, it also sends a unique key it generated for that attempt. The server stores the key with the result. If the same key arrives again, because the network dropped the response and the client retried, the server returns the stored result instead of charging a second time.
The follow-ups are where the depth is. What if the retry arrives while the first request is still running? How long do you keep the keys? What if the same key comes back with a different amount? The card walks through each one.
The story behind it
Alongside the questions, Sensei now has a story feed about how payments got the way they are, one card per screen, linked from the questions it explains. Knowing why card networks work the way they do makes the system design answers much easier to reason about.
The payments questions are live now at sensei.igit.space. If you have a fintech loop on the calendar, start with the timeout question.