Loading system design…
Loading system design...
Design a payment processing platform like Stripe that enables merchants to accept online payments via a simple API. The system handles card tokenisation (PCI-compliant), payment authorisation through card networks (Visa/Mastercard), idempotent charge processing, fraud detection, webhook-based event notifications, recurring billing/subscriptions, merchant payouts, and dispute management — all at extreme reliability (99.999% uptime).
| Metric | Value |
|---|---|
| Merchants (businesses) | 3 million |
| Payment volume per year | $1 trillion+ |
| Transactions per day | 50 million |
| Peak transactions per second | 10,000 |
| Webhook events per day | 500 million |
| Subscriptions managed | 100 million |
| Card tokens stored | 2 billion |
| Supported currencies | 135+ |
| Supported payment methods | 50+ |
| Countries | 45+ |
Charge API: merchants submit payment requests (amount, currency, payment method token, idempotency key); system authorises, captures, and settles the payment; returns a charge object with status
Payment method tokenisation: securely collect card details (PAN, expiry, CVV) via client-side SDK; convert to a single-use token that never exposes raw card data to the merchant's server (PCI compliance)
Multi-payment-method support: credit/debit cards, bank transfers (ACH/SEPA), digital wallets (Apple Pay, Google Pay), Buy Now Pay Later (Klarna, Afterpay), UPI, and local payment methods per country
Idempotent processing: guarantee that retrying the same payment request (same idempotency key) does NOT result in a double charge; critical for network failures, timeouts, and retries
Refunds: merchants can issue full or partial refunds on completed charges; refund reverses the money flow from merchant → acquirer → issuing bank → cardholder
Webhooks: send real-time event notifications (charge.succeeded, charge.failed, refund.created, dispute.opened) to merchant-configured HTTPS endpoints with retry and delivery guarantees
Recurring billing / subscriptions: merchants define plans (price, interval: monthly/annual); customers subscribe; system automatically charges on each billing cycle; handle upgrades, downgrades, prorations, and failed payments with retry logic
Merchant payouts: aggregate settled funds and transfer to merchant's bank account on a configurable schedule (daily/weekly/monthly); multi-currency; detailed payout reports with per-charge breakdown
Fraud detection: real-time risk scoring on every transaction using ML; block or flag high-risk payments; rules engine for custom fraud rules per merchant; 3D Secure / SCA for strong customer authentication
Dispute / chargeback management: when a cardholder disputes a charge, notify merchant; merchant submits evidence; system manages the dispute lifecycle with the card network; track win/loss rates
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In