What's the scale - charges/sec, peak Black-Friday burst, total dollar volume?

10K charges/sec steady, 100K charges/sec Black Friday peak. 100M charges/day. 7-year retention = ~250B charge records. Multi-region active-active for resilience.

What's the latency budget for a card auth - p99 < 2s typical (network round-trip to Visa/Mastercard dominates).

Charge p99 < 3s end-to-end (processor round-trip is 1-2s of this; everything else must fit in <1s). Refund p99 < 2s. Webhook delivery p99 < 30s after the underlying state change.

gitGood.dev

Payments

Design a Payments / Checkout System (Stripe-style)

Hard Premium

Idempotency keys, double-spend prevention, the ledger model, and why eventual consistency is wrong for balances. The interview where ambiguity costs you money.

The problem

Design a payments backend that accepts charge requests, talks to one or more payment processors (card networks, ACH, wallets), records the result in a durable ledger, and exposes status to callers via API responses and webhooks. Support refunds, partial refunds, retries on transient processor errors, and reconciliation against processor settlements.

This problem is graded on correctness obsession, not throughput. Strong candidates open with the two failure modes that ruin a payments system - duplicate charges and lost charges - and design every component to make each impossible. Weak candidates focus on scale and miss the actual interview signal.

Clarifying questions

Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.

→Are we the merchant of record (Stripe) or the merchant (Shopify checkout integrating Stripe)? The trust boundary changes everything.
→Which payment methods - cards only, ACH/SEPA, wallets (Apple/Google Pay), BNPL, crypto? Each has different async vs sync semantics.
→What's the scale - charges/sec, peak Black-Friday burst, total dollar volume?
→What's the latency budget for a card auth - p99 < 2s typical (network round-trip to Visa/Mastercard dominates).
→Is full PCI scope acceptable, or must card data never touch our servers (tokenization required)?
→Multi-currency? Multi-region? Cross-border settlement?
→What's the dispute / chargeback flow - automated, manual review, or hybrid?
→How long do we need to store transaction history - 7 years (financial retention) is the usual answer.

Requirements

Functional requirements

·POST /charges - accept a charge request with idempotency key, return charge_id + status (succeeded / pending / failed)
·POST /charges/{id}/refunds - full or partial refund of a captured charge
·GET /charges/{id} - retrieve current status
·Webhooks delivered to merchant on terminal state changes (charge.succeeded, charge.refunded, charge.disputed)
·Async settlement: nightly batch reconciles processor reports against our ledger
·Support for auth + capture (two-step) and auth+capture (one-step)

Non-functional requirements

Scale: 10K charges/sec steady, 100K charges/sec Black Friday peak. 100M charges/day. 7-year retention = ~250B charge records. Multi-region active-active for resilience.
Latency: Charge p99 < 3s end-to-end (processor round-trip is 1-2s of this; everything else must fit in <1s). Refund p99 < 2s. Webhook delivery p99 < 30s after the underlying state change.
Availability: 99.99% for the charge API. A 30-minute outage during a flash sale costs the merchant millions and ends contracts. The ledger and idempotency store must be more available than the API.
Consistency: Strongly consistent for balance, charge state, and idempotency. A charge either happened or it didn't - no eventually-consistent maybe. Reporting and analytics can be eventually consistent, but the source-of-truth ledger cannot.

The full walkthrough covers

Architecture components

·API Gateway
·Tokenization service (PCI-isolated)
·Idempotency service
·Charge orchestrator
·Ledger service
·Processor adapter pool
·Webhook delivery service
·Reconciliation pipeline
·Fraud scoring service

Deep dives

Idempotency: the foundation everything else stands on
Double-spend prevention and the ledger
The split-brain failure: processor said yes, we crashed
PCI scope reduction and tokenization
Webhooks: at-least-once with the merchant's pain in mind
Async vs sync flows: cards vs ACH vs BNPL
Refunds, disputes, and reversal accounting

What's in the full walkthrough

Capacity estimation · architecture with all 9 components explained · 7 deep dives · trade-off analysis · 8 common follow-up questions

Subscribe to Continue

Get full access to gitGood.dev with a subscription.

Start Your 10-Day Trial

Try everything free for 10 days. Cancel anytime.

1,950+ practice questions
AI mock interviews (3/day)
Coding challenges with real execution
Verified skill badges
146 certification guides, 26 with practice exams

View Plans

10-day trial, then $5/mo - or $40/yr ($3.33/mo, save 33%). Cancel anytime.

Companies that test this topic

Senior Software Engineer

Practice in interview format

Reading is the floor. The interview signal is in walking through this live with someone probing follow-ups. Use the AI mock interview to practice talking through requirements, architecture, and trade-offs out loud.

Start an AI mock interview →