Design a Merchant Payout System
Design a payment system that can accept 10,000 transactions per second of incoming payments and periodically pay out merchants based on their accumulated earnings.
Asked at:
Stripe
Wise
A merchant payout system is a payment platform, like Stripe or Adyen, that accepts customer payments at very high throughput and periodically transfers accumulated funds to merchants’ bank accounts. Users pay via cards or bank transfers; merchants track balances, refunds, and then receive payouts on a schedule (daily/weekly) with statements. Interviewers ask this to test how you blend high-scale ingestion (10k TPS) with financial correctness: idempotency, ledgering, reconciliation, and safe interaction with external banking rails. They’re looking for your ability to separate real-time payment capture from batch-like payout workflows, handle contention on balances, and design for durability, backpressure, and auditability without compromising latency. Expect to justify partitioning, exactly-once semantics strategies, and failure handling across multi-step processes.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to submit and complete payments to merchants at up to 10,000 transactions per second.
Merchants should be able to view their real-time available balance, transaction history, refunds, and fees.
Merchants should be able to configure payout preferences (schedule, destination account, currency) and receive periodic payouts with statements.
Merchants should be able to have adjustments (refunds, chargebacks, disputes, fees) correctly reflected in balances and future payouts.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
High write rates plus network retries make duplicate requests and spikes inevitable. Interviewers want to see durable buffering, idempotency keys, and a plan for smoothing bursts without losing data or blocking the API. - Consider putting an API gateway in front of stateless payment frontends that validate idempotency keys and enqueue requests to a durable log (for example, Kafka) to decouple accept path from processing. This lets you absorb spikes and keep tail latencies predictable. - You could use an outbox pattern from your payment processor service to Kafka to avoid dual-write anomalies when persisting the ledger and publishing events. Make idempotency keys first-class and dedupe with conditional writes. - Plan explicit backpressure: per-tenant throttles, queue depth alarms, and load-shedding for non-critical paths. Separate synchronous steps (auth) from asynchronous steps (capture/settlement) to keep the hot path fast.
This is where many designs fail. If you increment a single balance row per merchant, popular merchants become hotspots. Interviewers expect an append-only ledger and safe aggregation strategy. - Model money with an immutable, double-entry ledger: one entry for the merchant’s account and a corresponding entry for a platform/clearing account. Derive balances by summing, then periodically create balance snapshots to speed reads. - Partition by merchant (and possibly by time) so writes spread evenly. Avoid hot counters; use conditional writes or sharded counters if you need real-time available balance updates. - Use idempotent ledger writes keyed by payment_id and adjustment_id. Recompute or compact into snapshots offline so you can scale reads without sacrificing correctness.
Payouts are multi-step workflows that cross trust boundaries (ACH/wires). Interviewers look for sagas/workflows, retries, and idempotent side effects so that money moves once, even if services crash. - Treat payouts as a saga: lock the payout window, compute eligible balance, create a payout instruction, submit to the payment rail, and finalize when confirmation arrives. Store state transitions durably and make each step idempotent. - Use per-merchant workflow instances to isolate failures. Add retry with exponential backoff and a dead-letter queue for manual review when bank APIs misbehave. - Generate idempotency tokens for external transfers and reconcile confirmations asynchronously. Never block your ingestion path on payout processing.
Financial systems must prove where every cent went. Interviewers expect an auditable ledger, automated reconciliation against providers/banks, and the ability to repair state without data loss. - Keep an immutable ledger with full lineage (who/when/why) and store external reference IDs from card networks/banks. Build daily reconciliation jobs to compare internal totals with processor and bank statements. - Support compensating entries (not in-place edits) for refunds, disputes, and fee adjustments, so history is consistent and auditable. - Design backfills: if late events arrive, write them to the ledger, re-run balance snapshots or materialized views, and regenerate statements. Alert on drift beyond thresholds.
Relevant Patterns
Relevant patterns that you should know for this question
The system must accept 10k TPS of incoming payments and persist a ledger for every transaction. Separating accept path from processing, using append-only storage, and partitioning by merchant/time are core write-scaling moves interviewers expect.
Popular merchants create hotspots if you increment a single balance row. Using per-merchant partitions, sharded counters, snapshots, and append-only ledgers avoids hot rows and lost updates while keeping balances accurate.
Payouts cross multiple services and external banking rails. Modeling payouts as sagas with idempotent steps, retries, and compensations ensures correctness despite partial failures and makes the workflow explainable in interviews.
Relevant Technologies
Relevant technologies that could be used to solve this question
Similar Problems to Practice
Related problems to practice for this question
Both require high-throughput payment ingestion, idempotency, fraud/authorization steps, and a durable ledger. The payout system adds periodic settlement, but the ingestion and correctness concerns are shared.
Both aggregate a firehose of events into per-entity totals (merchant balances vs. campaign spend). They share partitioning, write-scaling, and snapshot/materialization techniques to avoid hot keys.
Payouts are scheduled, stateful workflows with retries and failure handling, akin to distributed job orchestration. Reliable execution, idempotence, and observability patterns transfer directly.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Updating a single mutable balance row per merchant for each payment
This creates hot-row contention and lost updates at 10k TPS. It undermines correctness and scalability. An append-only ledger with snapshots or sharded counters is the safer, auditable approach.
Assuming exactly-once delivery and skipping idempotency
Networks and clients retry; duplicates will happen. Without idempotency keys and conditional writes, you risk double charges or double payouts, which is catastrophic in financial systems.
Running payouts as a single monolithic batch without workflow state and retries
External bank APIs fail and time out. Without a saga/workflow, idempotent steps, and compensation, partial failures lead to stuck money, inconsistent records, and painful manual recoveries.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late September, 2025
Wise
Staff
Design a real-time currency conversion system that powers YouPay's global money transfer platform.
Late January, 2025
Stripe
Manager
Design a payment system to periodically pay out merchants after ensuring you accept 10k TPS of incoming payments.
Mid May, 2024
Stripe
Senior
Your account is free and you can post anonymously if you choose.