Payment and Ledger Interview Questions: Coding, OOD and Design

Big-tech loops test payments and ledgers in every round format, so the classic design-a-payment-system whiteboard question is only one of them. As of 2026-10-16, TrueInterview's bank holds 41 candidate-reported payment and ledger questions from 17 big-tech companies, and 35 of them were last reported in the previous 12 months. They split almost evenly: 13 coding, 12 system design and 10 object-oriented design, plus 3 SQL, 2 behavioral or knowledge and 1 AI-assisted coding. Find out which format your target company files the topic under before you choose what to rehearse; the correctness ideas you need (one operation, one ledger effect, records that reconcile) are the same in all of them.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

Which payment and ledger prompts do candidates report most?

Five named prompts carry most of the evidence: Design Payment System, Payment / Coffee-Shop Ordering, Dasher Payment Model, Payment Invoice Reconciliation and Banking System with Payments and Account Merging. They span system design, object-oriented design and coding, and their write-up links come from OpenAI, ByteDance, DoorDash, Stripe, Coinbase and Anthropic. Start your list with them, then add the transactional key-value stores below the line.

The table ranks the most-linked prompts in this family by write-up links. Senior share is the number of links from candidates who reported a senior, staff-plus or manager level themselves.

Read the top of the table as a shopping list, not a frequency chart. The top five are the prompts that enough candidates wrote up to show what the room looks like, and they cover all three formats, so a single whiteboard rehearsal leaves three of the five unprepared.

What each top prompt asks you to get right

Design Payment System is the full design version. Our view: the decision that carries it is where you put the idempotency boundary and how the ledger records one effect per business operation. Rehearse it as a failure walkthrough, not a component diagram.

Payment / Coffee-Shop Ordering is filed as system design at OpenAI, and its title warns you to read the prompt. Our view: treat the ordering flow as the scope and the money movement as the correctness constraint, because a generic gateway diagram answers a different question.

Dasher Payment Model is an object-oriented build. Our view, inferred from the title and format: aim for clean entities (the courier, the delivery, the pay rule) and a calculation you can extend without rewriting, written as working code.

Payment Invoice Reconciliation is a coding question, and TrueInterview lists it as high frequency, medium difficulty, tagged payment, simulation and string. Its tags suggest parsing and a careful simulation of matching rules; in our view, input-format edge cases are the likely trap rather than an algorithmic trick.

Banking System with Payments and Account Merging is an object-oriented simulation. Merging accounts forces you to decide what happens to balances and history, which is the same audit question a ledger asks.

Which companies ask them, and in which format?

Stripe files the most (13), followed by Coinbase (7), DoorDash (5), OpenAI (4) and Lyft (3); Anthropic, Instacart, Airbnb, Google and Robinhood each file 2. The format changes completely by company, which is the single most useful fact for narrowing your preparation.

The heatmap overturns the usual advice. Most guides prepare you for a whiteboard, yet Lyft's and Anthropic's reported prompts are all object-oriented design, and Stripe's lean to coding. Stripe still has system design questions on file, so a Stripe loop needs one design rehearsal, not zero.

Our take: check the company's format before you choose material. These are small samples of candidate-reported questions (three at Lyft, four at OpenAI), so read them as a lean, not a format policy; still, a Lyft loop rewards object models over whiteboard time, and an OpenAI loop the reverse.

Does your level predict which format you get?

Level and format move together in the reports, though that is a correlation, not proof. Across all these prompts, write-up links split 81 from candidates who reported a senior, staff-plus or manager level and 47 from those who reported junior, new-grad or intern. By format, system design is 47 against 5, coding 15 against 19, and object-oriented design 19 against 23.

Levels here are what candidates reported about themselves, so treat them as a strong lean, not a rule. Design Payment System draws 23 of its 27 links from senior-or-above candidates, and Payment / Coffee-Shop Ordering 15 of 16. Those two prompts supply most of the senior design links, so the lean rests on them. Dasher Payment Model goes the other way, with 9 of its 15 links from junior-or-below.

