System design interview guide
Design Stripe: System Design Interview Guide
Short answer
Stripe system design is a payments API built for correctness first. Every write request carries an idempotency key, so a retry never charges twice. Card numbers go to a separate vault, and other services see only tokens. Each money movement is written to an append-only double-entry ledger. Merchants hear the result through signed webhooks, retried for up to three days.
Two courses by the author of this page:
770 lessons · 18 free to read
₹1,111 in India · $25 elsewhere, once
Get System DesignYou own this course
214 lessons · 10 free to read
₹1,333 in India · $35 elsewhere, once
Get Generative AI and Agentic AIYou own this course
Save your progress and get the interview checklist PDF
Businesses on Stripe moved $1.9 trillion in 2025, up from $1 trillion in 2023 (Stripe annual letters). Over Black Friday to Cyber Monday 2025, Stripe handled more than 578 million transactions, peaking above 152,000 a minute, with API uptime above 99.9999%. Every one of those charges has to happen exactly once, even when the merchant's request times out and is retried.
Designing Stripe means designing a payment system from the API down to a double-entry ledger. The defining concerns are correctness (charge exactly once), durability (no charge is ever lost), regulatory compliance (PCI DSS scope, KYC), and global reach (multiple currencies and payment methods). It is the canonical system design problem where consistency dominates speed.
Where it shows up
Commonly asked at Stripe, PayPal, Adyen, Square, and any fintech. Also asked at FAANG, especially Amazon (for the order pipeline) and Google (for Google Pay).
Spec sheetStripe
- 01Annual payment volume
- $1.9T (2025)
- 02Transactions per minute (peak)
- 152,000+
- 03API requests per second
- 50K
- 04Database queries per second
- 5M+
worked through below, with the maths
in this guide
Design Stripe, part by part
8 parts open to everyone · 3 with a free account · 3 with the course
You can read 8 of 14 parts. A free account opens the deep dive; the course opens all of it.
- Requirementsopen
- Scale estimatesopen
- High-level architectureopen
- How a Stripe card payment flows, step by stepopen
- Core componentsopen
- Data modelfree account
- Deep dives (7)free account
- Trade-offs to discussfree account
- What the interviewer asks nextwith the course
- The interview scorecardwith the course
- Mock interview on this questionwith the course
- How Stripe actually does itopen
- Frequently asked questionsopen
- Interview readiness checkopen
The hard parts of this design are taught step by step in the System Design course: Idempotency, Saga Pattern and Message Queues.
Why this question is asked
Design Stripe forces you to talk about idempotency seriously, the double-entry ledger, webhook delivery guarantees, PCI scope reduction, fraud signals, and global card network interaction. It is the cleanest test of whether a candidate can design a system where correctness matters more than throughput.
This page is the free part.
The course goes deeper on the Stripe design
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers the Stripe design across a run of lessons, not one page. These 4 alone are about 113 minutes of step-by-step reading, 1 of them with code you run in the browser, all with a quiz.
- Idempotency
Why some operations are safe to retry and others charge you twice, and how to make everything safe.
- Saga Pattern
Long-lived transactions without distributed locking, orchestration vs choreography for microservices.
- Message Queues
Decouple producers from consumers with a buffer that holds messages until they're processed.
- Database Sharding
Splitting a database across multiple servers, the nuclear option for scaling writes, and the architecture behind Instagram, Uber, and YouTube.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
You own this course
Continue with Idempotencypay once,
yours for life
The payment system design series
Every payment system rests on the same few ideas: an idempotency key so a retry never charges twice, a double-entry ledger so no money appears or vanishes, and daily reconciliation against the bank. These guides show those ideas inside real products.
- Design a payment systemStart here: the core pattern every guide below uses
- Design Stripe(this page)Card payments API, idempotency keys, webhooks
- Design RazorpayPayment gateway for India: UPI, cards, settlement
- Design UPIIndia's central payment switch run by NPCI
- Design PayPalWallet, ledger and sagas across services
- Design PaytmUPI app and wallet, the DEEMED state
- Design PhonePeUPI at national scale, sharded MySQL
- Design a digital walletBalances, holds and captures
- Design a banking systemCore banking: ledger, available balance, NEFT/IMPS/RTGS
- Design CREDBill payments driven by order state machines
- Design fraud detectionScoring a payment in milliseconds
Live from the course bench
Before you design Stripe, try the questions it rests on.
Real interview questions, live diagrams and measured lab results, pulled at random from the lessons. A new set every time you come back.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Merchants create charges via REST API or hosted checkout
- Charges are routed to a card network (Visa, Mastercard) or alternative method
- Idempotent retries: the same idempotency key returns the same result, no double charge
- Webhooks fire on every state change (succeeded, failed, refunded)
- Refunds (full and partial) are first-class entities
- Subscriptions: recurring charges with retry and dunning logic
- Multi-currency support and FX conversion
Non-functional requirements
- 99.999% API availability (the famous five nines)
- Exactly-once charge semantics
- PCI DSS Level 1 compliance with minimum scope on merchant side
- Webhook delivery at least once, with no promise of order, so receivers dedupe by event ID (Stripe's documented behaviour)
- Fraud and chargeback detection
- Audit trail for every state transition
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Annual payment volume
$1.9T (2025)
Stripe's 2025 annual letter (24 Feb 2026): $1.9 trillion in total volume, up 34% from 2024. It was $1 trillion in 2023. Used to size ledger storage and reconciliation jobs.
Transactions per minute (peak)
152,000+
Stripe's published Black Friday to Cyber Monday 2025 peak (2 Dec 2025). That is about 2,500 a second. Design the charge path for this, plus headroom.
API requests per second
50K
Interview estimate, not a Stripe figure. Includes reads (charge lookups, customer fetches) and writes. Reads outnumber writes 5:1.
Database queries per second
5M+
Published by Stripe in June 2024: its DocDB database service serves over five million queries a second across more than 2,000 shards.
Ledger events per day
5B
Published by Stripe in February 2024: its Ledger sees five billion events a day, and 99.99% of dollar volume is verified within four days.
Webhooks per day
100M
Interview estimate. Multiple events per charge (succeeded, captured, dispute opened). At-least-once delivery with retries amplifies this further.
Ledger storage per year
5 to 20 TB
Interview estimate. Double-entry rows per charge plus partial refunds and disputes. Append-only and partitioned by time.
High-level architecture
Client (merchant or hosted checkout) calls the Public API. The API Gateway terminates TLS, authenticates the API key, and routes to the appropriate service. The Charge Service is the heart of the system: it validates the request, looks up or creates the customer, dedupes by idempotency key (Redis with strong consistency, falls back to a sharded SQL idempotency_keys table), writes a pending charge to the canonical Postgres store, and submits to the appropriate card network gateway. On network response, the Charge Service updates the charge state, writes corresponding rows to the double-entry Ledger, and emits a state-change event. The Webhook Service consumes events and delivers them to merchant endpoints with at-least-once retry. A Fraud Service runs synchronously on the request path to score and optionally block. A Reconciliation Service runs nightly to compare the ledger against bank statements. Two rules hold the whole design together. A network timeout leaves the charge pending, never failed, until its real status is known. And the ledger rows and the outgoing event are written in one database transaction, through an outbox table, so a crash can never leave a charge that nobody was told about.
In a real interview, sketch this on the whiteboard before diving into any single box.
How a Stripe card payment flows, step by step
One card payment through the design above, from the checkout page to the merchant's bank. The steps follow Stripe's public PaymentIntent API.
- 1
The card goes to Stripe, not to the merchant
The customer types the card into a field served by Stripe (Elements or Checkout). The card number goes to Stripe's vault. The merchant's server only gets a token.
- 2
The merchant creates a payment with an idempotency key
The merchant's server sends POST /v1/payment_intents with an Idempotency-Key header. If the call times out, it retries with the same key.
- 3
Stripe checks the key
A key seen before returns the saved result of the first call, even if that was an error. The same key with different parameters is rejected.
- 4
The charge is saved as pending
The Charge Service writes the payment before calling the card network. If a server dies now, the record survives and a job can finish it.
- 5
Fraud scoring
The Fraud Service scores the payment on the request path and returns allow, review or block before any money moves.
- 6
Authorization through the card network
The request goes through Visa or Mastercard to the customer's bank. If the bank wants 3D Secure, the PaymentIntent moves to requires_action until the customer confirms.
- 7
Result, ledger rows and event in one transaction
On success the status becomes succeeded. Balanced ledger rows and an outbox event are written in the same transaction. A decline sends the PaymentIntent back to requires_payment_method.
- 8
The webhook tells the merchant
Stripe sends payment_intent.succeeded to the merchant's endpoint, signed and retried for up to three days. The merchant fulfils the order from the webhook, not the browser redirect.
- 9
Payout and reconciliation
Card networks settle in batches, and Stripe pays out to the merchant's bank. Reconciliation matches the ledger against network and bank reports.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Public API Gateway
Authenticates API keys, enforces rate limits, validates request schemas, and routes to internal services. Logs every request for audit. Exposes /v1/charges, /v1/customers, /v1/refunds, and so on.
Charge Service
Owns the charge lifecycle. Dedupes by idempotency key. Writes the canonical charge record. Calls the card network gateway. Updates state on response. Emits events.
Idempotency Store
Redis with strong consistency for fast dedup, fallback to a sharded SQL table for durability. Key is the idempotency_key plus API key. Value is the status code and body of the first call, whether it succeeded or failed: Stripe documents that it saves even 500 errors, and rejects a reused key sent with different parameters.
Card Network Gateway
Talks to Visa, Mastercard, and other card networks over ISO 8583 or modern APIs. Handles 3D Secure flows, tokenization, and authorization vs capture distinction.
Ledger Service
Double-entry bookkeeping. Every charge writes two rows: a credit to merchant balance and a debit to customer's card account (in Stripe's books). All rows are append-only.
Webhook Service
Consumes state-change events from a durable queue. Delivers to merchant URLs with HMAC signing. Retries with exponential backoff for up to 3 days. Stripe does not promise delivery order, so each event carries an ID the receiver uses to drop duplicates.
Fraud Service
Synchronous risk scoring on the charge path. Inputs include card history, customer history, IP geolocation, and device fingerprint. Returns a block, review, or allow decision.
Reconciliation Service
Nightly batch job comparing the internal ledger to settlement reports from card networks and partner banks. Flags discrepancies for ops investigation.
Data model
charges. Sharded by merchant_id. Idempotency key is indexed and unique per merchant. State transitions are immutable; new states are appended to a charge_events table.
Every table for Stripe, its keys, and which store fits it and why.
Deep dives
Idempotency: exactly-once on a retry-prone network. The internet is unreliable. A merchant's POST to /v1/charges might time out after the server has already created the charge. If the merchant retries, you cannot create a…
7 deep dives on the parts that break at scale: Idempotency: exactly-once on a retry-prone network; Double-entry ledger and balance correctness; Webhook delivery with at-least-once and ordering.
Trade-offs to discuss
Fulfil the order on the webhook vs on the browser redirect. The redirect back to the merchant's site feels like the natural place to ship. But the customer can close the tab after paying and before the redirect. Stripe's docs…
6 decisions an interviewer expects you to defend, each with the alternative and why it loses here.
What the interviewer asks next
A merchant retries a charge with the same idempotency key 25 hours later, after the key has expired. What stops a double charge?
4 follow-up questions with model answers, the interview scorecard for this question, and a mock interview on Design Stripe with the AI tutor.
How Stripe actually does it
Stripe's API famously prioritizes correctness over speed, and the idempotency key pattern is now an industry standard largely because of Stripe. Here is what Stripe itself has published, with dates. Its API docs say an idempotency key can be up to 255 characters, that the first call's status code and body are saved even when it failed, and that a reused key with different parameters is rejected. Its webhook docs say live-mode events are retried for up to three days with exponential backoff, that order is not guaranteed, and that duplicates can arrive. Its Ledger (described in February 2024) is an immutable double-entry log that sees five billion events a day and verifies 99.99% of dollar volume within four days. Its product applications use DocDB, a database service built on MongoDB Community, which in June 2024 served over five million queries a second across more than 2,000 shards. Card data sits with a PCI Level 1 certified service, and merchants that use Stripe's hosted fields only see tokens. The fraud system, Radar, scores payments using data from across the Stripe network. For scale, Stripe reported $1.9 trillion in total volume for 2025, and a Black Friday 2025 peak above 152,000 transactions a minute with API uptime above 99.9999%. The internal component names in the design above (Charge Service, Webhook Service and so on) are this guide's interview design, not Stripe's published architecture.
Sources
- Stripe API documentation: Idempotent Requests
- Stripe Engineering: Online migrations at scale
- Stripe Engineering: Designing robust and predictable APIs
- Stripe docs: Webhooks, retries and event ordering (read 2026-10-04)
- Stripe docs: Payment status updates (read 2026-10-04)
- Stripe docs: Integration security guide, PCI DSS (read 2026-10-04)
- Stripe: Ledger, Stripe's system for tracking money movement (2024-02-16)
- Stripe: How Stripe's document databases supported 99.999% uptime (2024-06-06)
- Stripe newsroom: Black Friday to Cyber Monday 2025 (2025-12-02)
- Stripe newsroom: 2025 annual letter (2026-02-24)
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Idempotency
foundation / core fundamentals
Saga Pattern
advanced / distributed systems core
Message Queues
intermediate / messaging event systems
Database Sharding
foundation / database fundamentals
Capstone: Design Payment System
capstone / capstone
Idempotency Keys
intermediate / api design protocols
Transactional Outbox Pattern
intermediate / messaging event systems
Idempotent Consumer
intermediate / messaging event systems
Frequently asked questions
interview readiness
Are you ready for Design Stripe?
Three questions from this guide. Answer them without scrolling up, the way you would have to in the room.
Go deeper
This guide is built on these 6 lessons. Each one teaches one piece of the Stripe design above, step by step.
- IdempotencySystem Design · core fundamentals · 28 min
- Saga PatternSystem Design · distributed systems core · 30 min
- Message QueuesSystem Design · messaging event systems · 20 min
- Database ShardingSystem Design · database fundamentals · 35 min
- Design a Payment SystemSystem Design · capstone · 70 min
- Idempotency KeysSystem Design · api design protocols · 18 min
Practice with 770 system design lessons
Lifetime access for ₹1,111 in India or $25 elsewhere. Interactive diagrams, quizzes, and 20 capstone projects to practise on.
This one question is not enough for the interview.
Get all 200 questions in the System Design and Distributed Systems pack
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
NEWSystem Design Hands-On
Included in the System Design course: real systems, built live
Postgres Sharding: Complete Hands-On (PgBouncer + Citus). 2 h 36 min and 20 chapters: one PostgreSQL loaded until it breaks, then four shards behind a router you write, PgBouncer and Citus, with the 139-page slide deck. The first 15 minutes are free to watch.