Design a Payment System
Accept card payments for an e-commerce platform, move money correctly exactly once, and be able to prove it.
3 questions on this site are reported in PayPal software engineer interviews. Each has a full reference design (requirements, back-of-envelope numbers, components, user flows and deep dives with interviewer follow-ups). Each one can be walked through turn by turn and then sat as a mock. Patterns covered: consistency, idempotency, ledger, fintech, sharding, hot-keys, fraud, feature-store, stream-processing, low-latency, exploration.
Run an AI mock PayPal interview →One of these questions, run as a live round in that style, with a debrief at the end.
Attribution comes from public interview guides and candidate reports, not from PayPal. It indicates where a question has been asked, nothing more.
Accept card payments for an e-commerce platform, move money correctly exactly once, and be able to prove it.
80 M users paying friends instantly: 15 M transfers a day on a sharded double-entry ledger, funded and cashed out over slow bank rails.
Allow, block or challenge 10,000 card payments a second in under 100 ms, then learn from chargebacks that arrive months later.
45–60 minutes. Prompts are reported to be either payments-shaped, such as a money transfer flow or fraud checks on a payment, or general product problems such as a reservation system or a shopping cart, and some rounds go down to tables, APIs and locking.
Preparing for only one level of design. Candidates describe rounds that move from a high-level design to tables, APIs and database locks, or that mix high-level and low-level questions in the same hour, so be ready to go from boxes to schema without warning.
From public interview guides and candidate reports, and PayPal’s own interview guidance where it publishes any. Not endorsed by PayPal. Formats change; treat it as a prior, not a promise.
Large-company loops run 45 to 60 minutes, expect numbers, and spend most of the time on deep dives. Walk through a question to see how a strong candidate paces the hour, sit the same question as a mock until you can produce the requirements, the estimates and the design without looking, then read the interview framework guide for how to structure the hour. The other questions on the site teach patterns that show up in PayPal interviews under different names.
Questions reported in PayPal system design interviews include Payment System, Venmo and Fraud Detection System. Between them they test consistency, idempotency, ledger, fintech, sharding and hot keys. The reports come from public interview guides and candidate accounts, not from PayPal, so practise the patterns rather than memorising one list.
45–60 minutes. Prompts are reported to be either payments-shaped, such as a money transfer flow or fraud checks on a payment, or general product problems such as a reservation system or a shopping cart, and some rounds go down to tables, APIs and locking.
Reports say the PayPal round weighs 3 things. 1. Correctness where money moves: retries that cannot charge twice, and no lost or duplicated transactions. 2. A database schema and APIs, with locking where two requests compete for the same rows. 3. Scaling follow-ups: caching, load balancing and how data flows through the system. Preparing for only one level of design. Candidates describe rounds that move from a high-level design to tables, APIs and database locks, or that mix high-level and low-level questions in the same hour, so be ready to go from boxes to schema without warning.
Practise the questions reported there out loud, under a 45-minute clock: requirements with numbers first, then estimates, a high-level design, and deep dives into the two or three hardest parts. Start with Payment System: watch a strong candidate answer it turn by turn, then sit it yourself. Then cover the patterns the round leans on (consistency, idempotency, ledger and fintech) with one more question each.