Our take: if you are interviewing at senior level, the design version is your core rehearsal, and the implementation prompts are where you protect the screen. If you are junior-or-below, put your hours into working implementations; the whiteboard version is the less likely draw.

Which rounds bring the small implementation versions?

In the examples above, most phone-screen reports are implementation prompts, though onsites carry more reports overall. The reported rounds are onsite 26, phone screen 16 and OA 4, and one question can appear in more than one round. Most phone-screen examples in the table are implementation prompts: Dasher Payment Model, Payment Invoice Reconciliation, Design Key-Value Store with Transactions and the Google invoice-matching prompt. The exception is OpenAI's coffee-shop ordering prompt, a system design question reported in a phone screen.

In our view, design-first preparation leaves these phone-screen implementation prompts under-practised. Practise these prompts with code that compiles and passes your own tests, and answer them in object or algorithm terms; sharding and message brokers have no place in a forty-five-minute implementation.

Onsites carry both shapes. Anthropic's banking-system simulation and Lyft's transactional key-value store are onsite object-oriented prompts, while ByteDance's Design Payment System is an onsite design round, as the table shows.

What do interviewers push on in the payment system design?

Correctness under failure, not throughput. The Pragmatic Engineer chapter's sample dialogue sets a scale of 1 million transactions per day and says "the focus of this system design interview is on how to correctly handle payment transactions, rather than aiming for high throughput." That is a book example, not a candidate report; we expect the same emphasis in the senior-heavy design prompts above, and that expectation is our view.

The Pragmatic Engineer chapter says its sample interviewer makes reconciliation an explicit requirement. PracHub's guide frames the test as whether retries, duplicate callbacks and settlement mismatches end in one business operation with a record you can verify. Hello Interview's breakdown says the design needs durability and auditability with no transaction data lost during failures, and for financial integrity despite asynchronous external payment networks.

These are the deciding questions to prepare. Each is our view of what a senior interviewer will press on, built from the sources above.

• Our view: what is your unit of "once"? Name the business operation the idempotency key protects and show where the uniqueness constraint lives. If you cannot point to it, the rest of the design has no anchor.
• Our view: what happens after a timeout? Walk the lost-response case before anyone asks. The section below gives the sourced answer.
• Our view: what proves the books are right? Say which invariants you check beyond balance, and what reconciliation compares against.
• Our view: what is out of scope? Hello Interview's breakdown lists merchant-initiated charges and status updates as core and places refunds below the line. Agree on that line early, and ask whether payouts are in scope; System Design Handbook's guide says many candidates forget the disbursement side.

The System Design Handbook guide also calls choosing databases before defining scope a red flag. Our view is that the senior signal sits in the failure walkthrough. A design that shards at a scale the prompt never asked for spends the interviewer's time on the part they did not ask about.

How should you handle a charge whose outcome is unknown?

Treat it as unknown, recover it under the same identity, and never retry it as a new charge. Stripe's engineering blog states the stakes plainly: "accidentally calling it twice would lead to the customer being double-charged, which is very bad." The idempotency key is the contract that prevents it, and the follow-ups test whether you know its edges.

Stripe's blog describes the mechanism: the client generates a unique ID per operation and sends it with the payload, and when the call succeeded but the response was lost, the server replies with the cached result. Stripe's API documentation adds two edges that a senior answer should name. Stripe's documentation says its idempotency layer compares a retry's parameters with the original and errors if they differ, and a key reused after the original has been pruned is treated as a new request.

PracHub's guide supplies the failure to rehearse. PracHub's guide says a timeout shows only that the caller has no result, not that the provider rejected the charge, so in PracHub's guide, marking the attempt Failed and retrying with a new provider key can charge the customer again. PracHub's guide also says concurrent arrivals with one key must contend on one record, and that no ordinary local transaction commits both your database and an external processor.

