Credit Card Processing System
COMMONCredit card processing is asked at every fintech and major tech company because it tests exactly-once guarantees, distributed state machines, and financial data integrity. It is how Stripe processes 250M API requests per day across millions of merchants. You will design a payment gateway handling 10K transactions per second where a network timeout mid-charge must never result in a double charge or lost payment, using idempotency keys, a 5-state payment machine, and a double-entry ledger.
- Guarantee exactly-once payment processing with idempotency keys
- Design a 5-state payment machine that prevents double charges
- Build a double-entry ledger where every cent is accounted twice
Visual Solutions
Step-by-step animated walkthroughs with capacity estimation, API design, database schema, and failure modes built in.
Cheat Sheet
Key concepts, trade-offs, and quick-reference notes for Payment Processing. Everything you need at a glance.
Anti-Patterns
Common design mistakes candidates make. Wrong approaches vs correct approaches for each trap.
Failure Modes
What breaks in production, how to detect it, and how to fix it. Detection metrics, mitigations, and severity ratings.
Start simple. Build to staff-level.
“I would design a credit card processing system for 50M merchants handling 10K TPS at peak. Each transaction flows through a 5-state machine with an idempotency key enforced by a PostgreSQL UNIQUE constraint for exactly-once processing. Per-transaction storage is 900 bytes across 432M daily transactions, totaling 389 GB/day. A double-entry ledger records every state change. Card network calls use 2-second timeouts with T+1 reconciliation for ambiguous responses. Webhooks retry via exponential backoff and a dead letter queue. 99.99% availability, zero double charges.”
Idempotency Keys
STANDARDPostgreSQL UNIQUE constraint on (merchant_id, idempotency_key) in one ACID transaction. Makes double-insert physically impossible. 2ms overhead per request.
Core Feature DesignPayment State Machine
STANDARD5 states (pending, authorized, captured, settled, failed) with forward-only transitions. Each change logged in append-only ledger. 7-day capture window.
Core Feature DesignTokenization (PCI-DSS)
EASYRaw PANs replaced with tokens at the edge. Dedicated token vault in isolated VPC. Reduces PCI audit scope from hundreds of servers to one vault.
High Level DesignTwo-Phase Capture
STANDARDAuthorize (hold) then capture (move money) within 7 days. Hotels, e-commerce, restaurants. Partial capture allowed. Avoids refund delays.
Core Feature DesignDouble-Entry Ledger
TRICKYEvery txn creates 2 entries: debit + credit. Append-only, no UPDATE/DELETE. 864M rows/day. Refunds are new entries, not reversals. Sum debits = sum credits always.
Database SchemaWebhook Delivery with Retry
STANDARD1.3B webhooks/day via Kafka. Exponential backoff (1m, 5m, 30m, 2h, 24h). DLQ after 5 retries. HMAC-SHA256 signature. At-least-once delivery.
Replication and Fault ToleranceCard Network Routing
EASYMerchant -> acquirer -> card network (Visa/MC) -> issuing bank. 2-second timeout. On timeout: mark unknown, reconcile T+1. Never retry a timed-out charge.
High Level DesignReconciliation & Settlement
TRICKYT+1 settlement file from card network. Line-by-line comparison against ledger. 389 GB/run across 50 workers. Settlement at T+2/T+3. Zero-delta target.
Replication and Fault Tolerance