Our view: draw the crash boundary between the moment the provider charged and the moment you recorded it, and give the recovery path a name, an owner and a state. For retries, Stripe's blog recommends exponential backoff with random jitter to avoid the thundering herd; mention it in one sentence and move on.

What does a balanced ledger fail to prove?

Correctness. PracHub's guide points out that a duplicated or misdirected journal can still balance, so a double-entry ledger is a necessary structure, not evidence that the money is right. Our view: follow-ups on corrections and currency scale are where a ledger answer gets tested.

Three points make a senior ledger answer. Store amounts as integer minor units with an explicit currency scale, as PracHub's guide advises. Correct mistakes with reversal and replacement entries linked to the original, never by editing history, per the same guide. Reconcile against the outside world: System Design Handbook's guide describes comparing internal logs against bank settlement reports and flagging discrepancies for manual or automated correction. Stripe's PaymentIntents documentation notes that attaching an order ID as metadata lets you reconcile Stripe payments to your own orders.

Our view: state at least one invariant beyond balance, such as one capture posting per business reference, and say who owns an unexplained difference. Name the reconciliation report you compare against and how often it runs.

Which adjacent questions belong in the same prep set?

Transactional key-value stores and transaction-log processing. They test the same commit, rollback and audit reasoning as payments, and they show up in the same loops: Design Key-Value Store with Transactions and Transactional Key-Value Store at Lyft and Snowflake, and Transaction Logs Trigger / Resolve at Stripe, all ranked in the table above.

Two transaction-flavoured coding prompts sit at the edge of the family. Compute Stock Profit with One or Unlimited Transactions was reported in a Meta onsite in 2026-08, and Maximize block fee with transaction selection in a Coinbase onsite in 2026-02. The first is a single pass that tracks the minimum price, or a greedy sum of gains for the unlimited case; the second is a selection problem under a capacity limit. Practise them as coding, not as design.

Our take: implement nested begin, commit and rollback until you get them right the first time. It makes the ledger and idempotency ideas concrete, and it covers the Lyft and Snowflake key-value store prompts at once; treat the Stripe transaction-log prompt as its own exercise.

What changes at senior and staff level?

The design version becomes the default draw, and its depth carries the level signal. Prompts linked from staff-plus or manager write-ups include Design Key-Value Store with Transactions and Design a Scalable Idempotent Ledger Service, one link each. That is a thin signal, and in our view both put transactional correctness at the centre.

Our view: at senior and staff level, expect to defend idempotency and ledger invariants under failure, and to explain why you chose each boundary. Staff candidates should add the operating view: who is paged when reconciliation finds a difference, and how a correction is reviewed.

Down-leveling note (our view): the level signal in a loop with a payments prompt sits in the design round's failure depth and in the scope you set in the first minutes. A senior candidate who answers the design version with a component tour and no lost-response walkthrough gives the panel a mid-level reading, even with a clean coding round.

Our take

Prepare payments as a domain across formats, then weight by company and level. The bank shows the topic split across coding, object-oriented design and system design at roughly equal counts, so the generic advice of one whiteboard rehearsal covers about a third of what candidates actually report.

Pick the winners for your loop. For OpenAI or ByteDance at senior level, rehearse Design Payment System end to end and spend most of the time on failure, idempotency and reconciliation. For Stripe, weight timed coding: Payment Invoice Reconciliation, Processing Invoices and Payments, which TrueInterview lists as a Stripe coding question, and the transaction-log prompt, with one design rehearsal kept in reserve. For Lyft, Anthropic, Coinbase, or any loop at junior level, build working object models first.

A worked example: a senior engineer with loops at Stripe and DoorDash. Stripe's typed prompts lean to coding and its invoice-reconciliation prompt sits in the phone screen, so week one is timed coding. DoorDash files mostly system design, and Handle Upstream Failures in a Payment-Calculation Service sits in the family list, so week two pairs the Dasher Payment Model build with a design rehearsal of that prompt, centred on the call that times out with an unknown outcome.

How we counted

We counted questions in TrueInterview's bank filed under the payments and ledger family as of 2026-10-16, with each question's company, format, round and last reported month. Write-up links count candidate interview write-ups that link a question, and levels are what those candidates reported about themselves. These are candidate-reported questions reconstructed for practice, not any company's official list, and counts measure what candidates wrote up, not how often a company asks.

FAQ

How do you design a payment system like Stripe in an interview?

Agree on scope first: who initiates a charge, which statuses the merchant sees, whether refunds and payouts are in. Then spend most of the time on failure. Walk the timeout with an unknown outcome, show where the idempotency key is enforced and what happens when its parameters change, and explain how the ledger and reconciliation prove one effect per operation. Throughput matters less than correctness here, as the sections above argue.

Is the payment question a system design, coding or OOD round?

It depends on the company and your level more than on the topic. Use the company table above: OpenAI's reported prompts are all design, Lyft's and Anthropic's are all object-oriented, and Stripe's lean to coding. In self-reported levels, senior candidates lean strongly toward the design version, while junior candidates lean toward implementation prompts; that is a lean, not a rule.

Does an idempotency key alone prevent double charges?

No. It prevents a duplicate only when the retry carries the same key, the parameters match, and the key is still retained by the provider. The dangerous case is a timeout that you misread as a failure and retry under a new key. Recover the attempt under its original identity, and keep your own durable record of the operation rather than relying on the provider's retention window.

What is a double-entry ledger, and why do interviewers ask about it?

It records every money movement as balanced debits and credits across accounts, so the books can be audited. Interviewers ask about it because it shows whether you think about money as history rather than as a mutable balance. Expect follow-ups on corrections, currency handling and what balance does not prove, all covered in the ledger section above.

What do junior candidates get asked compared with senior candidates?

In self-reported levels, junior-or-below candidates lean toward implementation prompts: object-oriented models such as Dasher Payment Model and coding prompts such as invoice reconciliation. Senior-or-above candidates account for nearly all the design links. Start with Dasher Payment Model if you are junior, or Design Payment System if you are senior, then add the other format.

Your practice plan

A three-week plan for someone working full time, about an hour on weekdays and a longer block at the weekend.

1. Week one, days one and two: find your target companies in the company table and decide which format you are preparing for.
2. Week one, rest of the week: solve Payment Invoice Reconciliation and Match payments to invoices by memo or amount under a forty-five-minute timer, with working code and your own edge-case tests.
3. Week one, weekend: build the Dasher Payment Model as a clean object model, then extend it with a new pay rule without rewriting the core.
4. Week two, weekdays: implement nested begin, commit and rollback in Transactional Key-Value Store, then attempt Transaction Logs Trigger / Resolve under a timer.
5. Week two, weekend: write a one-page failure script for Design Payment System: the timeout with an unknown outcome, the key with a parameter check, the duplicate webhook, and reconciliation against the settlement report.
6. Week three, weekdays: rehearse the design aloud twice, then do Design a Scalable Idempotent Ledger Service and state one ledger invariant beyond balance.
7. Week three, weekend: run one full mock of whichever format your target company files most, and fix the single weakest step before the real loop.

Sources

• TrueInterview question bank — payments and ledger at big-tech companies — counted 2026-10-16
• Coding Interview Questions by Company · TrueInterview — checked 2026-10-16
• Designing a Payment System - by Gergely Orosz — checked 2026-10-16
• Payment System Design Interview Guide: Idempotency, Ledgering, and Reconciliation | PracHub Knowledge Hub — checked 2026-10-16
• Design a Payment System like Stripe | Hello Interview System Design in a Hurry — checked 2026-10-16
• Design a Payment System: A Complete Guide (Updated 2026) — checked 2026-10-16
• Designing robust and predictable APIs with idempotency — checked 2026-10-16
• Idempotent requests | Stripe API Reference — checked 2026-10-16
• The Payment Intents API | Stripe Documentation — checked 2026-10-16

Last reviewed: 2026-10-16.